目錄
- 一個愈來愈明顯的落差
- Agent = Model + Harness
- 從提示詞到環境：三個階段的演進
- Anthropic 的實驗：9 美元與 200 美元的差距
- OpenAI 的實戰：五個月、零行手寫程式碼
- 反方觀點：這些鷹架不會被模型吃掉嗎
- 對企業的意義：競爭力不在模型，在模型周圍
- 結語
一個愈來愈明顯的落差
過去一年，AI 模型的升級速度沒有慢下來。推理更強、context window 更長、工具使用更穩定，每一次改版的評測分數都在往上走。
但很多企業心裡有另一種感受：模型明明變強了，自己的 AI 應用卻好像卡在原地。同樣的任務，AI 有時做得漂亮，有時做到一半就宣稱完成；上個月調好的流程，這個月換了情境又不靈了。於是結論常常變成「AI 還不夠成熟，再等等」。
國外的工程社群在 2025 年底到 2026 年給出了另一種解釋：問題往往不在模型，而在模型「周圍」的東西。這個「周圍」，現在有了名字——harness。
Agent = Model + Harness
Harness 原意是馬具、韁繩，在工程領域指的是「連接、保護、協調各個元件，但本身不做工的那一層」。放到 AI 的脈絡裡，harness 是模型周圍所有讓它能有效工作的系統層：任務怎麼啟動、有哪些工具可用、context 怎麼管理、進度怎麼交接、權限開到哪裡、成果由誰驗收。業界現在有一條愈來愈常被引用的公式：
Agent = Model + Harness
同一顆模型，放進不同的 harness，表現可以是天壤之別。這也解釋了前面那個落差：模型升級是模型供應商的事，harness 卻是每一家企業自己的事。模型在進步，harness 沒跟上，整體體驗就停在原地。
「Harness Engineering」這個詞，由 HashiCorp 共同創辦人 Mitchell Hashimoto 在 2026 年 2 月的文章〈My AI Adoption Journey〉中定名。他給了一個很務實的操作型定義：每當 AI 犯錯，不要急著重寫提示詞，而是在 AI 的工作環境裡做一次永久性的工程修復，讓同一類錯誤在結構上不可能再發生。
這句話值得多讀一次。它描述的是兩種完全不同的工作方式：一種是每次出錯就修一次話術，錯誤永遠會換個形式回來；另一種是把修正沉澱進環境本身，錯誤修一次就不再發生。前者是消耗，後者是累積。
從提示詞到環境：三個階段的演進
Harness engineering 不是憑空冒出來的，它是三年演進的第三站。
第一站是 prompt engineering（2023 到 2024 年）：琢磨單次指令的措辭，讓模型一次回答得更好。這是多數企業認識 AI 的起點，也是許多企業目前所在的位置。
第二站是 context engineering（2025 年）：Anthropic 在〈Effective context engineering for AI agents〉中定調——重點不再是一句指令怎麼寫，而是每一步進入 context window 的資訊組合怎麼管理。他們的說法是，模型跟人一樣有「注意力預算」，塞進去的每一個 token 都在消耗這個預算，所以好的 context 工程是「找到最小而訊號最強的 token 組合」。
第三站就是 harness engineering（2025 年下半至今）：當任務從單輪問答延伸到數小時、數天、跨越多個 context window 的長程工作，光管理單次的資訊組合已經不夠，需要設計的是整個環境與迴圈——初始化、進度交接、驗證機制、權限邊界、可觀測性。
Anthropic 在〈Effective harnesses for long-running agents〉裡一句話點出了核心難題：長程任務的 AI 必須分段工作，而每個新的工作階段開始時，對先前發生的事一無所知。怎麼讓一個「每次上工都失憶」的聰明員工把長期專案做完？答案不在提示詞裡，在環境裡。
Anthropic 的實驗：9 美元與 200 美元的差距
Anthropic 在 2025 年 11 月與 2026 年 3 月發表了兩篇工程文章，記錄他們讓 AI Agent 獨立完成長程開發任務的實驗，其中的失敗模式對任何導入 AI 的企業都很有參考價值。
沒有 harness 的 agent 會怎麼失敗？他們觀察到三種典型：想一口氣做完所有事，context 用盡時功能只做了一半、也沒留下任何交接文件；後期接手的 agent 看到已有進度，就提早宣告整個專案完成；以及最危險的一種——沒有經過測試，就把功能標記為「已完成」。
解法聽起來一點都不炫：讓一個 agent 先把環境建好（啟動腳本、進度日誌、版本控制、一份兩百多項全部預設「未通過」的功能清單），後續每個 agent 每次只做一件事，開工先讀進度、收工必須留下紀錄。Anthropic 自己說，這些做法的靈感直接來自「高效軟體工程師每天在做的事」——交接文件、版本控制、測試紀律。Harness engineering 的本質，是把人類的工作紀律工程化到 AI 的環境裡。
第二篇文章補上了一個更關鍵的發現：AI 給自己的工作打分數，必然過度樂觀。原文寫得很直白——被要求評估自己產出時，agent 傾向自信地稱讚那份工作，即使在人類看來品質明顯平庸。所以他們把「做事的 agent」和「驗收的 agent」徹底分開，互相制衡。
這篇文章還留下了一組值得記住的數字。同一個任務（開發一套小型應用），單一 agent 跑了 20 分鐘、花費 9 美元，核心功能是壞的；完整 harness 跑了 6 小時、花費 200 美元，功能可用。成本高出二十多倍，但前者交出的東西不能用，後者可以。對企業來說，這組數字的意義是：AI 的成本不該用「便宜」衡量，該用「交付」衡量。
OpenAI 的實戰：五個月、零行手寫程式碼
有趣的是，Anthropic 的競爭對手給出了幾乎相同的答案。OpenAI 的 Codex 團隊在 2026 年 2 月發表〈Harness engineering: leveraging Codex in an agent-first world〉，記錄三位工程師在五個月內、沒有手寫任何一行程式碼的情況下，靠 AI Agent 完成了上百萬行程式碼、約 1,500 個 PR 的系統。
他們把新的分工濃縮成四個字：Humans steer. Agents execute.（人類掌舵，agent 執行。）工程師的工作變成設計環境、明確表達意圖、建立回饋迴圈。而他們回顧進度緩慢的時期，原因從來不是模型不夠力，而是「環境定義得不夠清楚」。
這篇文章有兩個觀察對企業特別有感。第一，給 AI 的指示文件應該是地圖，不是千頁的說明書——巨型的指令文件會排擠當下任務的注意力、瞬間過時、且無從驗證，不如給一個結構清楚的目錄，讓 AI 需要什麼再去讀什麼。第二，他們提出了「agent legibility」（對 agent 的可讀性）這個概念：從 agent 的視角看，執行時拿不到的資訊，等於不存在。 藏在通訊軟體對話裡的共識、只存在某人腦中的規則、散落在會議裡沒被記錄的決策——這些對 AI 都是不存在的。想讓 AI 做好工作，第一步是把知識放到它看得見的地方。
反方觀點：這些鷹架不會被模型吃掉嗎
Harness engineering 並非沒有爭議，而且提出質疑的人分量十足。
Claude Code 的創造者 Boris Cherny 就說過，所有的秘方都在模型裡，Claude Code 只是「罩在模型上最薄的一層包裝」，而且這層包裝隨著模型進步愈改愈簡單。OpenAI 的 Noam Brown 則是「Bitter Lesson」立場的代表：這些鷹架，終將被愈來愈強的推理模型直接取代。翻成白話：你現在辛苦搭的 harness，可能下一代模型出來就不需要了。
這個提醒是對的，但結論不是「所以不用做」。Anthropic 自己給出了目前最好的調和論述：harness 裡的每一個元件，都隱含著一個「模型自己做不到」的假設，而這些假設會隨模型進步而過時，所以要定期檢驗、拆掉不再必要的鷹架。但他們同時強調——值得探索的 harness 空間不會因為模型變強而縮小，它只會移動。模型吃掉舊的鷹架，新的協作方式又會打開新的設計空間。
對企業來說，這代表 harness 是一種需要「維運」的資產：模型每次大改版，都值得重新體檢一次自己的 harness，該拆的拆、該留的留。過度投資即將被模型吸收的鷹架是浪費，但因為害怕過時而什麼都不建，等於把「AI 用不起來」的現狀再延長一年。
對企業的意義：競爭力不在模型，在模型周圍
把這些線索收攏，可以得到一個對企業相當關鍵的推論：模型人人租得到，harness 卻是各家自己的。
你的同業用的很可能是同一顆模型。真正拉開差距的，是模型周圍那一圈屬於你們公司的東西——工作流程有沒有被寫下來、知識放在 AI 看得見的地方了嗎、驗收機制獨立嗎、成功的做法有沒有沉澱成可重複使用的資產。這些沒有一項可以向模型供應商採購，每一項都得自己建。
如果要把這篇文章變成幾個可以立刻自問的問題，會是這四個：
- 知識寫下來了嗎？ 那些只存在資深同仁腦中、通訊軟體對話裡的規則與判斷，對 AI 而言等於不存在。
- 驗收獨立嗎？ AI 自評必然樂觀，讓產出的 AI 自己說「做完了」是不可信的，生成與驗證需要分開。
- 修正有沉澱嗎？ 每次 AI 出錯，是改一次話術，還是修一次環境？前者是重複消耗，後者才是累積。
- 鷹架有折舊管理嗎？ 模型升級時，有人負責重新檢視哪些補丁已經不需要了嗎？
這四個問題，沒有一題在問「你們用的模型夠不夠新」。
結語
2023 年我們學會寫提示詞，2025 年我們學會管理 context，2026 年的功課是設計環境。Harness engineering 這個詞很新，但它描述的事情一點都不新——交接文件、版本控制、獨立驗收、知識管理，都是好團隊行之有年的紀律。AI 沒有發明新的管理學，它只是讓這些紀律從「做了更好」變成「不做就不行」。
Agent = Model + Harness。模型的進步是供應商的功課，harness 的累積是每一家企業自己的功課。而 harness 拆開來看，至少有五個具體的切面：AI 的記憶怎麼建立、組織知識怎麼讓 AI 讀懂、工作方法怎麼沉澱成可重用的資產、AI 的執行介面怎麼設計、人跟 AI 的團隊怎麼分工協作。
接下來的系列文章，我們會一個切面一個切面拆開來談。
參考資料
- Mitchell Hashimoto, My AI Adoption Journey（2026-02）
- Anthropic, Effective harnesses for long-running agents（2025-11）
- Anthropic, Harness design for long-running application development（2026-03）
- Anthropic, Effective context engineering for AI agents（2025-09）
- OpenAI, Harness engineering: leveraging Codex in an agent-first world（2026-02）
- Latent Space, Is Harness Engineering real?（2026-03）