多 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 模式，也是部署最廣的。Generator-Verifier 模式邏輯很簡單。一個 Agent 負責生成輸出，另一個負責評估。評估通過就結束，不通過就把反饋打回給生成方，重新來一輪。循環下去直到通過或者達到最大迭代次數。最典型的應用是代碼生成：一個 Agent 寫代碼，另一個寫測試、跑測試。客服場景也適用，生成方起草郵件回覆，驗證方檢查是否準確引用了產品文檔、是否回應了用戶提到的每個問題。這個模式看着簡單，但踩坑的地方也很集中。最常見的失敗是驗證標準太模糊。如果你只告訴驗證方檢查輸出是否足夠好，它大概率會糊弄人，放行所有東西。驗證方的價值完全取決於你能不能把“好”拆成具體的、可檢查的標準。這一點在我之前寫 Harness 設計那篇裏也提過。Anthropic 的工程師 Prithvi 花了很多精力調教 Evaluator，反覆看日誌、找判斷偏差、改 Prompt，來回迭代了好幾輪才讓它的評分標準達到合理水平。另一個問題是迭代循環可能卡死。生成方解決不了驗證方提的問題，兩邊來回震盪不收斂。所以必須設最大迭代次數，加一個兜底策略，比如升級給人處理，或者返回當前最好的版本並標註問題。模式二：編排-子Agent這是層級式的分工。一個 Agent 當 Team Lead，負責規劃任務、分配工作、彙總結果。子 Agent 接到具體任務後執行完就彙報。Orchestrator-Subagent 模式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 是持久的。Agent Teams 模式一個協調者啓動多個 worker Agent 作為獨立進程。領任務，幹活，交結果。不重置，不遺忘。每個 worker 在多輪迭代中積累對自己負責領域的熟悉度。最直觀的例子是大規模代碼遷移。每個 worker 分管一個服務，在反覆處理這個服務的依賴、測試、部署配置的過程中，逐漸摸清它的脾氣。一次性 subagent 每次接手都要重新理解服務的配置約定和依賴關係，持久 worker 第一次弄明白之後後續迭代直接複用，省掉重複的上下文加載。但獨立性是硬前提。團隊模式裏的 worker 沒有中間人幫忙傳話。一個 worker 的改動影響了另一個，誰都不知道，產出可能衝突。多個 worker 操作同一個代碼庫時尤其明顯，常見的應對方式是文件級別的分區或者合併前跑衝突檢測，但這增加了協調者的複雜度。完成時間的參差也是個問題，一個 worker 兩分鐘搞定，另一個要二十分鐘，協調者得有耐心等。模式四：消息總線前面三種模式都有明確的協調者在指揮交通。但如果 Agent 數量繼續增加、交互模式變得不可預測呢？Message Bus 模式消息總線引入了一個共享通信層。核心操作就兩個：發佈和訂閲。Agent 訂閲自己關心的 topic，路由器負責分發。新 Agent 上線不需要改已有的連接，訂閲相關 topic 就能開始接收工作。搞過微服務事件驅動架構的應該不陌生，本質上就是 Kafka 那套思路，只不過參與者從服務變成了 Agent。Anthropic 舉的例子是安全運維自動化。告警從多個來源進來，分診 Agent 分類後路由給對應的調查 Agent，調查結果再流向響應協調 Agent。事件一個階段接一個階段地流下去，新出了什麼威脅類型就加個新 Agent，各個 Agent 還能獨立開發部署。代價是可追溯性變差了。一個告警觸發五個 Agent 之間的事件級聯，要搞清楚到底發生了什麼，調試難度比編排模式那種順序決策鏈高了不少。路由器分錯類或者丟了事件更麻煩，系統會靜默失敗，什麼都不處理但也不崩潰。模式五：共享狀態前四種模式裏都有一箇中心角色在管理信息流。共享狀態模式把這個中間人去掉了。Shared State 模式沒有中央協調者。Agent 自主運行，讀寫一個共享的數據庫、文件系統或文檔。工作一般從往存儲裏丟一個問題或數據集開始。停下來的條件有幾種：時間到了、結果收斂了，或者有個專門的 Agent 判斷存儲裏的東西已經夠用了。研究綜合場景是這個模式的主場。多個 Agent 分頭調查一個複雜問題的不同方面，學術 Agent 發現了一個關鍵研究者，這條信息對行業 Agent 調查這個研究者的公司立刻就有用。不用等協調者來路由，發現直接寫進存儲，其他 Agent 馬上就能看到。附帶好處是沒有單點故障，任何一個 Agent 停了，其他 Agent 繼續讀寫。代價也很明顯。Agent 可能重複工作或者走互相矛盾的方向。更棘手的是反應式循環：Agent A 寫了一個發現，Agent B 讀到後寫了跟進，Agent A 看到跟進後又回應。系統持續燒 token 但不收斂。重複工作和併發寫入有成熟的工程方案，加鎖、版本控制、分區都行。但反應式循環是行為層面的問題，必須認真設計終止條件：時間預算、收斂閾值，或者專門的 Agent 來判斷何時該停。這個模式讓我想到分佈式系統裏的最終一致性。沒有強協調者的好處是吞吐量高、沒有瓶頸，但你需要在應用層面處理衝突和收斂問題。Agent 領域也是同樣的取捨。怎麼選，怎麼演進五種模式擺在面前，選哪個？Anthropic 給了幾組對比的決策邏輯，我覺得最實用的是前兩組。編排-子Agent vs Agent 團隊編排-子Agent vs Agent 團隊兩者都有協調者分派工作，區別在於 worker 需要維持上下文多久。子任務短小、輸出明確的，用編排模式。子任務需要多步驟持續工作、會從積累的上下文中受益的，用團隊模式。判斷標準是：當子 Agent 需要跨調用保留狀態時，團隊模式更合適。我自己的經驗也驗證了這一點。Claude Code 日常的代碼搜索、文件查閲用編排模式完全夠用，subagent 幹完就走。但之前寫複雜 feature 的時候，需要多個 Agent 持續處理不同模塊的開發和測試，編排模式的一次性 subagent 就不夠用了，每次都要重新理解模塊上下文。編排-子Agent vs 消息總線編排-子Agent vs 消息總線兩者都能處理多步驟工作流，區別在於工作流結構是否可預測。步驟順序事先已知的，用編排模式。工作流由事件驅動、可能隨發現變化的，用消息總線。有個經驗法則：當編排 Agent 裏的條件分支越來越多、需要處理越來越多的特殊情況時，就該考慮換消息總線了。Agent 團隊 vs 共享狀態Agent 團隊 vs 共享狀態各管各的互不交叉，用團隊模式。發現需要實時流通，用共享狀態。一旦 worker 之間需要互相溝通而不只是最後彙總結果，共享狀態更自然。消息總線 vs 共享狀態消息總線 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 模式，也是部署最廣的。Generator-Verifier 模式邏輯很簡單。一個 Agent 負責生成輸出，另…
- 多 Agent 協調的五種模式：從最簡單的開始，按需演進
- 多 Agent 協調的五種模式：從最簡單的開始，按需演進｜重點 2
- 多 Agent 協調的五種模式：從最簡單的開始，按需演進｜重點 3
- 多 Agent 協調的五種模式：從最簡單的開始，按需演進｜重點 4
- 多 Agent 協調的五種模式：從最簡單的開始，按需演進｜重點 5
可記低 Prompt
題記：本文編譯自 Anthropic 博客《Multi-agent coordination patterns: Five approaches and when to use them[1]》，由 Cara Phillips 撰寫。用一個…
整理版
題記：本文編譯自 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 模式，也是部署最廣的。Generator-Verifier 模式邏輯很簡單。一個 Agent 負責生成輸出，另一個負責評估。評估通過就結束，不通過就把反饋打回給生成方，重新來一輪。循環下去直到通過或者達到最大迭代次數。最典型的應用是代碼生成：一個 Agent 寫代碼，另一個寫測試、跑測試。客服場景也適用，生成方起草郵件回覆，驗證方檢查是否準確引用了產品文檔、是否回應了用戶提到的每個問題。呢個模式看着簡單，但踩坑的地方也很集中。最常見的失敗是驗證標準太模糊。如果你只告訴驗證方檢查輸出是否足夠好，它大概率會糊弄人，放行所有東西。驗證方的價值完全取決於你能不能把“好”拆成具體的、可檢查的標準。這一點在我之前寫 Harness 設計那篇裏也提過。Anthropic 的工程師 Prithvi 花了很多精力調教 Evaluator，反覆看日誌、找判斷偏差、改 Prompt，來回迭代了好幾輪才讓它的評分標準達到合理水平。另一個問題是迭代循環可能卡死。生成方解決不了驗證方提的問題，兩邊來回震盪不收斂。所以必須設最大迭代次數，加一個兜底策略，比如升級給人處理，或者返回當前最好的版本並標註問題。模式二：編排-子Agent這是層級式的分工。一個 Agent 當 Team Lead，負責規劃任務、分配工作、彙總結果。子 Agent 接到具體任務後執行完就彙報。Orchestrator-Subagent 模式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 是持久的。Agent Teams 模式一個協調者啓動多個 worker Agent 作為獨立進程。領任務，幹活，交結果。不重置，不遺忘。每個 worker 在多輪迭代中積累對自己負責領域的熟悉度。最直觀的例子是大規模代碼遷移。每個 worker 分管一個服務，在反覆處理呢個服務的依賴、測試、部署配置的過程中，逐漸摸清它的脾氣。一次性 subagent 每次接手都要重新理解服務的配置約定和依賴關係，持久 worker 第一次弄明白之後後續迭代直接複用，省掉重複的上下文加載。但獨立性是硬前提。團隊模式裏的 worker 沒有中間人幫忙傳話。一個 worker 的改動影響了另一個，誰都不知道，產出可能衝突。多個 worker 操作同一個代碼庫時尤其明顯，常見的應對方式是文件級別的分區或者合併前跑衝突檢測，但這增加了協調者的複雜度。完成時間的參差也是個問題，一個 worker 兩分鐘搞定，另一個要二十分鐘，協調者得有耐心等。模式四：消息總線前面三種模式都有明確的協調者在指揮交通。但如果 Agent 數量繼續增加、交互模式變得不可預測呢？Message Bus 模式消息總線引入了一個共享通信層。核心操作就兩個：發佈和訂閲。Agent 訂閲自己關心的 topic，路由器負責分發。新 Agent 上線不需要改已有的連接，訂閲相關 topic 就能開始接收工作。搞過微服務事件驅動架構的應該不陌生，本質上就是 Kafka 那套思路，只不過參與者從服務變成了 Agent。Anthropic 舉的例子是安全運維自動化。告警從多個來源進來，分診 Agent 分類後路由給對應的調查 Agent，調查結果再流向響應協調 Agent。事件一個階段接一個階段地流下去，新出了什麼威脅類型就加個新 Agent，各個 Agent 還能獨立開發部署。代價是可追溯性變差了。一個告警觸發五個 Agent 之間的事件級聯，要搞清楚到底發生了什麼，調試難度比編排模式那種順序決策鏈高了不少。路由器分錯類或者丟了事件更麻煩，系統會靜默失敗，什麼都不處理但也不崩潰。模式五：共享狀態前四種模式裏都有一箇中心角色在管理信息流。共享狀態模式把呢個中間人去掉了。Shared State 模式沒有中央協調者。Agent 自主運行，讀寫一個共享的數據庫、文件系統或文檔。工作一般從往存儲裏丟一個問題或數據集開始。停下來的條件有幾種：時間到了、結果收斂了，或者有個專門的 Agent 判斷存儲裏的東西已經夠用了。研究綜合場景是呢個模式的主場。多個 Agent 分頭調查一個複雜問題的不同方面，學術 Agent 發現了一個關鍵研究者，這條信息對行業 Agent 調查呢個研究者的公司立刻就有用。不用等協調者來路由，發現直接寫進存儲，其他 Agent 馬上就能看到。附帶好處是沒有單點故障，任何一個 Agent 停了，其他 Agent 繼續讀寫。代價也很明顯。Agent 可能重複工作或者走互相矛盾的方向。更棘手的是反應式循環：Agent A 寫了一個發現，Agent B 讀到後寫了跟進，Agent A 看到跟進後又回應。系統持續燒 token 但不收斂。重複工作和併發寫入有成熟的工程方案，加鎖、版本控制、分區都行。但反應式循環是行為層面的問題，必須認真設計終止條件：時間預算、收斂閾值，或者專門的 Agent 來判斷何時該停。呢個模式讓我想到分佈式系統裏的最終一致性。沒有強協調者的好處是吞吐量高、沒有瓶頸，但你需要在應用層面處理衝突和收斂問題。Agent 領域也是同樣的取捨。怎麼選，怎麼演進五種模式擺在面前，選哪個？Anthropic 給了幾組對比的決策邏輯，我覺得最實用的是前兩組。編排-子Agent vs Agent 團隊編排-子Agent vs Agent 團隊兩者都有協調者分派工作，區別在於 worker 需要維持上下文多久。子任務短小、輸出明確的，用編排模式。子任務需要多步驟持續工作、會從積累的上下文中受益的，用團隊模式。判斷標準是：當子 Agent 需要跨調用保留狀態時，團隊模式更合適。我自己的經驗也驗證了這一點。Claude Code 日常的代碼搜索、文件查閲用編排模式完全夠用，subagent 幹完就走。但之前寫複雜 feature 的時候，需要多個 Agent 持續處理不同模塊的開發和測試，編排模式的一次性 subagent 就不夠用了，每次都要重新理解模塊上下文。編排-子Agent vs 消息總線編排-子Agent vs 消息總線兩者都能處理多步驟工作流，區別在於工作流結構是否可預測。步驟順序事先已知的，用編排模式。工作流由事件驅動、可能隨發現變化的，用消息總線。有個經驗法則：當編排 Agent 裏的條件分支越來越多、需要處理越來越多的特殊情況時，就該考慮換消息總線了。Agent 團隊 vs 共享狀態Agent 團隊 vs 共享狀態各管各的互不交叉，用團隊模式。發現需要實時流通，用共享狀態。一旦 worker 之間需要互相溝通而不只是最後彙總結果，共享狀態更自然。消息總線 vs 共享狀態消息總線 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 公眾號，我會定期分享實踐中的發現和踩坑經驗。
