2025 年 LLM Agent 開發框架完整指南：AutoGen、CrewAI、LangGraph 到底該選哪個？

三個月前，我在 Reddit 上看到一個帖子：「What's going on with AutoGen and AG2?」

帖子底下吵成一團。有人說 AutoGen 被微軟放棄了，有人說要趕快遷移到 AG2，還有人困惑地問：「我上週才開始學 AutoGen，現在該怎麼辦？」

說實話，那時候我也一頭霧水。

我正在評估要用哪個框架來建立公司的多代理人客服系統，結果發現這個領域在 2024 年底發生了翻天覆地的變化。AutoGen 分裂了、OpenAI 把 Swarm 升級成正式 SDK、Anthropic 推出了 MCP 協議還捐給了 Linux Foundation...

如果你也正在選擇 LLM Agent 框架，這篇文章應該能幫你省下不少冤枉路。

---

先搞清楚：什麼是 LLM Agent？

在深入比較框架之前，我們得先對齊一下概念。

你可以把 LLM Agent 想像成一個超級聰明的助理。這個助理不只會回答問題，還能主動規劃任務、使用各種工具、甚至自己判斷下一步該做什麼。

傳統的 LLM 應用是這樣的：你問一個問題，它給你一個答案。結束。

但 Agent 不一樣。你給它一個目標，比如「幫我研究這家公司然後寫一份報告」，它會：

1. 先規劃需要哪些步驟
2. 上網搜尋公司資訊
3. 讀取財報 PDF
4. 分析數據
5. 撰寫報告
6. 如果發現資訊不足，自己決定要不要再查更多

這種「自主決策 + 工具使用 + 多步驟執行」的能力，就是 Agent 的核心。

那什麼是「多代理人系統」呢？

想像你要做一個複雜的專案，不可能一個人包辦所有事。你會組建團隊：有人負責研究、有人負責寫程式、有人負責測試、有人負責專案管理。

多代理人系統就是這個概念。不同的 Agent 扮演不同角色，互相協作完成任務。一個 Agent 可能專門負責寫程式，另一個專門負責 code review，第三個負責執行測試...

聽起來很美好對吧？問題是，怎麼讓這些 Agent 順暢協作、不會互相打架、還能可靠地完成任務？

這就是為什麼我們需要框架。

---

2024 年底發生了什麼事？

如果你在 2024 年中開始學 AutoGen，恭喜你，你選了當時最熱門的框架。

微軟研究院開發的 AutoGen 是多代理人領域的先驅，GitHub 上有超過 4 萬顆星。文件完整、社群活躍、企業級支援。

然後，2024 年 11 月，事情變得複雜了。

AutoGen 分裂事件

簡單來說，AutoGen 的核心貢獻者和微軟產生了分歧。一群人離開微軟，創建了新的組織 AG2AI，fork 了 AutoGen 並改名為 AG2。

現在的狀況是這樣的：

AG2（社群版）

• 由原始核心開發者維護
• 繼承了 pyautogen 和 autogen 套件名稱
• Apache 2.0 開源授權
• 保持向後相容，你的舊程式碼可以直接跑
• 持續在 0.3.x 版本上開發新功能

Microsoft AutoGen 0.4（微軟版）

• 微軟進行的完全重寫
• 新的 API 設計，不向後相容
• 可能會與 Semantic Kernel 整合
• 更注重企業級功能

怎麼說呢，這有點像 Node.js 和 io.js 當年的分裂，或是 MySQL 和 MariaDB。

對開發者來說，這意味著你需要做選擇：

• 如果你重視穩定性和向後相容 → 跟著 AG2
• 如果你已經深度使用微軟生態系統 → 考慮等 AutoGen 0.4 穩定
• 如果你還沒開始 → 可能值得考慮其他框架

這件事也讓我意識到，選擇開源框架時，專案的治理結構和社群健康度有多重要。

---

六大主流框架深度比較

好，現在來看看 2025 年你有哪些選擇。

LangGraph：給需要精確控制的人

如果你用過 LangChain，對 LangGraph 應該不陌生。它是 LangChain 團隊開發的圖結構編排框架。

