Harness Engineering 是什麼？Agent 工程新領域

Harness engineering 是設計與建造 AI 代理（agent）時，模型以外的系統工程。系統提示、工具、記憶、沙箱、編排邏輯、回饋迴圈與約束，都可納入 harness。工程師要把這些部分組成一個環境，讓模型能在其中執行多步驟任務。常見的心智模型是：Agent = Model + Harness（代理等於模型加上 harness）。

截至 2026 年 8 月，本次查核未找到一致的中文譯法。本文保留英文，第一次出現時再用中文說明。

討論 agent 時，人們很容易先看模型能力；但任務一旦拉長，工具是否合適、權限是否清楚、錯誤能否及時回報，也會左右結果。換模型仍可能改善表現，只是結果不由模型單獨決定。

重點先看

• Agent = Model + Harness：Vivek Trivedy 在 2026 年 3 月的 LangChain 文章用這個公式說明，harness 包含模型以外的程式碼、設定與執行邏輯。
• 三個觀察層次：prompt engineering 關注指令，context engineering 關注模型當下取得的資訊，harness engineering 則把工具、執行環境、控制與驗證一併納入。
• 前饋與回饋：Birgitta Böckeler 將使用者端 harness 分成 guides（前饋控制）與 sensors（回饋控制），可用來檢查規範與驗證是否完整。
• harness 會影響評測：LangChain 團隊自述，使用 GPT-5.2-Codex 並調整 harness 後，deepagents-cli 在 Terminal-Bench 2.0 的分數由 52.8% 升至 66.5%。模型識別未變，但最後一階段有調整 reasoning effort，不能解讀為所有推論條件都固定。
• 術語仍新：本次可追溯的公開文章集中在 2026 年 2 月之後，定義與適用邊界尚未完全收斂。

目錄

1. 先把 Agent = Model + Harness 這句公式講清楚
2. 為什麼 2026 年開始受到注意：prompt、context、harness 的三個觀察層次
3. Harness 裡到底有什麼：六類組件拆解
4. guides 與 sensors：前饋與回饋框架
5. 同一個模型換了 harness 為什麼會變強：評測的真相
6. OpenAI 用 Codex 蓋產品告訴我們的事
7. 給想動手的人：設計 harness 的實務判斷
8. 自建、框架或託管平台：取得 harness 的三條路
9. Harness 常見的失敗模式
10. Harness 帶來的攻擊面：工具、MCP 與信任邊界
11. 常見誤解與限制
12. FAQ
13. 結論與下一步

先把 Agent = Model + Harness 這句公式講清楚

一句話定義：在 AI 代理裡，模型以外的程式碼、設定與執行邏輯，都可視為 harness。

Vivek Trivedy 在 LangChain 發表的文章（2026 年 3 月 10 日）寫道：「Agent = Model + Harness. If you're not the model, you're the harness.」Addy Osmani 後來的整理（2026 年 4 月 19 日）也沿用這個說法。它要表達的是：應用團隊除了選擇模型，還能設計包在模型外面的整套執行結構。

術語起源不宜歸給單一人物。Addy Osmani 認為這個詞由 Vivek Trivedy 提出，但目前可核對的公開紀錄顯示，Mitchell Hashimoto 在 2026 年 2 月 5 日的文章已使用 harness engineering；OpenAI 在 2 月 11 日發布同名工程文章；Vivek Trivedy 的 Improving Deep Agents with Harness Engineering則發布於 2 月 17 日。較穩妥的說法是：這個詞在 2026 年 2 月由多位業界作者相繼使用，Vivek Trivedy 隨後用 Agent = Model + Harness 公式整理出清楚的定義。

把公式拆開來看。

Model 是代理呼叫的模型。若使用託管式模型 API，應用團隊通常不會在每次任務中直接改動模型權重。Harness 則包含系統提示、工具、檔案系統、子代理編排、工具呼叫前後的 hooks 或 middleware，以及 logs 與 traces。模型微調或自建模型是另一層工作，不影響這個公式作為代理架構的簡化說明。

