多 Agent 協調的五種模式：從最簡單的開始，按需演進

題記：呢篇文係編譯自 Anthropic 博客《Multi-agent coordination patterns: Five approaches and when to use them》^[1]》，由 Cara Phillips 寫嘅。

用一個 Agent 搞唔掂複雜任務？就用多 Agent 啦。呢個判斷而家大家都同意咗。但係用多 Agent 之後，緊接住一個更具體嘅問題：呢啲 Agent 之間點樣配合？

我之前寫過 Anthropic 嘅 Harness 設計和 Managed Agents 架構都係講多 Agent 嘅分工協作。但嗰兩篇偏重點樣搭建基礎設施，冇系統咁講過協調模式本身點樣揀。網上揾到嘅多 Agent 教程大多都係停留喺『拆任務 + 合結果』呢個層面，對模式之間嘅取捨同演進路徑講得唔多。Anthropic 啱啱出嘅呢篇博客正好補咗呢個缺口，將多 Agent 協調歸納成五種模式，由最簡單到最複雜，仲畀咗啲判斷標準，話乜嘢時候應該由一種演進到另一種。

讀完最大嘅感受係：大部分團隊嘅問題唔係唔知多 Agent 嘅好處，而係一嚟就揀咗一個聽落最型嘅模式，結果俾協調開銷拖死咗。Anthropic 嘅建議係，由最簡單、行得通嘅模式開始，睇佢邊度頂唔順，再向上演進。

模式一：生成-驗證

呢個係最簡單嘅多 Agent 模式，亦都係部署得最廣嘅。

邏輯好簡單。一個 Agent 負責生成輸出，另一個負責評估。評估通過就完，唔通過就將反饋打返畀生成方，重新嚟一輪。咁樣循環直到通過或者達到最大迭代次數。

最典型嘅應用係代碼生成：一個 Agent 寫代碼，另一個寫測試、行測試。客服場景都適用，生成方草擬郵件回覆，驗證方檢查係咪準確引用咗產品文檔、係咪回應咗用戶提到嘅每一個問題。

呢個模式睇落簡單，但係踩坑嘅地方都好集中。

最常見嘅失敗係驗證標準太模糊。如果你淨係叫驗證方檢查輸出係咪夠好，佢好大機會會求其，放行曬所有嘢。驗證方嘅價值完全取決於你能唔能夠將『好』拆成具體嘅、可檢查嘅標準。

呢一點喺我之前寫 Harness 設計嗰篇入面都提過。Anthropic 嘅工程師 Prithvi 花咗好多精力調教 Evaluator，反覆睇日誌、揾判斷偏差、改 Prompt，來回迭代咗好幾輪先至令到佢嘅評分標準達到合理水平。

另一個問題係迭代循環可能會卡死。生成方解決唔到驗證方提出嘅問題，兩邊來回震盪唔收斂。所以一定要設最大迭代次數，加一個後備策略，比如升級畀人處理，或者返回當前最好嘅版本並標註問題。

模式二：編排-子Agent

呢個係層級式嘅分工。一個 Agent 做 Team Lead，負責規劃任務、分配工作、匯總結果。子 Agent 接到具體任務之後執行完就匯報。

Claude Code 用嘅就係呢個模式。主 Agent 自己寫代碼、編輯檔案、行命令，需要搜索大型代碼庫或者調查獨立問題嘅時候，就喺後台派 subagent 去做，自己繼續手頭上嘅工作。每個 subagent 喺自己嘅上下文窗口入面工作，完成之後將精煉過嘅結果返回畀主 Agent。

呢個模式適合任務拆分清晰、子任務之間依賴少嘅場景。比如自動化代碼審查：一個 PR 入嚟，需要查安全漏洞、檢查測試覆蓋率、評估代碼風格、驗證架構一致性。每個檢查維度獨立、上下文唔同、輸出格式明確。編排 Agent 將每個檢查派畀專門嘅子 Agent，收集結果之後合成一份統一嘅 Review。

