單一 Agent 即使擁有強大的 LLM、規劃（Planning）、記憶（Memory）與工具呼叫（Tool Calling）機制，在面對複雜的真實世界任務時，依然會迅速撞上效能與穩定度的極限。

引進 Multi-Agent（多 Agent 協同架構） 不是為了把架構搞複雜，而是為了將軟體工程中的分工、封裝與降維思維引入 AI 系統中。

一、 單一 Agent 的「四大致命瓶頸」

當我們嘗試用「一個超強 Agent 搞定所有事」時，系統通常會在以下四個層面崩潰：

1. Context Window 資訊污染（Context Contamination）：

• 隨著對話輪次增加，系統 Prompt、程式碼、搜尋結果、工具呼叫紀錄通通塞在同一個視窗。模型注意力會嚴重分散，導致「中間遺忘（Lost in the Middle）」或忽略核心指令。

2. 工具過載（Tool Overload）：

• 如果給單一 Agent 綁定 20 個工具，模型在決定「當下該選哪個工具」時的錯誤率會呈指數級上升。

3. 角色衝突與認知負載（Role Conflict）：

• 讓同一個 Agent 既當「創意寫手」、又當「嚴苛的 Code Reviewer」、還要當「SQL 查詢員」，模型很難在同一個 Context 下完美切換完全相反的人設與評判標準。

4. 單點故障與除錯困難（Single Point of Failure & Un-debuggable）：

• 當一個 10 步驟的任務在第 7 步出錯時，整條軌跡（Trajectory）過於龐大，很難進行局部重試（Retry）或定位是哪一個工具回傳干擾了最終決策。

二、 Multi-Agent 的核心價值：康威定律與模組化

Multi-Agent 的本質是「Divide and Conquer（分治法）」。它借鏡了人類組織管理與微服務架構（Microservices）的優點：

                    ┌───────────────────────────┐
                    │  Orchestrator / Router    │
                    └─────────────┬─────────────┘
                                  │
     ┌────────────────────────────┼────────────────────────────┐
     ▼                            ▼                            ▼
【Coder Agent】           【Reviewer Agent】          【Researcher Agent】
- 專注寫程式碼              - 專注尋找漏洞/批判          - 專注搜尋與資料整理
- 綁定：FS Edit Tools       - 綁定：Linter/Tester       - 綁定：Search / RAG

1. 專責化與 Context 隔離（Context Isolation）

• 乾淨的專屬視窗：每個 Agent 只接收與其任務相關的 Prompt 和上下文。Researcher 的幾萬字搜尋結果不用全部塞給 Coder，只需傳遞「摘要後的 API 規格」即可。
• 縮減工具集：每個 Agent 只綁定 2~3 個專用 Tool，大幅提升 Tool Calling 的精準度。

2. 異質模型混合搭配（Cost & Latency Optimization）

• 在 Multi-Agent 系統中，不需要所有節點都使用最高昂的旗艦模型（如 Claude 3.5 Sonnet / GPT-4o）：

• 主控/規劃（Orchestrator）：用 GPT-4o 負責複雜推理與任務指派。

• 簡單執行（Workers）：用 GPT-4o-mini 或 Claude 3 Haiku 進行簡單格式轉換或資料抽取。

• 程式碼生成（Coder）：用專門優化 Coding 的模型。

• 這能大幅降低 Token 費用並提升整體回應速度。

3. 自然引入「對立制衡」機制（Adversarial & Dynamic Verification）

• 單一 Agent 很難「自己挑自己的毛病」（存在自我偏見 Self-Bias）。
• Multi-Agent 能輕鬆建立 Generator vs. Critic 或 Red Team vs. Blue Team 機制。例如：一個 Agent 負責寫 SQL，另一個 Agent 專門扮演 DB 專家審查查詢效能與 SQL Injection 風險，通過後才真正對資料庫執行。

三、 現代 Multi-Agent 的三大主流拓撲結構（Topologies）

根據任務複雜度，業界主要採用以下三種協同架構：

四、 Multi-Agent 的落地挑戰：什麼時候「不該」用 Multi-Agent？

Multi-Agent 雖然強大，但也帶來了嚴重的工程複雜度：

• 通信延遲（Latency Explosion）：Agent 之間的每輪對話與轉發都是額外的 API 呼叫，回應時間可能從 3 秒拉長到 30 秒以上。
• 無限對話死迴圈（Infinite Agent Loops）：如果兩個 Agent 意見不合（例如：A 覺得 Code 還不夠完美，B 覺得已經改好了），容易在彼此批評中耗盡 Token。
• 責任歸屬難定（Agent Confusion）：訊息傳遞過多導致中途資訊失真。

💡 工程原則：

1. 能用單一 Prompt 解決的，不要用 Agent。
2. 能用單一 Agent + Tool 解決的，不要用 Multi-Agent。
3. 只有當 Context 爆滿、工具過多無法收斂，或需要明確的角色制衡（如 寫 Code + Code Review）時，才是引入 Multi-Agent 的最佳時機。