設計多智能體系統時真正幫到我的一篇文章

最近團隊在設計智能體系統。單個智能體已經有了一定的掌握，但要把多個串在一起時，才發現要考慮的問題遠比想像中多。

用什麼結構來編排？通訊怎麼做？記憶體怎麼管理？

後來發現了 Rohit Ghumare 寫的一篇文章，幾乎把我糾結的問題都釐清了，分享給大家。也附上了我自己的實戰經驗。

為什麼要用多智能體

之前的文章中也提過，多智能體並不總是最佳解。但去年一整年，我在單智能體的上下文管理上反覆踩坑。

核心問題是：單智能體的上下文視窗很快就滿了，一旦滿了就容易遺失上下文。再加上同時處理多個領域時，判斷力會明顯下降。

多智能體可以透過關注點分離來解決這個問題，但代價是引入了協調開銷。如何管理這個開銷才是關鍵，文章對此有非常具體的討論。

三種編排模式

這部分最實用。不是按「哪個更炫」來分類，而是按**「什麼時候用什麼」**來組織的。

監督者模式 (Supervisor)

管理智能體負責任務分解、分配給工作者、彙總結果。

• 適合情境：任務可以明確拆分為子任務，或需要追蹤稽核時
• 最佳規模：3-8 個工作者
• 注意：所有決策都經過監督者，容易成為瓶頸

群體模式 (Swarm)

沒有中心管理者，智能體之間 P2P 直接通訊，自主組織。

• 適合情境：需要多角度分析，或即時回應很重要時
• 注意：重複工作、無限迴圈、次優收斂的風險。除錯非常困難

階層模式 (Hierarchical)

監督者模式的遞迴擴展。頂層 → 中層管理者 → 工作者的多層結構。

• 適合情境：智能體 10 個以上，需要分離策略和戰術時
• 注意：每增加一個協調層，token 成本急劇上升

從個人實踐來看，監督者模式是最穩定的。關鍵在於工作者分配的效率和錯誤處理 - 如果做不好，管理智能體本身就會成為故障點。

智能體間的通訊方式

如果說編排模式決定了結構，那通訊方式就決定了資訊在智能體之間實際怎麼流動。

• 共享狀態 (Shared State)：所有智能體讀寫同一個狀態物件。實作簡單，除錯方便。大多數情況從這裡開始就夠了
• 訊息傳遞 (Message Passing)：透過事件匯流排進行非同步通訊。需要智能體之間保持鬆耦合時使用
• 交接 (Handoff)：智能體之間明確傳遞接力棒和上下文。適合固定順序的管線

多智能體的記憶體架構

核心問題很直接：*如何在共享狀態的同時避免衝突？*文章給出了三種模式。

基於工作階段的記憶體 (Session-Based)

每個智能體在隔離的本地狀態中工作，完成後將變更合併到共享記憶體。

• 適合情境：平行工作者需要獨立工作互不干擾時
• 運作方式：工作階段開始時取得共享狀態快照，在本地工作 → 工作階段結束時只合併差異
• 優勢：無衝突的平行處理

視窗記憶體 (Window Memory)

滑動視窗只保留最近 N 次互動，舊的內容壓縮為摘要。

• 適合情境：長對話中需要保持上下文同時控制 token 消耗時
• 運作方式：視窗溢出時，將最舊的 1/3 壓縮為摘要
• 優勢：解決狀態無限增長的問題

情節記憶 (Episodic Memory)

儲存特定智能體組合的歷史協作紀錄和結果，用於學習優化。

• 適合情境：經常協作的智能體需要根據過去經驗進行改進時
• 運作方式：記錄哪些智能體組合在哪些任務上成功或失敗
• 優勢：可以做出「上次這個組合效果好，再用一次」這樣的決策

正式環境注意事項

Token 成本

• 監督者 + 4 個工作者：分解 1K + 工作者 12K + 彙總 2K = 約 15K token
• 同樣的任務單智能體大約 4K。協調成本接近 4 倍
• 優化：快取監督者指令，工作者輸出用結構化資料，按需呼叫

延遲

• 每次 LLM 呼叫 2-5 秒，4 個智能體串列 12 秒，平行 3-4 秒
• 獨立任務一定要平行化

錯誤傳播防護

• 逾時：每一層都必須設定
• 熔斷器：連續失敗 N 次後停止呼叫該智能體
• 優雅降級：部分智能體不可用時核心功能仍然運作
• 狀態隔離：工作者失敗不能污染共享狀態

看不到就修不了。監控從第一天起就是必需品。

應該避免的反模式

• 過度編排：把本可以獨立運行的智能體強行串聯
• 萬能智能體：一個做所有事，那多智能體就沒意義了
• 忽視成本：不做 token 監控就上線，看到帳單才嚇到
• 沒有降級方案：假設所有智能體都永遠可用

總結

文章的結論最打動我：

先做一個智能體 → 找到瓶頸 → 在瓶頸處加第二個智能體 → 需要的話加監督者 → 重複。

我一開始也是用階層模式做了個宏大設計，最後簡化成了監督者 + 3 個工作者。先把兩個智能體的穩定協作跑通，再往上擴展，這才是正確的路徑。

如果你正在考慮多智能體系統，推薦讀一讀原文。

原文：Building Effective Multi-Agent Systems