Agent 框架多到看不完，但真正把它推上生產環境的團隊卻不多。這不是巧合。過去一年，從 LangGraph、CrewAI、AutoGen 到各家雲廠商自家的 Agent SDK，抽象層一個比一個漂亮，Demo 一個比一個順。但當你要把它接進一個已經跑了好幾年的訂單系統、ERP、或客服後台，痛點會集中在幾個很無聊的地方——而這些地方，框架的行銷頁上通常不會寫。
框架解決的問題，跟你以為的不一樣
多數 Agent 框架的核心賣點是「編排」：怎麼讓多個 LLM 呼叫、工具呼叫串成一條有邏輯的流程。這件事重要，但它其實是最容易寫的一段。真正難的是：
- 狀態要放哪裡：Agent 執行到一半掛了，怎麼續跑？跨對話的長期記憶要不要落地？落到哪個資料庫？
- 錯誤怎麼處理：LLM 回了不合格的 JSON、工具 timeout、外部 API 改欄位，這些在 Demo 裡看不到，但在生產環境每天發生。
- 觀測性：一個 Agent run 呼叫了 12 次 LLM、跳了 4 個工具，中間哪一步出錯？token 花在哪？沒有 trace，除錯等於通靈。
舉個例子，假設一家中型電商想做一個「自動處理退貨申請」的 Agent：讀信、判斷理由、查訂單、決定是否退款。用任何框架都能在半天內寫出 Demo。但要上線，你得回答：如果 Agent 判斷錯，誰負責？決策要不要留 audit log？客服要不要能在中途接手？這些問題跟框架選哪個關係其實不大，跟你的系統設計關係比較大。
# 示意：一個 agent step 的最小骨架
# 實際 API 請參考各框架官方文件
def handle_refund(state):
order = fetch_order(state["order_id"]) # 外部 API，會失敗
decision = llm_decide(order, state["reason"]) # 可能回錯格式
if decision.needs_human:
return escalate(state)
return apply_refund(order, decision)
關鍵不在這幾行怎麼寫，而在 fetch_order 掛了要怎麼 retry、llm_decide 回不合格內容時要不要重跑、apply_refund 是否 idempotent。這些是後端老題目，Agent 框架幫不了太多。
選型時該問的三個問題
如果現在要選一個 Agent 框架，我們的經驗法則是先問這三題，再看 API 好不好看：
- 它的狀態模型能不能塞進你現有的持久化層？ 有些框架綁自己的 checkpoint 格式，有些讓你自己接 Postgres/Redis。後者遷移成本低很多。
- 它的 trace 輸出能不能接進你現有的觀測工具？ 支援 OpenTelemetry 幾乎是必要條件。不然你會為了看一個 bug 而多買一套 SaaS。
- 不用框架，你能不能一週內自己寫一個 80 分的版本？ 如果答案是可以，那框架帶來的價值主要是「省時間」而不是「省複雜度」。當框架自己變成複雜度來源，就該退回自己寫。
第三題最常被忽略。Agent 邏輯的本質是一個帶狀態的 while loop 加上工具呼叫，用純 Python 或 TypeScript 寫一個夠用的版本，門檻其實不高。框架的價值在於它把常見模式做成慣用寫法，讓你不用每次重造。但如果你的流程長得跟它預設的模式差很多，硬套反而繞路。
我們的觀察
技術選型的重點從來不是「這個東西紅不紅」，而是「它幫我少寫什麼、又逼我多寫什麼」。Agent 框架現在還處在快速演化期，抽象層每三個月就會換一輪。與其押寶某個框架，不如先把自己的工具介面、狀態儲存、trace 管線設計得夠乾淨——這些不管框架怎麼換，都留得下來。