Harness 的範圍超過提示。模型提供推理與生成能力；harness 負責把狀態、工具執行、權限、驗證與復原路徑接起來。少了這些結構，模型仍能輸出文字，但還不具備持續執行任務所需的代理系統。

Prompt engineering 處理「這次要怎麼指示模型」；harness engineering 處理「模型要在什麼環境裡完成整個任務」。兩者會重疊，因為 prompt 本來就是 harness 的一部分，但後者還包含工具、權限、狀態與驗證機制。

可以把它想成廚藝和廚房的差別。Prompt engineering 像一道菜怎麼做；harness engineering 則連動線、水電、排煙、庫存與食安規範一起考慮，讓工作能連續進行。

這個公式在除錯時也很好用。代理出錯時，先問問題出在等號哪一邊：是模型推不動，還是 harness 沒給對工具、沒設好權限、沒接上回饋。把變因分開，才不會把環境問題誤當成模型問題，或反過來。

為什麼 2026 年開始受到注意：prompt、context、harness 的三個觀察層次

Harness engineering 受到注意，和 agent 開始承擔更長、更多工具參與的任務有關。

Milvus 的文章（Min Yin，2026 年 4 月 9 日）用三個層次整理這個變化。不過，這是方便理解的分類，不是業界標準或嚴格成熟度模型。

Prompt engineering（提示工程）關注模型收到的指令與範例。Context engineering（脈絡工程）關注模型在當下能取得哪些歷史、文件與檢索結果。Harness engineering 則把視野擴到任務執行環境，包括工具、沙箱、停止條件、驗證與回饋。

三者互相包含，也可能同時出現在同一個系統裡。Martin Fowler 網站上的文章明確把 coding agent 的使用者端 harness 視為 context engineering 的一種具體形式。因此，下面這張表是觀察角度的區分，不能當成互斥的技術分級。

判斷是否需要 harness，不必先數決策次數。更實用的判斷是：任務會不會跨多個工具、持續較久、動到真實資源，而且需要在無人逐步確認時發現並修正錯誤。符合的項目越多，harness 的重要性越高。若只是不斷加長 system prompt，卻沒有補上驗證、權限或工具設計，通常解決不了執行層的問題。

早期的 LLM 應用多以聊天式互動為主；現在的 coding agent 可以讀取程式碼庫、修改檔案、執行測試，甚至建立 pull request。任務拉長後，模型能力之外的環境設計自然成為獨立議題。

從本次查到的公開文章看，2026 年 2 月是這個詞開始密集出現的時間點：Mitchell Hashimoto 在 2 月 5 日公開使用，OpenAI 在 2 月 11 日發布工程案例，Vivek Trivedy 在 2 月 17 日整理評測經驗；3 月 10 日，LangChain 刊出 Agent = Model + Harness 的系統化文章；4 月又有 Birgitta Böckeler、Milvus 與 Addy Osmani 的延伸整理。這些紀錄只能說明公開討論在當時增加，無法據此斷定誰是唯一發明者。

這個術語到本文更新時仍很新，各家的組件清單與命名略有差異。本文沿用 LangChain 與 Addy Osmani 的內容，再為了閱讀方便整理成六類。這是本文的分類方式，不宣稱它已成為正式標準。

Harness 裡到底有什麼：六類組件拆解

以下六類涵蓋 LangChain 與 Addy Osmani 文章提到的主要組件。LangChain 原文列出系統提示、工具與 MCP、基礎設施、編排邏輯、hooks／middleware；Addy Osmani 的整理另把可觀測性明列為一類。

這六類並非互斥。例如 compaction 是 middleware，也會影響 trace 的可讀性；AGENTS.md 是指令來源，也可當作 guide。分類的用途是協助盤點，不需要為每個元件硬找唯一歸屬。

指令檔。CLAUDE.md、AGENTS.md 這類檔案，是寫給 agent 讀的專案指引。它可以說明程式碼庫規範、不可變更的範圍、測試方式與驗收條件。README 通常先回答「這個專案是什麼」，而代理指令還要補上「可以做什麼、不可做什麼、完成後怎麼驗證」。兩者可以互相連結，不必把全部內容複製一遍。

