多 Agent 設計模式 (Multi-Agent Design)
原文：Microsoft AI Agents for Beginners · MIT 授權
課程簡介
一旦你開始處理涉及多個 Agent 的專案，你就必須思考多 Agent 設計模式。但什麼時候該切換到多 Agent？又有哪些優勢？本課將回答：
- 哪些場景適合使用多 Agent？
- 相較於讓單一 Agent 做所有事，多 Agent 有什麼優勢？
- 實作多 Agent 設計模式的建構模塊有哪些？
- 如何觀察多個 Agent 之間的互動？
學習目標
- 辨識多 Agent 適用的場景
- 理解多 Agent 相對於單一 Agent 的優勢
- 掌握實作多 Agent 設計模式的建構模塊
多 Agent 適用場景
哪些場景適合使用多 Agent？以下是最典型的幾種：
| 場景類型 | 說明 | 實際範例 |
|---|---|---|
| 大規模工作負載 | 將大型工作負載拆分成小任務，分配給不同 Agent 並行處理，加速完成 | 大規模資料處理任務，每個 Agent 處理一部分數據 |
| 複雜任務 | 將複雜任務拆分成子任務，每個 Agent 專精於特定面向 | 自動駕駛：導航 Agent、障礙物偵測 Agent、車輛通訊 Agent 各司其職 |
| 多元專業知識 | 不同 Agent 擁有不同領域的專業知識，協同處理更全面 | 醫療：診斷 Agent、治療計畫 Agent、病患監控 Agent |
使用多 Agent 的優勢（相較於單一 Agent）
單一 Agent 系統在簡單任務上表現良好，但面對複雜任務時，多 Agent 能提供以下優勢：
| 優勢 | 說明 |
|---|---|
| 專業化 (Specialization) | 每個 Agent 專精於特定任務。單一 Agent 缺乏專業化時，雖然什麼都能做，但面對複雜任務容易混淆，甚至做了自己不擅長的事 |
| 可擴展性 (Scalability) | 透過新增 Agent 來擴展系統，遠比讓單一 Agent 過載來得容易 |
| 容錯能力 (Fault Tolerance) | 某個 Agent 故障時，其他 Agent 仍可繼續運作，確保系統可靠性 |
訂旅行行程：單一 vs 多 Agent
以幫使用者訂一趟旅行為例：
- 單一 Agent：必須同時處理找航班、訂飯店、租車等所有環節。Agent 需要具備全部工具，導致系統變得複雜、單體化、難以維護和擴展。
- 多 Agent 系統：找航班 Agent、訂飯店 Agent、租車 Agent 各自專精。系統更模組化、更容易維護、更具可擴展性。
這就像夫妻老婆店旅行社 vs. 連鎖旅行社——前者一人包辦所有事，後者每人分工明確、各有所長。
實作多 Agent 設計模式的建構模塊
在實作多 Agent 設計模式之前，你需要了解構成此模式的基礎模塊。讓我們繼續以訂旅行為例：
| 建構模塊 | 說明 | 關鍵問題 |
|---|---|---|
| Agent 通訊 | 航班 Agent、飯店 Agent、租車 Agent 之間需要共享使用者的偏好和限制資訊（如旅行日期） | 哪些 Agent 在共享資訊？ 它們如何共享資訊？ |
| 協調機制 | Agent 必須協調行動以滿足使用者偏好（如「飯店靠近機場」）和限制（如「租車僅在機場提供」） | Agent 如何協調它們的行動？ |
| Agent 架構 | 每個 Agent 需要內部結構來做決策，並從與使用者的互動中學習（例如：基於歷史偏好推薦航班） | Agent 如何做決策和從互動中學習？ |
| 多 Agent 互動可視性 | 需要工具和技術來追蹤 Agent 的活動和互動：日誌記錄、監控工具、視覺化工具、效能指標 | 如何看到 Agent 之間在「聊什麼」？ |
| 多 Agent 模式 | 不同的實作模式：集中式、分散式、混合式架構 | 哪種模式最適合你的場景？ |
| 人機迴圈 (Human in the loop) | 在大多數情況下需要人類參與，你必須指示 Agent 何時請求人類介入——例如使用者要求特定飯店或確認預訂 | 何時把球傳給人類？ |
多 Agent 互動的可視性 (Visibility)
能夠看到多個 Agent 之間的互動至關重要——這對偵錯、優化和確保整體系統效能都是必須的。要達成可視性，你需要以下工具：
日誌記錄與監控工具
記錄每個 Agent 的每個動作：哪個 Agent 做了什麼、何時做的、結果如何。這些資訊可用於偵錯和優化。
視覺化工具
用圖形直觀顯示 Agent 之間的資訊流，幫助識別瓶頸、低效率和其他問題。
效能指標
追蹤任務完成時間、單位時間完成任務數、Agent 建議的準確率等，幫助識別改進空間。
多 Agent 模式 (Patterns)
以下是幾種值得參考的具體實作模式：
1. 群組聊天 (Group Chat)
適用場景：團隊協作、客服支援、社群網路
每個 Agent 代表群組中的一個使用者，訊息透過通訊協定在 Agent 之間交換。可使用集中式架構（訊息由中央伺服器路由）或分散式架構（直接交換訊息）。
2. 交接 (Hand-off)
適用場景：客服支援、任務管理、工作流程自動化
每個 Agent 代表工作流程中的一個任務或步驟，Agent 根據預定義規則將任務交接給下一個 Agent。例如：客服機器人先收集問題 → 交接給技術專家 Agent → 必要時交接給人類客服。
3. 協作過濾 (Collaborative Filtering)
適用場景：推薦系統，需要匯集多方專業知識
多個 Agent 各自擁有不同專業，協作為使用者提供更全面的建議。以股票推薦為例：
- 產業專家 Agent：專精特定產業趨勢
- 技術分析 Agent：專精技術指標與圖表
- 基本面分析 Agent：專精財務報表與估值
三者協作，提供比單一 Agent 更全面的投資建議。
場景演練：退款流程
考慮一個客戶申請退款的場景。涉及的 Agent 可區分為「退款專用」和「通用可重用」兩類：
退款專用 Agent
| Agent | 職責 |
|---|---|
| 客戶 Agent | 代表客戶，負責啟動退款流程 |
| 賣家 Agent | 代表賣家，負責處理退款 |
| 付款 Agent | 代表付款流程，負責退款給客戶 |
| 調解 Agent | 處理退款過程中的爭議和問題 |
| 合規 Agent | 確保退款流程符合法規與政策 |
通用 Agent（其他業務也可用）
| Agent | 職責 | 可重用場景 |
|---|---|---|
| 物流 Agent | 處理退貨運送 | 一般購物出貨也可用 |
| 回饋 Agent | 收集客戶意見 | 任何需要收集回饋的流程 |
| 升級 Agent | 將問題升級至高層支援 | 任何需要升級的流程 |
| 通知 Agent | 在退款各階段發送通知 | 任何需要通知的流程 |
| 分析 Agent | 分析退款相關數據 | 任何需要數據分析的流程 |
| 審計 Agent | 審計退款流程正確性 | 任何需要審計的流程 |
| 報表 Agent | 產生退款報表 | 任何需要報表的流程 |
| 知識庫 Agent | 維護退款相關知識庫 | 任何需要知識管理的場景 |
| 安全 Agent | 確保退款流程安全 | 任何需要安全防護的流程 |
| 品質 Agent | 確保退款流程品質 | 任何需要品質控管的流程 |
練習
設計一個客服支援流程的多 Agent 系統。識別流程中涉及的 Agent、各自的角色和責任、以及它們如何互動。同時考慮客服專用 Agent 和可重用的通用 Agent。
👉 查看解答
知識測驗
問題 1：哪個場景最適合使用多 Agent 系統？
- A1：一個客服機器人使用單一知識庫和少量工具回答常見問題
- A2：退款工作流程需要獨立的詐騙偵測、付款和合規角色，各自有專屬工具，結果必須協調 ✅
- A3：同樣的簡單分類請求每小時進來數千次
問題 2：何時單一 Agent 通常是更好的選擇？
- A1：任務可以用一組指令和工具處理，不需要專業分工交接 ✅
- A2：Agent 可以使用多個工具
- A3：工作流程需要不同角色、不同權限和獨立審計軌跡
👉 測驗解答
本課重點回顧
- 多 Agent 適用時機：大規模工作負載、複雜任務、需要多元專業知識的場景
- 三大核心優勢：專業化（各司其職）、可擴展性（加 Agent 不加重）、容錯能力（一個掛了其他繼續）
- 六大建構模塊：通訊、協調、架構、可視性、模式選擇、人機迴圈——缺一不可
- 三種實作模式：群組聊天（多對多通訊）、交接（鏈式傳遞）、協作過濾（多方專業匯集）
- 設計思維：區分流程專用 Agent 和通用 Agent，最大化複用價值