任何代理專案的第一個決策，也是最容易做錯、代價最高的一個。
選定一個框架、埋頭開發三個月，然後發現它表達不了你的狀態機——這時候你要換的不是一套函式庫，而是整個代理重寫。這就是為什麼網路上框架選擇的論戰永遠不會停，也是這份指南存在的原因：用同一份任務、同一組工具，實測 2026 年最重要的四個框架，並誠實回答一個沒有任何官方文件會告訴你的問題——什麼時候該完全跳過框架。
我們會在每一節維持一個不變的前提：**框架是編排層，不是模型層。**四個框架都接受任何 OpenAI 相容的 endpoint，也就是說「選模型」與「選框架」是可以分開的兩個決策。這個分離正是本比較的骨幹。
選擇之前：選擇、建構與協定
重點：框架選擇其實是三種不同決策的其中一種——而多數比較指南把它們混為一談。
- **建構（Construction）**談的是代理內部如何運作：tool-calling 迴圈、記憶、編排模式。這一層我們有完整的架構指南，而且它主張——我們認為這是對的——你應該先搞懂這個迴圈，再來採用框架。
- **協定（Protocol）**談的是代理與工具之間如何溝通：function calling、MCP、A2A。這是完全獨立的另一個決策，我們的協定比較有完整說明。
- 選擇（Selection）——也就是本文——決定的是：要用哪個框架（如果有的話）來包住你的建構層。
在往下讀任何一個選項之前，先做最後一道篩選：**什麼時候你根本不需要框架。**單一個 tool-calling 迴圈、一個模型、不需要持久化——這大概只要 50 行 Python，直接用 SDK 就寫得完，我們的快速上手示範了最基本的呼叫。下面每一個框架，都是為了解決那 50 行原型撐不住之後才出現的問題。
選項一：LangGraph——圖形編排與正式環境生態系
重點：LangGraph 是複雜有狀態代理的正式環境預設選擇——代價是四者中最陡的學習曲線。
LangGraph 把代理建模成圖形（graph）：節點是步驟、邊是轉換，而且這張圖擁有會在不同 run 之間持續存在的真實狀態。這個設計買到了其他框架難以做到的三件事：checkpointing（當機的代理從中斷處接續執行）、把 human-in-the-loop 中斷當成第一級原語、以及長時間執行工作流程所需的持久狀態。
1.0 的重寫（2025 年底）大幅清理了 API——2023 到 2024 年主導輿論的「LangChain 太臃腫」抱怨，大多針對的是舊的抽象技術堆疊，而不是圖形核心本身。圍繞它的生態系（tracing、部署、測試工具）是四者中最成熟的；LangGraph 概覽文件是目前 API 面貌的權威參考。
**成本這一面。**學習曲線是真的：圖形、reducers、checkpointers，還有「我的狀態到底住在哪裡」這種以前從沒想過的心智負擔。沒有具體狀態管理需求就採用 LangGraph 的團隊，等於白繳這筆稅。
**多供應商現實檢驗。**LangGraph 透過模型層與任何 OpenAI 相容的 endpoint 溝通。把它指向你的統一 API endpoint，這張圖就會依照你設定的模型路由執行——自訂路由可以把便宜的模型送去處理便宜的節點，把前沿模型送去處理關鍵節點。框架鎖住的是你的編排，不是你的模型。
**適合誰：**需要處理複雜、有狀態、長時間執行工作流程的團隊；任何需要 checkpoint／接續執行的人；以及一年內就會撐破簡單抽象層的組織。
選項二：CrewAI——角色分工協作，起步最快
重點：CrewAI 是上線多代理原型最快的路——也是最快撞上複雜狀態天花板的框架。
CrewAI 的賭注是：代理系統就是團隊。你定義帶有角色與目標的 Agents、帶有描述的 Tasks、以及負責編排一切的 Crew。這個抽象層連非工程背景的人都能看懂——產品經理可以打開一份 CrewAI 定義檔、讀完就懂。對那些代理設計不完全是工程產物的團隊來說，這是實打實的優勢。
**天花板在哪裡。**CrewAI 的流程模型（sequential 與 hierarchical 執行）把線性與輕度分支的工作流程處理得很好。一旦你的代理需要條件迴圈、動態重新規劃、或細粒度的狀態復原，你就是在跟抽象層搏鬥，而不是在使用它。誠實的建議：用 CrewAI 做原型，但如果工作流程真的會變有狀態，就把 LangGraph 或手刻遷移的預算先編進去。
**設定成本相對也低。**CrewAI 的定義讀起來就像一份規格書：帶有角色、目標與背景故事的 agents；帶有預期輸出的 tasks；以及依序或分層執行它們的 crew。你可以在午餐前就做出一個能跑的三人代理系統——這正是它成為產品團隊驗證點子時預設推薦的原因。
**適合誰：**正要交付第一個多代理系統的團隊、流程式自動化專案，以及任何把「多久能跑出第一個可用的代理」看得比架構空間更重要的人。
選項三：AutoGen——維護模式，以及該怎麼應對
重點：AutoGen 現在已進入維護模式——新的 Microsoft 生態系專案，請改用 Microsoft Agent Framework。
AutoGen 的 v0.4 重寫帶入了以 actor 為基礎、搭配型別化訊息的架構，影響力貨真價實——多代理對話模式、群組聊天編排，以及它背後的學術血統，在目前的代理生態系裡處處可見。如果你手上有一套能跑的 AutoGen 系統，它會繼續能跑；v0.4 的 actor 模型不會一夜之間腐壞。
但 2026 年的現況再清楚不過：Microsoft 整合了它的代理產品線，AutoGen 進入維護模式，接班人就是 Microsoft Agent Framework（Python 與 .NET）。維護模式的意思是：修 bug、發安全性更新，不會再有任何新功能。
**務實的鐵則：**不要在廠商已公開放生的框架上開新專案。如果你用的是 Microsoft 技術堆疊，直接評估 Agent Framework；如果不是，它啟發的那套多代理對話模式，由這裡另外三個選項來承接綽綽有餘。
**AutoGen 留給生態系的遺產。**在把這條血統整個否定之前，它的遺產值得好好研究。以「對話即運算（conversation-as-computation）」為核心的模型——代理之間交換結構化訊息、把群組聊天當作編排原語——現在已經是業界的常態。如果你的設計需要自由形式的多代理對話、又要能控制到訊息層級，你其實是在實作一個 AutoGen 的概念；Microsoft Agent Framework 與 LangGraph 都用各自的方式承接了這個概念，但最初的 v0.4 actor 模型，仍然是理解訊息傳遞系統最乾淨的心智模型。
**適合誰：**已經在 AutoGen 上有投資的團隊（留下來，並規劃一個遷移窗口）；除此之外，不建議任何人從零開始。
選項四：OpenAI Agents SDK——官方輕量原語
重點：Agents SDK 是最不像框架的框架——只有三個原語、沒有 DSL——對 OpenAI 生態系的團隊來說，它是最好的預設選擇。
Agents、Handoffs、Guardrails。整個框架的全部面貌就是這樣。Agent 包住一個模型加一些工具；Handoffs 讓一個代理把工作委派給另一個代理；Guardrails 在模型迴圈之外執行輸入與輸出的驗證。沒有圖形 DSL、沒有 crew 定義檔——就是 Python 物件與 async 函式，意思是這份程式碼讀起來像你自己的 codebase，而不是像某個框架的。
這個 SDK 建基於 Responses API（就 agentic 工作而言，它是 Chat Completions 的接班人），而 2026 年平台側動作頻頻：模型原生 harness 的改進、與 OpenAI 代理工具更緊密的整合——目前的完整功能清單請見 OpenAI Agents SDK 文件。對已經押注 OpenAI 模型的團隊來說，這是阻力最小的正式環境路徑：官方維護、預設值合理、代理核心沒有任何第三方依賴。
**取捨在哪裡：**原語刻意做得很小。複雜的狀態機還是需要圖形；重度的多代理角色設計還是需要更有結構的東西。而 SDK 預設親近 OpenAI 模型這件事，在壞掉之前一直都是優點——這正是模型層分離之所以重要的原因：同一組 Agent 物件，可以指向 OpenAI 相容的統一 endpoint，用你的路由層決定的任何模型。
**適合誰：**OpenAI 生態系的團隊、以正式環境為重且不信任 DSL 的開發者，以及任何想要最小框架表面積的人。
同一份任務、四個框架：一個正式環境代理
重點：這四個框架的差異，與其說在「能做些什麼」，不如說在「把什麼變得容易」——請用正式環境的維度衡量它們，別用 demo 影片。
拿同一個任務來說：一個有工具存取（查詢工單、檢查退款資格）、有對話記憶、而且超過門檻的退款需要人類核准步驟的客服代理。每個框架大約 150 到 250 行。結構上的差異如下：
| 面向 | LangGraph | CrewAI | AutoGen | Agents SDK |
|---|---|---|---|---|
| 狀態與持久化 | 第一級（checkpointers） | session 範圍 | actor 式訊息 | session 範圍 |
| Human-in-the-loop | 中斷原語 | 任務層級 | 對話層級 | 僅 guardrails |
| 除錯與追蹤 | 成熟生態系 | 基本 | 基本 | 官方 + 第三方 |
| 錯誤復原 | 從 checkpoint 接續 | 重跑任務 | 重放訊息 | retry wrapper |
| 模型可攜性 | OpenAI 相容 endpoint | 相同 | 相同 | 相同（預設 OpenAI） |
| 學習曲線 | 陡峭 | 平緩 | 中等 | 平緩 |
真正決定你專案的欄位是：**狀態與復原。**如果一個跑了一整夜的任務當機之後必須從圖形中途接續，LangGraph 是唯一把這件事設計成功能的框架。如果你的代理只是無狀態的 request-response 加上工具，Agents SDK 用一小部分的機制就能把事情做完。
表格裡看不出來的兩件事，重要性都超過任何一列：除錯體驗與團隊熟悉度。這裡每個框架都可以除錯；但一旦代理開始做真正的工作，沒有一個是容易除錯的。在 LangGraph 裡追蹤一次失敗的多步驟執行，你是在圖形上走一遍；在 Agents SDK 裡，你讀的是一串原語的 trace。兩者都堪用。真正拍板的是團隊熟悉度這一軸：一個團隊已經半熟的框架，勝過一個技術上更優秀、但沒人看得懂的框架。這其實是一個披著技術決策外衣的招募與培訓決策。
**關於鎖定，說句老實話。**這裡的每個框架，在編排層都是鎖定——這就是採用框架的意義。解法不是「挑鎖定最少的」，而是把模型層分離出來：四個框架都指向 OpenAI 相容的 endpoint，所以換模型——或是在價格變動時換供應商——只是改設定，不是重寫。這就是我們的正式環境優化指南所說的「模型即設定」模式，也是你唯一真正避得開的鎖定。
決策矩陣：團隊規模 × 複雜度
重點：預設選用最小的、足以表達你狀態的框架——拿不定主意時，就什麼框架都別用。
| 簡單的工作流程 | 複雜的有狀態工作流程 | |
|---|---|---|
| 個人／小團隊 | Agents SDK（或 raw SDK） | LangGraph——但只在狀態是真需求時 |
| 產品團隊 | CrewAI（上線最快） | LangGraph |
| Microsoft 技術堆疊 | Microsoft Agent Framework | Microsoft Agent Framework |
三個預設選擇，直接說清楚：
- **還沒有框架？**先從 raw SDK 和統一 client 模式開始——多數原型根本不需要框架，而「不需要框架」的原型，正好教會你真正需要的是什麼。
- **需要狀態或接續執行？**LangGraph。這份比較裡沒有任何其他框架把持久化當成核心功能。
- **已經押注 OpenAI、想要最少繁文縟節的正式環境方案？**Agents SDK。它官方、它小巧、而且它不會擋你的路。
最後一個提醒：每個框架的文件都是廠商自己寫的，而每個廠商的文件都預設你已經選了它。上面連結的協定層與建構層，無論你最後落在哪個框架——或完全不用框架——都一樣有用。
**一個 30 分鐘的評估測試。**從你的 backlog 挑一個真實任務，做兩遍：一遍用 raw SDK，一遍用你最中意的框架候選人。比較四件事——程式行數、當機後的 run 行為、你要怎麼加入人類核准步驟、以及你要怎麼換模型。四個問題，一個下午。如果框架在至少兩項上沒贏，你就不需要它。
常見問題
2026 年我應該學哪個框架？
先學最原始的 tool-calling 迴圈——它大概 50 行，而且是每個框架內部的同一個迴圈。如果你的工作牽涉狀態，再學 LangGraph；如果你在 OpenAI 的技術堆疊上，就學 OpenAI Agents SDK。學習順序比選哪個框架更重要。
框架會把我鎖住嗎？
會，在編排層——而且這沒關係。你必須避免的是模型鎖定：四個框架都接受 OpenAI 相容的 endpoint，所以把模型層放在統一 endpoint 後面，供應商變更就停留在設定層級，而不是重寫層級。
CrewAI 撐得住正式環境的工作負載嗎？
對於線性與輕度分支的工作流程，可以——上千個團隊在正式環境跑 CrewAI 風格的編排。一旦你需要條件迴圈、動態重新規劃或 checkpoint 復原，趁工作流程還沒反過來咬你之前，遷移到 LangGraph 或手刻的圖形。
框架和 MCP 有什麼差別？
它們回答的是不同的問題。MCP 把「代理如何與工具和伺服器溝通」標準化；框架把「你如何編排代理」標準化。你可以從任何框架使用 MCP servers——哪裡重疊、哪裡不重疊，我們的協定比較有詳細說明。
AgentKit 和 OpenAI Agents SDK 是同一回事嗎？
不是。Agents SDK 是用原語打造代理的 Python 與 TypeScript 函式庫。AgentKit 是 OpenAI 更高階的代理建構器，鎖定在 UI 上組裝代理的產品團隊。如果你在寫程式，從 Agents SDK 開始；如果你是從儀表板組裝，AgentKit 是那條路。兩者底層共用 Responses API，所以無論走哪條路，模型層都保持相容。
我怎麼在一個下午內評估一個框架？
跑一遍四問測試：用 raw SDK 做一個 backlog 任務，再用候選框架做一遍，比較程式行數、當機行為、你要怎麼加入人類核准步驟、以及你要怎麼換模型。在不到兩項上勝出的框架，沒有資格收它的抽象稅——而最便宜的解法，就是不要採用它。
用框架會讓我的代理變慢嗎？
抽象層的開銷很小——多數工作負載上是個位數百分比——而且通常跟模型延遲比起來根本不值一提。讓代理變慢的不是框架，是糟糕的模型路由。把便宜的模型路由到便宜的節點，框架稅就變成雜訊。
我可以在一個專案裡用兩個框架嗎？
別在同一個代理裡混用——你會同時繼承兩套抽象層，卻沒有其中任何一套的除錯故事。在不同專案（或不同服務）裡用不同框架就沒問題；共用一個模型 endpoint，兩邊的成本也維持可比。
總結
談到 AI 代理框架：LangGraph 掌握複雜狀態、CrewAI 掌握快速上線、Agents SDK 掌握最少繁文縟節、而 AutoGen 是維護模式下的遺產，不該拿來開新專案。這些框架的差異，與其說在能力，不如說在它們把什麼變得容易——所以選最小、足以表達你狀態的那個，並把模型層放在統一 endpoint 後面，讓框架決策就只是框架決策，僅此而已。
先量測，再選框架——順序別反了。取得你的 TokSpan API Key——首次贈送 $5 免費額度——把同一份工作負載丟給幾個模型跑一跑，讓實際跑出來的圖表，替網路上吵不完的論戰畫下句點。