AutoGen (Microsoft Multi-Agent Conversation Framework)

AutoGen 的 GroupChat 機制具體怎麼工作？GroupChatManager 是怎麼決定下一個發言者的？

AutoGen GroupChat 的工作原理：你定義多個 ConversableAgent（可對話的 Agent），每個 Agent 有自己的 System Prompt 定義它的角色（「你是一個加密技術分析師，專注於 RSI 和 MACD 指標」）。你把這些 Agent 加入一個 GroupChat 物件，指定最大輪次（max_round）和 speaker_selection_method（誰決定下一個發言者）。

speaker_selection_method 的選項：

auto（預設）：GroupChatManager 使用 LLM 推理來決定下一個最適合發言的 Agent。對話進行中，Manager 閱讀整個對話歷史，判斷「現在最需要哪個 Agent 的視角」。這是最靈活的，但也最不可預測——Manager 的 LLM 推理可能選擇意外的發言順序。

round_robin：按照預定義的順序循環讓每個 Agent 發言，不管當前對話狀態。最可預測，但失去了動態性。

random：隨機選擇發言者。幾乎不用在生產場景，更多是測試用。

自定義 function：你可以定義一個 Python 函數，根據當前對話狀態和 Agent 清單返回下一個發言者。這讓你在 auto 的靈活性和 round_robin 的確定性之間找到平衡——例如「如果上一個 Agent 表達了不確定，下一個一定是核實 Agent」。

對加密分析場景的建議：使用自定義 function，設計一個明確的辯論流程（技術分析 → 鏈上數據 → 宏觀分析 → 最終整合），不要完全依賴 auto 的 LLM 選擇，避免不可預測的發言順序影響分析品質。

AutoGen 和 LangGraph（LangChain 的多 Agent 框架）在加密場景最大的差異是什麼？選哪個？

這是加密 Agent 開發者最常問的框架選擇問題，答案取決於你的具體任務類型：

LangGraph 的核心優勢（適合執行層）：DAG 工作流讓執行路徑完全確定——你在設計時就知道「數據獲取 → 風險評估 → 決策 → 確認 → 執行」的順序固定不變。這讓系統可測試（可以為每個節點寫單元測試）、可審計（每次執行都走相同路徑，日誌可以精確對應）、對 Prompt Injection 防禦更好（Agent 間通訊通過預定義的 State 字典，不是自由格式的自然語言）。對有資金操作授權的 Agent 層，這些特性比「靈活性」更重要。

AutoGen 的核心優勢（適合分析層）：多 Agent 的動態辯論讓決策質量更高——一個 Agent 的分析結論會被其他 Agent 質疑，逼出更嚴謹的推理。對複雜的分析任務（評估一個新 DeFi 協議的安全性，需要法律合規 Agent、安全審計 Agent、代幣經濟 Agent 從不同角度辯論），AutoGen 的動態對話比 LangGraph 固定流程更能捕捉到更多維度的風險。

選擇框架的原則：用 LangGraph 構建「決策 → 執行」的確定性流程；用 AutoGen 構建「輸入 → 多角度分析 → 輸出分析報告」的辯論流程。在一個完整的加密 Agent 系統裡，可以把兩者結合：AutoGen 做分析（多 Agent 辯論生成分析報告），LangGraph 做執行（基於報告的確定性執行流程）。

安全考量：AutoGen 的自然語言通訊讓它在安全性上弱於 LangGraph——被 Prompt Injection 污染的 Agent 可以通過自然語言訊息影響其他 Agent。這是在執行層使用 AutoGen 必須謹慎的核心原因。

AutoGen 2.0 和 AutoGen 0.x（舊版）有什麼重大架構變化？如果從舊版遷移，需要注意什麼？

AutoGen 在 2025 年發布了 2.0 版本，架構有顯著變化，舊版用戶遷移需要理解以下核心差異：

最大的架構變化：AutoGen 2.0 引入了「Actor 模型」作為核心抽象，把 Agent 定義成可以在不同運行時（runtime）裡執行的獨立 Actor，而不是直接在 Python 進程裡的物件。這讓 AutoGen 2.0 的 Agent 可以分佈在不同的機器上或不同的語言環境裡（不只是 Python），支持更大規模的多 Agent 部署。

API 層面的 Breaking Change：AutoGen 0.x 的 ConversableAgent、AssistantAgent、UserProxyAgent 在 2.0 裡有了新的等效物（AssistantAgent 在 2.0 裡仍然存在但內部實作完全重寫）。GroupChat 和 GroupChatManager 的初始化參數有所調整。

遷移注意事項：AutoGen 2.0 提供了遷移指南，但舊代碼不能直接在 2.0 上運行。主要遷移工作：更新 Agent 的初始化方式、更新 GroupChat 的配置方式、確認你使用的模型 API 格式是否仍然兼容（2.0 對 OpenAI 兼容的 API 支持最好）。

建議：如果你在 2025 年後才開始使用 AutoGen，直接使用 2.0 版本；如果是現有的 0.x 代碼，在遷移前先在隔離的測試環境跑完整的功能測試，確認所有 GroupChat 行為一致後再遷移。不要在有真實資金 Agent 還在使用的環境裡直接升級，先在全新的測試環境驗證。

AutoGen 的「Code Execution」功能在加密場景有什麼潛力和風險？

AutoGen 的 Code Execution 功能讓 Agent 能夠生成並執行真實的 Python 代碼（在一個隔離的執行環境裡），這在加密場景有特別的應用潛力但也有相當的風險。

潛力：讓 Agent 能夠動態生成和執行鏈上分析代碼（例如「寫一段 Python 代碼查詢 Uniswap v3 的過去 7 天交易量並計算 TWAP」），不需要預先定義每種分析的工具。對需要高度客制化分析的任務（量化策略的回測、鏈上地址的行為聚類），Code Execution 比固定工具更靈活。

風險：Agent 生成的代碼可能包含安全漏洞——例如 Agent 被 Prompt Injection 誘導生成一段「查詢鏈上數據」的代碼，但代碼裡實際上包含了「把私鑰發送到外部服務器」的邏輯。更隱蔽的攻擊是讓 Agent 生成表面上看起來合理的數據查詢代碼，但實際上在後台做了其他操作。

安全設計要求（如果要用 Code Execution）：必須在完全隔離的 Docker 容器或 Sandbox 環境裡執行，容器不能有外部網路訪問（或只允許特定白名單 API），容器不能有任何私鑰或憑證；代碼執行有嚴格的超時設定（例如最多 30 秒）；每次代碼執行的完整記錄（生成的代碼 + 輸出 + 執行時間）寫入日誌供審計。

實際建議：在 2026 年的加密 Agent 生產環境裡，除非你有非常強的 Sandbox 安全能力，否則不建議在有資金操作能力的 Agent 裡使用 Code Execution。把它限制在「純分析、完全隔離、無私鑰接觸」的 Sub-agent 裡，結果只輸出文字分析，不輸出操作指令。