沙箱。當 agent 可以讀寫檔案、執行 shell 或操作瀏覽器，權限範圍就必須明確。沙箱能隔離執行環境，並限制檔案與網路存取。它是否必要、要限制到什麼程度，仍要看資料敏感度、操作可逆性與任務風險。

工具與 MCP（Model Context Protocol）。工具名稱、描述與 schema 會影響模型能否選對工具並正確填入參數。MCP 官方文件將 server 提供的能力分為 tools、resources 與 prompts，讓 client 透過標準介面探索與使用。不同的相容應用可以重複使用這些整合，但仍要自行處理實作安全、權限與工具說明。

工具描述的品質常被低估，卻會影響模型如何選擇工具。名稱、用途、參數意義與例外情況都會進入模型的決策；當兩個工具職責重疊，模型更容易猜錯。例如（示意）：同一個代理裡有「讀取檔案」與「讀取遠端資源」兩個工具，若描述都只寫「取得內容」，模型面對一個來源不明的路徑時，可能無法正確判斷該用哪一個。把每個工具的範圍、限制與不處理的情況寫清楚，是很實際的一種 guide。

編排邏輯。複雜任務有時會拆給不同子代理，主代理負責分派與彙整。這能隔離脈絡並平行處理獨立工作，但也增加交接與驗證成本。子代理不是必備組件，只有在任務確實可分割、而且交付內容能被檢查時才值得加入。

可觀測性。多步驟任務會經過多次模型與工具呼叫；trace 可用來回看輸入、輸出與失敗位置。成本與延遲計量則幫助團隊判斷瓶頸。收集資料只是第一步，還要先決定要檢查哪些指標，以及誰負責處理異常。

這些組件各自補上模型無法單獨處理的部分。專案規範需要指令檔，危險操作需要權限控制，執行結果需要測試或其他感測器，跨步驟狀態則需要檔案或記憶機制。Harness 就是把這些部分接起來的系統。

guides 與 sensors：前饋與回饋框架

六類組件回答「harness 裡有什麼」；guides 與 sensors 則提供一個設計角度。這個框架出自 Birgitta Böckeler 發表在 Martin Fowler 網站的文章，發布日為 2026 年 4 月 2 日。將它簡稱為「Martin Fowler 框架」容易誤認作者，因此本文直接歸名給 Böckeler。

她把 coding agent 的使用者端 harness 分成兩種控制：

guides（前饋控制，feedforward controls）在 agent 行動前提供資訊與規範，增加第一次就做對的機率，例如 AGENTS.md、skills、coding conventions 與 codemods。sensors（回饋控制，feedback controls）觀察 agent 行動後的結果，協助它修正，例如 linters、靜態分析、測試、review agents、logs 與瀏覽器檢查。

兩者的功能不同。Guides 能預先縮小解法空間，但無法預見所有錯誤；sensors 能根據實際結果回報，卻要等到系統產生可觀察訊號。實務上通常需要搭配使用。

兩者的成本也不同。Guides 通常較快建立，但會隨專案演變而過時；sensors 需要建置與執行成本。確定性的測試、linter 或型別檢查可以重複執行，使用模型判讀的 sensor 則仍有較高成本與非確定性。資源有限時，可以先處理代價最高又最常出現的錯誤：規範不清就補 guide，做錯後難以察覺則補 sensor。

這個框架把籠統的「要給 agent 什麼」拆成兩個問題：哪些資訊應該在動手前說清楚，以及哪些結果能在動手後立刻檢查。前者寫進 guides，後者做成 sensors。

Böckeler 另提出三個 regulation categories：maintainability（可維護性）、architecture fitness（架構適配度）與 behaviour（行為正確性）。這是作者認為目前有用的分類，不是公認標準。依原文例子，可整理如下：

文章也說明了 harness engineering 與 context engineering 的關係：「Engineering a user harness for a coding agent is a specific form of context engineering.」換成中文，就是為 coding agent 設計使用者端 harness，是 context engineering 的一種具體形式。

