多 Agent 協作架構實戰：從設計模式到生產落地

• 上下文視窗瓶頸：複雜任務的中間結果會塞滿上下文，後續推理品質驟降。
• 專業能力稀釋：一個 Agent 同時做檢索、寫程式、決策審核，樣樣都做但樣樣不精。
• 串行執行低效：所有子任務順序執行，總耗時為各步之和，無法並行。
• 單點故障風險：一旦該 Agent 出問題，整個流程全部停擺。

根據 MLflow 2026 年報告，Google 內部 Agent Bake-Off 實驗顯示，採用分散式多 Agent 架構後，處理時間從 1 小時降至 10 分鐘，提升超過 6 倍。AdaptOrch（2026 學術論文）進一步證明：在多 Agent 系統中，編排拓撲的選擇對系統效能的影響比底層模型選擇更大，在 SWE-bench 等基準測試中，正確的拓撲可帶來 12–23% 的效能提升。

可引用數據點 1：Google Agent Bake-Off 分散式架構處理時間 60 分鐘 → 10 分鐘（約 6× 加速）。

可引用數據點 2：AdaptOrch 證明編排拓撲優於模型選擇，基準測試提升 12–23%。

可引用數據點 3：MAST 研究團隊分析 1,642 條執行追蹤：57% 組織已有 Agent 上線，僅 8% 完成 LLM 可觀測性實施。

多 Agent 協作系統（Multi-Agent System，MAS）是指由多個獨立的 AI Agent 組成的系統，透過明確的通訊協議與編排機制協作，完成單一 Agent 無法高效處理的複雜任務。

三種控制模式：集中式（Orchestrator 統一調度，可審計但易成瓶頸）、分散式（Agent 點對點通訊，高彈性但除錯難）、層級式（頂層主管 + 子團隊 Lead，平衡控制與擴展）。生產環境最常採用層級式或集中式 + 並行扇出的混合拓撲。

以下六種模式覆蓋生產中 95% 以上的多 Agent 系統場景。

模式一：順序流水線（Sequential Pipeline）

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}

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()

模式二：並行扇出／扇入（Parallel Fan-out / Fan-in）

多個 Agent 同時處理獨立子任務，最後由匯聚節點合併結果。總耗時 = max(T1, T2, ..., Tn) 而非各步相加。LangGraph 的 Send API 配合 Annotated[list, operator.add] Reducer 可實現真正並行與自動聚合。

模式三：層級主管－工人（Hierarchical Supervisor-Worker）

主管 Agent 負責意圖識別、任務拆解與路由，將子任務分配給專業 Worker。建議採用雙層路由：關鍵字快速通道（<1ms，無 LLM 呼叫）+ LLM 精確路由（處理模糊意圖）。適用於 Replit 式程式助手、企業客服。

模式四：群體協作（Swarm / Network）

Agent 點對點直接傳遞任務，無中央協調者，依靠輪數、共識、超時等終止規則停止。適合多輪辯論（程式碼審查、方案評估），但非確定性高，生產環境慎用，須設定 max_round 硬性上限。

模式五：黑板架構（Blackboard）

所有 Agent 共享結構化工作空間（黑板），在前提條件滿足時主動讀寫，無需顯式排程。適用於小時級甚至天級的長時間非同步任務、異構服務協作。

模式六：混合模式（Hybrid）

在同一系統組合多種模式，常見為「Intent 路由器 + 層級主管 + 並行研究扇出 + 品質保障流水線」。企業內容生成平台多採此架構：簡單查詢直答，複雜報告走多 Agent 編排。

選 LangGraph：金融、醫療等合規場景、複雜狀態持久化、精細 Human-in-the-Loop。選 CrewAI：1–2 天快速驗證 Idea、角色制內容生成。選 AutoGen：微軟/Azure 技術棧、多輪辯論與迭代推理實驗。

2026 年，多 Agent 通訊已標準化為兩層互補架構，均由 Linux Foundation Agentic AI Foundation 管理：MCP（垂直）負責 Agent ↔ 工具／外部系統；A2A（水平）負責 Agent ↔ Agent 的任務委託、能力發現與狀態同步。

MCP 由 Anthropic 主導，實現「寫一次，到處用」的工具接入。A2A 由 Google 發起，2026 年初發布 v1.0，已有 Atlassian、Salesforce、SAP 等 50+ 合作夥伴。每個 A2A Agent 須發布 /.well-known/agent.json Agent Card，Orchestrator 透過 JSON-RPC 2.0 發現並委託任務。詳見 MCP 深度解讀與 MCP Server 實作教學。