核心概念很直接：把工作流程想像成一張圖，節點是操作，邊是流程。你可以精確控制狀態、設定條件分支、處理重試邏輯。

from langgraph.graph import StateGraph

# 定義狀態和節點
workflow = StateGraph(State)
workflow.add_node("research", research_agent)
workflow.add_node("write", writing_agent)
workflow.add_edge("research", "write")

優點：

• 精確的狀態控制
• 內建斷點和人工介入機制
• 平行執行支援
• 可視化工作流程

缺點：

• 學習曲線陡峭，你需要習慣「用圖思考」
• 對簡單任務來說可能過度設計

適合場景：複雜的多步驟工作流程、需要條件分支和重試邏輯、已經在用 LangChain 生態系統。

有個 Reddit 用戶說得很傳神：「LangGraph feels like writing a state machine with GPT agents.」

CrewAI：角色扮演的直覺設計

CrewAI 的設計哲學完全不同。它把 Agent 想像成團隊成員，每個成員有自己的角色、目標和工具。

from crewai import Agent, Task, Crew

researcher = Agent(
    role="Research Analyst",
    goal="Find comprehensive information",
    tools=[search_tool]
)

writer = Agent(
    role="Content Writer",
    goal="Create engaging articles"
)

crew = Crew(agents=[researcher, writer], tasks=[...])
crew.kickoff()

看到了嗎？這個 API 設計就是在模擬真實的團隊協作。

優點：

• API 直覺，學習曲線平緩
• 快速原型開發
• 角色定義清晰
• 文件和範例豐富

缺點：

• 當需求變複雜時，會撞到設計的天花板
• 客製化程度有限
• 有團隊反映，用了 6-12 個月後不得不改用其他框架

適合場景：快速原型、團隊協作模型契合業務邏輯、初學者入門。

說實話，如果你只是想快速驗證一個想法，CrewAI 可能是最快的選擇。但如果你知道這個專案會長期發展，可能要三思。

AutoGen/AG2：對話式的靈活彈性

即使經歷了分裂，AutoGen 的核心設計理念依然有價值。它強調的是「對話式」的多代理人協作。

from autogen import AssistantAgent, UserProxyAgent

assistant = AssistantAgent("assistant", llm_config=llm_config)
user_proxy = UserProxyAgent("user_proxy", code_execution_config={"work_dir": "coding"})

user_proxy.initiate_chat(assistant, message="Write a Python function to...")

Agent 之間透過對話來協作，就像真人在聊天室裡討論問題一樣。

優點：

• 極高的靈活性
• 強大的程式碼執行能力
• 適合複雜的對話式問題解決
• 企業級的錯誤處理

缺點：

• 目前的分裂狀況造成困惑
• 需要花時間理解該跟哪個版本

適合場景：需要複雜對話邏輯、程式碼生成和執行、企業環境。

MetaGPT：模擬軟體公司

MetaGPT 的野心很大：它想模擬一整間軟體公司的運作方式。

你給它一個需求，它會自動分配角色：產品經理、架構師、工程師、測試人員... 然後這些「虛擬員工」會協作完成整個軟體開發流程。

from metagpt.software_company import generate_repo

repo = generate_repo("Create a 2048 game")
print(repo)  # 輸出完整的專案結構和程式碼

這聽起來很科幻，但確實可以產出可運行的程式碼。

優點：

• 端到端的軟體開發自動化
• 結構化的角色分工
• 適合程式碼生成任務

缺點：

• 應用場景相對侷限
• 對非軟體開發任務支援有限

適合場景：自動化程式碼生成、軟體開發任務。

OpenAI Agents SDK：官方的優雅設計

還記得 OpenAI 在 2024 年發布的 Swarm 嗎？那是一個實驗性的多代理人框架。

現在 Swarm 已經進化成正式的 OpenAI Agents SDK，成為生產就緒的解決方案。

from openai import Agent, Swarm

agent = Agent(
    name="Assistant",
    instructions="You are a helpful assistant",
    tools=[...]
)

client = Swarm()
response = client.run(agent=agent, messages=[...])

