前言
Anthropic 最近幾篇關於 Agent Harness 的技術部落格很值得關注，把 Agent 工程從怎麼寫一個更聰明的迴圈，推進到了怎麼設計一個能進生產的執行時。
這篇文章分享關於 Agent Harness 的最新實踐：Session、Harness、Sandbox、Credential、Tool Protocol、Context Builder、Trace、Eval。
這幾年的思路變化
Anthropic 的 Agent Harness 思路不是突然變成 Runtime 的。過去幾年，它的重心變過幾次。
階段一：長上下文被當成主要抓手
早期 Anthropic 很強調 long context。
100K、200K context window 的出現，讓 Claude 可以讀更多文件、承載更長對話、處理更複雜材料。那時很多問題還被理解為 prompt engineering：怎麼把資訊放進去，怎麼讓模型在長上下文裡找到正確內容，怎麼減少遺漏。
這個階段的判斷可以理解。模型上下文突然變長，大家自然會把任務狀態、文件、歷史對話都往裡面放。
但後來的 Agent 實踐證明，長上下文只是工作區變大了，不等於系統有了可靠記憶。
上下文視窗再長，也還是一次模型呼叫能看到的 token。它會變貴，會退化，會被壓縮，也會被無關資訊污染。
階段二：Agent 被拆成 workflow 和 autonomous loop
到《Building Effective AI Agents》階段，Anthropic 開始把 workflow 和 agent 區分開。
workflow 是流程明確、路徑可控的系統。模型在某些節點做判斷。
agent 是開放式迴圈。模型自己規劃、呼叫工具、觀察結果、繼續行動。
這個區分很實用，很多產品並不需要高自治 Agent。
穩定業務流程用 workflow 更便宜、更穩、更容易除錯。硬上 Agent，往往只是把可控流程做成不可控黑盒。
這一階段 Anthropic 的思路是先用簡單結構，只有任務真的需要開放式決策時，再引入更高自治能力。
這句話現在依然適用。
階段三：工具、上下文、安全開始成為主戰場
2025 年之後，Anthropic 的分享明顯轉向工程細節。
think tool 解決複雜工具呼叫裡的思考空間。
multi-agent research system 解決複雜研究任務裡的平行搜尋和分工。
context engineering 解決上下文選擇、壓縮、裁剪、動態載入。
Agent Skills 解決領域程序性知識的按需載入。
Claude Code sandboxing 解決程式碼執行、檔案系統、網路和憑證邊界。
MCP、code execution with MCP、advanced tool use 解決工具連線、工具發現、工具定義膨脹和中間結果污染上下文。
這些看起來主題分散，其實都在指向同一個問題：
Agent 一旦開始做真實工作，問題會從模型會不會回答轉向系統怎麼承載模型行動。
工具太多，上下文會爆。
任務太長，聊天記錄不夠用。
執行太自由，安全邊界會失控。
多 Agent 太積極，成本和協調複雜度會壓上來。
模型升級太快，舊 harness 假設會過期。
階段四：把問題抬到 Runtime 層
到了最近的 Managed Agents，Anthropic 不再只討論某種 harness 怎麼寫，而是在討論 Agent Runtime 的穩定介面。
它把系統拆成 Session、Harness、Sandbox。
把 Claude + harness 稱為 brain，把 sandbox 和執行環境稱為 hands。
把 session 放在上下文視窗之外。
把憑證擋在 sandbox 外面。
它讓執行環境可以失敗、替換、重建。
這就是 Anthropic 這幾年思路變化的主線：
長上下文 → 工具迴圈 → 上下文工程 → 安全執行 → 可恢復執行時
Managed Agents 的核心邏輯：介面要穩定，策略可以換
Managed Agents 的核心邏輯就一句話：不要把會變化的東西綁死在一起。
模型會變，Harness 策略會變，工具會變，Sandbox 形態會變，上下文策略會變，客戶部署環境會變。安全要求也會變。
如果這些東西都塞進一個容器、一個 loop、一個 prompt 體系裡，系統很快會變成難以替換的工程包袱。
Harnesses encode assumptions that go stale as models improve.
Harness 會編碼目前模型的弱點。模型不會長任務規劃，就加 planner。模型容易漏檢，就加 evaluator。模型上下文快滿了容易提前收尾，就加 context reset。模型工具呼叫不穩，就加複雜 retry。
這些策略在某一代模型上可能有效。模型一升級，它們可能變成額外成本。
Anthropic 舉了一個具體的例子：Claude Sonnet 4.5 在接近上下文視窗上限時容易提前結束任務，所以 harness 加了 context reset。到了 Claude Opus 4.5，這個行為消失了，原來的 reset 邏輯就開始顯得多餘。
這個例子說明一件事：
不要把今天模型的缺陷，寫成明天系統的架構。
Managed Agents 沉澱的核心介面大致是：
Session：任務發生過什麼
Harness：下一步怎麼調度
Sandbox：動作在哪裡執行
Tool interface：動作如何被呼叫
Credential boundary：動作是否被授權
Context builder：這次模型該看什麼
Trace / Eval：過程和結果如何被復盤
這套設計不追求某一個固定 Agent loop 的優雅。
它追求的是當模型、工具、執行環境變化時，系統還能繼續演進。
這是 Managed Agents 真正值得學的地方。
關鍵點一：Brain / Hands 解耦
Managed Agents 裡最關鍵的一刀，是把 brain 和 hands 拆開。
Brain 是 Claude + harness。
Hands 是 sandbox、MCP server、外部工具、裝置、瀏覽器、程式碼執行環境。
早期做法往往是把 brain 放進 hands 裡面。也就是一個容器裡跑 harness、存 session、執行工具、放檔案系統，有時還放憑證。
但進入生產，它會製造一個典型問題：容器變成 pet server。
它不能輕易丟、不能輕易重啟，掛了要救、除錯要進去看。
使用者資料、執行狀態、工具呼叫、憑證邊界全混在一起。
Anthropic 後來的做法是讓 harness 離開 sandbox。Harness 成為相對無狀態的控制面，sandbox 變成可呼叫、可重建的執行資源。
二者之間透過一個簡單介面連接：
execute(name, input) -> string
這個介面讓 Harness 不必知道對面是容器、遠端服務、MCP server，還是某個客戶 VPC 內的工具環境。它只知道呼叫動作，拿回結果。
這樣一來，系統得到幾個直接收益：
- Sandbox 掛了，不等於任務死了
- Brain 可以先工作，sandbox 後載入
- 一個 brain 可以調多個 hands
關鍵點二：Session 的設計
Managed Agents 裡另一個關鍵判斷是：
Session is not Claude’s context window.
很多 Agent 系統會把 session、聊天記錄、memory、上下文視窗混在一起。短任務還能撐，長任務很容易亂。
上下文視窗只是模型這一次推理能看到的 token，它是工作區。
Session 應該是任務發生過的持久記錄，它更像 event log。
一個可靠的 session 至少應該記錄：
user_input
model_response
tool_call
tool_result
file_change
error
retry
approval
checkpoint
Harness 每次呼叫模型時，再從 session 中選擇目前需要的部分，構造成模型上下文。
這個分工非常關鍵，Prompt 是工作區，Session 是帳本。
工作區可以整理、壓縮、裁剪、重組；帳本要盡量完整、可查、可恢復。如果把所有歷史都塞進上下文，成本會爆，模型也會被雜訊拖累。如果只靠摘要，摘要漏掉的細節可能在後面變成關鍵錯誤。
所以更穩的結構是：
原始事件長期保存
↓
Context Builder 動態選擇
↓
目前模型呼叫看到一個高訊號上下文
這也是 context engineering 和 durable state 的分界線。
Context engineering 負責這次模型該看什麼。
Session event log 負責系統到底發生過什麼。
長任務 Agent 如果沒有這一層，後面做 resume、trace、eval、debug 都會很難。
關鍵點三：Sandbox 的設計
Sandbox 在 Agent 系統裡經常被低估。
很多團隊一開始只是給 Agent 一個 shell，能跑命令、能讀檔案、能改程式碼，就覺得夠了。
這在 demo 階段沒問題；生產裡，sandbox 是安全邊界，也是執行邊界，還是成本和延遲來源。
Anthropic 在 Claude Code sandboxing 和 Managed Agents 裡強調了幾個方向：
- Sandbox 要隔離檔案系統和網路。模型生成程式碼必須按不可信程式碼處理，sandbox 需要限制檔案系統存取範圍，也要限制網路存取範圍。否則 prompt injection 可以誘導 Agent 讀不該讀的檔案，存取不該存取的服務，把結果帶出去。
- Sandbox 不該直接持有長期憑證。只要 sandbox 裡有 GitHub token、資料庫 key、雲服務金鑰，Agent 就有機會被誘導讀取它們。
- Sandbox 要能重建和恢復。長任務 Agent 一定會遇到失敗，如果 sandbox 和 session 綁定太死，失敗就會拖垮任務。更好的做法是讓 sandbox 可重建，可恢復，必要時支援 snapshot / resume。這也是 Brain / Hands 解耦的延伸。
總結：2026 Anthropic Agent Harness 架構圖
把 Anthropic 2026 年的思路合在一起，可以抽象成下面這張圖：
這張圖的重點在每個模組的責任邊界。
Harness 是控制面，負責調度模型、上下文、工具、策略。
Session event log 是持久狀態，不跟某個容器綁定。
Context Builder 從 session、memory、skills、工具結果裡組裝高訊號上下文。
Tool Router 負責把動作分發給 MCP、程式碼執行環境、sandbox 或其他 hand。
Sandbox 負責執行動作，可以失敗，可以重建。
Credential Proxy / Vault 管住憑證，不讓不可信執行環境直接拿 token。
Trace / Eval 貫穿整個 run，讓系統能復盤、回歸、對比 harness 改動。
研究型 Harness 和生產型 Harness 的區別
很多 Agent demo 看起來很強，進入生產之後變得笨重、昂貴、難除錯。
原因是研究型 harness 和生產型 harness 的目標不同。
研究型 harness 追求能力上限。它可以多花 token，多開 subagent，多加 evaluator，多試幾輪。任務成功率上去，就算實驗有價值。
生產型 harness 追求穩定收益。它要算成本，要看延遲，要控權限，要可恢復，要能觀察，要能灰度，要能回滾。
| 維度 | 研究型 Harness | 生產型 Harness |
|---|---|---|
| 目標 | 拉高任務成功率上限 | 在成本、延遲、安全約束下穩定交付 |
| 狀態 | transcript、本地檔案、臨時 progress file | 外部 session log、checkpoint、event history |
| 上下文 | 盡量多給模型 | 更小、更高訊號的上下文集合 |
| 工具 | 能接多少接多少 | 動態發現、按需載入、權限收斂 |
| 多 Agent | 優先嘗試平行和角色分工 | 只在高價值、可平行任務中啟用 |
| 安全 | 人工確認、簡單隔離 | sandbox、proxy、vault、scoped credential |
| 失敗恢復 | 重跑或人工接管 | resume、replay、checkpoint、trace |
| 評估 | 看最終 demo 是否完成 | outcome eval、trace analysis、regression suite |
| 迭代方式 | 加模組、加策略、加 Agent | 做 ablation，刪掉過時策略 |
Anthropic 的部落格中有個說法是 Harness 策略會被模型升級重新定價。
意思是今天 planner 有用，明天可能拖慢系統；今天 evaluator 能救錯，明天可能只是在增加成本；今天 context reset 是必要補丁，明天可能成了無用複雜度。
所以生產型 harness 不能只會加東西，也要能刪東西。這就是 ablation 的價值。
每次模型升級，都應該重新測：memory 是否有收益，critic 是否有收益，tool search 是否有收益，multi-agent fanout 是否值得，context reset 是否還需要。
Agent 工程裡，能刪掉過時複雜度，是一種很實際的能力。
寫在最後
Agent 產品會繼續變複雜，但複雜度不應該都堆在 prompt 和 loop 裡，它會下沉到 runtime：
Session：持久狀態
Harness：控制面
Context Builder：上下文調度
Tool Router：工具分發
Sandbox：隔離執行
Credential Proxy：憑證邊界
Trace：過程記錄
Eval：結果評估
這組東西才是 Agent 進入生產的底座。
Multi-agent 還會繼續發展；MCP 生態也會繼續擴大；長上下文視窗還會變長；模型也會繼續提升工具呼叫、規劃和自我修復能力。
但這些變化只會讓一個問題更突出：系統要能替換掉舊策略。
一個把所有能力寫死在 prompt、容器和固定 loop 裡的 Agent 平台，會越來越難維護。
一個把狀態、執行、憑證、上下文、評估邊界拆清楚的系統，才有機會跟著模型一起演進。
參考資料
- Anthropic, Scaling Managed Agents: Decoupling the brain from the hands
www.anthropic.com/engineering/managed-agents - Anthropic, Harness design for long-running application development
www.anthropic.com/engineering/harness-design-long-running-apps - Anthropic, Effective harnesses for long-running agents
www.anthropic.com/engineering/effective-harnesses-for-long-running-agents - Anthropic, Effective context engineering for AI agents
www.anthropic.com/engineering/effective-context-engineering-for-ai-agents - Anthropic, Making Claude Code more secure and autonomous with sandboxing
www.anthropic.com/engineering/claude-code-sandboxing - Anthropic, Code execution with MCP: building more efficient AI agents
www.anthropic.com/engineering/code-execution-with-mcp - Anthropic, Introducing advanced tool use on the Claude Developer Platform
www.anthropic.com/engineering/advanced-tool-use - Anthropic, Equipping agents for the real world with Agent Skills
www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills - Anthropic, Building Effective AI Agents
www.anthropic.com/engineering/building-effective-agents