AG2 v1.0：從 AutoGen 分裂出來的協定驅動 AgentOS，值得你重新評估
AG2 (formerly AutoGen): The Open-Source AgentOS.Join us at: https://discord.gg/sNGSwQME3x
秒懂
- 它是什麼？
- AG2 曾是 AutoGen 的延續，但 v1.0 徹底改寫為協定驅動架構，導入 ag2 命名空間與 Network 協調模式。本文拆解其機制、安裝流程與遷移成本，並指出它不適合誰。
- 適合誰用？
- 若你正在開發新的多代理人系統，且願意擁抱 async 與協定優先設計，AG2 v1.0 值得嘗試。若你現有程式碼依賴 import autogen 或 ConversableAgent、GroupChat，請留在 ag2-classic，不要直接升級。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
AutoGen 分裂之後，AG2 選擇了什麼
AG2 這個專案的前身是 AutoGen，但 v1.0 之後它不再提供 autogen 這個 import 名稱。README 明確指出，ConversableAgent、GroupChat、AssistantAgent 這些經典類別已經移到 ag2ai/ag2-classic 這個獨立倉庫。這不是品牌改名而已，而是架構上的斷裂。AG2 v1.0 採用協定驅動的框架，頂層套件改為 import ag2，核心代理人類別是 Agent，多代理人協調則由 Network（hub 加 channels）取代過去的 GroupChat。如果你從 AutoGen 時代就開始使用，這個改變會直接影響你的程式碼結構。文件也警告，v1.0 不是 Classic 的 drop-in 升級，agent 模型、協調方式與 import 全部變了。這代表採用 AG2 之前，你得先決定是否願意放棄舊有的 AutoGen 習慣。
安裝與第一個 Agent：async 是起點，不是選項
安裝指令很直接。Windows 或 Linux 下執行 pip install ag2[openai]，Mac 則需要引號，pip install 'ag2[openai]'。Python 版本要求至少 3.10。最小依賴會預設安裝，但你必須依照模型供應商選擇對應的 extra，例如 ag2[anthropic]、ag2[gemini]、ag2[ollama]。API 金鑰透過標準環境變數讀取，export OPENAI_API_KEY="<your-api-key>"，其他供應商則是 ANTHROPIC_API_KEY、GEMINI_API_KEY 這類名稱。你也可以用 OpenAIConfig(model="gpt-4o-mini", api_key=...) 在程式碼中明確傳入金鑰，這在每個請求自帶金鑰的情境下有用。README 特別強調 AG2 全程 async，這不是建議而是預設。第一個 agent 的範例程式碼沒有在 README 中完整呈現，但從架構來看，你必須以 async 語法撰寫。對習慣同步程式碼的開發者，這是學習曲線的開端。
Network 取代 GroupChat：協調機制的根本差異
AG2 v1.0 的多代理人協調不再依賴 GroupChat 或 swarm，而是採用 Network 概念，由 hub 與 channels 組成。README 的比較表顯示，Classic 的 GroupChat、swarms、nested chats 對應到 v1.0 的是 Network。這個改變不只是名稱替換。GroupChat 通常以一個管理員角色來輪流分配發言權，Network 則更像是基礎建設，hub 負責路由，channels 提供不同的通訊路徑。文件提供了從 group chat 遷移到 Network 的指南，這暗示兩者的概念模型並不一致。如果你原本用 GroupChat 來模擬會議討論，現在得重新思考如何用 channels 來設計代理人之間的通訊拓撲。這對於想要精細控制對話流程的開發者來說，可能是一個退步，因為 GroupChat 的既有模式比較直觀。但對於需要非同步、非線性協作的場景，Network 可能更有彈性。
工具、人類參與與知識壓縮：AG2 的實際承諾
README 列出了幾個核心概念：Agents、Tools、Human in the Loop、Orchestrating Multiple Agents、以及 agent harness 中的 knowledge 與 compaction。Tools 指的是代理人可以呼叫外部函式，Human in the Loop 則是在自動化流程中保留人類審核或介入的節點。knowledge 與 compaction 是比較少見的設計，它暗示 agent harness 會管理代理人的知識狀態，並在必要時壓縮對話歷史或記憶，以避免上下文過長。這不是空泛的功能列表，而是具體的架構元件。但 README 沒有詳細說明 knowledge 的儲存格式或 compaction 的觸發條件，這需要查閱文件或原始碼才能確認。對於工程師來說，這代表評估時不能只依賴 README，必須深入 docs.ag2.ai 的文件才能判斷這些機制是否符合你的需求。
真正的限制：async 與遷移斷層不是小事
AG2 v1.0 最大的限制是它與 Classic 的徹底斷裂。README 用粗體警告，v1.0 不是 drop-in 升級，agent 模型、協調與 import 都變了。這代表任何現有的 AutoGen 應用程式都無法直接升級，必須重寫。另外，全程 async 的設計對某些團隊是障礙，例如內部工具如果依賴同步呼叫或阻塞式 I/O，整合時會需要額外的轉接層。AG2 也要求 Python 3.10 以上，這會排除仍在維護 Python 3.9 的專案。還有一個實際問題：AG2 依賴特定模型供應商的 extra，如果你同時使用 OpenAI 與 Anthropic，你得安裝多個 extra，這可能增加依賴衝突的風險。最後，AG2 由志願者維護，README 提到一群來自多個組織的志願者，這對於需要長期商業支援的企業來說，是一個需要考量的不確定因素。
替代方案：ag2-classic 與其他框架的取捨
最直接的替代方案是 AG2 Classic，也就是 ag2ai/ag2-classic 這個倉庫。它保留了 autogen 命名空間與 ConversableAgent、GroupChat 等熟悉的類別，安裝指令是 pip install ag2-classic。如果你現有的程式碼使用 import autogen，Classic 是唯一合理的選擇，因為 AG2 v1.0 已經不提供這個 import。Classic 仍然被維護且可安裝，這讓你可以繼續使用舊有程式碼而不需重寫。除了 Classic，市場上還有其他多代理人框架，例如微軟的 AutoGen 原始專案（如果它仍然獨立發展）或 LangChain 的 Agent 生態系。但 README 沒有提供這些比較，所以這裡只能指出架構上的差異：AG2 v1.0 以協定為核心，強調 hub 與 channels 的通訊模式，而 Classic 以對話管理為核心，GroupChat 直接模擬群組討論。選擇哪一個，取決於你想要的是通訊基礎設施，還是現成的會議式協調。
授權與維護成本：Apache-2.0 背後的現實
AG2 使用 Apache-2.0 授權，這對商業使用相對友善，允許修改與再散佈，只要保留著作權聲明。但 README 沒有提及任何貢獻者授權協議或商標政策，所以這方面需要自行查證。維護方面，專案最近釋出 v1.0.4（2026 年 9 月 7 日），顯示釋出節奏穩定，大約每兩週一個小版本。最後一次 push 是 2026 年 9 月 8 日，代表專案仍然活躍。但 README 也說專案由志願者維護，這意味著沒有商業公司的 SLA 保證。升級成本方面，從 Classic 遷移到 v1.0 需要重寫 agent 類別與協調邏輯，文件提供 group chat 遷移指南，但這不代表遷移是輕鬆的。如果你打算長期使用，你必須追蹤每個 minor 版本是否引入 breaking change，因為 v1.0 系列才剛開始，API 可能還會調整。Apache-2.0 讓你可以自由分叉，但分叉後你得自己承擔維護責任。
編輯結論
若你正在開發新的多代理人系統，且願意擁抱 async 與協定優先設計，AG2 v1.0 值得嘗試。若你現有程式碼依賴 import autogen 或 ConversableAgent、GroupChat，請留在 ag2-classic，不要直接升級。採用前先驗證三件事：你的團隊是否熟悉 asyncio、你的模型供應商是否有對應的 extra（例如 ag2[openai]）、以及 Network 的 hub 與 channel 模型是否符合你的協作場景。AG2 v1.0 不是 AutoGen 的向後相容版本，它是一套重新設計的框架，這個事實本身決定了你該不該碰它。
社群筆記