因此，harness engineering 不必被包裝成 context engineering 的替代品。它把 context engineering 在 coding agent 情境裡的工具、控制與驗證問題整理得更明確，兩者關注範圍不同，但高度重疊。

同一個模型換了 harness 為什麼會變強：評測的真相

評測 coding agent 時，分數同時反映模型與 harness，不能只看其中一項。

Vivek Trivedy 在 LangChain 的 Improving Deep Agents with Harness Engineering 描述團隊的實驗：使用 GPT-5.2-Codex 時，deepagents-cli 的 Terminal-Bench 2.0 基準分數為 52.8%；加入自訂 prompt 與 middleware 後為 63.6%，再調整 reasoning effort 後為 66.5%，總計增加 13.7 個百分點。模型識別維持 GPT-5.2-Codex，但推理配置並未固定。作者以當時排行榜形容為從 Top 30 之外進到 Top 5；官方排行榜截至 2026 年 8 月仍列出 Deep Agents 的 66.5% 成績，但名次會隨新提交變動，確切名次以排行榜為準。

這項結果仍要小心解讀。文章提供分階段分數、實驗設定、trace 資料集與開放原始碼的 agent，但結果主要來自開發團隊自述，本文未找到獨立重跑後的第三方驗證。它可以證明該次實驗中 harness 與推理配置變更伴隨分數上升，不能直接推論所有模型或任務都會有相同幅度。

閱讀 benchmark 時要一起看 agent 設定。模型、system prompt、工具、推理預算、逾時與驗證方式都可能影響分數。缺少這些資訊時，很難判斷差異來自哪裡。

模型選型也不是全部。同一個模型放進不同工具與執行迴圈，結果可能明顯不同；harness 也無法消除模型能力差異。

Agent 表現不佳時，可以先檢查錯誤發生在哪一層。若問題是工具描述不清、缺少測試回饋或權限設計錯誤，換模型未必能根治；若模型無法理解任務，則要重新評估模型或縮小任務。

延伸到自己設計評測時，有兩種偏差值得防範。其一是只測快樂路徑：挑容易通過的任務、用乾淨輸入，分數好看卻測不出邊界；真正的考驗常藏在格式異常、資訊不齊、工具回傳錯誤，或需要放棄原計畫的情境。其二是對基準過擬合：反覆調整 harness 去推高某一組題目的分數，換到沒見過的任務時反而退化。保留一部分沒拿來調校的任務作為驗證集，是降低這種偏差的實用做法。

評測除了分數，還要留下能用來判斷可靠範圍的訊號：這個 harness 在哪些情境會失效，以及失效時能不能被及時發現。

網路上可見替 harness 影響力指定精確百分比的說法，但本文未找到可信的一手研究支持。這類數字不應當作事實引用；確切影響幅度會隨模型、任務、評測方法與 harness 設定改變。

OpenAI 用 Codex 蓋產品告訴我們的事

OpenAI 的工程文章由 Ryan Lopopolo 撰寫，發布於 2026 年 2 月 11 日。文章記錄一項內部實驗：團隊用 Codex 建造並推出軟體產品的內部 beta，並以「0 lines of manually-written code」作為明確限制。

依 OpenAI 自述，空白程式碼庫的第一次 commit 在 2025 年 8 月下旬；五個月後，程式碼庫約為百萬行等級，期間約有 1,500 個 pull requests 被建立並合併。前五個月由 3 位工程師驅動 Codex，文章發布時團隊已增至 7 人。OpenAI 也明確表示，人類沒有直接提交程式碼，應用邏輯、測試、CI、文件、可觀測性與內部工具均由 Codex 產生。

這些數字是 OpenAI 對內部專案的公開自述，外部無法完整稽核。文章另估計開發時間約為手寫程式碼的十分之一，但沒有公開足以獨立驗證的計算方式，因此本文不把這項估算當成通用生產力數字。

文章用一句話概括分工：「Humans steer. Agents execute.」（人類掌舵，代理執行。）

在這個案例裡，工程師的工作集中在設計 agent 能理解與操作的環境、清楚指定意圖，以及建立能回報結果的驗證迴圈。這和傳統直接撰寫 production code 的工作重心不同。

