深度拆解：AI 智能體 Harness 的構造【譯】

寶玉AI2026年5月11日

本文將深入探討 Anthropic、OpenAI、Perplexity 和 LangChain 究竟在開發什麼。我們將聊聊編排循環、工具、記憶、上下文管理，以及那些將“無狀態”的大語言模型（LLM）轉變爲全能智能體（Agent）的底層機制。

你可能已經開發過聊天機器人，甚至可能用一些工具搭建了一個 ReAct 循環 （ReAct：Reason + Act，一種讓模型在行動前先進行推理的模式） 。跑 Demo 的時候看着挺好，但一旦投入生產環境，系統就會開始掉鏈子：模型會忘記三步前做了什麼，工具調用悄悄報錯，上下文窗口（Context Window）裏塞滿了毫無意義的垃圾信息。

問題其實並不在模型本身，而在模型外圍的基礎設施。

LangChain 證明了這一點：他們僅僅通過改變包裹大語言模型的底層架構——模型沒變，參數沒變——就讓系統在 TerminalBench 2.0 （一個衡量 AI 智能體處理命令行任務能力的權威基準測試） 上的排名從 30 名開外飆升到了第 5 名。另一項研究則通過讓大語言模型自己去優化這套架構，實現了 76.4% 的通過率，甚至超過了人類精心設計的系統。

現在，這套基礎設施有了一個正式的名字： AI 智能體 Harness 。

什麼是 Agent Harness？

雖然這個術語在 2026 年初才正式確立，但其核心理念早已存在。 Harness 是包裹在大語言模型之外的完整軟件架構：它包括編排循環、工具、記憶、上下文管理、狀態持久化、錯誤處理和護欄（Guardrails）。Anthropic 在其 Claude Code 文檔中直截了當地指出：SDK（軟件開發工具包）就是“驅動 Claude Code 的智能體 Agent Harness”。OpenAI 的 Codex 團隊也使用了同樣的說法，明確將“智能體”和“Harness”等同，指代那些讓大語言模型真正發揮作用的非模型架構。

我非常喜歡 LangChain 的 Vivek Trivedy 給出的定義公式： “如果你不是模型本身，那你就是 Harness。”

這裏有一個經常讓人搞混的區別： “AI 智能體” （Agent）是用戶感知到的行爲體現，它是一個有目標、會用工具、能自我糾錯的實體；而 “Harness” 則是產生這種行爲的背後機器。當有人說“我開發了一個智能體”時，他真正的意思是“我開發了一套 Harness，並把它接入了模型”。

Beren Millidge 在其 2023 年的博文中做了一個精準的類比：原生大語言模型就像一個沒有內存、沒有硬盤、也沒有輸入輸出設備的 CPU。此時， 上下文窗口 充當了內存（快但容量有限）， 外部數據庫 扮演了硬盤（大但速度慢）， 工具集成 則是設備驅動程序。而 Harness ，就是那個操作系統。正如 Millidge 所寫：“我們重新發明了馮·諾依曼架構（Von Neumann architecture）”，因爲這是任何計算系統最自然的抽象方式。

工程化的三個層次

圍繞模型，工程化可以分爲三個同心圓層次：

  • • 提示詞工程 (Prompt engineering) ：精心設計模型接收到的指令。
  • • 上下文工程 (Context engineering) ：管理模型在什麼時間點能看到什麼內容。
  • • Harness 工程 (Harness engineering) ：涵蓋了上述兩者，再加上整個應用架構：包括工具編排、狀態持久化、錯誤恢復、驗證循環、安全執行以及生命週期管理。

Harness 不僅僅是一個包裹提示詞的套殼（AI Wrapper），它是讓智能體能夠自主行動的完整系統。

生產級 Harness 的 12 個核心組件

綜合 Anthropic、OpenAI、LangChain 以及廣大從業者的實踐經驗，一個生產級的智能體 Harness 由 12 個不同的組件構成。讓我們逐一拆解。

1. 編排循環 (The Orchestration Loop)

這是系統的“心臟”。它實現了“思考 - 行動 - 觀察”（Thought-Action-Observation，簡稱 TAO）循環，也被稱爲 ReAct 循環。這個循環不停運轉：整合提示詞 -> 調用大語言模型 -> 解析輸出 -> 執行工具調用 -> 反饋結果 -> 重複，直到任務完成。

從技術實現上看，它通常只是一個 while 循環。但複雜的地方不在於循環本身，而在於循環所要處理的各種狀態和邏輯。Anthropic 將他們的運行時描述爲一個“笨循環”，所有的智慧都存在於模型之中，Harness 只負責管理回合的切換。

2. 工具 (Tools)

工具是智能體的“雙手”。它們被定義爲某種結構化模式（名稱、描述、參數類型），並注入到模型的上下文中，讓模型知道哪些工具可用。工具層負責註冊、格式校驗、參數提取、在 沙箱（Sandbox） 環境執行、結果捕獲，並最終將結果格式化爲模型可讀的“觀察結果”。

