Agent Harness Engineering:模型能力之外,真正拉開差距的是 scaffolding
Ryan Chou 轉述 Addy Osmani 的 Agent Harness Engineering:同一個 Opus 4.6 在不同 harness 下 Terminal Bench 2.0 排名可從 33 到 5。重點不是換更強模型,而是 system prompt、tools、context、subagents、hooks、memory、sandbox、retrieval 等 harness 設計如何把模型能力真正釋放出來。
Harness 是模型之外所有讓 agent 能完成任務的東西:system prompt、CLAUDE.md / AGENTS.md、skill files、tools、MCP servers、filesystem、sandbox、browser、subagent orchestration、hooks、middleware、logs、traces、cost/latency metering。raw model 不是 agent;有了狀態、工具、限制與回饋迴圈,才變成 agent。
HumanLayer 的說法是:「這不是 model problem,是 configuration problem。」agent 不懂專案慣例,就寫進 AGENTS.md;會跑危險指令,就加 hook;40 步任務迷路,就拆 planner / executor;老是交 broken code,就把 typecheck 接回 loop。
Addy 把這叫 ratchet:agent 犯錯不是笑話,而是永久訊號。被 merge 過的錯、被漏掉的測試、被誤解的慣例,都應該變成下一版 rule、hook、reviewer subagent 或 test gate。
Claude Agent SDK、Codex SDK、OpenAI Agents SDK 都指向同一方向:開發者拿到的不再只是 completion API,而是包含 loop、tools、context management、hooks、sandbox 的 runtime。客製化焦點從「怎麼接 LLM」移到「system prompt、tools、context、subagents 如何配置」。
| Harness 元件 | 解決的失敗模式 |
|---|---|
| AGENTS.md / CLAUDE.md / skills | agent 不知道專案慣例、build/test 指令、禁止事項 |
| Tool search / retrieval layer | MCP tools 描述塞爆 prompt,或工具選擇不精準 |
| Hooks / middleware | 危險命令、缺測試、lint/typecheck 未通過卻繼續交付 |
| Subagents | 長任務混亂、review 與 implementation 角色混在一起 |
| Memory / trace analysis | 同類錯誤重複出現,無法把失敗沉澱成下一輪規則 |
| Sandbox / filesystem / git | 缺乏 durable state、無法安全執行與回滾 |