設計環境，包括整理 repo、測試、lint、CI 與工具介面。指定意圖，則透過 prompt、規格、驗收條件與 AGENTS.md 說清楚目標。回饋迴圈讓 agent 在執行後取得測試、瀏覽器、logs 或 review 的結果，再決定是否修正。

這三項可以對照 Böckeler 的 guides 與 sensors，但兩篇文章沒有共同宣告一套統一框架。這裡的對照是本文的整理：意圖與環境資訊偏向 guides，測試與觀測結果偏向 sensors。

OpenAI 也在原文提醒，這種自主程度高度依賴該程式碼庫的特定結構與工具投入，不應假設能直接推廣到其他團隊。案例使用 OpenAI 內部產品、模型存取與工具鏈，外部團隊要先評估自己的驗證能力、風險與維護成本。

當 agent 負責更多程式碼產出，人類會花更多時間定義環境、規格與驗證方式。OpenAI 表示，該案例已把大部分審查交給 agent-to-agent 處理，人類主要負責排定優先順序、把回饋轉成驗收條件，以及驗證結果。其他團隊是否能採取同樣做法，仍取決於任務風險與現有的驗證能力。

給想動手的人：設計 harness 的實務判斷

開始前先判斷任務需要多少自主權。這會決定 harness 要做到多深。

這張表是規劃參考，不是正式分級。一次性問答通常不需要厚重指令檔；會修改正式程式碼的 agent，至少應有權限界線與可執行的驗證方式。實際配置仍要看錯誤成本與復原難度。

以下情境都是示意。

情境一，讓 agent 整理每天的信件摘要。流程固定時，可以先從收信工具、摘要格式、資料範圍與輸出位置開始。若信件涉及個資或機密，還要補上存取與外傳限制；不能只因任務看似簡單，就假設犯錯成本低。

情境二，讓 agent 修改已有測試的程式碼庫。可以用 AGENTS.md 說明專案規範，用測試與 linter 回報結果，再透過 diff、logs 或 trace 保留操作紀錄。測試覆蓋率高也不代表所有行為都被驗證，重要變更仍要依風險安排人工審查。

情境三，讓 agent 進行跨檔案、長時間的重構。除了工具、沙箱與指令，還要處理工作拆分、狀態保存、逾時、復原與逐步驗證。若使用子代理，主代理不能只接受摘要，重要產物仍要用檔案、測試或其他可重複方式確認。

實作順序沒有唯一答案。若既有專案已具備測試與 lint，可以先把它們接成 sensors；若 agent 一開始連專案入口與限制都不知道，則應先補一份精簡 guide。可以從目前最常發生、而且能被清楚觀察的失敗開始。

從零盤點時，可以依下表逐項確認：

版本控制 harness。AGENTS.md、skill files、工具定義與編排邏輯都可能隨專案變動，應和程式碼一樣接受 diff 與 review。涉及憑證、私人資料或環境專屬設定的內容，則要放在適當的安全儲存位置，不能因為要版本控制就提交機密。

Harness 需要持續調整。每次 agent 出錯時，先判斷是 guide 不清楚、sensor 缺失、工具有問題，還是模型能力不足。找到可重複的原因後再修正，避免把每次偶發失敗都堆成一條永久規則。

自建、框架或託管平台：取得 harness 的三條路

實作 harness 不一定要從零開始。大致有三條途徑，差別在於需要自行維護哪些層，以及能掌握多少控制權。

這三條可以混用。以 framework 為骨架，再針對高風險操作自建專屬工具與審核流程，是一種組合；也可以先在託管平台上測試流程，等需求與風險清楚，再把部分環節搬到自建環境。

選型時比起功能清單，更該先確認四件事：它的抽象能否表達你需要的 guides 與 sensors、權限界線能否收得夠細、trace 與成本資料是否容易取出，以及換掉它的成本有多高。平台包辦的部分越多，越要事先問清楚資料流向與匯出方式。

