Agent 駕馭工程懶人包 (2)｜Harness Engineering 是什麼？跟 Prompt、Context 怎麼分工

Agent 回報「已修好」，你一跑測試，三個紅燈。你在 prompt 補一句「改完一定要跑測試」，下一次它跑了測試，卻漏掉 lint（檢查程式碼格式與常見問題的工具）。再補一句，再漏一個。補到第五句，prompt 變成一份越來越長的清單，你開始懷疑問題根本不在 prompt。

這篇回答的是：反覆出現的錯，該改哪一層。駕馭層（harness）指模型以外、讓 Agent 能做事並被控制的整套軟體，設計與維護它的工作叫駕馭工程（Harness Engineering）。下面依四方的原文整理，再放進同一張表。

快速回答 Harness Engineering 是設計模型以外的整套軟體（工具、hook、檢查、迴圈），讓 Agent 的錯被擋住、結果被驗證。HashiCorp 共同創辦人 Mitchell Hashimoto 在 2026 年 2 月把做法寫成：Agent 每犯一次錯，就做一個工程解法讓它不再發生。Prompt 管單次輸入的文字，Context 管每一步放進視窗的內容，兩者在 Anthropic 技術團隊成員 Addy Osmani 的清單裡都屬於駕馭層。我的建議是：Agent 要跑多步並動檔案、錯誤又重複出現時，才值得為它設計駕馭層；單次呼叫的任務調 prompt 就夠。

Prompt、Context、Harness 三層各管什麼？

Prompt 管單次輸入的文字，Context 管每一步放進模型視窗的內容，Harness 管這兩者之外的工具、迴圈與檢查，而且在 Addy Osmani 2026 年 4 月的清單（下一節列出）裡把前兩者包在裡面。

Anthropic 在 2025 年 9 月 29 日的〈Effective context engineering for AI agents〉替前兩層劃了界線。Context 是「呼叫 LLM 取樣時放進去的那組 token」；context engineering 是「在推論過程中，挑選並維護最佳那組 token」的一套策略，範圍超出 prompt 本身。換句話說，prompt engineering 負責寫和排指令，context engineering 還要管對話歷史、工具結果這些每一步都會變的東西。

把三層放在一起看，結果如表 1。「管什麼」欄來自 Anthropic 與下一節引用的原文；「誰負責」與「怎麼驗證」兩欄是本站歸納，各方原文沒有這樣分。

表 1　三層對照。「管什麼」依 Anthropic 2025-09-29、Trivedy 2026-03-10、Osmani 2026-04-19；後兩欄為本站歸納。

工程上的意思： 同一個錯可能落在不同層。Agent 沒讀到規則，屬於 context；讀到了卻跳過檢查，要靠駕馭層讓檢查變成非做不可。

Harness 指什麼？各方的定義一致嗎？

Harness 指一個 Agent 裡除了模型以外的一切，LangChain、Birgitta Böckeler、Addy Osmani 與一篇 arXiv 論文在這一點相同，差別在清單寫多長。

LangChain 的 Vivek Trivedy 在 2026 年 3 月 10 日的〈The Anatomy of an Agent Harness〉把它寫成一條等式：Agent = Model + Harness。

"If you're not the model, you're the harness." （Vivek Trivedy, LangChain Blog, 2026-03-10）

他列出的零件有：給指示的 prompt、工具與 skills 與 MCP 伺服器（接外部工具的協定）、檔案系統與沙箱與瀏覽器、派子代理與切換模型的調度邏輯，以及 hook 與 middleware（掛在模型與工具呼叫前後、固定執行的程式，例如壓縮、續跑、lint 檢查）。

Thoughtworks 的 Distinguished Engineer Birgitta Böckeler 在 2026 年 4 月 2 日、Martin Fowler 網站上的〈Harness engineering for coding agent users〉，引用同一種簡寫：harness 是 Agent 裡除了模型以外的一切。她接著收窄範圍：對 coding agent 的使用者，她談的是你在 Agent 內建駕馭層之上，替自己的專案另外建的外層（她稱 outer harness）。

Addy Osmani 在 2026 年 4 月 19 日的〈Agent Harness Engineering〉列的清單最長：prompt、工具、context 政策、hook、沙箱、子代理、回饋迴圈與失敗後的復原路徑。依他個人網站所載，他現在是 Anthropic 的技術團隊成員，負責 Claude Code 相關工作（查閱於 2026-10-23）。

比這三篇都晚的資料，是 Paul Barbaste 等人 2026 年 7 月 15 日提交的 arXiv 論文〈Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents〉（arXiv:2609.00006）。作者群讀了十一個正式使用中的 coding agent 的原始碼，包括 Claude Code、Codex CLI、Gemini CLI，把駕馭層拆成七個子系統：Agent 迴圈、LLM 整合、工具與動作、記憶與 context、安全與權限、調度、擴充介面。論文寫明只比較各系統怎麼實作，沒有做基準測試，也沒有排名。

Harness Engineering 在日常做什麼？

