主流 AI Agent 框架比較:LangGraph、CrewAI、AutoGen 與 OpenAI Agents SDK 怎麼選

上季我們幫一家保險客戶收拾殘局。他們的資料科學團隊先用某個熱門框架寫了一個理賠審查 Agent,Demo 跑得漂亮,結果一放到有真實工單量的環境,狀態一斷線就整條流程重來,人工要從頭補資料。問題不在模型,在於框架的選型從一開始就沒考慮「這東西壞掉的時候會怎樣」。

所以每次有工程主管問我們「該用哪個 Agent 框架」,我們的第一個反問都是:你要的是快速做出一個會動的東西,還是一個三個月後還敢改的東西?這兩件事,常常導向不同的答案。

AI Agent 框架比較:先看你在哪個象限

主流的四個選擇——LangGraph、CrewAI、AutoGen、OpenAI Agents SDK——其實對應著不同的設計哲學。做 AI Agent 框架比較時,別被「誰功能多」帶著走,要看三個維度:能力邊界、學習曲線、生產可維運性。前兩個決定你多快能上手,最後一個決定你會不會在半夜被叫起來。

我們實際踩過的取捨

LangGraph 是我們在金融、醫療這類「錯一步就要留審計軌跡」的場景裡的預設選擇。它逼你把流程畫成狀態圖,節點、邊、條件分支都攤在明面上。代價是前兩週工程師會抱怨囉嗦——但正是這份囉嗦,讓你能在任意節點做 checkpoint、斷線續跑、插入人工審核。上面那個保險客戶,我們最後就是用它把「斷線重來」改成「從失敗節點續跑」。學習曲線陡,但它換來的是可維運性。

CrewAI 適合的是另一種需求:你要在一週內證明一個點子值不值得做。用角色(researcher、writer、reviewer)加任務去組裝,幾十行就有一個像模像樣的多 Agent。但它的抽象包得比較厚,一旦要塞進複雜的條件分支或嚴格的錯誤處理,你會開始跟框架的預設打架。我們把它定位成原型與內容型工作流的利器,不是核心系統的地基。

AutoGen 走的是「讓 Agent 彼此對話」的路線,配上程式碼執行能力,在研究性、探索性任務上很強。v0.4 改成事件驅動的非同步架構後,生產化程度明顯提升,背後有微軟撐著,但也意味著生態正在往 Semantic Kernel 那邊整併,選型時要把這個走向算進去。

OpenAI Agents SDK 是這批裡最年輕、也最克制的。它只給你 agents、handoffs、guardrails、sessions 幾個原語,內建 tracing,而且透過 LiteLLM 也能接非 OpenAI 的模型。概念少、上手快、預設就想著生產。缺點是生態還在長,複雜編排的成熟範例不如 LangGraph 多。

怎麼快速收斂

給工程主管一個粗略的決策法:流程複雜、要人工介入、要審計,選 LangGraph;只是要快速驗證概念,選 CrewAI;偏研究與程式碼協作,選 AutoGen;想要輕量又生產導向、團隊人手不多,選 OpenAI Agents SDK。別忘了它們並非互斥——我們也做過用 LangGraph 當主編排、把某個子任務丟給 CrewAI 的混搭。

框架只是起點。我們在客戶現場最花時間的,從來不是「哪個框架語法漂亮」,而是把 Agent 接上真實資料、扛住併發、留下可回溯的軌跡,最後真的有人天天在用。Demo 跑得順不算數,上線且有人用,才算數。