問題出喺信息瓶頸上。當子 Agent 發現咗對其他子 Agent 有用嘅信息時，呢條信息一定要經過編排 Agent 中轉。安全子 Agent 發現咗一個認證漏洞，呢個發現影響架構子 Agent 嘅分析。編排 Agent 需要識別呢種依賴關係並正確路由信息。經過幾輪中轉之後，關鍵細節成日俾人丟失或者喺摘要入面俾人省略咗。

我用 Claude Code 嘅 subagent 時都有類似體感。subagent 搜完代碼庫返嚟嘅結果有時會將關鍵上下文壓縮咗，主 Agent 收到嘅係一個乾淨但係唔完整嘅摘要。對於簡單查詢呢個唔係問題，但係對於需要子 Agent 之間共享發現嘅複雜任務，編排模式就開始吃力喇。

模式三：Agent 團隊

編排模式入面嘅子 Agent 係用完即棄嘅。接到任務，做完嘢，交結果，走人。但如果任務需要 worker 喺多輪入面積累經驗呢？

Agent 團隊模式嘅分別就係呢度：worker 係持久嘅。

一個協調者啟動多個 worker Agent 作為獨立進程。接任務，做嘢，交結果。唔重置，唔遺忘。每個 worker 喺多輪迭代中積累對自己負責領域嘅熟悉度。

最直觀嘅例子係大規模代碼遷移。每個 worker 分管一個服務，喺反覆處理呢個服務嘅依賴、測試、部署配置嘅過程中，逐漸摸清佢嘅脾氣。一次性 subagent 每次接手都要重新理解服務嘅配置約定同依賴關係，持久 worker 第一次搞掂之後後續迭代直接重用，慳返重複嘅上下文加載。

但獨立性係硬前提。

團隊模式入面嘅 worker 冇中間人幫手傳話。一個 worker 嘅改動影響咗另一個，大家都唔知，產出可能衝突。多個 worker 操作同一個代碼庫時尤其明顯，常見嘅應對方式係檔案級別嘅分區或者合併前跑衝突檢測，但呢個增加咗協調者嘅複雜度。完成時間嘅參差都係個問題，一個 worker 兩分鐘搞掂，另一個要二十分鐘，協調者要有耐性等。

模式四：消息總線

前面三種模式都有明確嘅協調者喺度指揮交通。但如果 Agent 數量繼續增加、交互模式變得不可預測呢？

消息總線引入咗一個共享通信層。核心操作得兩個：發佈同訂閲。Agent 訂閲自己關心嘅 topic，路由器負責分發。新 Agent 上線唔需要改已有嘅連接，訂閲相關 topic 就可以開始接收工作。搞過微服務事件驅動架構嘅應該唔陌生，本質上就係 Kafka 嗰套思路，只不過參與者由服務變成咗 Agent。

Anthropic 舉嘅例子係安全運維自動化。告警從多個來源入嚟，分診 Agent 分類之後路由畀對應嘅調查 Agent，調查結果再流向響應協調 Agent。事件一個階段接一個階段咁流落去，新出咗乜嘢威脅類型就加個新 Agent，各個 Agent 仲可以獨立開發部署。

代價係可追溯性變差咗。一個告警觸發五個 Agent 之間嘅事件級聯，要搞清楚到底發生咗乜嘢，調試難度比編排模式嗰種順序決策鏈高咗好多。路由器分錯類或者丟咗事件更麻煩，系統會靜默失敗，乜嘢都唔處理但係又唔崩潰。

模式五：共享狀態

前四種模式入面都有一個中心角色喺管理信息流。共享狀態模式將呢個中間人移除咗。

冇中央協調者。Agent 自主運行，讀寫一個共享嘅數據庫、檔案系統或文檔。工作一般都係由放一個問題或數據集入儲存開始。停落嚟嘅條件有幾種：時間到咗、結果收斂咗，或者有個專門嘅 Agent 判斷儲存入面嘅嘢已經夠用。

研究綜合場景係呢個模式嘅主場。多個 Agent 分頭調查一個複雜問題嘅唔同方面，學術 Agent 發現咗一個關鍵研究者，呢條信息對行業 Agent 調查呢個研究者嘅公司即刻就有用。唔使等協調者嚟路由，發現直接寫入儲存，其他 Agent 馬上就可以睇到。附帶好處係冇單點故障，任何一個 Agent 停咗，其他 Agent 繼續讀寫。

