AutoGen 進入維護模式後，還值得怎麼用？從 Core、AgentChat 到 MCP 的多代理架構拆解

先講結論：它仍是好教材，但不該再被當成新專案的預設答案

AutoGen 曾經把「多個 Agent 如何協作」這個問題帶進主流開發者視野。它不是只提供一個聊天 API，而是把訊息傳遞、事件驅動 runtime、AgentChat 的高階抽象、模型與工具整合，以及 AutoGen Studio 的視覺化原型環境，組成一個可拆解的框架。[1]

但現在必須先說清楚一個重要前提：官方 repository 已標示 AutoGen 為 maintenance mode，不再接受新功能或 enhancement，後續由社群維護；新專案則建議改用 Microsoft Agent Framework。[1] 因此，本文不是把 AutoGen 包裝成最新的 Agent 平台，而是回答更實際的問題：如果團隊已經在用 AutoGen，應該如何理解它的架構、如何安全地完成評估，以及什麼時候該把投資轉向 successor？

截至 2026 年 9 月 6 日，GitHub API 查詢顯示 microsoft/autogen 約有 60,834 顆星，最近一次 push 為 2026 年 4 月 15 日。[2] 星數代表社群影響力，不代表未來 roadmap；對今天的工程決策而言，maintenance mode 反而是最需要被放進評估表的資料。

AutoGen 真正解決的是哪個抽象層？

多代理系統最容易失控的地方，不是「能不能建立第二個 Agent」，而是不同角色之間如何傳遞訊息、共享狀態、決定下一步，以及在工具呼叫失敗時如何結束或恢復。AutoGen 的設計把這些責任分到不同層級，而不是讓每個應用程式自行拼接 callback 和 prompt。

官方 README 把框架拆成三個主要 API 層：

Core API：提供 message passing、event-driven agents，以及支援本機與分散式執行的 runtime；同一層也考慮 Python 與 .NET 的跨語言支援。
AgentChat API：建立在 Core 之上的較高階、較有意見的 API，適合快速建立兩個 Agent 對話或 group chat 等常見多代理模式。
Extensions API：容納模型 client、code execution 與其他第一方或第三方整合，將外部能力放在可替換的擴充邊界。[1]

這個分層提供了一個重要的工程選擇：原型可以從 AgentChat 開始，對 runtime、訊息型別或分散式部署有更高要求時，再往 Core 下探。換句話說，應用程式不必一開始就承擔所有基礎設施細節，也不必因為採用高階 API 就永遠失去底層控制。

從 Hello World 看出 Agent 的責任邊界

README 的最小 Python 範例只建立一個 AssistantAgent，再交給 OpenAIChatCompletionClient 執行任務。[1] 這個範例看起來簡單，但它揭示了三個分離的元件：Agent 負責行為與對話，model client 負責模型供應商連接，runtime 負責執行與生命週期。

import asyncio
from autogen_agentchat.agents import AssistantAgent
from autogen_ext.models.openai import OpenAIChatCompletionClient

async def main() -> None:
    model_client = OpenAIChatCompletionClient(model="gpt-4.1")
    agent = AssistantAgent("assistant", model_client=model_client)
    print(await agent.run(task="Say 'Hello World!'"))
    await model_client.close()

asyncio.run(main())

從 production 角度看，這段程式還不是完整服務。它沒有呈現身份驗證、請求配額、對話持久化、觀測性、重試策略或工具權限。但它很適合用來檢查第一個邊界：把模型 client 置換成另一個支援的 provider 時，Agent 的業務邏輯是否仍能維持不變？如果不能，表示整合層已經滲透進應用層，之後的維護成本會快速上升。

AgentTool：讓 Agent 成為另一個 Agent 的工具

AutoGen 的多代理編排範例使用 AgentTool 將專門的 Agent 包裝成工具，再交給一個 general assistant 選擇何時呼叫。[1] 例如，math expert 和 chemistry expert 可以各自保留自己的 system message 與 description，主 Agent 則根據任務把工作路由到正確角色。

這個模式的價值，不在於把「多個 prompt」堆在一起，而在於把專業角色變成可發現、可呼叫的能力。主 Agent 不需要知道專家內部如何完成任務，只要知道工具描述與回傳方式即可。

但工具化也帶來新的控制點。專家 Agent 可能進一步呼叫工具，形成巢狀迴圈；主 Agent 也可能在錯誤條件下反覆轉交任務。README 的範例設定 max_tool_iterations=10，這類上限在 production 不是可有可無的參數，而是成本、延遲與失控範圍的基本保險。[1]

導入時至少應記錄每一次路由：是哪個 Agent 決定呼叫哪個專家、傳入的任務摘要、工具迭代次數、模型成本與最後結果。否則當輸出錯誤時，團隊很難判斷問題來自路由、專家提示、工具本身，還是模型選擇。

MCP 整合：把外部能力接到 Agent 工作流

AutoGen README 也提供使用 Playwright MCP server 的範例。McpWorkbench 負責管理 MCP workbench，StdioServerParams 則描述以 npx 啟動的 server；Agent 透過 workbench 取得瀏覽器工具，並以 stream 方式輸出結果。[1]