Harness Engineering 的日常工作，是針對 Agent 犯過的錯，設計避免重犯的工程設定。

Mitchell Hashimoto（HashiCorp 共同創辦人，現在開發終端機軟體 Ghostty）在 2026 年 2 月 5 日的部落格〈My AI Adoption Journey〉，把他的第五步命名為 Engineer the Harness：

"I'm making an earnest effort whenever I see an agent do a Bad Thing to prevent it from ever doing that bad thing again." （Mitchell Hashimoto, mitchellh.com, 2026-02-05）

他在同一節說，他不確定業界有沒有通用的名稱，自己慣稱它為 harness engineering。他給了兩種做法。第一種是在 AGENTS.md（放給 Agent 讀的專案規則檔）補一行，修正 Agent 一直用錯的指令或找錯的 API。第二種是寫真正會執行的小工具，例如截圖、只跑部分測試的腳本，再在 AGENTS.md 註明這些工具存在。他也寫了反方向的目標：讓 Agent 能自己驗證它做對了某件事。

Osmani 把同一個心法整理成對照，並用了棘輪（ratchet）這個詞：限制只在真實失敗之後才新增，模型強到用不著時再拿掉。他在文中舉了四個失敗與對應修法的例子，這裡整理成表：

表 2　依 Addy Osmani〈Agent Harness Engineering〉2026-04-19 文中例子整理成表，表格形式為本站整理。

他還寫了一句判準：一份好的 AGENTS.md，每一行都能追溯到一件實際出過的錯。他引用 HumanLayer 的做法，把 AGENTS.md 控制在 60 行以內。

誰先用「harness engineering」這個詞，兩份文件的說法不同：Hashimoto 說這是他自己的叫法，Osmani 的文章寫「Viv Trivedy coined the term」，把命名歸給 LangChain 的 Trivedy。我沒有查到能裁決先後的一手資料，本文不下結論。

Guides 與 Sensors 怎麼分？

Böckeler 把駕馭層的控制分成兩個方向：動手前先引導的 Guides（前饋控制），以及動手後觀察結果、讓 Agent 自我修正的 Sensors（回饋感測）。

她對 Guides 的說明是：

"Guides increase the probability that the agent creates good results in the first attempt." （Birgitta Böckeler, martinfowler.com, 2026-04-02）

Guides 的例子有編碼慣例、指示與 codemod（自動改寫程式的腳本）。Sensors 在輸出專為 LLM 讀取而寫時特別有用，例如附上修法的 linter 訊息。她提醒，只有回饋的設計會讓 Agent 重複犯錯，只有前饋的設計則從不檢查規則有沒有生效，所以兩邊都要有。

第二條軸是控制的種類。Computational 控制是確定性的、由 CPU 執行，又快又便宜，例如測試、linter、型別檢查，可以在每次修改時都跑。Inferential 控制是語意層的判斷，例如 AI 程式碼審查與 LLM as judge（讓大型語言模型替結果評分或判斷），比較慢、比較貴，結果也比較不固定。

她再把要管的事分成三類：內部程式碼品質的 maintainability harness、架構特性的 architecture fitness harness，以及行為正確與否的 behaviour harness。前者現成工具最多，也最容易；行為這一類，她稱為房間裡的大象（the elephant in the room，指大家都知道重要、卻還沒妥善解決的問題），目前常靠 AI 生成的測試，而她認為那還不夠好。她另外指出，各個程式庫被駕馭的難易不同：強型別語言有型別檢查可當 Sensor，模組邊界清楚才能下架構規則。

工程上的意思： 把 linter 的錯誤訊息改成附修法的句子，改的是 Sensor 的輸出格式，不必動模型。

調整 Harness 真的會改變結果嗎？

至少在 LangChain 自己的實驗裡會：模型固定為 gpt-5.2-codex，只改駕馭層，在 Terminal Bench 2.0（一組讓 Agent 在終端機完成任務的基準測試）的分數從 52.8% 升到 66.5%，多了 13.7 個百分點。

這是 Trivedy 在 2026 年 2 月 17 日〈Improving Deep Agents with harness engineering〉的結果，文中說排名從前 30 名之外進到前 5 名。文章把調整範圍收在 system prompt、工具、middleware 三處，另外也調了推理預算的分配（規劃與驗證用 xhigh、實作用 high）。最常見的失敗是 Agent 寫完解法，重讀一遍程式碼，覺得沒問題就停下來。其中兩個對策是：system prompt 要求依「規劃與探索、實作、驗證、修正」四個階段走；另有一個 PreCompletionChecklistMiddleware，在 Agent 要結束之前攔下來，叫它對照任務規格再驗證一輪。66.5% 是這些改動一起上之後的分數，原文沒有拆出各項的貢獻。

這組數字有三個限制：它是 LangChain 對自家 Agent 的報告，沒有第三方重現；只用一個基準；改動是針對這個基準調的。前面那篇 arXiv 論文明說沒有做排名，本文引用的資料還不足以比較哪一種駕馭層設計最好。能引用的只有：同一個模型，駕馭層的改動可以讓分數差一大截。

