Anthropic 官方出品，實戰整理版
我常看到一種情況：團隊在選架構時，只挑聽起來厲害的，卻忘了問「這適合我現在的問題嗎？」 Anthropic 給了一個最務實的建議——從最簡單的、能跑通的模式開始，觀察它在哪裡卡關，再逐步升級。 今天這篇，我來拆解 5 種常見的多智能體協作模式：它們如何運作、何時最好用、以及最容易踩的坑在哪裡。
▋ 模式一：生成－驗證者（Generator-Verifier）
這是最簡單、也是目前落地最廣的多智能體模式。
⟡ 如何運作 生成者接到任務，產出初稿，交給驗證者依照明確標準審查。 不通過，就附上具體修改意見退回重做；通過了就放行。 這個「修改－審核」的循環會一直進行，直到驗證者滿意，或達到系統設定的最大修改次數限制。
⟡ 什麼時候用它最對 輸出品質重要，且你能清楚定義「什麼是好結果」的場景。 實例是自動回覆客服工單系統：生成者根據產品文件寫初稿，驗證者核查事實、語氣、是否每個問題都回答到。 適合用在：程式碼生成、事實查核、合規審查、按評分標準打分。
⟡ 最容易踩的坑 「坑一」是建好循環，卻沒定義「驗證」是什麼意思。只告訴驗證者「幫我看看好不好」，它就會變成橡皮圖章。 「坑二」是死循環。生成者解決不了驗證者的問題，系統就在兩者之間踢皮球。必須設定最大循環次數上限，並備好後備方案（轉人工，或帶著說明返回當前最佳版本）。 「坑三」是誤用於創意評估。如果「評估一個好創意」和「想出一個好創意」一樣難，驗證者就不太靠譜了。
▋ 模式二：調度－子智能體（Orchestrator-Subagent）
核心概念是「層級制」：一個主智能體規劃、分配任務並匯總結果；子智能體負責具體執行。
⟡ 如何運作 主調度者收到任務後，拆解並分配給對應子智能體。 子智能體各自在獨立的上下文視窗中作業，完成後回傳精煉結果。 調度者再把這些碎片彙整成最終答案。 Claude Code 就是這個架構：主智能體自己寫程式、改檔案、跑指令；需要大範圍搜尋時，在背景派出子智能體，主線工作不中斷。
⟡ 什麼時候用它最對 任務拆解清晰，子任務之間互相沒有依賴時。 實例是自動化程式碼審查系統：安全漏洞、測試覆蓋率、程式碼風格、架構一致性四個方向互不干涉，調度者派出四個專門子智能體分頭執行，查完後彙整成一份完整審查意見。
⟡ 最容易踩的坑 調度者容易成為資訊「瓶頸」。子智能體 A 發現的情報，必須先上報調度者再下發給 B，細節可能在反覆總結中流失。 另外，不做並行處理時，子智能體會按順序跑——你付了多智能體的成本，卻享受不到速度優勢。
▋ 模式三：智能體團隊（Agent Teams）
當大工作可拆成多個長期並行子任務，「組長派活」的層級制就顯得太死板了。
⟡ 如何運作 協調者創建多個「長期在職」的團隊成員，成員從共享任務佇列自主「搶單」。 接單後獨立完成多步操作，完成舉手示意。 與「調度－子智能體」最大的差別，在於成員是持久的：越做越熟，不斷累積領域知識。
⟡ 什麼時候用它最對 子任務相互獨立，且需要跨越多步、長時間處理時。 實例是大型程式碼庫框架遷移：每個成員獨立負責一個服務模組的遷移，自己處理依賴項、改程式、修測試 Bug、做驗證，協調者最後統一跑整合測試。
⟡ 最容易踩的坑 「獨立」是生命線，也是軟肋。成員 A 的工作影響到成員 B，但兩人毫不知情，最後交出打架的結果。 多個成員同時改同一個檔案時也容易發生衝突，任務分配時必須劃好邊界，並備好衝突解決機制。
▋ 模式四：消息總線（Message Bus）
智能體數量增加後，直接點對點溝通會變成災難。消息總線提供一個共享通訊大廳，讓智能體透過「發布／訂閱」協調工作。
⟡ 如何運作 智能體訂閱自己關心的話題，路由器把相關消息精準推送過去。 新智能體加入時，只要訂閱相應話題直接上班，不需改動現有架構。 就像公司大群裡有人發需求，相關部門自動領走，你不需要知道具體是誰接了單。
⟡ 什麼時候用它最對 事件驅動的流水線，且智能體生態系統還在持續擴張時。 實例是自動化安全運營系統：分診智能體評估警報，網路警報推給「網路調查智能體」，帳號警報推給「身份分析智能體」，所有發現流向「響應協調智能體」拍板。
⟡ 最容易踩的坑 排查問題極難。一個警報觸發五個智能體的連鎖反應，中間發生什麼必須查非常仔細的日誌記錄。 路由器分錯類時是「靜默崩潰」——不報錯、沒死機，但什麼也不做。 如果你的調度者腦子裡的「If-Else」越堆越多，這就是換成消息總線的訊號。
▋ 模式五：共享狀態（Shared State）
前四種模式都有某種中間商在管理資訊流。共享狀態直接幹掉中間商——所有智能體共同面對一個持久化的儲存區，直接讀、直接寫。
⟡ 如何運作 沒有中心指揮官。智能體像在公共黑板前工作：看黑板上有什麼線索，拿能處理的去做，有新發現就寫回黑板。 滿足終止條件就停止——時間到、收斂閾值、或裁判智能體宣布完成。
⟡ 什麼時候用它最對 高度協作、線索需要即時流轉的研究型任務。 實例是跨領域綜合研究系統：看論文的智能體發現一位核心研究員，看行業報告的智能體馬上就能深挖這家研究員背後的公司，不需要等協調者來回傳話。 「消除單點故障」也是這個模式的優勢：某個智能體宕機了，其他人繼續讀寫黑板，系統不癱瘓。
⟡ 最容易踩的坑 沒有統一指揮，容易重複造輪子，兩個智能體不約而同地調查同一條線索。 最致命的是「反應式死循環」：A 寫發現、B 補充、A 再回應，無限套娃，瘋狂燒算力卻沒有結論。 解法是設計之初就設好「一票否決」終止條件——固定時間預算、連續幾輪無新發現就強制停止、或指派裁判智能體判定答案是否足夠。
▋ 怎麼選？一張決策表
| 你的情況 | 推薦模式 |
|---|---|
| 輸出品質很重要，且有明確評估標準 | 生成－驗證者 |
| 任務拆解清晰，子任務短平快 | 調度－子智能體 |
| 子任務獨立、需要長時間處理 | 智能體團隊 |
| 事件驅動流水線，智能體還在持續增加 | 消息總線 |
| 需要高度協作、線索即時共享 | 共享狀態 |
| 絕對不允許單點故障 | 共享狀態 |
▋ 一個原則貫穿始終
選模式的核心問題是：「每個智能體需要知道哪些背景資訊來完成自己的工作？」 這五種模式最大的差別，就在於如何劃分上下文邊界、如何管理資訊流動。 對於大多數剛起步的需求，建議從「調度－子智能體」開始——以最低的協調成本解決最廣泛的問題，跑起來後再觀察系統在哪裡卡關，根據具體痛點升級到其他模式。 這些模式是積木，不是互斥的選擇。真實商業環境中往往混搭使用，這正是它們最強大的地方。
💡 記住：模式選錯的代價，遠大於從簡單模式出發後再升級的代價。
原文來源：Anthropic 官方部落格。整理：Ray 的數位管理學
