多 Agent 系統為什麼比「一個更強的單 Agent」更有效率？有哪些場景是單 Agent 做不到的？
多 Agent 系統的效率優勢來自三個方向：
第一，突破 Context Window 限制。所有 LLM 都有 Context Window 上限，一個 Agent 同時分析 10 個 DeFi 協議的即時數據、查詢 30 天交易記錄、評估 5 個候選策略——很容易超出上限。把任務分給多個 Sub-agent，每個只負責一小部分，問題消失。
第二，專業化提升推理品質。一個被要求同時做數據分析、情緒評估、風險評估、交易執行的 Agent，推理品質必然分散。每個 Sub-agent 的 System Prompt 可以非常精確地針對它的職責域，推理更準確。
第三，並行執行縮短時間。單 Agent 是串行的，A 完成才能做 B。多 Agent 允許 Orchestrator 同時派出多個 Sub-agent 並行工作，複雜任務的總執行時間大幅縮短。
單 Agent 真正做不到的場景：需要同時在多個平台監控資訊（一個 Sub-agent 看鏈上數據、一個看社群情緒、一個看 CEX 訂單簿），任何一個都可能超出單 Agent 的 Context 容量，且需要並行即時處理。
Orchestrator 在多 Agent 系統裡怎麼「管理」Sub-agent？它和 Sub-agent 之間的通訊用什麼協議？
Orchestrator 管理 Sub-agent 的方式主要依賴 A2A（Agent-to-Agent）通訊協議，這是一個專門為 Agent 之間互相傳遞任務、中間結果、最終輸出設計的協議層。
Orchestrator 的具體工作流：接收用戶的高層目標 → 用 LLM 推理拆解任務（或按預設規則映射任務到對應 Sub-agent）→ 透過 A2A 把子任務和所需輸入資料發給對應 Sub-agent → 等待 Sub-agent 透過 A2A 回傳結果 → 整合多個 Sub-agent 的結果 → 做出最終決策或向用戶報告。
A2A 和 MCP 是不同層次的協議，容易混淆：MCP 是 Agent 和「外部工具」（API、數據庫）之間的通訊；A2A 是 Agent 和 Agent 之間的通訊。兩者在一個完整的多 Agent 系統裡都會用到——Sub-agent 透過 MCP 調用工具取得資訊，透過 A2A 把結果傳回 Orchestrator。
加密場景的安全設計：Orchestrator 發給執行 Sub-agent 的授權指令應附帶加密簽名（用 Orchestrator 的私鑰），執行 Sub-agent 驗證簽名才執行，防止被注入的 Agent 偽冒 Orchestrator 發出惡意指令。
多 Agent 系統的錯誤怎麼傳播？一個 Sub-agent 出錯，會影響整個系統嗎？
多 Agent 系統的錯誤傳播是設計中最難處理的部分之一，因為錯誤可以以非直覺的方式擴散和放大。三種常見的傳播模式：
第一，資料汙染型：數據 Sub-agent 回傳了錯誤資訊（可能因為 MCP Server 被攻擊），分析 Sub-agent 基於這個錯誤資訊生成了看似合理的建議，Orchestrator 信任了建議並授權執行——每個環節單獨看都「正常運行」，但整體結果是錯的。
第二，過度自信型：分析 Sub-agent 用「信心 95%」這樣的高度肯定語氣輸出建議，Orchestrator 的邏輯因為高信心而跳過了風險評估步驟，直接授權執行。實際上那個「95%」只是 LLM 的語氣風格，不是真正的統計信心。
第三，無限重試型：執行 Sub-agent 因為 Gas 費或合約條件導致操作失敗，Orchestrator 不斷重試，消耗大量 Token 和 Gas 費，直到超時。
防禦設計：每個 Sub-agent 的回傳包含置信度和數據來源；Orchestrator 有失敗計數器和熔斷機制（N 次失敗後暫停通知用戶）；關鍵路徑上的數據必須交叉驗證。
目前主流的多 Agent 框架（LangGraph、AutoGen、CrewAI）各自有什麼優劣？加密場景怎麼選？
三個框架在加密多 Agent 場景的適用性差異明顯：
LangGraph（LangChain 的多 Agent 擴展）：用有向無環圖（DAG）定義 Agent 間工作流，每個節點是 Agent 或工具調用，邊定義依賴和觸發條件。優點：流程可視化和可控性非常好，適合需要精確定義執行路徑的策略系統（例如「確認 ETH 價格 → 評估風險 → 只有低風險才授權交易」）。缺點：靈活性較低，動態任務分配需要額外設計。
AutoGen（Microsoft）：基於對話的多 Agent 框架，Agent 之間用自然語言消息通訊。優點：設計門檻低，快速原型。缺點：自然語言通訊更容易被 Prompt Injection 影響，加密資產管理場景需要額外加強安全設計。
CrewAI：高層次框架，強調角色（Role）和目標（Goal）定義。優點：概念直覺。缺點：細粒度安全控制支援有限，需要大量客製化。
加密場景推薦：高安全要求的執行路徑（執行 Agent 的授權流程）用 LangGraph；分析類 Agent 的通訊用 AutoGen 或自定義 A2A；不推薦 CrewAI 用於鏈上資產管理，安全控制太薄。
實際案例：加密 DeFi 管理的多 Agent 架構
假設你要管理一個在多個 DeFi 協議的穩定幣倉位，要求「最大化收益，但任何單次移倉不超過總倉位的 20%，且 Gas 費超過收益的 10% 時不執行」。用單一 Agent 處理這個任務很容易超出 Context Window，且安全邊界難以實施。用多 Agent 架構：
數據 Agent（只讀）：每 30 分鐘掃描 Aave、Compound、Morpho 的 USDC 存款年化利率和 Gas 費，輸出一份「現況快照」給 Orchestrator。
策略 Agent（分析）：讀取數據 Agent 的快照，推算移倉的理論收益和成本，輸出「建議操作 + 預期淨收益 + 置信度」。
風險 Agent（審計）：讀取策略 Agent 的建議，核驗「是否超過 20% 單次上限」「Gas 費比例是否合理」，輸出「通過 / 拒絕 + 原因」。只有通過才傳給 Orchestrator。
執行 Agent（有限簽署）：只接受 Orchestrator 附帶加密簽名的授權指令，且金額在白名單合約和設定上限內，才調用 Agent 錢包執行移倉。
Orchestrator：整合以上結果，超過一定金額（例如 $5,000）時發通知讓你確認，否則自動授權執行 Agent。
這個架構的好處：每個 Agent 的職責單一、Context 輕量、安全邊界清晰。即使數據 Agent 被 MCP 攻擊，影響範圍也只到風險 Agent 這一層就被攔截。
多 Agent 系統的核心取捨是「能力和複雜度 vs 安全風險」。單 Agent 更簡單，出問題的根因更容易追蹤；多 Agent 系統能力更強，但 Agent 間的通訊本身引入了新的攻擊面（A2A 通訊被篡改、Sub-agent 之間的信任傳播問題）。另一個取捨是「並行效率 vs 狀態一致性」：多個 Sub-agent 並行操作同一個 Agent 錢包可能產生競態條件，需要明確的資源鎖機制。加密場景的建議：安全邊界的設計不能馬虎，最小必要權限 + 執行 Agent 的獨立驗證是不可省略的設計要素，不因為追求效率就跳過。