自建 Agent 平台還是導入框架?LangGraph、CrewAI、AutoGen 與自研的取捨

上一季我們接手一個製造業的稽核 Agent 專案。前一個團隊用 CrewAI 兩週就跑出 Demo,多 Agent 分工看板漂亮,老闆當場拍板。三個月後我到現場,系統在測試環境跑得好好的,一放到真實稽核流程就開始「亂編」——把不同批號的檢驗數據張冠李戴。問題不在框架爛,而在於當那個邊角案例炸開時,沒人說得清楚該由誰負責、從哪一層改起。

這就是 agent 框架比較裡最少人談、卻最致命的一件事:出事的時候,責任跟改動權在誰手上。

agent 框架比較:自建 vs 導入,先問對問題

多數人比框架,比的是「誰上手快」「誰支援多 Agent」「誰的社群大」。這些都對,但都是表層。真正決定你三個月後半夜會不會被叫起來的,是兩個維度:維運責任歸屬——線上出錯時,你能不能定位到是哪一步、哪個 prompt、哪次工具呼叫出的問題;以及邊角案例掌控度——當客戶的流程跟框架預設的「標準 Agent 迴圈」不一樣時,你改得動嗎,還是被抽象層鎖死。

導入現成框架,等於把一部分控制權換成開發速度。自研,等於用工程成本換完整的掌控。沒有哪個絕對對,只有你這個場景值不值得。

三個主流框架與自研的實際差異

這張表不是要你選一個「最強的」。是要你對照自己的處境。

我們的經驗是這樣分的。如果你要的是內部工具、快速驗證一個想法,CrewAI 或 AutoGen 讓你兩週內拿到能說服老闆的東西,這時候糾結自研是浪費生命。但如果這個 Agent 要進金融的授信、醫療的病歷、製造的稽核這類「錯一次就要寫報告給主管機關」的流程,LangGraph 的顯式狀態控制會是你的底線——因為你需要在每一個狀態轉移點攔截、記錄、回放。

大中華區企業,什麼時候該自研

這是很多歐美教學不會講的部分。大中華區的企業有三個特徵,會把「導入框架」的性價比往下拉。

第一,流程不標準。台灣的中型製造廠,一套稽核流程可能是二十年來疊出來的土法,沒有一個現成框架的「標準 Agent 迴圈」對得上。框架幫你省的那 70% 通用邏輯,對這些客戶可能只值 30%,剩下的全是你要硬塞進抽象層的例外。塞到後來,你維護框架 hack 的成本比自己寫還高。

第二,資料落地與合規。金融與醫療客戶常要求全程私有部署、可稽核、可解釋。當框架把 LLM 呼叫、記憶體、工具調度都包在黑盒裡,出事時你很難對稽核單位交代「這個決策是怎麼來的」。自研不是為了炫技,是為了讓責任鏈可以攤在桌上講清楚。

第三,維運誰扛。這是我們最在意的。導入框架,升級一次可能 break 你三個客製節點;框架社群一個 breaking change,你的生產環境就得重測。自研的地基醜歸醜,但那是你自己的,壞了你改得動,不用等上游 merge PR。

反過來說,如果客戶流程夠標準、合規壓力低、要的是速度,那硬要自研就是工程師的自我感動。我們踩過這個雷——曾經為一個其實用 LangGraph 兩週能解的內部知識問答,自研了一個月的編排層,最後那些程式碼九成跟框架重複。

我們現在怎麼決定

務實的切法:先問這個 Agent 上線後,出錯的代價由誰承擔、改動的速度由誰決定。代價高、要自己扛責任、流程又非標準,就往自研或 LangGraph 這類高掌控方案靠;代價低、求驗證速度,就用 CrewAI、AutoGen 快速跑起來,別過度工程。

在 Tenten,我們通常不是二選一,而是分層:用 LangGraph 這種可控框架搭骨架,把真正卡住客戶、框架處理不了的那 20% 邊角邏輯自研補上。工程師進場的第一週不是寫 code,是先把「這條流程錯了誰負責」畫清楚——因為 Demo 再漂亮,上線後沒人敢用、或沒人扛得起,那都不算數。