代價都好明顯。Agent 可能重複工作或者行互相矛盾嘅方向。更棘手嘅係反應式循環：Agent A 寫咗一個發現，Agent B 讀到之後寫咗跟進，Agent A 見到跟進之後又回應。系統持續燒 token 但唔收斂。重複工作同並發寫入有成熟嘅工程方案，加鎖、版本控制、分區都得。但反應式循環係行為層面嘅問題，一定要認真設計終止條件：時間預算、收斂閾值，或者專門嘅 Agent 嚟判斷幾時應該停。

呢個模式令我諗起分佈式系統入面嘅最終一致性。冇強協調者嘅好處係吞吐量高、冇瓶頸，但係你需要喺應用層面處理衝突同收斂問題。Agent 領域都係同樣嘅取捨。

點樣揀，點樣演進

五種模式擺喺面前，揀邊個？Anthropic 畀咗幾組對比嘅決策邏輯，我覺得最實用嘅係前兩組。

編排-子Agent vs Agent 團隊

兩者都有協調者分派工作，分別在於 worker 需要維持上下文幾耐。子任務短小、輸出明確嘅，用編排模式。子任務需要多步驟持續工作、會從積累嘅上下文中受益嘅，用團隊模式。判斷標準係：當子 Agent 需要跨調用保留狀態時，團隊模式更合適。

我自己嘅經驗都驗證咗呢一點。Claude Code 日常嘅代碼搜索、檔案查閲用編排模式完全夠用，subagent 做完就走。但之前寫複雜 feature 嘅時候，需要多個 Agent 持續處理唔同模塊嘅開發同測試，編排模式嘅一次性 subagent 就唔夠用，每次都要重新理解模塊上下文。

編排-子Agent vs 消息總線

兩者都能夠處理多步驟工作流，分別在於工作流結構係咪可預測。步驟順序事先已知嘅，用編排模式。工作流由事件驅動、可能隨發現變化嘅，用消息總線。有個經驗法則：當編排 Agent 入面嘅條件分支越來越多、需要處理越來越多嘅特殊情況時，就應該考慮換消息總線喇。

Agent 團隊 vs 共享狀態

各自管理各自嘅，互不交叉，用團隊模式。發現需要實時流通，用共享狀態。一旦 worker 之間需要互相溝通而唔係淨係最後匯總結果，共享狀態更自然。

消息總線 vs 共享狀態

事件從一個階段觸發到下一個階段然後完成嘅，用消息總線。Agent 喺持續積累嘅知識基礎上反覆迭代嘅，用共享狀態。仲有一個值得留意嘅信號：如果消息總線入面嘅 Agent 發佈事件係為咗分享發現而唔係觸發動作，咁你可能需要嘅係共享狀態。

寫喺最後

實際生產系統往往會混用多種模式。常見嘅組合係外層用編排-子Agent 管整體工作流，內層某個協作密集嘅子任務用共享狀態。或者外層用消息總線做事件路由，每種事件類型由一個 Agent 團隊嚟處理。呢五種模式係積木，唔係互斥嘅選項。

Anthropic 嘅建議係由編排-子Agent 開始。佢能夠覆蓋最廣嘅問題範圍，協調開銷亦都最低。等佢喺特定場景下頂唔順，再根據具體瓶頸演進到其他模式。

Claude Code 就係編排-子Agent 模式嘅典型實現，對大多數日常任務嚟講完全夠用。只有當任務複雜到需要多個 Agent 持續協作、共享中間發現嘅時候，先值得引入更複雜嘅模式。

有意思嘅係，唔同框架對協調模式嘅抽象思路差異好大。Anthropic 呢套分類偏描述性，話畀你知有啲乜嘢模式、點樣揀。LangGraph 行嘅係 graph-based 嘅路線，用狀態圖來定義 Agent 之間嘅流轉邏輯，更偏編程範式。CrewAI 就係角色分工優先，先定義 Agent 嘅角色同目標，協調模式隱含喺角色關係入面。三種抽象各有適用場景，但底層要解決嘅問題係一樣：邊個同邊個通信、信息點樣流、幾時應該停。