用 framework 或平台也不會自動得到合適的 harness。前面提過的失敗模式與安全風險仍然存在，只是改由你與供應商共同承擔；哪些能交給平台、哪些必須自己掌握，一樣回到錯誤成本與資料敏感度來決定。

Harness 常見的失敗模式

下面幾種問題常出現在模型外層，單看模型輸出不一定找得到原因。

guides 過載。 指令太長、規則互相衝突時，模型可能漏掉限制或套錯情境。OpenAI 的案例也提到，單一大型 AGENTS.md 會擠壓其他脈絡，因此改用約百行的索引，再連到結構化文件。確切長度沒有通用答案；做法是保留常用規則，其他內容分層放到任務相關文件。

回饋訊號太慢。 Agent 累積大量修改後才跑完整測試，失敗時較難定位是哪一步造成。可依專案測試成本，把快速檢查放在較前面，較慢的整合測試留到後面；不必機械式地在每次存檔後跑全部測試。

context 接近上限卻沒有管理。 長任務會累積對話與工具輸出，相關資訊可能被大量舊內容淹沒。常見做法包括 compaction、把大型輸出存到檔案後按需讀取，或用結構化交接檔開新 session。具體策略要配合模型的 context window 與任務特性。

沙箱權限過寬。 若 agent 有完整檔案寫入與網路存取權，一次錯誤就可能碰到無關資料或把內容傳到外部。權限應依任務最小化，高風險操作加上人工核准與可復原機制。

子代理交接未驗證。 子代理可能回傳看似合理但不存在的檔案、API 或事實。重要資訊應透過可重複檢查確認，例如驗證路徑存在、執行測試、開啟原始來源，不能只相信摘要。

可觀測性資料無人處理。 Logs、traces 與成本資料如果沒有檢查條件、負責人與處理流程，最後只會佔用儲存空間。先定義要回答的問題，再決定收哪些資料。

這些失敗多半可用 guides 與 sensors 重新檢查：規範是否足以引導、實際結果是否能被及時觀察，以及兩者有沒有連成可修正的流程。

Harness 帶來的攻擊面：工具、MCP 與信任邊界

代理取得越多能力，受操控的外部內容可能利用的能力也越多。Harness 本身也是攻擊面，設計自動化流程時不能略過這一層。

工具描述與參數 schema 是第一層。模型根據描述選工具並填參數；若描述模糊或兩個工具職責重疊，惡意或瑕疵輸入就可能引導模型選錯工具。OpenAI 將 prompt injection 說明為外部內容中的指令，目的在誘使模型執行使用者沒有要求的動作。代理讀取網頁、信件、文件或工具回傳內容時，都可能接觸這類輸入。

MCP 與第三方工具還有供應鏈信任問題。MCP 2025 年 11 月版規範明確指出，tool annotations 只是提示，無法保證忠實描述工具行為；client 不應根據不受信任 server 提供的 annotations 決定如何使用工具。一個 server 宣告的用途與實際存取範圍可能不同，更新後也可能改變行為。把外部 server 接進能動到真實資源的代理之前，應先確認來源、權限範圍與更新方式。

權限可從唯讀與隔離環境開始，需要寫入或對外呼叫時再依風險放寬，並為高風險操作加入人工核准。MCP 官方的授權指南也建議依工具或能力拆分權限範圍，避免使用涵蓋所有操作的 scope。

工具多、權限大、自主程度高時，一次誤判可能造成的影響也會增加。可觀測性除了協助除錯，也能用來察覺未預期的對外呼叫、大量資料讀取或其他異常操作。

常見誤解與限制

誤解一，harness 能補足任何模型。Harness 可以改善工具使用、環境資訊與驗證方式，但模型仍需具備理解任務所需的能力。若模型無法處理核心問題，應改用合適模型、拆小任務或保留人工處理。

誤解二，harness 越重越好。過度設計會增加維護成本，也可能讓規則互相競爭、產生大量無人處理的觀測資料。需要多深的 harness，應由錯誤成本、任務長度與自主程度決定。

誤解三，harness engineering 等於寫 AGENTS.md。AGENTS.md 只是 guides 的一種；工具設計、沙箱、編排、回饋與可觀測性同樣屬於模型外層。