Reddit 上有人這樣評價：「Agents SDK is designed in such an elegant way that it SEEMS lightweight and under-featured. But it's actually quite powerful.」

優點：

• API 設計優雅簡潔
• 與 OpenAI 生態系統無縫整合
• 生產就緒
• 快速部署

缺點：

• 綁定 OpenAI 模型
• 相對其他框架功能較少

適合場景：主要使用 OpenAI 模型、快速開發、偏好簡潔設計。

Claude Agent SDK：安全優先的選擇

Anthropic 不只推出了 Claude Agent SDK，還創造了可能改變整個產業的 MCP 協議。

from claude_agent_sdk import Agent

agent = Agent(
    model="claude-3-opus",
    tools=[...],  # MCP 原生支援
)

因為 MCP 是 Anthropic 開發的，Claude Agent SDK 自然有最好的 MCP 支援。

優點：

• MCP 協議原生支援
• 安全性設計優先
• Claude 模型的能力
• 簡潔的 API

缺點：

• 生態系統相對較新
• 綁定 Anthropic 模型

適合場景：重視安全性、使用 Anthropic 模型、需要 MCP 整合。

---

MCP 協議：不得不提的遊戲規則改變者

講到這裡，我必須特別談談 Model Context Protocol（MCP）。

MCP 是 Anthropic 在 2024 年底推出的開放標準，目的是解決一個根本問題：如何讓 AI 模型安全、標準化地連接外部服務和資料？

你可以把 MCP 想像成 AI 世界的 USB-C。不管你是什麼設備，只要支援 USB-C，就能互通。同樣的，不管你用什麼 AI 模型或框架，只要支援 MCP，就能使用相同的工具和資料來源。

2025 年 12 月，Anthropic 把 MCP 捐贈給了 Linux Foundation 下的 Agentic AI Foundation。這意味著 MCP 已經不再是某一家公司的東西，而是整個產業的標準。

目前支援 MCP 的框架包括：

• Claude Agent SDK（原生支援）
• PydanticAI
• LangChain/LangGraph（透過整合）
• 越來越多的框架正在加入

為什麼這很重要？

因為你寫的 MCP 工具可以跨框架使用。今天你用 CrewAI 開發，明天想換成 LangGraph，那些 MCP 工具不用重寫。

這對整個生態系統的標準化有重大意義。

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]

flowchart LR subgraph "AI 模型" A[Claude] B[GPT-4] C[其他 LLM] end

subgraph "MCP 協議層"
    D[標準化介面]
end

subgraph "外部服務"
    E[資料庫]
    F[API]
    G[檔案系統]
    H[其他工具]
end

A --> D
B --> D
C --> D
D --> E
D --> F
D --> G
D --> H</div>

---

如何選擇？一個實用的決策框架

說了這麼多，你可能還是想問：「那我到底該選哪個？」

這裡有一個決策流程供你參考：

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]

flowchart TD A[開始選擇框架] --> B{主要需求是什麼？}

B -->|快速原型驗證| C[CrewAI]
B -->|複雜工作流程控制| D[LangGraph]
B -->|對話式問題解決| E{生態系統偏好？}
B -->|軟體開發自動化| F[MetaGPT]

E -->|Microsoft 生態| G[AutoGen 0.4 / Semantic Kernel]
E -->|社群版本 / 穩定性| H[AG2]
E -->|OpenAI 生態| I[OpenAI Agents SDK]
E -->|安全優先 / Anthropic| J[Claude Agent SDK]

C --> K[開始開發]
D --> K
F --> K
G --> K
H --> K
I --> K
J --> K</div>

更具體一點：

選 CrewAI 如果：

• 你需要快速驗證想法
• 團隊協作的比喻符合你的業務邏輯
• 你是 AI Agent 新手

選 LangGraph 如果：

• 你需要精確控制工作流程
• 有複雜的條件分支和重試邏輯
• 你已經在用 LangChain

選 AG2 如果：

• 你之前用 AutoGen，想要穩定的遷移路徑
• 需要複雜的對話式協作
• 重視社群治理

選 Microsoft AutoGen 0.4 如果：

• 你深度整合 Microsoft 生態系統
• 願意接受新 API 的學習成本
• 考慮未來與 Semantic Kernel 整合

