若你正把檢索、推理、生成、審核全塞進一個 LLM Agent，卻在規模化時遭遇上下文爆滿、串行逾時與單點故障——本文給出可寫進架構評審的完整路徑：① 為什麼單 Agent 不夠、多 Agent 系統（MAS）的三種控制模式；② 覆蓋 95% 生產場景的六大編排設計模式（含 LangGraph / AutoGen 程式碼）；③ LangGraph vs CrewAI vs AutoGen 選型矩陣與 MCP+A2A 雙層通訊協定；④ 狀態持久化、可觀測性、四大踩坑與選型決策樹。與MCP 協定解讀、MCP Server 教學互補——本篇專注多 Agent 編排 → 框架選型 → 生產落地。
根據 MLflow 2026 年報告，Google 內部 Agent Bake-Off 實驗顯示，採用分散式多 Agent 架構後處理時間從 1 小時降至 10 分鐘，提升超過 6 倍。AdaptOrch（2026 學術論文）進一步證明：在多 Agent 系統中，編排拓撲的選擇對系統效能的影響比底層模型的選擇更大，在 SWE-bench 等基準上正確的拓撲可帶來 12–23% 的效能提升。
多 Agent 協作系統（Multi-Agent System，MAS）是指由多個獨立的 AI Agent 組成的系統，這些 Agent 透過明確的通訊協定與編排機制協作完成單個 Agent 無法高效完成的複雜任務。
Agent A 的輸出直接作為 Agent B 的輸入，嚴格線性執行。適用：步驟間有嚴格依賴、流程固定、不需要動態路由（文章創作流水線、程式碼審查流程）。
from langgraph.graph import StateGraph, START, END
from typing import TypedDict
class PipelineState(TypedDict):
query: str
retrieved_docs: str
analysis: str
final_report: str
def retrieval_agent(state):
return {"retrieved_docs": search_knowledge_base(state["query"])}
def analysis_agent(state):
result = llm.invoke(f"分析：{state['retrieved_docs']}")
return {"analysis": result.content}
builder = StateGraph(PipelineState)
builder.add_node("retriever", retrieval_agent)
builder.add_node("analyzer", analysis_agent)
builder.add_edge(START, "retriever")
builder.add_edge("retriever", "analyzer")
builder.add_edge("analyzer", END)
pipeline = builder.compile()
優缺點：實作簡單、行為可預測、適合合規稽核；但總耗時 = 各步之和，單步失敗整體阻塞，無法處理動態分支。
多個 Agent 同時處理獨立子任務，匯聚節點合併結果。總耗時 = max(T1, T2, ..., Tn) 而非求和。適用：子任務彼此獨立（多來源研究、多維度風險評估）。
from langgraph.types import Send
from typing import Annotated
import operator
class ResearchState(TypedDict):
query: str
research_results: Annotated[list, operator.add]
final_synthesis: str
def supervisor(state):
return [Send("research_worker", {"query": state["query"], "source": s})
for s in ("academic", "industry", "news")]
def research_worker(state):
return {"research_results": [search_by_source(state["query"], state["source"])]}
關鍵技術點：LangGraph 的 Send API 回傳 Send 物件列表，子圖會真正並行執行。配合 Annotated[list, operator.add] Reducer，並行分支結果自動聚合，無需手寫鎖或同步邏輯。
主管 Agent 負責意圖識別、任務拆解和路由決策，將子任務分配給專業 Worker，最後匯總。適用：工作可拆解為不同專業領域（研究員、寫手、程式設計師）、任務類型多樣需動態路由（Replit 程式碼助手、客服系統）。
雙層路由最佳化：第一層關鍵字快速通道（回應 <1ms，無需 LLM）；第二層 LLM 精確路由處理複雜/模糊意圖。
Agent 之間點對點直接傳遞任務，無中央協調者，依靠終止規則（輪數、共識、逾時）停止。適用：多輪協商和辯論（程式碼審查、方案評估）。注意：非確定性高，生產環境慎用，建議用層級模式替代。 AutoGen GroupChat 範例中須設定 max_round=6 硬性終止防止無限迴圈。
所有 Agent 共享一個結構化工作空間（黑板），Agent 在滿足前提條件時主動讀寫黑板，無需顯式調度。適用：長時間非同步任務（小時級甚至天級）、異構服務協作、工作流條件複雜難以提前預定路由。
在同一系統中組合多種模式，通常是「主管模式 + 流水線」。真實案例：Intent Agent 路由 → 簡單查詢直接回答；複雜報告 → Supervisor 層級 → 並行研究扇出 + 品質保障流水線（審核 → 人工審核 → 發布）。
| 維度 | LangGraph | CrewAI | AutoGen（微軟） |
|---|---|---|---|
| 架構典範 | 狀態機圖 | 角色制團隊 | 對話式多 Agent |
| 程式語言 | Python / JS/TS | Python | Python / .NET |
| 學習曲線 | 較陡 | 平緩 | 中等 |
| 狀態管理 | 原生支援 | 需自行實作 | 有限支援 |
| Human-in-the-Loop | 原生支援 | 需自行實作 | 支援 |
| 可觀測性 | LangSmith（商業） | 有限 | Azure Monitor |
| 生產就緒度 | 極高 | 中 | 高 |
| 快速原型 | 中 | 極高 | 高 |
| Azure 整合 | 中 | 偏低 | 極高 |
| 適用場景 | 複雜有狀態工作流 | 角色制內容流水線 | 對話式協作 |
選 LangGraph：生產級可靠性（金融、醫療）、複雜狀態管理與持久化、Human-in-the-Loop 精細控制、條件分支和迴圈精確表達。
選 CrewAI：1–2 天快速驗證 Idea、團隊用「角色」直覺理解 Agent、內容生成/研究報告等角色制場景。
選 AutoGen：微軟/Azure 技術堆疊、需要 Agent 多輪辯論和迭代推理、研究或快速實驗不同對話模式。
2026 年，多 Agent 系統通訊協定已標準化為兩層互補架構，均已納入 Linux Foundation Agentic AI Foundation 管理：
每個 A2A Agent 發布 Agent Card（/.well-known/agent.json），Orchestrator 透過 JSON-RPC 2.0 發現並委託任務。詳見MCP 協定解讀與MCP Server 開發教學。
使用 PostgresSaver 作為 LangGraph 檢查點儲存，即使程序重啟也可從上次狀態恢復（thread_id 跨工作階段）。
LangGraph interrupt() 在高風險操作前暫停，等待人工確認（如修改生產資料庫）。
對外部 Agent 呼叫實施 Circuit Breaker（CLOSED / OPEN / HALF_OPEN），失敗閾值觸發熔斷，避免級聯故障。
TokenBudgetManager 在每次 Agent 呼叫前檢查剩餘預算，超額拋出 BudgetExceededException，按 Agent 維度記錄用量。
根據 MAST 研究團隊對 1642 個執行追蹤的分析，多 Agent 系統故障分布如下：
| 故障類型 | 占比 | 說明 |
|---|---|---|
| 系統設計問題 | 41.77% | 步驟重複、工具選擇錯誤、上下文溢位、缺少終止條件 |
| Agent 間不對齊 | 36.94% | 交接時上下文遺失、一個 Agent 的幻覺成為下一個的「事實」 |
| 任務驗證失敗 | 21.30% | 過早終止、不完整驗證 |
更令人擔憂的是：57% 的組織已有 Agent 在生產環境運行，但僅 8% 完成了 LLM 可觀測性實施。大量錯誤以 HTTP 200 返回，監控面板全綠，系統實際輸出卻是錯誤結果。
分散式追蹤：每次 Agent 呼叫攜帶 correlation_id，OpenTelemetry span 記錄 agent.name、tokens_used、status。
關鍵監控指標：端到端任務完成率（目標 >85%）、P95 延遲（<30s）、各 Agent 錯誤率（<5%）、重試次數、Token 成本、LLM-as-a-Judge 輸出品質評分。
Agent A 產生幻覺，錯誤結果傳給 B、C，整個系統基於錯誤前提輸出，HTTP 狀態碼卻全是 200。防坑：每個 Agent 交接點做 Schema 驗證、置信度閾值（<0.7 拒絕）、必填欄位檢查。
Agent 進入重試迴圈，Token 費用幾分鐘內暴漲至預期百倍。防坑：硬性上限 MAX_ITERATIONS=10、MAX_TOOL_CALLS_PER_AGENT=20、MAX_TOTAL_TOKENS=50_000；LangGraph interrupt_before 高代價操作前暫停。
把簡單兩步 LLM 鏈拆成 8 個 Agent，除錯難度指數級上升。原則：先從順序流水線開始；有具體證據（併發需求、超上下文、專業能力需獨立升級）才增加 Agent。生產系統最佳 Agent 數量通常是 3–8 個。
內部 Demo 效果好，上線後邊緣輸入頻繁失敗。防坑：輸入長度限制、提示注入偵測、PII 過濾、有害內容偵測——ProductionGuardrails 從第一天就位。
Send API 派發並行分支後，Supervisor 在慢分支完成前重跑，導致重複執行。防坑：builder.add_node("supervisor", supervisor_node, defer=True) 建立顯式同步屏障。
thread_id，支援斷點續傳與 Human-in-the-Loop。核心要點：① 編排拓撲 > 模型選擇；② 從簡單順序流水線開始；③ MCP + A2A 是未來標準；④ 可觀測性不是可選項；⑤ 生產 Agent 數量 3–8 個最佳，超過應考慮層級化。
2026 年值得關注：聯邦編排（多團隊子編排器共享路由策略）、多模態多 Agent（視覺/音訊與文字混合）、自適應拓撲選擇（AdaptOrch 方向）、EU AI Act 合規要求完整決策稽核鏈。
但若把 LangGraph 編排、MCP Server 與 A2A Gateway 跑在會睡眠的筆電或與他人共用的開發機上，你會面臨三項隱性成本：檢查點與工作階段因合蓋中斷、環境漂移導致 Agent 交接失敗、以及無法維持 7×24 多步驟工作流。對需要穩定多 Agent 編排與 MCP/A2A 長連線的生產環境，把 Gateway 與狀態儲存落在 MACCOME Mac mini（M4 / M4 Pro）獨占節點上，通常比在本地與睡眠策略搏鬥更省總成本；公開檔位見租用價格說明。
常見問題
LangGraph、CrewAI、AutoGen 怎麼選？
需要生產級狀態管理、Human-in-the-Loop 與複雜分支選 LangGraph；快速角色制原型選 CrewAI；微軟/Azure 堆疊且需多輪辯論選 AutoGen。詳見上文對照矩陣。
MCP 和 A2A 在多 Agent 系統中分別做什麼？
MCP 是垂直層（Agent ↔ 工具）；A2A 是水平層（Agent ↔ Agent）。詳見MCP 協定解讀。
生產環境應該有多少個 Agent？
實證甜區是 3–8 個。超過後協調開銷往往超過收益，應考慮層級化拆分為子團隊。