Harness Engineering

AI agent 的外部運行系統設計範式。模型是馬(動力),人類是騎士(方向),Harness 是馬具(控制與導向)——它不教模型怎麼回答,而是設計模型外部的執行機制。

為什麼存在

2026 年的 AI 工程已進入第三階段(見 AI 工程三代演進):模型夠強了,但單靠模型聰明不夠——長鏈路任務中每步 95% 成功率、20 步後端到端只剩 36%(見 長鏈路成功率衰減)。系統穩定性無法只靠提升模型能力解決,需要工程層面的驗證與恢復機制。

核心隱喻

角色隱喻
模型(LLM)馬——強大但需要導向
人類騎士——決定方向與目標
Harness馬具——外部的控制、導向、驗證裝備

Harness ≠ Prompting(不是教模型怎麼回答) Harness = 設計任務拆解、工具編排、狀態轉移、驗證與恢復的整體系統

核心原則

1. 生成與評估分離

模型評估自身工作時有「自評估系統性缺陷」——傾向過度自信地稱讚平庸作品。

工程化一個獨立、嚴格的外部評估器,比教生成器自我批評更容易且有效。

具體實作:Anthropic 的 3A 架構——Planner / Generator / Evaluator 三角。Evaluator 用真實環境(如 Playwright)進行交互式驗證。

2. 狀態外部化(Externalized Memory)

Agent 本質上無狀態(Stateless)——每個新 session 都失憶。

解法:Externalized Memory——把進度、需求清單、增量 Git commit、checkpoint 外部化為製品(Artifacts),讓 Agent 每次開始前從這些製品重建上下文。

3. 工具約束

工具約束原則——Vercel 反直覺發現:移除 80% 工具後,Agent 更快、更省、成功率更高。

4. 確定性約束(Deterministic Constraints)

在 Harness 中使用不依賴模型推斷的硬性規律(Linter、結構化測試),直接強制執行邊界。不讓模型「推理」那些有明確正確答案的問題。

5. 上下文管理

  • Context Anxiety(上下文焦慮):context 隨對話增長 → 模型變得不穩定、急於收尾(類似 Context Rot Zone
  • Context Reset / Reflect:不只壓縮內容,而是把工作交接給乾淨的新 Agent——如同重啟進程以清除記憶負擔
  • 對應 vault 的 上下文壓縮 + /compact 實踐

6. 漸進式揭露(Progressive Disclosure)

根據任務進程,動態且按需地向模型揭露 SOP 或工具詳情,而非一次性填塞所有資訊。

7. AI 垃圾回收(Garbage Collection)

OpenAI 的做法:定期運行後台 Agent 掃描程式庫的不一致性、架構違規與技術債,對抗 AI 生成大規模程式庫的「熵增」。

過度工程化風險

Harness 必須與當前模型能力邊界相匹配。隨著模型增強,某些補償性 Harness 模塊可能變得多餘。Harness 應具備「可撕裂性」——隨模型進化而簡化或移除不再需要的補償機制。

各公司實踐

公司主要貢獻
Anthropic3A 架構(Planner / Generator / Evaluator);Context Reset
Vercel工具約束原則(移除 80% 工具反而更好)
OpenAIAI 垃圾回收;程式庫架構優先服務 Agent 可推理性
GoogleGemini 加密推理狀態(S-mechanism)

關鍵術語對照

術語定義
Harness Engineering設計 AI 模型運行機制、任務編排、驗證與恢復的完整工程體系
Externalized Memory將 Agent 中間進度以文件形式存於模型外部,實現跨 session 持久化
Progressive Disclosure按需動態揭露 SOP / 工具詳情給 Agent
Self-Assessment Bias模型評估自身產出時傾向給高分的系統性缺陷
Deterministic Constraints不依賴模型推斷的硬性規律(Linter / 測試)

相關概念

強連結(原文明確提及)

推斷連結(LLM 認為相關,待確認)

深入閱讀

← 回到 wiki