server_params = StdioServerParams(
    command="npx",
    args=["@playwright/mcp@latest", "--headless"],
)

async with McpWorkbench(server_params) as mcp:
    agent = AssistantAgent(
        "web_browsing_assistant",
        model_client=model_client,
        workbench=mcp,
        model_client_stream=True,
        max_tool_iterations=10,
    )

MCP 讓 Agent 與外部工具之間有比較清楚的協定邊界，但不等於自動安全。官方 README 特別提醒，只應連接可信任的 MCP server，因為它們可能在本機執行命令或暴露敏感資訊。[1]

實務上，MCP server 應像 production service 一樣被管理：固定版本而不是無限制使用 @latest，限制可執行的命令與檔案路徑，為每一個工具定義最小權限，並在寫入、刪除或對外送出資料前增加人工核准。對瀏覽器工具而言，還要處理登入狀態、cookie、下載檔案與外部網站 prompt injection。

AutoGen Studio 適合原型，不代表可以直接上線

AutoGen Studio 提供 no-code GUI，用來建立與執行多代理工作流；README 的啟動方式是 autogenstudio ui --port 8080 --appdir ./my-app。[1] 這對產品經理、研究人員或需要快速比較 Agent topology 的團隊很有用，因為它縮短了從概念到可觀察 demo 的距離。

但官方也明確寫出 Studio 不是 production-ready app。真正部署時仍要自行補上身份驗證、安全控制與其他服務級功能。[1] 這個提醒值得延伸成一個常見檢查：原型工具展示的是「工作流能不能跑」，production 系統要證明的是「誰能跑、能跑到哪裡、失敗後如何恢復、每次執行能不能追溯」。

因此，Studio 最適合作為：

早期驗證 Agent 分工與工具路由的沙盒。
讓非純工程角色理解工作流的溝通介面。
建立測試案例與比較不同編排策略的入口。

一旦流程涉及真實客戶資料、付款、刪除資料或外部訊息，就應把 Studio 的結果轉成可測試的程式與明確的權限策略，而不是把原型環境直接暴露給使用者。

Maintenance mode 改變了採用策略

如果 AutoGen 仍在積極開發，團隊可能會把學習成本視為長期平台投資；現在則應把它分成兩種情境。

第一種是既有系統。 已經使用 AutoGen 的團隊可以先盤點 Core、AgentChat、Extensions 與 Studio 的依賴範圍，鎖定版本，補齊測試與觀測性，再依官方 migration guide 評估轉往 Microsoft Agent Framework 的路徑。[1][3] 不需要因為 maintenance mode 就立刻重寫所有程式，但要停止無限擴大對舊 API 的依賴。

第二種是全新專案。 若沒有相容性或既有資產的理由，應先研究 Microsoft Agent Framework，而不是把 AutoGen 當成新服務的預設基礎。這不是因為 AutoGen 的架構沒有參考價值，而是新專案需要明確的長期支援預期；官方 README 已經替使用者做出方向指引。[1]

這也讓 AutoGen 變成一個很好的架構教材：它示範了如何分層、如何將 Agent 包裝成工具、如何接 MCP，以及如何把高階編排與低階 runtime 分開；同時也示範了為什麼 framework 的生命週期與 migration strategy 必須和技術功能一起評估。

AI Chain 的實作判斷

AutoGen 最值得讀的不是某一段 magic prompt，而是它把多代理系統的責任切開：Core 管 runtime 與訊息，AgentChat 管常見編排，Extensions 管模型與外部能力，Studio 則縮短原型回饋迴圈。[1]

如果今天要做技術評估，我會依序完成四個小實驗：

用一個 model client 跑通最小 Agent，確認生命週期與錯誤處理。
用 AgentTool 建立一個有迭代上限的專家路由，量測成本與失敗率。
連接一個固定版本、權限受限的 MCP server，測試工具發現、執行與撤銷。
將同一組測試案例放到目前 AutoGen 與 Microsoft Agent Framework，記錄 API 差異與遷移成本。

這樣的評估不會只得到「demo 很酷」的結論，而能回答真正影響採用的問題：執行邊界是否可控、工具權限是否可審查、觀測資料是否足夠，以及團隊是否願意承擔 maintenance mode 下的長期維護。

AutoGen 仍然值得讀、值得用於既有系統的穩定化，也值得作為多代理架構的參考實作；但對全新 production 專案，最負責任的做法是把它當成需要規劃遷移的成熟資產，而不是把高星數誤讀成未來承諾。

參考來源

本文依據 AutoGen 官方 GitHub repository、GitHub API metadata，以及官方 migration／documentation 連結整理。星數與更新資料以 2026 年 9 月 6 日查詢結果為準。

[1] https://github.com/microsoft/autogen

[2] https://api.github.com/repos/microsoft/autogen

[3] https://learn.microsoft.com/en-us/agent-framework/migration-guide/from-autogen/

[4] https://microsoft.github.io/autogen/stable/user-guide/agentchat-user-guide/index.html