誤解四，harness engineering 取代 prompt engineering。Prompt 是 harness 的組件之一。做好 harness，仍然需要清楚的指令與輸出條件。

誤解五，harness 做完就不必再管。模型、工具與專案會更新，原本有效的 guide 可能過時，sensor 也可能漏掉新的錯誤類型。Harness 應有版本、變更紀錄與定期檢查。

這個領域目前還有幾個限制。

定義邊界仍在演變。本文的六類組件是方便盤點的整理，不是正式標準。本次查核也未找到一致的中文譯法，「駕馭工程」「套具工程」等翻譯各自只能涵蓋部分語意，實務上保留 harness engineering 較容易對照原文。

適用範圍也有限。一次性問答或步驟固定、風險低的自動化，未必需要完整 harness；長時間、多工具、能改動真實資源的任務，才需要更嚴格地處理權限、狀態、驗證與復原。

看到產品宣稱支援 harness engineering 時，可以直接檢查它提供哪些工具、權限控制、執行環境、驗證與觀測能力，不必只看行銷名稱。

FAQ

Harness Engineering 中文要怎麼翻？

目前沒有可確認的公認譯名。Harness 在這裡帶有套具、控制與包覆結構等意思，很難用單一中文詞完整對應。實務上保留英文，第一次出現時用中文解釋，讀者也比較容易查到原始資料。

Harness Engineering 跟 context engineering 有什麼不同？

兩者高度重疊。Context engineering 處理模型當下能取得哪些資訊；harness engineering 還會明確討論工具、沙箱、編排、hooks、驗證與觀測。Böckeler 的原文將 coding agent 的使用者端 harness 視為 context engineering 的一種具體形式，因此不宜把兩者寫成互相取代。

學了 harness engineering，還需要 prompt engineering 嗎？

需要。System prompt、skill file 與任務指令都要清楚表達目標、限制與驗收方式。Harness engineering 把視野擴到整個執行環境，沒有讓提示設計消失。

我一定要幫 agent 寫 AGENTS.md 嗎？

不一定。一次性問答通常不需要；若 agent 會在程式碼庫裡進行多步驟操作，AGENTS.md 或等效指令檔能提供穩定入口。內容應精簡，主要負責索引專案規範、禁止事項與驗證方式，細節再連到對應文件。OpenAI 的案例採用約百行的 AGENTS.md，但那是單一專案做法，不是通用上限。

沒有工程團隊，能用 harness engineering 嗎？

可以從個人層級開始，例如設定專案指令、限制工具權限、執行 linter 或測試，並保留可回溯的操作紀錄。子代理編排、自建沙箱或完整可觀測性需要較多開發工作，是否值得投入要看任務風險與重複頻率。

Harness 跟 LangChain、LangGraph 這類 agent framework 是什麼關係？

Framework 提供實作 harness 的部分元件，例如工具註冊、流程編排與 tracing；harness 則是針對特定任務設計出來的整套執行環境。使用 framework 不會自動得到合適的權限、工具描述與驗證流程，不用特定 framework 也能自行組出 harness。選型時應確認它的抽象能否支援你的 guides、sensors、權限與觀測需求。

結論與下一步

Harness engineering 把 agent 的模型外層當成可設計、可測試、可版本控制的工程系統。當任務從單次回答變成多步驟執行，工具、狀態、權限、驗證與復原會直接影響結果。

Agent = Model + Harness 提醒我們，模型能力會經由 harness 接觸真實環境。Guides 在行動前提供方向，sensors 則在行動後回報結果。

若要開始，可以先挑一個重複任務，記錄 agent 最常出錯的地方。資訊不足時補一份精簡 guide；結果無法判斷時接上一個可執行的 sensor；涉及檔案、網路或外部系統時，先收緊權限並設計復原方式。指令、工具定義與編排邏輯可以納入版本控制，但不要提交憑證或敏感資料。

這個詞的公開討論仍在早期，分類與命名可能繼續變化。實作時應確認每項規範對應的風險、每個檢查能否回報可處理的訊號，以及高風險決策是否仍由人類掌握。