選 OpenAI Agents SDK 如果：

• 你主要用 OpenAI 模型
• 偏好簡潔的 API 設計
• 需要快速部署到生產

選 Claude Agent SDK 如果：

• 安全性是首要考量
• 你想充分利用 MCP 協議
• 使用 Anthropic 模型

還有一個選項越來越多團隊在採用：混合使用。

比如用 LangGraph 做主要的工作流程編排，但在某些子任務中使用 CrewAI 的角色定義。或者用 OpenAI Agents SDK 做主要開發，但透過 MCP 連接各種工具。

---

生產環境的真實考量

選好框架只是開始。真正的挑戰是讓它在生產環境中穩定運行。

Anthropic 的工程團隊有一個很好的建議：從簡單開始。

很多模式其實只需要幾行程式碼就能實現，不一定需要複雜的框架。他們特別強調：「如果你用框架，確保你理解底層程式碼。錯誤的假設是客戶最常見的問題來源。」

這句話值得反覆咀嚼。

成本控制

LLM 調用不便宜。一個多代理人系統可能在一個任務中呼叫十幾次 LLM，費用很快就會累積。

建議：

• 設定預算上限和監控
• 考慮哪些步驟真的需要用大模型
• 快取可重複使用的結果
• 評估是否某些任務可以用小模型處理

延遲管理

多代理人系統的延遲是個大問題。Agent A 呼叫 LLM，等回應，然後 Agent B 再呼叫，再等回應... 串聯起來可能要等很久。

建議：

• 盡可能平行化
• 考慮使用串流
• 設定合理的 timeout
• 讓用戶知道系統在做什麼（進度指示）

可觀察性

當系統出問題時，你需要知道是哪個 Agent 在哪個步驟做了什麼決定。

推薦工具：

• Langfuse
• LangWatch
• Phoenix (Arize)
• Weights & Biases

安全性

Agent 可以執行程式碼、存取外部 API、處理敏感資料。這些能力也帶來風險。

注意事項：

• 沙盒化程式碼執行
• 限制 Agent 的權限範圍
• 提示注入防護
• 敏感資料處理策略

---

寫在最後

2025 年的 LLM Agent 框架領域，說實話，還是有點混亂。

AutoGen 分裂了、新框架不斷冒出來、MCP 正在成為標準、每隔幾週就有重大更新...

但混亂也意味著機會。這個領域還在快速演進，現在入場的人有機會影響未來的發展方向。

我的建議是：

1. 不要追逐最新最熱門的。選一個適合你需求的框架，深入學習。
2. 理解底層原理。框架只是工具，理解 Agent 的設計模式更重要。
3. 關注 MCP。這可能是未來幾年最重要的標準化趨勢。
4. 從簡單開始。不要一開始就設計複雜的多代理人系統。先用單一 Agent 驗證價值，再逐步擴展。
5. 投資可觀察性。當系統變複雜時，你會慶幸自己早早建立了監控。

最後，如果你問我會選哪個？

我目前的專案選了 LangGraph 搭配 MCP。學習曲線確實陡峭，但精確的控制能力在生產環境中很有價值。

但這只是我的選擇。你的情況可能完全不同。

希望這篇文章能幫你在這個快速變化的領域中找到方向。如果你有任何問題或想分享你的經驗，歡迎交流。

---

參考資料

來源	標題
GitHub	AG2 (formerly AutoGen) Repository	⭐⭐⭐⭐⭐
Microsoft	AutoGen 0.4 Documentation	⭐⭐⭐⭐⭐
Anthropic	Building Effective Agents	⭐⭐⭐⭐⭐
Anthropic	Introducing the Model Context Protocol	⭐⭐⭐⭐⭐
DataCamp	CrewAI vs LangGraph vs AutoGen	⭐⭐⭐⭐
Datagrom	Top 3 Trending Agentic AI Frameworks	⭐⭐⭐⭐
ZenML	LLM Agents in Production	⭐⭐⭐⭐
ClickHouse	How to build AI agents with MCP	⭐⭐⭐⭐

---

本文最初發布於 HackMD @BASHCAT。