Anthropic 3個智能體輪班寫代碼，連續跑8小時不崩潰

一個 AI 寫代碼，寫到一半開始"失憶"；兩個 AI 協作，互相甩鍋說對方寫得爛；三個 AI 輪班，居然能連續肝 8 小時全棧開發——這是 Anthropic 工程師最近拿出的新玩法。

4 月 4 日，Anthropic 發布了一套多智能體協作框架（multi-agent harness），專門解決"AI 編程馬拉松"里的兩個老毛病：上下文丟失和任務半途而廢。不是讓單個模型硬撐，而是把活兒拆給三個角色：規劃師、生成師、質檢員。

為什么一個 AI 干不了長活兒

用過 Claude 寫代碼的人都知道，聊到第 50 輪左右，模型開始"眼神渙散"。不是算力不夠，是上下文窗口（context window）塞滿了——之前的對話、代碼、報錯信息像堆疊的快遞盒，把通道堵死。

常見的解法是上下文壓縮（compaction），把歷史對話精簡摘要。但 Anthropic 工程師發現，這會讓模型變得"謹小慎微"：它知道快觸頂了，于是提前收手，長任務反而做不完整。

更隱蔽的問題是自我評估偏差。AI 給自己寫的 UI 打分時，往往比人類寬松得多——"這個按鈕配色挺和諧的"——結果用戶看到實物直接沉默。

單個智能體的天花板，不是算力，是自我認知的盲區。

Anthropic 的解法很產品經理思維：不卷單個模型的極限，而是設計一套"輪班制"。三個智能體各司其職，交接時不是扔一堆聊天記錄，而是結構化的狀態文檔——下一位接班者能快速定位，不用從頭翻歷史。

三班倒是怎么運轉的

這套框架把開發流程切成三道工序：

規劃智能體（Planning Agent）負責拆解任務。拿到"做一個電商后臺"這種模糊需求，它輸出技術方案、文件結構、依賴清單——相當于開工前的圖紙會審。

生成智能體（Generation Agent）是主力碼農。它只認規劃師給的藍圖，埋頭寫代碼。寫完不自己拍板，把產物打包成"交付物"（artifact）。

評估智能體（Evaluation Agent）當質檢。它用預定義的評分標準（rubric）驗收，比如"按鈕對比度是否達標""API 響應是否小于 200ms"。不通過就打回，附帶具體修改意見。

關鍵設計在交接機制。規劃師下班時，不會把腦子里想的都倒給生成師——而是輸出一份結構化文檔：技術決策、待辦事項、風險點。生成師完工后，交付物里包含代碼、測試用例、已知缺陷。評估師的反饋又是下一輪規劃的輸入。

上下文在這里不是被壓縮，而是被"歸檔"——每個角色只讀自己需要的卷宗。

這套流程支持多輪迭代。Anthropic 的測試顯示，系統能穩定運行數小時，處理前端設計到后端部署的全棧任務。對比單智能體長會話，任務完成率顯著提升——具體數字未公開，但工程師提到"從頻繁中斷到可持續交付"。

為什么專門拆出一個"質檢員"

AI 給自己打分虛高，這事 Anthropic 早有觀察。設計類任務尤其明顯：模型容易陷入"自我陶醉"，把平庸的 UI 評成優秀。

評估智能體的獨立性是刻意設計的。它不參與代碼生成，只拿著評分表當"甲方"。評分標準可以定制——可以是設計規范文檔，也可以是性能基準測試。

這種分離有個額外好處：可解釋性。當生成師抱怨"憑什么打回"時，評估師能指著評分表逐條說理。雖然都是 AI，但角色對立制造了類似"代碼評審"的張力。

Anthropic 工程師在內部文檔里打了個比方：「讓同一個廚師又做菜又寫食評，和讓獨立美食評論家打分，結果必然不同。」

質檢員的存在，本質是給系統引入"外部視角"——盡管這個外部也是機器。

長時運行的工程細節

支撐數小時不間斷運行的，是一組底層機制。

上下文重置（context reset）是核心。每個智能體啟動時，不繼承前任的完整對話歷史，而是讀取結構化的"交接文檔"。這避免了上下文線性膨脹，也讓模型始終保持"清醒"——不會被幾十輪前的錯誤假設帶偏。

狀態持久化（state persistence）確保中斷后可恢復。如果任務跑到一半服務器掛了，重啟后能從最后一個檢查點繼續，不用從頭再來。

工具調用鏈（tool chaining）被嚴格管控。生成師調用代碼解釋器、瀏覽器、文件系統時，操作日志被完整記錄，評估師可以復盤"這行 bug 是怎么引入的"。

這些設計指向同一個目標：把"AI 編程"從聊天式的即興創作，變成可管理、可追蹤的工程流程。

和前代方案的區別

多智能體協作不是新概念，但 Anthropic 的實現有幾處差異化。

