今天的快評不談單一 repo，談一個很常見、也很貴的 AI 導入坑：把 agent framework 當成工作流引擎。

這個坑會出現在團隊從 demo 走向正式流程的時候。早期你用 LangGraph、Pydantic AI、Mastra、Agno 或 OpenAI Agents SDK 做一個 agent，看起來很順：模型能判斷下一步、能呼叫工具、能保留一點狀態，甚至能跑幾輪自我修正。於是大家很自然地想，把客服處理、文件審核、報表生成、合約比對、內部請款流程也都丟進 agent graph。問題是，這些流程真正難的地方，往往不是「模型下一步要做什麼」。

真正難的是：任務跑到一半 API 掛了怎麼辦？第三方工具成功扣款但回傳 timeout 怎麼辦？人工審核三天後才回來，狀態放哪裡？同一個 webhook 重送兩次，會不會重複執行？模型決定要刪資料時，誰批准？流程第七步失敗，要 rollback 還是開補償任務？這些問題不是 prompt 寫好就會消失，它們是 workflow engineering，不是 agent reasoning。

所以我的採用判斷是：agent framework 適合管「AI 步驟」，不一定適合管「整個業務流程」。 如果流程只是在一次請求裡完成，例如分類、抽取、摘要、單次工具查詢，agent framework 當主體很合理。你需要的是 schema、tool calling、guardrails、trace、少量狀態，這時引入大型 workflow engine 反而太重。

但如果任務會跨分鐘、跨小時、跨人、跨系統，請把它拆開看。模型可以是 Temporal、Prefect、Dagster、Airflow、內部 queue worker 裡的一個步驟；agent graph 可以負責某個決策段；但外層最好仍由更可靠的工作流或任務系統管理重試、排程、人工等待、冪等鍵、補償邏輯與審計紀錄。這樣比較無聊，但正式環境通常就是靠無聊活下來。

誰適合現在就調整？已經把 agent 接進真實後台流程、而且開始遇到「偶發失敗不知道怎麼補」、「任務卡住沒人知道」、「人工審核回來時上下文不見」、「模型多跑一步就多花錢」的團隊。這代表你遇到的不是 AI 能力不足，而是控制層不夠硬。

誰不需要急？還在探索產品價值、使用者流程未定、一天只有少量內部任務的人。這時先用簡單 agent framework 跑通需求沒問題，過早導入 workflow engine 只會拖慢學習速度。

一句話結論：agent framework 是 AI 步驟的工程化工具，不是天然可靠的長任務作業系統。 先讓模型負責判斷，讓 workflow 負責活著，會比把所有責任都塞進 agent 裡穩很多。