SDK
選 Agent 框架是一次至少六個月的承諾：心智模型、狀態管理、除錯工具鏈全都會跟著它走。但在比較 LangGraph、CrewAI、AutoGen 與 OpenAI Agents SDK 之前，2026 年有一個更值得先回答的問題——你真的需要多個 Agent 嗎？
前言：先付掉 Swarm Tax
史丹佛 2026 年的一項研究（Tran & Kiela）給了多智能體熱潮一盆冷水：在等量思考 token 預算下，單一 Agent 在多跳推理任務上的表現持平甚至優於多 Agent 系統。過去多 Agent 看起來更強，部分原因是 API 層的預算控制假象——多 Agent 架構默默拿到了更多 token。研究者稱之為「swarm tax」：每一次 Agent 之間的資訊交接，都是一次摘要與轉述，也就是一次資訊損失的機會。
UC Berkeley 的 MAST 分類研究（NeurIPS 2025，分析 1,600 多筆跨七個框架的生產故障）則從另一面印證：79% 的多 Agent 失敗是規格與協調問題——步驟重複、推理與行動脫節、不知道何時終止——而不是模型或基礎設施的問題。框架選得再好，也救不了寫不好的協作規格。
所以選型流程的第一步不是比框架，而是誠實回答：這個任務真的需要 3 個以上的 Agent 協作嗎？如果答案是否定的，一個配好工具的單 Agent 往往是最強的預設架構。
一、四大框架的心智模型
如圖一，每個框架背後都是一種不同的「世界觀」：
- LangGraph——狀態機／圖：Agent 與函式是節點，控制流是邊，狀態是型別化且可 checkpoint 的。你畫得出流程圖，它就跑得出來；也因此它天生支援暫停、中斷後續跑（resume）與 human-in-the-loop。2025 年 10 月 LangGraph 1.0 穩定版發布後，LangChain 官方立場已是「Agent 用 LangGraph，不用 LangChain」。
- CrewAI——角色分工：用「研究員、寫手、審稿」這種角色語言思考，Crew＋Agent＋Task 三件套，經理協調任務鏈。從想法到可跑 demo 最快，適合快速驗證。
- AutoGen——對話輪流：Agent 之間用自然語言對話協作，直到滿足終止條件。v0.4 重寫為非同步事件驅動架構，但 2026 年現實是：微軟已把它與 Semantic Kernel 合併為 Microsoft Agent Framework，AutoGen 本體進入維護模式（只修安全問題、不加新功能）。新專案不建議再從 AutoGen 起手。
- OpenAI Agents SDK——交棒＋守門：2025 年 3 月接替實驗性的 Swarm，核心原語極簡：Agents、Handoffs、Guardrails。2026 年 4 月加入沙箱執行與記憶控制；同年 2 月 OpenAI 推出企業治理平台 Frontier（Agent 身份、權限、共享上下文、效能追蹤）。代價是與 OpenAI 生態深度綁定，旗艦功能多半只走 Responses API。
一句話記法：LangGraph 管流程、CrewAI 管角色、AutoGen 管對話、OpenAI Agents SDK 管交棒＋守門。
二、生產級實測：數字會說話
第三方實測給出了相當一致的結論。一份 2026 年的生產部署評估（AlterSquare，實際跑過三個框架）指出：
- LangGraph 每任務約 4.2 次 LLM 呼叫、成本約 $0.08（GPT-4o）；AutoGen 平均 22.7 次呼叫、$0.45——對話式協調的 token 開銷在規模化時非常真實。
- 錯誤恢復率 LangGraph 達 96%，checkpoint 可存進 PostgreSQL／Redis／DynamoDB；CrewAI 在 5–10 個 Agent 規模後協調鏈開始脆弱，且缺乏細緻的 replay 能力。
另一份 Towards AI 的 2026 企業指南評分也呼應：生產可靠度、可觀測性（LangSmith tracing 開箱即用）、human-in-the-loop、成本可預測性，LangGraph 都是五星；CrewAI 贏在開發速度（2–3 個工程日就有 demo，LangGraph 要 10–14 天）；AutoGen 最大的風險是成本不可預測與維護模式。
值得一提的是 CrewAI 自己的發現：分析 17 億次 agentic workflow 後，他們的結論是「deterministic backbone with intelligence deployed where it matters」——確定性骨幹＋只在關鍵處放智能。這其實也是整個產業 2026 年的共識方向：把確定性留給流程，把智能留給決策點。
三、選型決策流程
如圖二，把上面的結論收斂成一棵決策樹：
- 真的需要 3 個以上 Agent 協作？否 → 單 Agent＋工具，先省下 swarm tax（見前言）。
- 需要長跑、暫停續跑或 human-in-the-loop？是 → LangGraph：checkpoint、interrupt、條件邊都是原生一等公民。
- 要最快做出 demo？是 → CrewAI：角色語言最直覺，但上線前要有「硬化」計畫——2026 年常見模式是 CrewAI 做原型、LangGraph 做生產。
- 否 → OpenAI Agents SDK（＋Frontier 做企業治理）：心智模型最簡單、guardrails 內建，適合已在 OpenAI 生態的團隊；若需多模型中立，回到 LangGraph。
Google ADK（v1.0 穩定）是第五個選項：如果你全家都在 Vertex AI 與 Google Workspace 上，它的整合深度無人能及；否則 Gemini-first 的定位會是限制。
四、實作入門：LangGraph 最小三節點
用 LangGraph 畫一個「規劃→執行→檢查，不通過就回規劃」的迴圈，不到 40 行：
from typing import TypedDict
from langgraph.graph import StateGraph, END
class State(TypedDict):
task: str
plan: str
result: str
approved: bool
def planner(s: State) -> State:
s["plan"] = llm(f"為任務擬定步驟：{s['task']}")
return s
def executor(s: State) -> State:
s["result"] = run_tools(s["plan"])
s["approved"] = checker(s["result"]) # 驗證器：通過才結束
return s
g = StateGraph(State)
g.add_node("plan", planner)
g.add_node("execute", executor)
g.set_entry_point("plan")
g.add_edge("plan", "execute")
g.add_conditional_edges("execute",
lambda s: END if s["approved"] else "plan") # 條件邊：迴圈
app = g.compile(checkpointer=checkpointer) # 中斷可續跑
注意最後一行：checkpointer 讓整個圖的狀態持久化，服務重啟、人審核、中斷後都能從斷點續跑——這正是 LangGraph 與「對話式」框架在生產環境的本質差別：狀態是資產，不是對話紀錄的副產品。
結論：框架是第二個問題
2026 年選 Agent 框架的務實順序是：
- 先問需不需要多 Agent——多數任務單 Agent＋好工具就夠，別先付 swarm tax。
- 需要多 Agent，先寫清楚協作規格——Berkeley 的數據說 79% 的失敗死在這層，換框架救不回來。
- 再按決策樹選框架：長跑與治理選 LangGraph、快速驗證選 CrewAI、OpenAI 生態選 Agents SDK＋Frontier；AutoGen 新專案跳過，直上 Microsoft Agent Framework。
框架會繼續演化，但這三個問題的順序不會變：要不要多 Agent → 規格寫清楚了沒 → 才選框架。
參考來源
- Towards AI：LangGraph vs CrewAI vs AutoGen: Production Guide (2026) — pub.towardsai.net
- AlterSquare：LangGraph vs CrewAI vs AutoGen 生產部署評估（2026-05） — altersquare.medium.com
- VentureBeat：Are you paying an AI 'swarm tax'?（Stanford 2026 研究） — venturebeat.com
- Forkast：UC Berkeley MAST 故障分類（79% 為規格與協調問題） — forkast.news
- OpenAI：New tools for building agents（Agents SDK） — openai.com
- LangChain Blog：LangGraph 1.0 — blog.langchain.com
- Microsoft Research：AutoGen v0.4 — microsoft.com