async def discover_and_delegate(agent_url: str, task: str):
    card = (await httpx.get(f"{agent_url}/.well-known/agent.json")).json()
    skills = [s["id"] for s in card["skills"]]
    if "web_research" not in skills:
        raise ValueError(f"Agent {card['name']} 不支援 web_research")
    payload = {
        "jsonrpc": "2.0",
        "method": "message/send",
        "id": "task-001",
        "params": {"message": {"role": "user", "parts": [{"type": "text", "text": task}]}}
    }
    return (await httpx.post(card["url"], json=payload)).json()

• 狀態持久化與斷點續傳：LangGraph PostgresSaver 檢查點，以 thread_id 跨程序恢復。
• Human-in-the-Loop：interrupt() 暫停高風險操作，等待人工確認後繼續。
• 熔斷器與重試：CLOSED / OPEN / HALF_OPEN 三態，防止故障 Agent 拖垮整體。
• Token 預算控制：TokenBudgetManager 在任務級設定上限，超限即拒絕。

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)
    return {"status": "cancelled"}

每次 Agent 呼叫須攜帶 correlation_id，透過 OpenTelemetry 形成完整呼叫鏈。核心指標：端到端任務成功率（目標 >85%）、P95 延遲（<30s）、各 Agent 錯誤率（<5%）、Token 成本／任務。品質維度可採 LLM-as-a-Judge 自動評估（完成度、準確性、相關性、幻覺檢測）。

• 上下文污染：Agent A 幻覺傳遞給 B、C，HTTP 200 但輸出錯誤。防坑：每個交接點做 Schema 驗證與置信度閾值（<0.7 拒絕）。
• 無限循環與代價失控：設定 MAX_ITERATIONS=10、MAX_TOOL_CALLS_PER_AGENT=20、MAX_TOTAL_TOKENS=50_000 硬性上限。
• 過度工程化：兩步 LLM 鏈拆成 8 個 Agent。原則：先順序流水線，有具體證據再擴展；生產最佳 Agent 數量通常 3–8 個。
• Demo 到生產的鴻溝：輸入長度限制、提示注入檢測、PII 過濾、有害內容分類缺一不可。

任務是否有明確線性依賴？是 → 子任務可否並行？否 → 順序流水線；是 → 並行扇出 + 流水線混合。否 → 是否有決策權威 Agent？是 → 規模是否需要子團隊？否 → Supervisor-Worker；是 → 多層層級式。否 → 是否長時間非同步？是 → 黑板架構；否 → Agent ≤5 且終止條件明確？是 → Swarm（設硬性上限）；否 → 重構為層級模式。

1. 編排拓撲 > 模型選擇：如何組織 Agent 協作比選什麼底層模型影響更大。
2. 從簡單開始：先用順序流水線驗證核心價值，有具體需求再引入並行與層級。
3. MCP + A2A 是未來標準：新專案建議直接採用。
4. 可觀測性不是可選項：57% 上線 vs 8% 可觀測性的差距是事故溫床。
5. 生產 Agent 數量 3–8 個最佳：超過則協調開銷往往超過收益。

2026 年趨勢：聯邦編排（多團隊子編排器共享路由策略）、多模態多 Agent、自適應拓撲選擇（AdaptOrch 方向）、EU AI Act 合規要求完整決策審計鏈。

1. 01
   選定編排框架與拓撲：合規／長時任務選 LangGraph + Postgres 檢查點；快速原型選 CrewAI。先畫決策樹確定流水線或層級模式。
2. 02
   控制台撥備雲端 Mac：登入 NUKCLOUD 控制台，選擇 16 GB+ 記憶體（多 Agent 並行建議 32 GB）；見 定價頁 按小時試跑。
3. 03
   部署 MCP Server 與 Agent 節點：依 MCP Server 教學 暴露工具層；各 Worker Agent 透過 MCP 存取資料庫與 API。
4. 04
   接入可觀測性：OpenTelemetry + correlation_id；設定 Token 預算、熔斷器與 MAX_ITERATIONS 硬性上限。
5. 05
   Human-in-the-Loop 與生產防護：高風險操作 interrupt()；輸入注入檢測、PII 過濾、交接點 Schema 驗證。
6. 06
   launchd 常駐與固定月租：撰寫 LaunchAgents plist 保持 7×24 執行；試點通過後於 下單頁 鎖定規格。詳見 NUKCLOUD 生產就緒 Runbook。

在本機筆電或共享 VPS 跑多 Agent 編排常見合蓋休眠中斷長時任務、頻寬抖動導致 A2A 連線斷開、多開發者搶占同一程序。需要穩定 7×24 運行 LangGraph 工作流、MCP 工具層與 OpenTelemetry 收集時，NUKCLOUD 多區域裸金屬 Mac／雲端 Mac 節點在獨占租戶邊界與規格彈性上更易與多 Agent 架構對齊。更多說明見 說明中心。