六大編排模式 · LangGraph vs CrewAI · MCP + A2A · 生產可觀測性
團隊在 Cursor 裡跑通了單 Agent Demo,上線後卻要面對並行研究、工具隔離、人工審核閘門與共享 Token 預算。單一 Agent 會撞上上下文窗口、樣樣通樣樣鬆、零並行、單點故障(SPOF)四道牆。本文面向 AI 工程師與技術負責人:拆解多 Agent 協作系統(MAS)的六大編排模式、LangGraph vs CrewAI vs AutoGen 選型矩陣、MCP + A2A 雙層協定棧、生產級工程實踐(PostgresSaver、HITL interrupt、熔斷器)、MAST 可觀測性資料,以及決策樹與 2026 趨勢展望。
2024 至 2025 年,AI Agent 從實驗室走向生產。許多團隊很快發現:把所有任務塞給一個 LLM Agent,系統會在規模化時崩潰。問題不在模型不夠聰明,而在結構性限制。
上下文窗口瓶頸:複雜任務的中間結果會把上下文塞滿,後續推理品質驟降,Agent 忘記十輪前設定的約束。
專業能力稀釋:一個 Agent 既要做資訊檢索、又要寫程式、又要做決策審核,樣樣都做但樣樣不精,指令互相干擾提高幻覺率。
串行執行低效:所有子任務順序執行,總耗時是每步耗時之和,無法並行;獨立子任務(同時爬三個站、跑三套測試)白白浪費牆鐘時間。
單點故障風險:一旦這個 Agent 出問題,整個流程全部停擺;沒有隔離域供重試或回滾。
成本歸因不透明:財務無法回答哪一步燒掉了 Token;沒有 per-agent 預算,一個話多的研究 Agent 就能耗盡月度上限。
根據 MLflow 2026 年報告,Google 內部 Agent Bake-Off 實驗顯示:採用分散式多 Agent 架構後,處理時間從 1 小時降至 10 分鐘,提升超過 6 倍。AdaptOrch(2026 學術論文)進一步證明:在多 Agent 系統中,編排拓撲的選擇對系統效能的影響比底層模型的選擇更大,在 SWE-bench 等基準測試中,正確的拓撲選擇可帶來 12–23% 的效能提升。
拓撲大於模型。AdaptOrch 證明編排結構比模型選型多解釋 12–23% 的結果變異——先畫好圖,再升級 GPT 方案。
多 Agent 協作系統(Multi-Agent System,MAS)是指由多個獨立的 AI Agent 組成的系統,這些 Agent 透過明確的通訊協定和編排機制協作,完成單一 Agent 無法高效處理的複雜任務。
| 特徵 | 描述 |
|---|---|
| 角色專一 | 只負責一個明確定義的子任務(檢索、推理、生成、驗證等) |
| 工具存取 | 擁有完成自身任務所需的特定工具集 |
| 狀態隔離 | 維護自己的上下文和記憶體,不污染其他 Agent |
| 可替換性 | 可以獨立升級、替換,不影響整體系統 |
| 拓撲 | 控制流 | 優點 | 風險 |
|---|---|---|---|
| 集中式(Centralized) | 單一 Orchestrator 路由所有訊息 | 可稽核、可控、政策執行嚴格 | Orchestrator 上下文膨脹;路由器 SPOF |
| 分散式(Decentralized) | Agent 點對點直接通訊,無中央協調者 | 高彈性、低延遲、容錯好 | 除錯難、非確定性高、終止條件難保證 |
| 層級式(Hierarchical) | Supervisor 委派給 Worker,Worker 向上回報 | 企業工作流、多層審批、兩者平衡 | Supervisor 提示複雜;延遲堆疊 |
2026 年大多數生產堆疊預設採用層級式,並以薄型集中式路由器處理鑑權與預算執行——混合第一與第三種拓撲的優點。
這六種模式覆蓋生產中 95% 以上的多 Agent 系統場景。模式可組合——客服堆疊可能用 Supervisor 扇出並行研究 Agent,再流水線合成給 Writer。
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: PipelineState):
docs = search_knowledge_base(state["query"])
return {"retrieved_docs": docs}
def analysis_agent(state: PipelineState):
result = llm.invoke(f"分析以下內容:{state['retrieved_docs']}")
return {"analysis": result.content}
def writer_agent(state: PipelineState):
report = llm.invoke(f"根據分析撰寫報告:{state['analysis']}")
return {"final_report": report.content}
builder = StateGraph(PipelineState)
builder.add_node("retriever", retrieval_agent)
builder.add_node("analyzer", analysis_agent)
builder.add_node("writer", writer_agent)
builder.add_edge(START, "retriever")
builder.add_edge("retriever", "analyzer")
builder.add_edge("analyzer", "writer")
builder.add_edge("writer", END)
pipeline = builder.compile()
| 優點 | 缺點 |
|---|---|
| 實作簡單、易於除錯、行為可預測、適合合規稽核 | 總耗時 = 各步耗時之和;單步失敗整體阻塞;無法處理動態分支 |
多個 Agent 同時處理獨立子任務,最後由匯聚節點合併結果。總耗時 = max(T1, T2, ..., Tn) 而非加總。LangGraph 的 Send API 實現真正的並行 fan-out。
from langgraph.types import Send
from langgraph.graph import StateGraph, START, END
from typing import TypedDict, Annotated
import operator
class ResearchState(TypedDict):
query: str
research_results: Annotated[list, operator.add]
final_synthesis: str
def supervisor(state: ResearchState):
subtasks = [
{"query": state["query"], "source": "academic"},
{"query": state["query"], "source": "industry"},
{"query": state["query"], "source": "news"},
]
return [Send("research_worker", task) for task in subtasks]
def research_worker(state: dict):
result = search_by_source(state["query"], state["source"])
return {"research_results": [result]}
def synthesizer(state: ResearchState):
combined = "\n".join(state["research_results"])
synthesis = llm.invoke(f"綜合以下研究結果:{combined}")
return {"final_synthesis": synthesis.content}
builder = StateGraph(ResearchState)
builder.add_node("research_worker", research_worker)
builder.add_node("synthesizer", synthesizer)
builder.add_conditional_edges(START, supervisor, ["research_worker"])
builder.add_edge("research_worker", "synthesizer")
builder.add_edge("synthesizer", END)
graph = builder.compile()
主管 Agent 負責意圖識別、任務拆解和路由決策,將子任務分配給專業 Worker Agent。加入關鍵字快速通道:高信心意圖用 regex 匹配,跳過 LLM 路由呼叫,回應延遲 <1ms。
KEYWORD_ROUTING = {
"程式碼": "code_agent",
"code": "code_agent",
"搜尋": "search_agent",
"查詢": "search_agent",
"資料": "data_agent",
}
def supervisor_with_fast_path(state):
query = state["query"].lower()
for keyword, agent_name in KEYWORD_ROUTING.items():
if keyword in query:
return {"next": agent_name}
routing_prompt = f"""
使用者請求:{state['query']}
可用 Agent:code_agent, search_agent, data_agent
請返回最合適的 Agent 名稱,只返回名稱。
"""
decision = llm.invoke(routing_prompt)
return {"next": decision.content.strip()}
Agent 之間點對點直接傳遞任務,沒有中央協調者,依靠終止規則(輪數、共識、逾時)停止。適合多輪協商和辯論;非確定性高,生產環境慎用。
import autogen
reviewer_1 = autogen.AssistantAgent(
name="SecurityReviewer",
system_message="你是一位安全專家,專注於程式碼中的安全漏洞。"
)
reviewer_2 = autogen.AssistantAgent(
name="PerformanceReviewer",
system_message="你是一位效能專家,專注於程式碼的效率和資源使用。"
)
human_proxy = autogen.UserProxyAgent(
name="CodeAuthor",
human_input_mode="NEVER",
max_consecutive_auto_reply=2,
is_termination_msg=lambda x: "APPROVED" in x.get("content", "")
)
groupchat = autogen.GroupChat(
agents=[human_proxy, reviewer_1, reviewer_2],
messages=[],
max_round=6
)
manager = autogen.GroupChatManager(groupchat=groupchat)
所有 Agent 共享一個結構化工作空間(黑板),Agent 在滿足自身前提條件時主動讀寫黑板,無需顯式排程。適合長時間非同步任務(小時級甚至天級)、異構服務協作、工作流條件複雜難以預定路由的場景。
在同一系統中組合多種模式,通常是「主管模式 + 流水線」的組合。典型架構:Intent Router → 簡單查詢直接回答;複雜報告 → Supervisor → 並行研究扇出 + 品質保障流水線 → 人工審核 → 發布。
| 模式 | 並行性 | 可除錯性 | 典型框架 |
|---|---|---|---|
| Sequential Pipeline | 低 | 高 | LangGraph、CrewAI sequential |
| Fan-out / Fan-in | 高 | 中 | LangGraph Send |
| Supervisor-Worker | 中 | 高 | LangGraph、CrewAI hierarchical |
| Swarm | 中 | 低 | AutoGen、Swarm SDK |
| Blackboard | 中 | 中 | Custom + 共享儲存 |
| Hybrid | 可變 | 中 | LangGraph(最常見) |
三者均在 2026 年有生產使用者,但優化方向不同。依拓撲選框架,而非品牌偏好。
| 維度 | LangGraph | CrewAI | AutoGen(微軟) |
|---|---|---|---|
| 架構範式 | 狀態機圖 | 角色制團隊 | 對話式多 Agent |
| 程式語言 | Python / JS/TS | Python | Python / .NET |
| 學習曲線 | 較陡 | 平緩 | 中等 |
| 狀態管理 | 原生支援(PostgresSaver) | 需自實作 | 有限支援 |
| Human-in-the-Loop | 原生 interrupt() | 需自實作 | UserProxyAgent 模式 |
| 可觀測性 | LangSmith(商業) | 有限 | Azure Monitor |
| 生產就緒度 | 最高 | 中等 | 高 |
| 快速原型 | 中等 | 最快 | 高 |
| Azure 整合 | 中等 | 較弱 | 最強 |
| 適合場景 | 複雜有狀態工作流 | 角色制內容流水線 | 對話式協作、研究實驗 |
需要持久檢查點 + HITL 審批閘門? → LangGraph(合規、金融、醫療)。
需要 1–2 天出可讀角色 YAML 原型? → CrewAI(內容生成、研究報告)。
需要 Agent 多輪辯論和迭代推理? → AutoGen(微軟/Azure 技術棧)。
需要圖控制 + 對話 handoff 並存? → LangGraph Orchestrator 包裝 AutoGen Worker。
2026 年,多 Agent 系統的通訊協定已標準化為兩層互補架構,兩者均已納入 Linux Foundation Agentic AI Foundation 管理。MCP 負責垂直整合(Agent ↔ 工具/資料);A2A 負責橫向編排(Agent ↔ Agent)。
| 層級 | 協定 | 連接對象 | 類比 |
|---|---|---|---|
| 垂直層 | MCP(Model Context Protocol) | Agent ↔ 工具、資料庫、API | AI 工具整合的 USB-C |
| 橫向層 | A2A(Agent-to-Agent) | Agent ↔ Agent 任務委派 | 服務網格的 HTTP |
MCP 由 Anthropic 主導,統一 Agent 存取外部工具的介面。每個 Agent 內部透過 tools/list 發現工具;A2A 則透過 Agent Card 發現並委派任務給其他 Agent。
from mcp.server import Server
from mcp.types import Tool, TextContent
app = Server("data-agent-mcp")
@app.list_tools()
async def list_tools():
return [
Tool(
name="query_customer_db",
description="查詢客戶資料庫,支援按 ID、姓名、Email 檢索",
inputSchema={
"type": "object",
"properties": {
"field": {"type": "string", "enum": ["id", "name", "email"]},
"value": {"type": "string"}
},
"required": ["field", "value"]
}
)
]
@app.call_tool()
async def call_tool(name: str, arguments: dict):
if name == "query_customer_db":
result = db.query(arguments["field"], arguments["value"])
return [TextContent(type="text", text=str(result))]
{
"name": "ResearchAgent",
"version": "1.0",
"description": "專業資訊檢索與摘要 Agent",
"url": "https://research-agent.internal/a2a",
"capabilities": {
"streaming": true,
"async": true
},
"skills": [
{
"id": "web_research",
"name": "網路資訊檢索",
"description": "從網際網路檢索並摘要最新資訊",
"tags": ["research", "summarization", "web"]
},
{
"id": "academic_search",
"name": "學術文獻檢索",
"description": "檢索 arXiv、Google Scholar 等學術資料庫"
}
]
}
import httpx
async def discover_and_delegate(agent_url: str, task: str):
card_response = await httpx.get(f"{agent_url}/.well-known/agent.json")
agent_card = card_response.json()
available_skills = [s["id"] for s in agent_card["skills"]]
if "web_research" not in available_skills:
raise ValueError(f"Agent {agent_card['name']} 不支援 web_research 技能")
payload = {
"jsonrpc": "2.0",
"method": "message/send",
"id": "task-001",
"params": {
"message": {
"role": "user",
"parts": [{"type": "text", "text": task}]
}
}
}
response = await httpx.post(agent_card["url"], json=payload)
return response.json()
垂直層詳見 MCP 協定深度解讀;本節聚焦 Agent 之間的橫向委派模式。
Demo 用記憶體狀態;生產需要當機恢復、高風險操作人工審批、成本上限。四個原語覆蓋大多數團隊在自建基礎設施前的需求。
from langgraph.checkpoint.postgres import PostgresSaver
with PostgresSaver.from_conn_string("postgresql://user:pass@localhost/agentdb") as checkpointer:
graph = builder.compile(checkpointer=checkpointer)
config = {"configurable": {"thread_id": "user-session-12345"}}
result = graph.invoke({"query": "分析 Q2 財報"}, config)
from langgraph.types import interrupt
def high_risk_action_agent(state):
proposed_action = plan_action(state)
human_decision = interrupt({
"proposed_action": proposed_action,
"risk_level": "HIGH",
"message": "此操作將修改生產資料庫,請確認是否執行"
})
if human_decision["approved"]:
return execute_action(proposed_action)
else:
return {"status": "cancelled", "reason": human_decision.get("reason")}
import time
from functools import wraps
class CircuitBreaker:
def __init__(self, failure_threshold=5, recovery_timeout=60):
self.failure_count = 0
self.failure_threshold = failure_threshold
self.recovery_timeout = recovery_timeout
self.state = "CLOSED"
self.last_failure_time = None
def __call__(self, func):
@wraps(func)
async def wrapper(*args, **kwargs):
if self.state == "OPEN":
if time.time() - self.last_failure_time > self.recovery_timeout:
self.state = "HALF_OPEN"
else:
raise Exception("Circuit breaker OPEN - Agent 暫時不可用")
try:
result = await func(*args, **kwargs)
if self.state == "HALF_OPEN":
self.state = "CLOSED"
self.failure_count = 0
return result
except Exception:
self.failure_count += 1
self.last_failure_time = time.time()
if self.failure_count >= self.failure_threshold:
self.state = "OPEN"
raise
return wrapper
@CircuitBreaker(failure_threshold=3, recovery_timeout=30)
async def call_external_agent(task):
return await agent_client.send(task)
class TokenBudgetManager:
def __init__(self, total_budget: int = 100_000):
self.total_budget = total_budget
self.used_tokens = 0
self.agent_usage = {}
def check_budget(self, agent_name: str, estimated_tokens: int) -> bool:
remaining = self.total_budget - self.used_tokens
if estimated_tokens > remaining:
raise BudgetExceededException(
f"Agent {agent_name} 請求 {estimated_tokens} tokens,"
f"但剩餘預算僅 {remaining} tokens"
)
return True
def record_usage(self, agent_name: str, actual_tokens: int):
self.used_tokens += actual_tokens
self.agent_usage[agent_name] = self.agent_usage.get(agent_name, 0) + actual_tokens
建議:做混沌演練——在圖執行中途 kill Worker、重啟,確認 PostgresSaver 從上次檢查點恢復且無重複副作用。
MAST 研究團隊分析了 1,642 個多 Agent 執行追蹤,故障分布高度可預測——多數是設計問題,而非模型智商不足。
| 故障類型 | 占比 | 說明 |
|---|---|---|
| 系統設計問題 | 41.77% | 步驟重複、工具選擇錯誤、上下文溢出、缺少終止條件 |
| Agent 間不對齊 | 36.94% | 交接時上下文遺失、一個 Agent 的幻覺成為下一個的「事實」 |
| 任務驗證失敗 | 21.30% | 過早終止、不完整驗證、任務看似完成實則未完成 |
更令人擔憂的是:57% 的組織已有 Agent 在生產環境運行,但僅 8% 完成了 LLM 可觀測性的實施。大量錯誤以 HTTP 200 返回,監控面板全綠,系統實際輸出的卻是錯誤結果。
from opentelemetry import trace
import uuid
tracer = trace.get_tracer("multi-agent-system")
def traced_agent_call(agent_name: str, task: dict, correlation_id: str = None):
if not correlation_id:
correlation_id = str(uuid.uuid4())
with tracer.start_as_current_span(f"agent.{agent_name}") as span:
span.set_attribute("agent.name", agent_name)
span.set_attribute("correlation.id", correlation_id)
span.set_attribute("task.type", task.get("type", "unknown"))
try:
result = agent_registry[agent_name].run(task)
span.set_attribute("agent.tokens_used", result.get("tokens", 0))
span.set_attribute("agent.status", "success")
return result
except Exception as e:
span.set_attribute("agent.status", "error")
span.set_attribute("error.message", str(e))
raise
| 指標 | 意義 |
|---|---|
| task_success_rate | 端到端任務完成率(目標:>85%) |
| e2e_latency_p95 | P95 端到端延遲(目標:<30s) |
| total_cost_per_task | 每次任務平均 Token 成本 |
| agent_error_rate | 各 Agent 錯誤率(目標:<5%) |
| handoff_error_rate | A2A 結構不匹配與訊息遺失 |
| output_quality_score | LLM-as-Judge 或人工標註的輸出品質評分 |
import json
def evaluate_agent_output(original_task: str, agent_output: str) -> dict:
evaluation_prompt = f"""
你是一位嚴格的品質評審專家。請評估以下 AI Agent 的輸出品質。
原始任務:{original_task}
Agent 輸出:{agent_output}
請從完成度、準確性、相關性、幻覺檢測四個維度評分(1-5 分)。
以 JSON 格式返回:
{{"completeness": x, "accuracy": x, "relevance": x, "hallucination_detected": true/false, "comments": "..."}}
"""
evaluation = llm.invoke(evaluation_prompt)
return json.loads(evaluation.content)
Agent A 產生幻覺(錯誤的「事實」),錯誤結果傳給 Agent B、C,整個系統輸出基於錯誤前提——而所有 HTTP 狀態碼都是 200。
def validate_agent_output(output: dict, schema: dict) -> bool:
jsonschema.validate(output, schema)
if output.get("confidence_score", 1.0) < 0.7:
raise LowConfidenceError(f"Agent 輸出置信度過低: {output['confidence_score']}")
required_fields = schema.get("required", [])
missing = [f for f in required_fields if not output.get(f)]
if missing:
raise MissingFieldsError(f"輸出缺少必填欄位: {missing}")
return True
Agent 進入重試循環或反覆呼叫工具,Token 費用在幾分鐘內暴漲至預期的百倍。
MAX_ITERATIONS = 10
MAX_TOOL_CALLS_PER_AGENT = 20
MAX_TOTAL_TOKENS = 50_000
graph = builder.compile(
checkpointer=checkpointer,
interrupt_before=["high_cost_tool"]
)
為了使用多 Agent 而使用多 Agent,把簡單的兩步 LLM 鏈拆成 8 個 Agent,除錯難度指數級上升。生產系統最佳 Agent 數量通常是 3–8 個——只有當有具體證據(並行需求、上下文溢出、子 Agent 需獨立升級)時才增加數量。
內部 Demo 效果很好,上線後面對真實使用者的邊緣輸入就頻繁失敗。生產環境必須從第一天就包裝邊界防護。
class ProductionGuardrails:
def validate_input(self, user_input: str) -> str:
if len(user_input) > 10000:
raise InputTooLongError("輸入超過 10000 字元限制")
injection_patterns = ["ignore previous instructions", "forget everything"]
for pattern in injection_patterns:
if pattern.lower() in user_input.lower():
raise PromptInjectionError("偵測到潛在的提示注入攻擊")
return user_input.strip()
def validate_output(self, output: str) -> str:
output = self.pii_filter.redact(output)
if self.content_classifier.is_harmful(output):
raise HarmfulContentError("輸出包含有害內容")
return output
警告:最昂貴的錯誤是用加 Agent 來修 prompt 問題。先調整專家 Agent 提示與交接 schema,再考慮新增節點。
在選框架和畫拓撲之前,用以下決策樹快速定位模式。答案沒有唯一正解,但順序問對問題能避免 80% 的過度設計。
你的任務是否有明確的線性依賴步驟?
├─ 是 → 子任務是否可以並行執行?
│ ├─ 否 → 【順序流水線】
│ └─ 是 → 【並行扇出 + 順序流水線 混合】
│
└─ 否 → 是否有一個 Agent 具有決策權威?
├─ 是 → 規模是否足夠大需要子團隊?
│ ├─ 否 → 【Supervisor-Worker 層級模式】
│ └─ 是 → 【層級式(Supervisors of Supervisors)】
│
└─ 否 → 任務是否是長時間非同步的?
├─ 是 → 【黑板架構】
└─ 否 → Agent 數量是否 ≤ 5?
├─ 是 → 【Swarm(注意設定終止條件)】
└─ 否 → 【考慮重新拆分為層級模式】
子任務彼此獨立? 是 → 並行扇出。否 → 繼續。
順序嚴格? 是 → 順序流水線。否 → 繼續。
需要湧現式對話? 是 → Swarm / AutoGen。否 → Supervisor-Worker。
需要當機安全恢復? 是 → LangGraph + PostgresSaver。否 → CrewAI 快速路徑。
跨團隊 Agent 發現? 是 → 發布 Agent Card + A2A。僅工具 → 每 Agent 各自 MCP。
筆電適合跑 Agent Demo,卻在闔蓋休眠、缺少 macOS 原生工具鏈與長期程序守護上削弱 7×24 體驗;純 Linux 雲主機能跑無狀態 API Worker 與遠端 HTTP+SSE MCP,卻難以承載相依 Keychain、Xcode 或 Apple 生態的 MCP 工具。對要把多 Agent 編排圖當「常駐基礎設施」、讓 LangGraph 檢查點與 MCP 工作階段跨週累積複利的技術團隊,VpsMesh Mac Mini M4 雲端租用把 uptime、遠端 KVM 與可預期月租打包成生產級 OpEx。方案見 Mac Mini M4 租用價格,部署與運維問題見 幫助中心,線上下單見 訂購頁。
單 Agent 適合步驟少(≤3)、無並行需求、上下文不會溢出、且不需要獨立升級某子能力的場景。多 Agent 在以下情況值得引入:上下文窗口瓶頸、需要專業分工(檢索/生成/審核分離)、子任務可並行、或某個子 Agent 需獨立換模型而不動整圖。生產系統最佳 Agent 數量通常為 3–8 個;先以 Supervisor + 2 Worker 起步,量測 tokens_per_success 後再拆分。
LangGraph 心智模型是狀態機圖:原生 PostgresSaver 檢查點、interrupt() HITL、Send API 並行、LangSmith 追蹤——適合合規、金融、長時運行工作流。CrewAI 心智模型是「帶職位的團隊」:1–2 天可出角色制原型,適合內容生成與研究報告,但精細狀態管理與條件分支需自實作。需要生產可靠性與可觀測性 → LangGraph;需要快速驗證 Idea → CrewAI。
不必須。無狀態 LangGraph Worker 與遠端 MCP(HTTP+SSE)可部署在 Linux 雲主機。若 Agent 相依 macOS 工具鏈、Xcode 建置、Keychain 機密,或你需要 LangGraph 檢查點與 MCP 工作階段 7×24 不被闔蓋打斷,Mac Mini M4 月租比反覆重裝開發機更省心。建議先租 1 個月驗證檢查點延遲與 Token 消耗曲線。方案見 Mac Mini M4 租用價格,運維問題見 幫助中心,下單見 訂購頁。