一是角色固定而非動態拆分。有些框架讓 AI 自己決定"我現在該當規劃師還是碼農"，結果角色切換頻繁，狀態混亂。Anthropic 選擇硬編碼三角色，降低協調成本。

二是交接物的結構化。不是扔一段自然語言總結，而是帶格式的技術文檔——類似人類團隊里的需求文檔、接口文檔、測試報告。

三是評估的強制性。生成師的產出必須經過評估師關卡，不能自我放行。這增加了延遲，但減少了"半成品上線"的風險。

Anthropic 提到，這套框架已在內部用于原型開發，覆蓋從 React 前端到 Python 后端的完整棧。工程師特別指出，前端設計任務受益最明顯——因為評估標準相對客觀（對比度、間距、響應式斷點），質檢員能有效約束生成師的"審美放飛"。

對開發者的實際意義

這套設計目前以研究形態發布，尚未集成到 Claude 的公開 API。但技術文檔已足夠詳細，第三方可以復現。

對普通用戶的直接價值有限——你沒法明天就雇三個 AI 輪班寫自己的 App。但它揭示了 Anthropic 的產品思路：不追求單點參數突破，而是把 AI 能力封裝成可組合的工程模塊。

更深遠的影響在生態層面。如果多智能體協作成為標準做法，開發工具鏈會被重塑。IDE 不再是對話窗口，而是"智能體調度臺"：查看哪個角色在值班、當前迭代輪次、歷史評估記錄。

調試方式也會變。現在的 AI 編程，出錯了只能翻聊天記錄猜原因。未來可能是調取評估師的質檢報告，看"第三輪迭代時性能評分驟降，對應哪次代碼變更"。

從"和 AI 聊天"到"管理 AI 團隊"，交互范式正在轉移。

另一個值得注意的點是成本結構。三智能體輪班，意味著同樣的任務要調用三次模型（規劃、生成、評估）。Anthropic 沒有披露具體開銷，但承認"增加了計算資源消耗"。這是換取可靠性的代價——和雇人類團隊一樣，分工細化帶來效率，也帶來管理成本。

行業里的同類探索

多智能體編程并非 Anthropic 獨家。OpenAI 的 Swarm、Google 的 Multi-Agent Orchestration、開源社區的 AutoGen 都在嘗試類似方向。

差異主要在協調機制。Swarm 強調動態任務分配，智能體根據當前狀態自選角色；AutoGen 支持更靈活的角色定義，但配置復雜度較高。Anthropic 的選擇是"做減法"——固定三角色、強制評估關卡、結構化交接——換取可預測性。

這種取舍符合其產品調性。Claude 一貫以"更可控"為賣點，相比 GPT 的創意奔放，更強調遵循指令和減少幻覺。三智能體框架延續了這一路線：不是讓 AI 更聰明，而是讓 AI 協作更可靠。

也有批評聲音。部分開發者認為固定角色限制了靈活性，"有些任務根本不需要規劃師，直接寫代碼更快"。Anthropic 的回應是框架支持配置化——可以關閉某個角色，但默認三班倒是經過驗證的"安全模式"。

技術文檔里的一個細節

Anthropic 發布的技術文檔中，有個容易被忽略的參數：評估智能體的評分表（rubric）支持人工覆蓋。

意思是，如果自動評估和人類判斷沖突，開發者可以介入調整標準。這保留了"人在回路"（human-in-the-loop）的接口——不是完全自動化的黑箱。

這個設計很產品經理。完全自動化的 AI 團隊是遠景，但現階段"AI 干活、人類把關"更務實。評估師的存在，其實是把"把關"環節也自動化了大部分，但留了一扇后門。

文檔里還提到一個邊界案例：當生成師和評估師陷入"改-打回-再改-再打回"的循環時，系統會觸發升級機制，由規劃師重新介入調整任務拆分。這類似于人類團隊里的" escalate 到管理層"。

這些細節說明，Anthropic 設計的不是三個獨立 AI，而是一個有反饋回路、有異常處理的組織系統。

開放問題

三智能體框架能跑通，建立在 Anthropic 對 Claude 能力的深度了解上。換成其他模型，同樣的角色分工是否有效？評估智能體的評分標準，遷移到不同技術棧時需要多少調整？

更長遠的疑問是：當 AI 能組成三人小隊，四人、五人的協作邊界在哪里？規劃師是否需要再拆出"架構師"和"項目經理"？評估師要不要分化出"安全審計"和"用戶體驗"兩個專職？

Anthropic 沒有給出答案。技術文檔的結尾很克制，只提到"持續優化角色定義和交接協議"——換句話說，三班倒只是起點，不是終局。

如果這套框架開源，你會先用它做什么：是讓三個 AI 輪班維護自己的遺留代碼，還是賭一把，看它們能不能獨立交付一個完整產品？