Claude Code 提供了六大類工具：文件操作、搜索、執行、網頁訪問、代碼分析和子智能體創建。OpenAI 的 Agents SDK 則支持函數工具（通過 @function_tool 定義）、託管工具（如網頁搜索、代碼解釋器、文件搜索）以及 MCP （Model Context Protocol，一種開放的工具接入標準） 服務器工具。

3. 記憶 (Memory)

記憶在不同的時間尺度上運作。 短期記憶 是單次會話中的對話歷史。 長期記憶 則跨越多個會話持久存在：Anthropic 使用項目文件和自動生成的 memory.md 文件；LangGraph 使用按命名空間組織的 JSON 存儲；OpenAI 則支持由 SQLite 或 Redis 驅動的會話存儲。

Claude Code 實現了三層記憶架構：一個輕量級索引（每條約 150 字符，始終加載）、按需調用的詳細主題文件，以及僅通過搜索訪問的原始對話記錄。一個核心設計原則是： 智能體將自己的記憶視爲一種“提示”，在行動前必須根據實際狀態進行驗證。

4. 上下文管理 (Context Management)

這是許多智能體容易暗中翻車的地方。核心問題在於 上下文腐爛 ：當關鍵信息處於窗口中間位置時，模型表現會下降 30% 以上（這就是斯坦福大學發現的“迷失在中間”現象）。即便是支持百萬級 Token （Token：模型處理文本的最小單位，大致相當於單詞或漢字的部分） 的窗口，隨着上下文的增長，指令遵循能力也會退化。

生產環境的應對策略包括：

  • • 壓縮 (Compaction) ：在接近限制時總結對話歷史（Claude Code 會保留架構決策和未修復的 Bug，同時丟棄冗餘的工具輸出）。
  • • 觀察掩碼 (Observation masking) ：隱藏舊的工具輸出，但保留工具調用的記錄。
  • • 即時檢索 (Just-in-time retrieval) ：只保留輕量級標識符，動態加載數據（Claude Code 傾向於使用 grep 或 head 命令，而不是加載整個文件）。
  • • 子智能體委託 ：讓每個子智能體進行深度探索，但僅返回 1000 到 2000 Token 的濃縮摘要。

Anthropic 的上下文工程指南指出，目標是：找到能最大化達成目標概率的、信號最強的最小 Token 集合。

5. 提示詞構建 (Prompt Construction)

這決定了模型在每一步具體能看到什麼。它是層級化的：系統提示詞、工具定義、記憶文件、對話歷史，以及當前的用戶消息。

OpenAI 的 Codex 使用嚴格的優先級棧：服務器控制的系統消息（最高優先級）、工具定義、開發者指令、用戶指令，最後纔是對話歷史。

6. 輸出解析 (Output Parsing)

現代 Harness 依賴於 原生工具調用 ，即模型返回結構化的 tool_calls 對象，而不是需要費力解析的自由文本。Harness 會檢查：是否有工具調用？如果有，執行並繼續循環；如果沒有，那當前的輸出就是最終答案。

對於結構化輸出，OpenAI 和 LangChain 都支持通過 Pydantic 模型 （Python 中用於數據校驗和格式化的庫） 進行模式約束。

7. 狀態管理 (State Management)

LangGraph 將狀態模擬爲在圖形節點中流動的類型化字典。系統會在關鍵步驟進行“存檔”（Checkpointing），這樣即使中斷也能恢復，甚至可以進行“時間旅行”式的調試。OpenAI 則提供了四種策略：應用內存、SDK 會話、服務器端 API 或輕量級的響應 ID 鏈。Claude Code 採用了不同的思路：將 Git 提交作爲存檔點，將進度文件作爲結構化的草稿紙。

8. 錯誤處理 (Error Handling)

爲什麼這很重要？一個包含 10 個步驟的過程，即使每一步的成功率高達 99%，最終全流程的成功率也只有約 90.4%。錯誤是會滾雪球的。

LangGraph 將錯誤分爲四類：臨時性的（帶延遲的重試）、模型可恢復的（將錯誤作爲工具消息返回，讓模型自己調整）、用戶可修復的（暫停等待人類干預）以及意外錯誤（上報調試）。

9. 護欄與安全 (Guardrails and Safety)

OpenAI 的 SDK 實現了三個層級：輸入護欄（在第一個智能體運行時檢查）、輸出護欄（檢查最終結果）以及工具護欄（每次調用工具前檢查）。一旦觸發“絆網”（Tripwire）機制，智能體將立即停止。

Anthropic 在架構上將“權限執行”與“模型推理”分離。模型決定想做什麼，但 Harness 決定允許做什麼。

10. 驗證循環 (Verification Loops)