相關資源：

• • 原文連結：https://claude.com/blog/multi-agent-coordination-patterns
• • 構建多 Agent 系統：https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
• • Harness 設計：https://www.anthropic.com/engineering/harness-design-long-running-apps
• • Managed Agents：https://www.anthropic.com/engineering/managed-agents
• • 構建有效 Agent：https://www.anthropic.com/engineering/building-effective-agents

好啦，今日就傾到呢度。如果你都喺度探索多 Agent 架構同 AI 編程，歡迎關注 Feisky 公眾號，我會定期分享實踐入面嘅發現同踩坑經驗。

題記：本文編譯自 Anthropic 博客《Multi-agent coordination patterns: Five approaches and when to use them^[1]》，由 Cara Phillips 撰寫。

用一個 Agent 搞不定複雜任務？上多 Agent 吧。這個判斷現在大家基本都認了。但上多 Agent 之後緊跟着一個更具體的問題：這些 Agent 之間怎麼配合？

我之前寫過 Anthropic 的 Harness 設計和 Managed Agents 架構，都涉及到多 Agent 的分工協作。但那兩篇偏重怎麼搭基礎設施，沒有系統聊過協調模式本身該怎麼選。網上能找到的多 Agent 教程大多也停留在“拆任務 + 合結果”這個層面，對模式之間的取捨和演進路徑講得不多。Anthropic 剛發的這篇博客正好補了這個缺口，把多 Agent 協調歸納成五種模式，從最簡單到最複雜，還給出了什麼時候該從一種演進到另一種的判斷標準。

讀完最大的感受是：大部分團隊的問題不是不知道多 Agent 的好處，而是上來就挑了一個聽起來最酷的模式，結果被協調開銷拖死了。Anthropic 的建議是，從最簡單的能跑通的模式開始，看它哪裏撐不住了，再往上演進。

模式一：生成-驗證

這是最簡單的多 Agent 模式，也是部署最廣的。

邏輯很簡單。一個 Agent 負責生成輸出，另一個負責評估。評估通過就結束，不通過就把反饋打回給生成方，重新來一輪。循環下去直到通過或者達到最大迭代次數。

最典型的應用是代碼生成：一個 Agent 寫代碼，另一個寫測試、跑測試。客服場景也適用，生成方起草郵件回覆，驗證方檢查是否準確引用了產品文檔、是否回應了用戶提到的每個問題。

這個模式看着簡單，但踩坑的地方也很集中。

最常見的失敗是驗證標準太模糊。如果你只告訴驗證方檢查輸出是否足夠好，它大概率會糊弄人，放行所有東西。驗證方的價值完全取決於你能不能把“好”拆成具體的、可檢查的標準。

這一點在我之前寫 Harness 設計那篇裏也提過。Anthropic 的工程師 Prithvi 花了很多精力調教 Evaluator，反覆看日誌、找判斷偏差、改 Prompt，來回迭代了好幾輪才讓它的評分標準達到合理水平。

另一個問題是迭代循環可能卡死。生成方解決不了驗證方提的問題，兩邊來回震盪不收斂。所以必須設最大迭代次數，加一個兜底策略，比如升級給人處理，或者返回當前最好的版本並標註問題。

模式二：編排-子Agent

這是層級式的分工。一個 Agent 當 Team Lead，負責規劃任務、分配工作、彙總結果。子 Agent 接到具體任務後執行完就彙報。

Claude Code 用的就是這個模式。主 Agent 自己寫代碼、編輯文件、跑命令，需要搜索大型代碼庫或者調查獨立問題時，就在後台派 subagent 去做，自己繼續手頭的活。每個 subagent 在自己的上下文窗口裏工作，完成後把精煉過的結果返回給主 Agent。

這個模式適合任務拆分清晰、子任務之間依賴少的場景。比如自動化代碼審查：一個 PR 進來，需要查安全漏洞、檢查測試覆蓋率、評估代碼風格、驗證架構一致性。每個檢查維度獨立、上下文不同、輸出格式明確。編排 Agent 把每個檢查派給專門的子 Agent，收集結果後合成一份統一的 Review。