工程上的意思： 這個案例改的是「Agent 要結束」這條出口：結束前多一道檢查，Agent 就不能憑自己覺得好就停。

各方哪裡一致，哪裡不同？

本文引用的四方都用駕馭層的改動來處理 Agent 的錯，分歧在範圍、改動從哪來、哪一塊還沒解。

一致的有兩點：Hashimoto 與 Osmani 都從實際失敗出發，Trivedy 與 Böckeler 都把做完後的驗證放在核心。不同的有三點：範圍上，Böckeler 只談使用者自己建的外層，Trivedy 與 Osmani 涵蓋整個 Agent；改動來源上，Hashimoto 與 Osmani 看專案的失敗紀錄，LangChain 看基準分數；還沒解的部分，Böckeler 點名行為驗證。Osmani 引用 Anthropic 的說法：駕馭層每個元件都隱含一個「模型自己做不到」的假設；接著他自己寫，模型變強後部分腳手架會多餘，新能力又需要新腳手架。

我的 Agent 出錯時，第一步該改哪裡？

我的建議是先把重複出現的錯記下來，再依能不能用程式檢查決定放在哪：能檢查的做成 hook 或測試，無法用程式檢查的規則才寫進 AGENTS.md。

理由有兩個。Böckeler 說 computational 控制快、便宜、結果固定，Inferential 控制慢、貴、不固定，能用前者就不用後者。另一個是 Hashimoto 與 Osmani 的共同要求：每一條規則都要能追溯到一次真實的錯，規則才不會越寫越長。這個順序成立的前提是 Agent 要跑多步並動檔案；只出現一次的錯，不值得為它建檢查。我自己沒有用這幾份來源做過對照實驗，這是依原文整理出的建議。

你的 Agent 昨天犯的最後一個錯，今天有哪一道檢查會擋住它？

下一篇拆駕馭層的第一個零件：工具回傳值該怎麼寫給 Agent 看。

常見問題

Context Engineering 和 Harness Engineering 是同一件事嗎？

兩者的範圍不同。Anthropic 把 context engineering 定義為挑選並維護推論時那組 token 的策略；Osmani 列的駕馭層清單裡，context 政策是其中一項，另有 hook、沙箱、子代理、復原路徑。所以 context engineering 可以視為駕馭工程的一部分。

小專案需要駕馭層嗎？

最小的駕馭層可以只有一份 AGENTS.md 和幾支腳本。Hashimoto 的兩種做法就是這個規模，Osmani 引用的 HumanLayer 則把 AGENTS.md 控制在 60 行內。我的判斷是，Agent 要跑多步並動檔案、同類錯又反覆出現時，才值得另外建檢查；只出現一次的錯，先不為它新增檢查。

換了模型，原來的駕馭層還能用嗎？

可能要調整。Osmani 引用 Anthropic 的說法：駕馭層每個元件都隱含一個「模型自己做不到」的假設；他自己寫，模型變強後部分腳手架會變多餘，新能力又需要新腳手架。這個系列後面有一篇專門談換模型的情況。

Guides 和 Sensors 要先做哪一個？

兩個都要。Böckeler 指出只有 Sensors 會讓 Agent 重複犯同樣的錯，只有 Guides 則不會檢查規則有沒有生效。若只能先做一個，我會先做 Sensors 裡由程式執行的測試或型別檢查，因為快、便宜、結果固定。

延伸閱讀

• Agent 駕馭工程懶人包 (1)｜Deep Agent 有哪些內建能力？三家說法對成六項
• 為什麼 AI 越聊越笨、一直犯同樣的錯？Anthropic 揭密 Context Engineering 實戰（2026 懶人包）
• AGENTS.md 怎麼寫？規則寫越多，Agent 反而越貴？（2026 完整教學＋範例）

參考資料

• Mitchell Hashimoto, My AI Adoption Journey（2026-02-05） https://mitchellh.com/writing/my-ai-adoption-journey
• Birgitta Böckeler, Harness engineering for coding agent users, martinfowler.com（2026-04-02） https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html
• Vivek Trivedy, LangChain, Improving Deep Agents with harness engineering（2026-02-17） https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering
• Vivek Trivedy, LangChain, The Anatomy of an Agent Harness（2026-03-10） https://www.langchain.com/blog/the-anatomy-of-an-agent-harness
• Addy Osmani, Agent Harness Engineering（2026-04-19） https://addyosmani.com/blog/agent-harness-engineering/
• Addy Osmani 個人網站首頁（職稱，查閱於 2026-10-23） https://addyosmani.com/
• Mitchell Hashimoto 個人網站首頁（身分，查閱於 2026-10-23） https://mitchellh.com/
• Anthropic, Effective context engineering for AI agents（2025-09-29） https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Paul Barbaste 等, Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents, arXiv:2609.00006（2026-07-15 提交） https://arxiv.org/abs/2609.00006