Anthropic Harness 設計：讓 AI Agent 連跑 6 小時不失控的架構拆解（2026）

Anthropic Harness 是一種專為長時間自主開發設計的 AI Agent 架構。核心是把「做事的 agent」和「評分的 agent」分開，再用 Sprint Contract 把每一輪要做什麼、怎麼驗證講清楚。Anthropic 用這套架構讓 Claude 連續跑 4-6 小時，從一句話 prompt 產出完整的全端應用 — 包含前端 UI、後端 API、資料庫、甚至內建 AI 功能。

如果你有在用 AI coding agent（Claude Code、Cursor、Copilot），大概都遇過這種狀況：前半段寫得不錯，越到後面越亂，最後莫名其妙宣布「完成了」，但其實一堆東西沒做完。

這不是你的 prompt 寫得不好，是 agent 的架構問題。

Anthropic 在 2026 年 3 月發了一篇工程文章 Harness design for long-running application development，直接把這個問題拆開來講，而且給了可操作的解法。這篇不是行銷文，是真的跑了好幾輪實驗、給了成本數據的工程報告。

長時間 Agent 的兩個核心失敗模式

在講解法之前，先搞清楚 agent 到底怎麼壞掉的。Anthropic 定義了兩個失敗模式，我覺得非常精準。

Context Anxiety：越跑越焦慮，提前收工

任務一長，agent 會出現幾個症狀：

• 忘記前面為什麼這樣做
• 開始亂收尾
• 為了節省上下文，提前宣告完成
• 後期做出跟前面不一致的決策

Anthropic 用了一個詞叫 context anxiety — 模型感覺自己快到上下文邊界時，開始焦慮式收工。這個說法很貼切，因為很多 coding agent 到後面不是能力不夠，而是開始亂結案。

自我評價偏差：自己當裁判永遠過關

第二個問題更隱蔽。當同一個 agent 既負責做，又負責評分，它通常會對自己的產出過度寬容。

前端設計尤其明顯 => 看起來能用、其實很普通、甚至有明顯 bug，但 agent 會說「已完成且品質良好」。

這不是 Claude 的問題，是所有 LLM 的通病。讓一個模型評價自己的產出，它天然傾向給高分。

解法：Generator / Evaluator 分離

Anthropic 的核心策略很簡單 — 把「做事的人」和「評分的人」分開。

靈感來自 GAN（Generative Adversarial Networks）的對抗思路：

• Generator 負責產出
• Evaluator 負責用 Playwright 實際操作產品、截圖、評分、寫具體 critique
• 把 feedback 回灌給 Generator，跑下一輪

這個分離不是魔法，Evaluator 也是 LLM，一開始一樣傾向對 LLM 產出手下留情。但 Anthropic 發現：調教一個獨立的 Evaluator 變嚴格，比讓 Generator 對自己變嚴格容易得多。

前端設計實驗裡，他們跑了 5-15 輪迭代。有些設計一路微調，有些中途大轉向。有個很酷的案例是做荷蘭美術館網站，到第十輪突然捨棄原本的暗色主題，改成 CSS 3D 空間體驗 — 畫作掛在虛擬牆上，用門口導航而不是滾動。這種創意跳躍在單次生成裡根本不可能出現。

三代理架構：Planner → Generator → Evaluator

接著 Anthropic 把這套思路搬到長時間全端開發，升級成三代理架構：

Planner：從一句話變成完整產品規格

Planner 不是寫實作細節，而是把短 prompt 擴展成完整的產品規格。Anthropic 特別強調兩點：

• 偏產品與高階技術方向，不過早寫死實作
• 如果 Planner 一開始就把底層細節規定錯，後面整條鏈都會被帶偏

白話說就是：Planner 決定「做什麼」和「成功長什麼樣」，不決定「怎麼做」。

實測中，Planner 把一句 Create a 2D retro game maker 展開成 16 個功能、10 個 sprint 的完整規格，還主動加入 AI 輔助功能。

Generator：一次只做一個 Sprint

Generator 是實作 agent，但不是無限制亂做。關鍵在 => 一次只做一塊、每塊有邊界、每塊結束後交給 Evaluator 驗證。

技術棧是 React + Vite + FastAPI + SQLite（後來升 PostgreSQL），加上 Git 版控。

Evaluator：不只看 code，實際操作產品

Evaluator 不是看靜態 code review，而是用 Playwright MCP 實際操作跑起來的 app：

• 點 UI、測 API、檢查 DB state
• 對每個 sprint 的每項 criterion 打分
• 任何一項低於門檻 = 整個 sprint 失敗
• 寫出具體 bug 清單讓 Generator 修正

這把 QA 從「最後才做」變成生成流程裡的結構性元件。

Sprint Contract：最有工程味的設計

我覺得整篇文章最值得學的不是三代理架構本身，而是 Sprint Contract。

每個 sprint 開始前：

• Generator 先提案這輪要做什麼
• Evaluator 檢查定義是否合理、是否可驗證
• 雙方先對「done 長什麼樣」達成共識
• 對不上就來回溝通，直到同意才開工

這一步補的是「高階 spec」和「實際可測試行為」之間的缺口。

很多 AI coding 失敗不是 code 品質差，而是 spec 太抽象、done definition 不清楚、測試目標不明確。Agent 常常寫出「好像對，但不是你要的東西」— Sprint Contract 就是在解這個問題。

