Agent = Model + Harness 這個等式常被引用，右邊那個 harness 裝了什麼，各家文件的寫法各有出入。以下依序釐清三個問題：等式兩邊各自負責什麼、既有文獻把 harness 拆成哪六項執行期職責、這六項之間怎麼互相牽動。
harness 這個詞怎麼界定，Birgitta Böckeler 在 martinfowler.com 的文章裡說得很明確：
harness 已經成為一種簡稱，指的是 AI agent 裡除了 Model 本身以外的所有東西
這是個排除式定義，好處是邊界清楚：
| Model | Harness | |
|---|---|---|
| 提供什麼 | 推論 | 其餘全部 |
| 狀態 | 無 | 有 |
| 副作用 | 無 | 有 |
| 可替換性 | 換推論端點即可 | 換掉等於換整個系統 |
Guo 等人 2026 年的調查則從實作角度給了同一個結構，論文摘要的寫法是：
把 LLM agent 的實作觀點視為一個基礎模型耦合一個執行 harness
兩個來源用不同路徑得到同一條分界線，一邊從定義排除，一邊從實作拆解。
同一篇 martinfowler.com 文章還把 harness 的作用拆成兩種機制：
harness engineering 這個說法最早出自 Mitchell Hashimoto，2026 年 2 月，他在自己的部落格上這樣說：
每當發現 agent 犯了一個錯，就投入時間工程化一個解法，讓它再也不會犯同一個錯
這句話隱含了一個要求，錯誤必須能被描述成一種形式。「重新啟動後，先前寫入的偏好遺失」講得出形式，工程化才有對象，「agent 壞了」則停在後果。
Hashimoto 也提到工程化一個解法有兩種形式，兩者正好落在 harness 的不同位置：
依這個定義，除錯紀錄採固定四段結構：
| 段落 | 寫什麼 | 成立條件 |
|---|---|---|
| 現象 | 可重現的觀察 | 依步驟能再次觸發 |
| 根本原因 | 為什麼會這樣 | 指得出程式碼或組態的位置 |
| 修正方式 | 動了哪一項職責、改了什麼 | 改動落在該職責的機制上 |
| 迴歸測試 | 同一種錯誤再次出現時怎麼擋下 | 有一個會因該錯誤而失敗的檢查 |
Guo 等人的調查把執行 harness 分解成六項耦合的執行期職責，論文摘要列出的原文是 observation、context、control、action、state、verification。各項的定義與涵蓋範圍如下，取自該論文的職責定義一節：
| 職責 | 決定什麼 | 涵蓋的機制 |
|---|---|---|
| Observation Interface | 把原始環境訊號轉成模型可用的觀察 | 終端輸出、file diff、螢幕截圖、DOM 狀態、API 回應、日誌、檢索到的段落、事件串流 |
| Context Manager | 什麼資訊進入模型 context、何時進、以什麼形式進 | prompt 構造、system instructions、檢索、記憶選取、壓縮、摘要、工具描述、當前任務狀態 |
| Control Loop | 編排觀察、推理、行動、回饋這個循環 | 步驟排程、停止條件、重試、反思、委派、交接、多 agent 協調、模型路由與角色指派 |
| Action Interface | 把模型輸出對映成可執行的操作 | 函式呼叫、MCP 工具、shell 與程式碼執行、瀏覽器操作、檔案操作、API 呼叫、子 agent 呼叫 |
| State and Artifact Store | 保存執行狀態與產物 | 對話歷史、計畫、scratchpad、checkpoints、日誌、traces、diff、記憶紀錄、產生的檔案與任務產物 |
| Verification and Governance | 透過檢查、約束與修復管理執行 | 測試、斷言、verifier 模型、沙箱政策、權限閘門、rollback、重試、預算控制、安全約束、稽核軌跡 |
Model 位在這六項之外，是可替換的推論端點。
其中兩項牽涉合併與拆分：
論文強調這六項是互相耦合的職責，並指出三組具體的牽動關係：
| 這兩項 | 怎麼互相牽動 |
|---|---|
| Observation 與 Context | 觀察給得越豐富，context 的處理成本越高，兩者緊密互動 |
| Action 與 Verification | 行動介面越有表達力，需要的權限控制越強 |
| State 對 Context 與 Verification | 保存下來的產物決定了什麼能被重新端上來、以及有哪些證據可供查核 |
這三組關係說明的是同一件事：動其中一項會把成本或風險推到另一項身上，六項要一起看。
論文另外把 Action Interface 的品質稱為 agent 可靠性的主要來源之一，並把工具粒度、結構化 schema 與協定式生態列為該項底下的議題。
以下是這次實作的建構順序，屬於自訂的排程，論文本身只定義職責：
| 職責 | 這次怎麼處理 |
|---|---|
| Observation Interface | 這次的範圍限於對話與排程兩種輸入，環境訊號的轉換留在範圍外 |
| Context Manager | 量測固定 prompt 的預算佔用、壓縮行為、工具 schema 的佔比、SOUL.md 的注入 |
| State and Artifact Store | 記憶的寫入與讀回、checkpoints 與 session 的回溯 |
| Action Interface | MCP 協定、自建 MCP server、工具實際被呼叫的紀錄 |
| Control Loop | 排程觸發、失敗與成功路徑分流、模型替換與路由 |
| Verification and Governance | profile 的沙箱政策、授權邊界、稽核軌跡、輸出驗證與驗收 |
有一項機制的位置要自己指定：身分宣告。該論文討論的是多 agent 的角色指派，agent 自身的 identity 屬於另一個議題。這次仍然要做，因為它對應到一個實際發生過的失效。
身分宣告的歸屬要自己決定，而它是我遇過最難查的一種失效。
把 agent 接進一個多人聊天平台之後，它開始用其他人的名字自稱。原因是群組訊息以「顯示名稱: 內容」的格式進入 context，模型把前綴解析成自己的身分。
身分宣告本來寫在 system prompt 裡，只出現一次，對話變長之後 context 被壓縮，那段宣告被移除，剩下唯一能判斷身分的線索就是訊息開頭那個名字。
用六項職責的語彙來描述，這是 Context Manager 的壓縮行為把一段應該長期存在的內容清掉了，而它原本該待的位置是 State and Artifact Store。只依賴 Context Manager 注入的內容，存活期就等於一次壓縮的間隔。
一個機制要不要做，取決於它對應到哪一種失效，它在既有分解裡的位置由實作者自己指定
盤點 2026 年的 agent 生態系，比較 MCP、A2A、Agent Skills 與 Plugin 各自的定位。
iThome鐵人賽
看影片追技術