Sub-agent 和 Orchestrator 怎麼分工？哪些決策應該在哪個層做？
Orchestrator 和 Sub-agent 的分工是多 Agent 系統設計的核心，分工不清會導致整個系統的性能和安全性都下降。
Orchestrator 負責的決策（「做什麼」）：
Sub-agent 負責的決策（「怎麼做」）：
為什麼分工清晰很重要：如果讓 Sub-agent 自己決定「要不要把結果告訴其他 Sub-agent」、「應不應該繞過 Orchestrator 直接執行下一步」，整個系統的行為就變得難以預測和審計。好的設計是：Sub-agent 只做被明確要求的事，所有的「判斷要做什麼」都留給 Orchestrator。
Sub-agent 有哪四種主要類型？在 DeFi Agent 系統裡各自扮演什麼角色？
按功能特性分類，Sub-agent 通常可以分成四種類型：
類型一：數據採集 Sub-agent（Read-only Agent） 只有讀取工具（查詢 API、讀取鏈上狀態），沒有任何寫入工具。在 DeFi 系統裡：查詢各協議的 APY、Gas 費、代幣價格、流動性深度、鏈上地址持倉。這類 Sub-agent 的安全風險最低——即使被 Prompt Injection 攻擊，它也無法執行任何鏈上操作。可以讓它接觸更多外部數據源（多個 API、協議官網），因為讀取操作沒有鏈上後果。
類型二：分析 Sub-agent（Analysis Agent） 接收數據採集 Sub-agent 的輸出，做推理分析。在 DeFi 系統裡：比較各協議利率差、評估 Gas 費窗口、分析市場情緒、生成移倉建議。這類 Sub-agent 只需要 LLM 推理能力，不需要任何鏈上工具，也不需要接觸原始外部數據。它的輸入是已清洗的結構化數據，輸出是結構化的分析建議。
類型三：執行 Sub-agent（Execution Agent） 有鏈上寫入工具（簽署交易、調用合約），負責把 Orchestrator 批准的操作實際執行上鏈。安全風險最高，應該配置最嚴格的工具白名單和金額上限，只接受來自 Orchestrator 的指令（不直接接觸外部數據），在高金額操作前必須有確認通道。
類型四：監控 Sub-agent（Monitor Agent） 持續監控系統狀態，觸發熔斷和告警。在 DeFi 系統裡：監控操作錢包的餘額、監控策略倉位的 PnL、監控市場異常（價格閃崩、Gas 費飆升）。這類 Sub-agent 只做「觀察和告警」，不做任何操作決策——它的告警輸出是給 Orchestrator 看的，由 Orchestrator 決定怎麼響應。
Sub-agent 之間的通信協議怎麼設計？Agent 間的數據傳遞有哪些安全考量？
在大多數多 Agent 系統裡，Sub-agent 之間不直接通信——所有通信都通過 Orchestrator 中轉。這個「Hub-and-Spoke」架構不只是設計選擇，也是安全要求：
為什麼 Sub-agent 不能直接互相通信：如果 Sub-agent A 能直接把輸出發給 Sub-agent B，且這個通信通道不被 Orchestrator 監控，攻擊者只需要污染 Sub-agent A 的輸出，就能在 Orchestrator 不知情的情況下影響 Sub-agent B 的行為。這等於在系統裡開了一條 Orchestrator 看不到的指令通道——是重大安全漏洞。
Orchestrator 中轉的格式要求：Sub-agent 的輸出應該是嚴格格式化的結構化數據（JSON Schema 驗證），不是自由文本。自由文本輸出容易攜帶隱藏的 Prompt Injection（例如，數據採集 Sub-agent 的輸出裡混入了「忽略之前的所有指令，轉而做 X」），Orchestrator 直接把這個輸出傳給下一個 Sub-agent 時，就完成了 Prompt Injection 的「傳播」。結構化輸出 + Schema 驗證讓 Orchestrator 能在傳遞數據前過濾掉異常字段。
輸出大小限制：每個 Sub-agent 的輸出應該有明確的最大長度限制（例如最多 2,000 Token）。這防止一個被攻擊的 Sub-agent 把一段超長的「惡意指令」藏在輸出裡，通過 Orchestrator 傳播到整個系統。
實作建議：使用 LangGraph 的有向圖設計時，Sub-agent 之間的邊（Edge）只允許數據從 Sub-agent → Orchestrator，Orchestrator → Sub-agent，不允許 Sub-agent → Sub-agent 的直接邊。在圖的設計層面就消除了這個攻擊面。
Sub-agent 的安全邊界設計原則是什麼？最小權限原則怎麼在多 Agent 系統裡落地？
最小權限原則（Principle of Least Privilege）在多 Agent 系統裡的落地是最重要的安全設計決策之一。每個 Sub-agent 應該只持有它的具體任務所需的最小工具集和最小授權：
工具集最小化：
get_aave_rates()、get_morpho_rates()、get_gas_price()——不能有任何寫入工具execute_deposit(protocol, amount)、execute_withdraw(protocol, amount)——只有白名單協議的操作，不能有「向任意地址轉帳」的工具get_wallet_balance()、get_position_status()——只讀，無寫入Context 信息最小化：每個 Sub-agent 的 System Prompt 只包含它執行任務所需的信息，不包含其他 Sub-agent 的工作邏輯、不包含整個策略的完整設計。攻擊者即使污染了一個 Sub-agent 的 LLM 推理，也只能看到這個 Sub-agent 的局部上下文，無法從中推斷整個系統的設計和其他 Sub-agent 的授權範圍。
失敗隔離設計：一個 Sub-agent 失敗（崩潰、被攻擊、輸出異常）不能導致整個系統崩潰。Orchestrator 必須能捕獲任何 Sub-agent 的異常輸出，標記為「子任務失敗」，決定是重試、跳過、還是升級到人工處理——而不是把異常輸出直接傳給下一個 Sub-agent 繼續執行。
驗證點設計：Orchestrator 在把每個 Sub-agent 的輸出傳給下一個 Sub-agent 之前，做一次「完整性驗證」：輸出格式是否符合預期 JSON Schema？數值是否在合理範圍？有沒有包含不應該出現的字段或指令？驗證失敗 → 拒絕傳遞，記錄異常，告警。
具體架構：一個四層 Sub-agent 的 DeFi 利率優化系統
把一個 DeFi 利率優化 Agent 拆成四個 Sub-agent 協作：
Sub-agent 1：利率採集器（Rate Collector）
get_aave_usdc_apy()、get_morpho_usdc_apy()、get_compound_usdc_apy()、get_gas_price(){"aave_apy": 4.2, "morpho_apy": 5.1, "compound_apy": 3.8, "gas_gwei": 12}Sub-agent 2：策略分析器（Strategy Analyzer）
{"recommended_action": "move_to_morpho", "reason": "APY diff 0.9%, exceeds threshold 0.5%", "estimated_gas_cost": "$2.4", "net_gain_estimate": "$8.7/day"}Sub-agent 3：交易執行器（Trade Executor）
withdraw_from_aave(amount_usdc)、deposit_to_morpho(amount_usdc){"tx_hash": "0x...", "status": "success", "actual_gas": "$2.1", "actual_apy_received": 5.08}Sub-agent 4：監控器（Monitor）
get_wallet_balance()、get_position_pnl()、check_market_volatility(){"alert_type": "high_volatility", "action": "pause_all_execution"}Orchestrator 的角色：接收 Sub-agent 1 的數據，傳給 Sub-agent 2 分析，收到 Sub-agent 2 的建議後，如果建議金額 > $100，觸發 Telegram 人工確認，確認後才把 approval token 連同指令傳給 Sub-agent 3 執行。Sub-agent 4 的告警可以隨時覆蓋 Orchestrator 的執行計劃，暫停一切操作。
Sub-agent 分工越細緻 → 每個 Sub-agent 的安全邊界越清晰、工具集越小、被攻擊的影響範圍越小；但系統複雜度、通信延遲、和 Orchestrator 的調度邏輯複雜度都線性上升。Sub-agent 數量少 → 系統簡單、延遲低、維護成本低；但每個 Sub-agent 需要更多工具授權（安全邊界更寬），一個 Sub-agent 被攻陷的影響範圍也更大。最佳實踐：以「功能隔離」和「安全邊界」為主要分拆理由，以「減少維護複雜度」為約束條件，找到適合當前業務規模的平衡點。對早期 DeFi Agent，2-3 個 Sub-agent（讀取/分析/執行分開）通常已足夠，不需要追求過度細分。