問題出在信息瓶頸上。當子 Agent 發現了對其他子 Agent 有用的信息時，這條信息必須經過編排 Agent 中轉。安全子 Agent 發現了一個認證漏洞，這個發現影響架構子 Agent 的分析。編排 Agent 需要識別這種依賴關係並正確路由信息。經過幾輪中轉之後，關鍵細節經常被丟失或者在摘要中被省略掉。

我在用 Claude Code 的 subagent 時也有類似體感。subagent 搜完代碼庫回來的結果有時候會把關鍵上下文壓縮掉，主 Agent 拿到的是一個乾淨但不夠完整的摘要。對於簡單查詢這不是問題，但對於需要子 Agent 之間共享發現的複雜任務，編排模式就開始吃力了。

模式三：Agent 團隊

編排模式裏的子 Agent 是用完即棄的。接到任務，幹完活，交結果，走人。但如果任務需要 worker 在多輪中積累經驗呢？

Agent 團隊模式的區別就在這裏：worker 是持久的。

一個協調者啓動多個 worker Agent 作為獨立進程。領任務，幹活，交結果。不重置，不遺忘。每個 worker 在多輪迭代中積累對自己負責領域的熟悉度。

最直觀的例子是大規模代碼遷移。每個 worker 分管一個服務，在反覆處理這個服務的依賴、測試、部署配置的過程中，逐漸摸清它的脾氣。一次性 subagent 每次接手都要重新理解服務的配置約定和依賴關係，持久 worker 第一次弄明白之後後續迭代直接複用，省掉重複的上下文加載。

但獨立性是硬前提。

團隊模式裏的 worker 沒有中間人幫忙傳話。一個 worker 的改動影響了另一個，誰都不知道，產出可能衝突。多個 worker 操作同一個代碼庫時尤其明顯，常見的應對方式是文件級別的分區或者合併前跑衝突檢測，但這增加了協調者的複雜度。完成時間的參差也是個問題，一個 worker 兩分鐘搞定，另一個要二十分鐘，協調者得有耐心等。

模式四：消息總線

前面三種模式都有明確的協調者在指揮交通。但如果 Agent 數量繼續增加、交互模式變得不可預測呢？

消息總線引入了一個共享通信層。核心操作就兩個：發佈和訂閲。Agent 訂閲自己關心的 topic，路由器負責分發。新 Agent 上線不需要改已有的連接，訂閲相關 topic 就能開始接收工作。搞過微服務事件驅動架構的應該不陌生，本質上就是 Kafka 那套思路，只不過參與者從服務變成了 Agent。

Anthropic 舉的例子是安全運維自動化。告警從多個來源進來，分診 Agent 分類後路由給對應的調查 Agent，調查結果再流向響應協調 Agent。事件一個階段接一個階段地流下去，新出了什麼威脅類型就加個新 Agent，各個 Agent 還能獨立開發部署。

代價是可追溯性變差了。一個告警觸發五個 Agent 之間的事件級聯，要搞清楚到底發生了什麼，調試難度比編排模式那種順序決策鏈高了不少。路由器分錯類或者丟了事件更麻煩，系統會靜默失敗，什麼都不處理但也不崩潰。

模式五：共享狀態

前四種模式裏都有一箇中心角色在管理信息流。共享狀態模式把這個中間人去掉了。

沒有中央協調者。Agent 自主運行，讀寫一個共享的數據庫、文件系統或文檔。工作一般從往存儲裏丟一個問題或數據集開始。停下來的條件有幾種：時間到了、結果收斂了，或者有個專門的 Agent 判斷存儲裏的東西已經夠用了。

研究綜合場景是這個模式的主場。多個 Agent 分頭調查一個複雜問題的不同方面，學術 Agent 發現了一個關鍵研究者，這條信息對行業 Agent 調查這個研究者的公司立刻就有用。不用等協調者來路由，發現直接寫進存儲，其他 Agent 馬上就能看到。附帶好處是沒有單點故障，任何一個 Agent 停了，其他 Agent 繼續讀寫。