這是區分“玩具演示”和“生產級智能體”的關鍵。Anthropic 推薦三種方法：基於規則的反饋（測試、代碼檢查）、視覺反饋（通過 Playwright 截取 UI 截圖）以及 以大語言模型爲裁判 (LLM-as-judge) （由另一個子智能體評估輸出）。

Claude Code 的創造者 Boris Cherny 指出，讓模型能夠驗證自己的工作，能讓產出質量提升 2 到 3 倍。

11. 子智能體編排 (Subagent Orchestration)

Claude Code 支持三種模式： 克隆 (Fork) （複製父級上下文）、 隊友 (Teammate) （通過文件郵箱通信的獨立窗口）和 工作樹 (Worktree) （獨立的 Git 分支）。OpenAI 則支持將智能體作爲工具（專家處理特定子任務）或移交（專家接管後續控制權）。

循環運作：步進式演練

既然瞭解了組件，讓我們看看它們在一次循環中是如何協同工作的。

  1. 1. 第一步（提示詞組裝） ：Harness 構建完整的輸入信息。
  2. 2. 第二步（模型推理） ：組裝好的內容發送給模型 API，模型生成 Token：可能是文本，也可能是工具調用請求。
  3. 3. 第三步（輸出分類） ：如果沒有工具調用，循環結束；如果有，進入執行階段。
  4. 4. 第四步（工具執行） ：Harness 校驗參數、檢查權限，在沙箱中運行並捕獲結果。
  5. 5. 第五步（結果打包） ：將結果格式化爲模型可讀的消息，捕獲錯誤以便模型自愈。
  6. 6. 第六步（上下文更新） ：將結果追加到歷史記錄，必要時觸發壓縮。
  7. 7. 第七步（循環） ：返回第一步，直到滿足退出條件。

現實中的框架是如何實現的

  • • Anthropic (Claude Agent SDK) ：通過一個簡單的 query() 函數暴露 Harness，運行時是一個“笨循環”，智慧全在模型裏。
  • • OpenAI (Agents SDK) ：採用“代碼優先”策略，工作流邏輯直接用 Python 表達，而不是複雜的圖形語言。
  • • LangGraph ：將 Harness 建模爲顯式的狀態圖，強調對流程的精細控制。
  • • CrewAI ：實現了基於角色的多智能體協作，由“流程層”管理確定性的骨幹邏輯。
  • • AutoGen ：由微軟開發，支持多種編排模式，如順序執行、羣聊、移交和動態任務管理。

“腳手架”的比喻 (The Scaffolding Metaphor)

“腳手架”這個比喻並非裝飾，而是極其精準的。建築腳手架是臨時性的基礎設施，讓工人們能觸及原本夠不到的高度。腳手架本身不蓋房子，但沒有它，工人就上不去高層。

關鍵洞察在於： 房子蓋好後，腳手架是要拆除的。 隨着模型能力的提升，Harness 的複雜程度應該逐漸降低。

這就是 協同進化原則 ：現在的模型在訓練時，就已經考慮了 Harness 的存在。如果你的 Harness 設計得好，當模型升級時，你不需要增加複雜度，性能就會自動提升。

定義 Harness 的 7 個關鍵決策

每個 Harness 的架構師都面臨這七個選擇：

  1. 1. 單智能體 vs. 多智能體 ：官方建議：先充分挖掘單智能體的潛力。多智能體會帶來額外的開銷和信息損耗。
  2. 2. ReAct vs. 先規劃後執行 ：ReAct 靈活但成本高；“先規劃後執行”速度更快。
  3. 3. 上下文管理策略 ：是總結對話，還是動態加載？
  4. 4. 驗證循環設計 ：是用硬性的代碼測試，還是用另一個 LLM 來打分？
  5. 5. 權限與安全架構 ：是追求速度自動批准，還是追求安全步步確認？
  6. 6. 工具範圍管理 ：工具不是越多越好。暴露當前步驟所需的最小工具集往往效果最佳。
  7. 7. Harness 的厚度 ：多少邏輯寫死在系統裏，多少邏輯留給模型發揮？

Harness 即產品

兩個使用完全相同模型的智能體，性能可能天差地別，原因就在於 Harness 的設計。TerminalBench 的證據已經非常明確：僅僅改變 Harness，就能讓排名變動 20 多位。

Harness 不是一個已經解決的問題，也不是一個通用的商品層。它是硬核工程能力的體現：如何將上下文視爲稀缺資源進行管理？如何設計驗證循環以防止錯誤累積？如何構建不產生幻覺的記憶系統？

隨着模型越來越強，Harness 會變薄，但它永遠不會消失。即便最強大的模型，也需要系統來管理窗口、執行代碼、保存狀態並驗證工作。

下次當你的智能體表現不佳時，別光顧着抱怨模型，去檢查一下你的 Harness 吧。

原文： https://x.com/akshay_pachaar/status/2041146899319971922

閱讀原文