大多數工程師的選擇：「先裝一個框架，之後再說。」 有經驗的工程師的選擇：「先定義 Agent 的交互模式，再選能支撐它的框架。」 框架給你速度，但也給你它的限制；抽象層降低入門門檻，但隱藏了你最需要控制的細節。 正確的問題不是「哪個框架最好」，而是「這個框架的抽象層，跟我的問題邊界對不對齊」。
這篇給正要在 AutoGen、CrewAI、LangGraph 之間做選擇、或已經選了一個卻開始被它的執行模型卡住的工程師看。讀完你會能用「誰決定下一步、狀態存哪裡、出錯怎麼辦」三個問題拆解任何 Agent 框架、說出四個主流框架各自的執行模型與生產限制、判斷自建薄協調層的觸發條件，並為多 Agent 客服系統排出從框架預設配置到持久化、再到自建的升級順序。
一、核心問題：框架選型的本質是什麼
Agent 框架的選型問題，表面上是技術選擇，本質上是控制權與抽象層的交換。
每個框架都做了一組隱性決策：
- 執行模型：對話驅動 vs. 圖驅動 vs. 任務佇列驅動
- 狀態管理：記憶體內 vs. 持久化 vs. 外部化
- Agent 通訊：廣播 vs. 點對點 vs. 中介者模式
- 錯誤恢復：重試策略、fallback 路徑、人工介入點
選錯框架的代價不是「換框架」這麼簡單。當你的 Agent 邏輯與框架的執行模型深度耦合後，重構成本等同於重寫。
框架的三個本質問題
問題 1：誰決定下一步由誰執行？
├── 框架決定 → 高度結構化，靈活性低
├── LLM 決定 → 靈活但不可預測
└── 工程師的程式碼決定 → 可控但需要更多開發工作
問題 2：狀態存在哪裡？
├── 對話歷史 (messages list) → 簡單，但 token 成本高
├── 結構化狀態物件 → 可查詢，但需要 schema 設計
└── 外部資料庫 → 持久化，但增加延遲
問題 3：出錯時怎麼辦？
├── 讓 LLM 自己決定 → 彈性，但不可靠
├── 框架的重試機制 → 簡單，但缺乏語意
└── 工程師的顯式錯誤處理 → 精確，但需要更多程式碼
理解這三個問題的答案，才能判斷一個框架是否適合你的用例。
二、何時該升級：從框架預設配置到持久化、再到自建薄協調層的觸發條件
起步時直接用 CrewAI 或 AutoGen 的預設配置、狀態放記憶體、stdout 看 log，是驗證「這幾個 Agent 的分工到底有沒有價值」最快的路。該升級的訊號不是對話量，而是失敗後的代價：一次 LLM 失敗讓整段多 Agent 對話從頭來、沒有 trace 能說出哪個 Agent 花了多少 token、或是出現需要人工確認才能繼續的步驟。這時需要的是有 checkpointer 的執行模型（LangGraph，§五）或把狀態外部化（Redis session + PostgreSQL audit log），再接 LangSmith／Langfuse 之類的追蹤。
第二道門檻是框架的執行模型與你的問題不對齊：GroupChat 由 LLM 決定下一個發言者，讓 P99 延遲不可預測；框架升級帶來破壞性變更（AutoGen 0.2 → 0.4）；需要跨機器的真正並行而框架只給偽並行；或是每個 Agent 要獨立部署與計費。§七列出四個自建的觸發條件——效能瓶頸、可觀測性、升級風險、特殊執行模型——符合其中兩個以上，才值得把協調層換成自建的薄層（狀態容器 + Agent 介面 + 協調器）加訊息佇列。
| 從 | 到 | 觸發訊號 |
|---|---|---|
| 框架預設配置、記憶體狀態 | LangGraph checkpointer 或外部化狀態 + 追蹤 | 失敗需要從頭重跑；無法回答哪個 Agent 花了多少；需要人工介入點 |
| 單一框架協調 | 自建薄協調層 + 訊息佇列 + 獨立 Agent 服務 | 符合 §七兩個以上的觸發條件；每個 Agent 需獨立部署與計費 |
| 單一框架 | 混合使用（確定性流程 LangGraph、研究型子任務 AutoGen） | 不同模組的互動模式差異大到一個框架無法同時支撐 |
三、AutoGen：對話式多 Agent 的工程哲學
AutoGen（Microsoft Research）的核心哲學：把 Agent 協作建模成對話。每個 Agent 是對話參與者，協作透過訊息傳遞完成，沒有顯式的「工作流程圖」。
2026 年註記：Microsoft 於 2025 年 10 月發布 Microsoft Agent Framework，把 AutoGen 與 Semantic Kernel（§六）整合為同一個產品線，兩者後續以維護為主。本文對 AutoGen 與 SK 的分析仍適用於理解設計取捨，但新專案應評估 Agent Framework；同時也值得一併比較各模型廠商的 Agent SDK（如 OpenAI Agents SDK、Claude Agent SDK）與 Pydantic AI。
核心架構
┌─────────────────────────────────────────────────────────┐
│ AutoGen 對話模型 │
│ │
│ UserProxyAgent AssistantAgent │
│ ┌──────────────┐ ┌──────────────────────────┐ │
│ │ 代表人類使用 │ │ 實際執行 LLM 推理 │ │
│ │ 者的代理人 │◀──────▶│ + 工具呼叫 │ │
│ │ │ │ + 程式碼執行 │ │
│ │ 可執行程式碼 │ │ │ │
│ │ 可代為確認 │ └──────────────────────────┘ │
│ └──────────────┘ │
│ │ │
│ ▼ (群組對話) │
│ ┌────────────────────────────────────────────────┐ │
│ │ GroupChat │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Agent A │ │ Agent B │ │ Agent C │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ ▲ │ │ │
│ │ │ GroupChat │ │ │
│ │ │ Manager │ │ │
│ │ └──────────────┘ │ │
│ │ (由 LLM 決定下一個發言者) │ │
│ └────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
上圖是 AutoGen 0.2 的 UserProxyAgent / GroupChat 模型；0.4 改寫為事件驅動的 Core + AgentChat 架構，概念相近但 API 不同。
AutoGen 的優勢場景
- 研究型任務：需要多輪反覆辯論才能得出答案（論文分析、程式碼除錯）
- 程式碼執行循環：AssistantAgent 寫程式碼 → UserProxyAgent 執行 → 錯誤回傳 → 修正
- 快速原型：20 行程式碼就能跑起 2 個 Agent 的對話
AutoGen 的工程限制
- 狀態不透明：狀態藏在 messages list 裡，難以查詢特定欄位
- 流量控制困難：對話輪數由 LLM 決定，難以預測 token 用量
- 生產部署複雜：AutoGen 0.4（AgentChat）架構重寫，0.2 升 0.4 需大量重構
- 延遲數字：每次工具呼叫 +150–400ms overhead（HTTP to executor）；GroupChat 中每輪需一次 LLM 呼叫決定下一個 speaker，增加 ~800ms–2s
適用規模：POC 到 MVP 早期。日對話超過 20K 後，GroupChat 的不可預測性開始造成 P99 延遲爆炸。
四、CrewAI：角色扮演協作的工程實現
CrewAI 的核心哲學：把 Agent 協作建模成組織。有明確角色（Role）、目標（Goal）、背景（Backstory）的 Agent，像公司員工一樣被分配任務。
核心設計模式
1# CrewAI 的典型程式碼結構（概念示意）
2
3researcher = Agent(
4 role="資深研究員",
5 goal="收集競爭對手的技術架構資訊",
6 backstory="你是有 10 年經驗的技術情報分析師",
7 tools=[search_tool, scrape_tool],
8 verbose=True
9)
10
11writer = Agent(
12 role="技術文件撰寫者",
13 goal="將研究結果轉成清晰的技術報告",
14 backstory="你擅長將複雜技術概念轉為可執行的洞察",
15 tools=[file_write_tool]
16)
17
18task1 = Task(
19 description="分析 {competitor} 的 API 設計模式",
20 agent=researcher,
21 expected_output="結構化的技術分析報告"
22)
23
24crew = Crew(
25 agents=[researcher, writer],
26 tasks=[task1, task2],
27 process=Process.sequential # 或 hierarchical
28)
CrewAI 的優勢場景
- 內容生成流水線：研究 → 撰寫 → 審核的線性流程
- 結構清晰的分工：角色定義讓非工程師也能理解 Agent 在做什麼
- 快速 Demo：角色描述比圖節點更直觀，stakeholder presentation 效果好
CrewAI 的工程限制
- 動態路由困難：Process.sequential 和 Process.hierarchical 以外的流程需要繞路實現
- 錯誤處理薄弱：Task 失敗的 fallback 邏輯需要自己包裝
- 生產監控不足：內建可觀測性較弱，需要外掛 LangSmith 或 Langfuse
- 記憶體管理：長對話的 context window 管理需要手動處理
適用規模：MVP 中期。流程固定、分工明確的批次任務表現優異；需要動態分支的即時對話系統則捉襟見肘。
五、LangGraph：有狀態圖執行的生產級設計
LangGraph 的核心哲學：把 Agent 執行流程建模成有向圖（DAG/循環圖），狀態是一等公民。
核心架構
┌──────────────────────────────────────────────────────────┐
│ LangGraph 圖執行模型 │
│ │
│ State Schema（TypedDict） │
│ ┌─────────────────────────────────┐ │
│ │ messages: List[BaseMessage] │ │
│ │ intent: str │ │
│ │ retrieved_docs: List[str] │ │
│ │ draft_response: str │ │
│ │ quality_score: float │ │
│ └──────────────┬──────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │ intent_ │─▶│retriever │─▶│generator │─▶│quality │ │
│ │classifier│ │ _node │ │ _node │ │_checker│ │
│ └──────────┘ └──────────┘ └──────────┘ └───┬────┘ │
│ │ │
│ ┌────────────────────────────┘ │
│ │ 條件邊 (conditional edge) │
│ ▼ │
│ quality_score < 0.8? │
│ ┌──────┴──────┐ │
│ Yes No │
│ │ │ │
│ ▼ ▼ │
│ generator_node END │
│ (重新生成) │
│ │
│ Checkpointer： │
│ SQLite（開發）→ PostgreSQL（生產）→ Redis（高頻） │
└──────────────────────────────────────────────────────────┘
LangGraph 的生產級特性
1. Checkpointing（斷點續傳）
1# 每個節點執行後自動儲存狀態
2from langgraph.checkpoint.postgres import PostgresSaver
3
4checkpointer = PostgresSaver.from_conn_string(DB_URL)
5graph = workflow.compile(checkpointer=checkpointer)
6
7# 任何節點失敗都可以從上一個 checkpoint 重新執行
8result = graph.invoke(input, config={"configurable": {"thread_id": "user-123"}})
2. Human-in-the-loop LangGraph 原生支援在任意節點暫停，等待人工確認後繼續執行。這是 AutoGen 和 CrewAI 都難以優雅實現的功能。
3. 流式輸出 逐 token 串流 + 節點執行事件串流，讓前端可以顯示即時進度。
LangGraph 的工程限制
- 學習曲線陡峭：TypedDict state + graph 語法 + conditional edges 需要 1–2 週才能熟練
- 圖的調試困難：循環圖的執行路徑不直觀，需要搭配 LangSmith 才能有效調試
- LangChain 耦合：雖然可以獨立使用，但許多工具假設你在 LangChain 生態
適用規模：MVP 後期到 Scale。需要持久化狀態、人工介入點、複雜分支邏輯的系統，LangGraph 是目前生產成熟度最高的選擇。
六、Semantic Kernel：企業整合的 Microsoft 路線
Semantic Kernel（SK）的核心哲學：把 AI 能力以「插件（Plugin）」形式整合進現有企業系統，而非建立獨立的 AI 系統。
適用場景
- 已有大量 .NET / C# 程式碼庫，需要整合 LLM
- 企業 Azure 環境，使用 Azure OpenAI Service
- 需要嚴格的安全審計與 RBAC 整合
- 已使用 Microsoft 365 / Teams，需要 Copilot 式整合
SK 的工程特性
- 跨語言：Python、C#、Java SDK 均有支援
- Planner：自動把使用者目標分解成 Plugin 呼叫序列
- Memory：內建向量記憶體抽象，接 Azure Cognitive Search 等企業級後端
- 成熟度：Azure 生態整合最佳，但社群活躍度遠低於 LangChain/LangGraph
- 現況：SK 的後續發展已併入 Microsoft Agent Framework（見 §三 註記）
適用規模：企業 IT 系統整合。如果你的團隊不在 Microsoft 技術棧，遷移成本高，不建議採用。
七、自建框架：何時抽象層成為負擔
自建框架不是「更好」，而是「框架的抽象層已經成為你前進的障礙」。
自建的觸發條件
觸發條件 1：效能瓶頸
症狀：框架 overhead 佔總延遲 > 30%
數字：LangGraph 節點切換 overhead ~20–50ms/node
AutoGen GroupChat speaker selection ~800ms–2s/turn
決策點：當你有 < 10 個節點的確定性工作流程，自建更快
觸發條件 2：可觀測性需求
症狀：框架的 trace 格式不符合你的監控堆疊
決策點：需要 per-agent 成本追蹤、自定義 span 屬性
觸發條件 3：升級風險
症狀：AutoGen 0.2 → 0.4 破壞性重構
LangChain 頻繁的 API 變更
決策點：框架升級的測試成本 > 維護自建程式碼的成本
觸發條件 4：特殊執行模型
症狀：需要真正的並行 Agent（非偽並行）
需要分散式 Agent 跨機器協作
決策點：框架的執行模型根本上不符合你的需求
自建框架的最小核心
1# 自建框架的核心只需要三個東西
2
3# 1. 狀態容器
4@dataclass
5class WorkflowState:
6 session_id: str
7 messages: list
8 metadata: dict
9 created_at: datetime
10 updated_at: datetime
11
12# 2. Agent 介面
13class BaseAgent(ABC):
14 @abstractmethod
15 async def run(self, state: WorkflowState) -> WorkflowState:
16 pass
17
18# 3. 協調器
19class Orchestrator:
20 def __init__(self, agents: dict[str, BaseAgent], router: Callable):
21 self.agents = agents
22 self.router = router # 你的業務邏輯決定下一步
23
24 async def run(self, initial_state: WorkflowState) -> WorkflowState:
25 state = initial_state
26 while (next_agent := self.router(state)) is not None:
27 state = await self.agents[next_agent].run(state)
28 await self.save_checkpoint(state) # 自己實現
29 return state
這 ~30 行程式碼比任何框架都更容易加入你的 tracing、cost tracking、retry 邏輯。
代價：你需要自己維護、自己寫測試、自己處理邊緣情況。在團隊規模 < 5 人且 Agent 邏輯簡單時，這通常不值得。
八、為什麼選 X 不選 Y
「單一框架 vs 混合使用」與「有框架 vs 純 LLM API」的條件已分別寫在 §二與 §七；這裡只留四組框架之間的正面比較。
決策 1：AutoGen vs. CrewAI
選擇 選 AutoGen 的理由 選 CrewAI 的理由
──────────────────────────────────────────────────────────────
互動模式 對話式、反覆辯論型任務 角色分工明確的批次任務
程式碼執行 原生支援 code execution loop 需要自行整合
可讀性 訊息串流，調試直觀 角色定義，stakeholder 易讀
生產成熟度 0.4 架構重寫，需謹慎升級 相對穩定但功能較少
學習曲線 中等（對話模型直觀） 低（角色隱喻易懂）
Flip condition：
- 選 AutoGen 當：任務需要多輪程式碼執行與修正循環
- 選 CrewAI 當：流程是線性的，且需要非技術人員理解 Agent 分工
決策 2：LangGraph vs. AutoGen
選擇 選 LangGraph 的理由 不選 AutoGen 的理由
──────────────────────────────────────────────────────────────
狀態管理 TypedDict 明確定義，可查詢 messages list 不透明
持久化 原生 checkpointer，斷點續傳 需要自行實作
條件分支 conditional edge 精確控制 GroupChat 由 LLM 決定
延遲 確定性路由，P99 可預測 Speaker selection 不穩定
生產案例 Replit、Elastic 已上線 生產案例相對較少
Flip condition：
- 選 LangGraph 當：需要持久化、人工介入、複雜分支邏輯
- 選 AutoGen 當：快速 POC、研究型任務、程式碼生成循環
決策 3：LangGraph vs. 自建
選擇 選 LangGraph 的理由 選自建的理由
──────────────────────────────────────────────────────────────
開發速度 Checkpointer 開箱即用 需自行實作所有基礎設施
社群支援 活躍社群，問題易找到答案 需自行解決所有問題
升級風險 LangChain 生態頻繁變更 完全自控，不依賴外部
效能 節點切換 overhead ~20–50ms 可優化到 < 5ms
可觀測性 與 LangSmith 深度整合 可接入任何 OTel 相容工具
Flip condition：
- 選 LangGraph 當：團隊 < 10 人，需要快速迭代，生產成熟度夠
- 選自建當：節點數 < 10、流程確定性高、框架 overhead 是瓶頸
決策 4：Semantic Kernel vs. LangGraph
選擇 選 SK 的理由 不選 LangGraph 的理由
──────────────────────────────────────────────────────────────
技術棧 .NET / Azure 環境 Python 優先環境
企業整合 Azure AD、RBAC、Compliance 需自行處理企業安全
社群生態 Microsoft 官方支援 LangChain 社群更大
AI 功能多樣性 Planner 強，記憶體抽象好 圖執行更靈活
Flip condition：
- 選 SK 當：在 Microsoft 企業技術棧，有 Azure 合規需求
- 選 LangGraph 當：Python 優先，需要靈活的圖執行
九、系統效應
各框架的量化比較（示意估算，綜合社群經驗整理，非統一條件下的 benchmark 實測）：
指標 AutoGen 0.4 CrewAI LangGraph 自建
──────────────────────────────────────────────────────────────────────
POC 開發時間 1–2 天 1–2 天 3–5 天 5–10 天
MVP 開發時間 2–3 週 2–3 週 3–4 週 6–10 週
節點切換 overhead 150–400ms 100–300ms 20–50ms < 5ms
GroupChat latency +800ms–2s N/A N/A N/A
Checkpointing 需自行實作 需自行實作 原生支援 需自行實作
Human-in-the-loop 有（複雜） 有（有限） 原生支援 需自行實作
框架升級風險 高（0.2→0.4） 中 中 低（自控）
社群活躍度（★） ★★★★ ★★★ ★★★★★ N/A
生產案例 中等 中等 較多 視團隊而定
Python 型別安全 中等 中等 高（TypedDict） 完全自控
成本追蹤粒度 Task 級 Task 級 Node 級 完全自控
示意估算，非實測數據
關鍵洞察：
- LangGraph 在 可靠性 和 可觀測性 上領先，但學習成本最高
- CrewAI 在 可讀性 和 快速交付 上領先，但生產靈活性不足
- AutoGen 在 研究型對話任務 上最適合，但不適合高流量生產環境
- 自建框架的 overhead < 5ms 對比 LangGraph 的 20–50ms，但相對於動輒數秒的 LLM 呼叫，這點框架延遲幾乎可以忽略，不足以作為自建的成本理由；自建真正的收益在於升級風險可控、除錯路徑清楚等維運面
十、系列導航
← Phase 14 Part 2：Phase 14 Part 2：Agent 規劃系統 — 從目標到行動計畫
→ Phase 14 Part 4：Phase 14 Part 4：Agent 生產化 — 可靠性、可觀測性與成本控制
本文屬於「AI 工程從零開始」系列 Phase 14。如有技術討論，歡迎透過 GitHub Issues 或部落格留言區交流。