代價也很明顯。Agent 可能重複工作或者走互相矛盾的方向。更棘手的是反應式循環：Agent A 寫了一個發現，Agent B 讀到後寫了跟進，Agent A 看到跟進後又回應。系統持續燒 token 但不收斂。重複工作和併發寫入有成熟的工程方案，加鎖、版本控制、分區都行。但反應式循環是行為層面的問題，必須認真設計終止條件：時間預算、收斂閾值，或者專門的 Agent 來判斷何時該停。

這個模式讓我想到分佈式系統裏的最終一致性。沒有強協調者的好處是吞吐量高、沒有瓶頸，但你需要在應用層面處理衝突和收斂問題。Agent 領域也是同樣的取捨。

怎麼選，怎麼演進

五種模式擺在面前，選哪個？Anthropic 給了幾組對比的決策邏輯，我覺得最實用的是前兩組。

編排-子Agent vs Agent 團隊

兩者都有協調者分派工作，區別在於 worker 需要維持上下文多久。子任務短小、輸出明確的，用編排模式。子任務需要多步驟持續工作、會從積累的上下文中受益的，用團隊模式。判斷標準是：當子 Agent 需要跨調用保留狀態時，團隊模式更合適。

我自己的經驗也驗證了這一點。Claude Code 日常的代碼搜索、文件查閲用編排模式完全夠用，subagent 幹完就走。但之前寫複雜 feature 的時候，需要多個 Agent 持續處理不同模塊的開發和測試，編排模式的一次性 subagent 就不夠用了，每次都要重新理解模塊上下文。

編排-子Agent vs 消息總線

兩者都能處理多步驟工作流，區別在於工作流結構是否可預測。步驟順序事先已知的，用編排模式。工作流由事件驅動、可能隨發現變化的，用消息總線。有個經驗法則：當編排 Agent 裏的條件分支越來越多、需要處理越來越多的特殊情況時，就該考慮換消息總線了。

Agent 團隊 vs 共享狀態

各管各的互不交叉，用團隊模式。發現需要實時流通，用共享狀態。一旦 worker 之間需要互相溝通而不只是最後彙總結果，共享狀態更自然。

消息總線 vs 共享狀態

事件從一個階段觸發到下一個階段然後完成的，用消息總線。Agent 在持續積累的知識基礎上反覆迭代的，用共享狀態。還有一個值得留意的信號：如果消息總線裏的 Agent 發佈事件是為了分享發現而不是觸發動作，那你可能需要的是共享狀態。

寫在最後

實際生產系統往往會混用多種模式。常見的組合是外層用編排-子Agent 管整體工作流，內層某個協作密集的子任務用共享狀態。或者外層用消息總線做事件路由，每種事件類型由一個 Agent 團隊來處理。這五種模式是積木，不是互斥的選項。

Anthropic 的建議是從編排-子Agent 開始。它能覆蓋最廣的問題範圍，協調開銷也最低。等它在特定場景下撐不住了，再根據具體瓶頸演進到其他模式。

Claude Code 就是編排-子Agent 模式的典型實現，對大多數日常任務來說完全夠用。只有當任務複雜到需要多個 Agent 持續協作、共享中間發現的時候，才值得引入更復雜的模式。

有意思的是，不同框架對協調模式的抽象思路差異很大。Anthropic 這套分類偏描述性，告訴你有哪些模式、怎麼選。LangGraph 走的是 graph-based 的路子，用狀態圖來定義 Agent 之間的流轉邏輯，更偏編程範式。CrewAI 則是角色分工優先，先定義 Agent 的角色和目標，協調模式隱含在角色關係裏。三種抽象各有適用場景，但底層要解決的問題是一樣的：誰跟誰通信、信息怎麼流、什麼時候該停。

相關資源：

• • 原文連結：https://claude.com/blog/multi-agent-coordination-patterns
• • 構建多 Agent 系統：https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
• • Harness 設計：https://www.anthropic.com/engineering/harness-design-long-running-apps
• • Managed Agents：https://www.anthropic.com/engineering/managed-agents
• • 構建有效 Agent：https://www.anthropic.com/engineering/building-effective-agents

好了，今天就聊到這兒。如果你也在探索多 Agent 架構和 AI 編程，歡迎關注 Feisky 公眾號，我會定期分享實踐中的發現和踩坑經驗。