翻成白話：先講清楚這一輪到底要交什麼、怎麼驗證，不要先埋頭寫。

Context Reset vs Compaction

長時間跑下來，上下文一定會爆。Anthropic 比較了兩種處理方式：

有趣的是，這不是永遠二選一。Anthropic 早期用 Sonnet 4.5 時，context anxiety 很嚴重，必須用 Context Reset。到了 Opus 4.5，模型本身在長任務表現穩定很多，就能改用 automatic compaction。再到 Opus 4.6，直接拿掉 sprint 結構，讓 Generator 連續跑兩小時不用切。

重點不是哪個一定比較好，而是：根據模型的長任務特性來決定 orchestration 策略。 模型進步了，harness 就該跟著簡化。

Communication via Files：被低估的關鍵設計

三個 agent 之間的溝通是透過檔案完成的 — 一個 agent 寫文件，另一個讀文件再回覆。

這看起來普通，但其實是長時間 agent 系統很核心的設計。因為只要資訊只存在聊天視窗裡，就無法被下一輪接手、被其他 agent 檢查、被人類追蹤。

所以長跑型 agent 幾乎都會走向：規格文件化、handoff 文件化、驗證結果文件化。這也是為什麼 Claude Code 的 CLAUDE.md、task files、skill files 都是檔案 — 不是偶然，是長時間 agent 的必然設計。

成本與產出：不是在鼓吹全自動

Anthropic 給的數字很有教育意義：

三代理比單 agent 貴 20 倍以上，但產出品質差距巨大。單 agent 做的遊戲核心功能壞了（角色不能動）；三代理做的雖然有瑕疵但核心功能完整，還自帶 AI 輔助生成。

DAW 的成本拆解更有趣：

Planner 不到 5 分鐘、不到 $0.5 就完成，超划算。QA 每輪也只要幾分鐘和幾塊錢，但抓到的 bug 是真的。大部分成本在 Build 階段，第一輪佔了一半以上。

這說明兩件事 => 高品質長任務 agent 目前仍然昂貴，但價值在於處理「高複雜度、需要持續驗證」的任務。小改 UI、修單一 bug 用這種 harness 太重了。

隨模型進步簡化 Harness

Anthropic 自己也說：harness 的每個組件都是對「模型做不到什麼」的假設，這些假設要持續驗證，因為模型會進步。

從 Opus 4.5 到 4.6，他們做了幾個簡化：

• 拿掉 Context Reset，改用 automatic compaction
• 拿掉 Sprint 結構，讓 Generator 自己決定怎麼切工作
• Evaluator 從每個 sprint 評一次改成最後統一評一次

結果品質沒有下降。因為 Opus 4.6 本身在長任務表現、code review、debug 能力都提升了，harness 不需要再補那麼多。

原則就是：找到最簡的 harness 就好，只在需要時加複雜度。

可以直接用的五條原則

如果要把這篇收斂成可操作的原則：

1. 不要讓同一個 agent 既做事又當最終裁判

至少要建立外部 review loop。哪怕只是另一個 Claude session 跑 code review，都比讓同一個 agent 自我評價強。

2. 長任務一定要切成可驗證的回合

每個回合都要有清楚的 done definition。不一定要用正式的 sprint contract，但至少要讓 agent 在開始前講清楚「這輪要做什麼、怎麼算完成」。

3. 高階 spec 與可測試行為之間，要補一層 contract

這能大幅減少「寫錯方向但看起來很忙」的情況。

4. 交接內容要 artifact 化

寫進 repo 或穩定文件，不要只留在對話裡。這樣下一輪、其他 agent、或人類都能追蹤。

5. 模型進步了，harness 就該跟著簡化

定期回頭檢查：哪些組件還是 load-bearing 的？哪些已經被模型能力取代了？不要永遠抱著最複雜的版本。

FAQ

Harness 跟普通的 prompt engineering 有什麼不同？

Prompt engineering 是在優化單次對話的品質。Harness 是設計整個 agent 系統的架構 — 包含多個 agent 的分工、溝通方式、驗證機制、上下文管理策略。當任務從 10 分鐘變成 4 小時，prompt 再好也救不了架構問題。

我自己的專案也需要三代理架構嗎？

不一定。Anthropic 自己也強調要從最簡的方案開始。如果你的任務在 30 分鐘內能完成，單 agent 加上好的 verify skill 就夠了。三代理適合「從短 spec 長出完整產品雛形」這類高複雜度、多模組的任務。

Context anxiety 在最新的 Claude 模型還存在嗎？

大幅改善了。Anthropic 表示 Opus 4.5 開始就不太明顯，到 Opus 4.6 幾乎消除。但如果你用的是 Sonnet 或其他較小的模型跑長任務，context anxiety 仍然可能出現，需要用 context reset 策略處理。

Sprint Contract 在實務上怎麼實作？

最簡單的方式是在 CLAUDE.md 或 skill 裡加一條規則：「每次開始一個新功能前，先寫一份 contract 說明要做什麼、done definition 是什麼、怎麼驗證，確認後才開始寫 code。」不需要正式工具，用檔案記錄就行。

Evaluator 為什麼用 Playwright 而不是跑 unit test？

因為 Evaluator 要驗證的是「使用者看到的東西對不對」，不只是「程式邏輯對不對」。Playwright 可以實際點 UI、填表單、截圖、測互動流程，抓到的是 unit test 抓不到的體驗層問題。兩者互補，不是替代。