AI Agent 匯入前先問一句：出事之後，狀態去哪裡了？
企業匯入 AI agent 前，比選 framework 更該想清楚的是狀態管理與失敗復原機制。這篇從系統整合的角度拆解為什麼多數 AI 自動化案子出包，不是模型不夠聰明，而是根本沒設計「壞掉之後怎麼辦」。
- AI agent 出包，九成不是模型笨，是沒人設計失敗之後要去哪裡
- 框架名詞一直換，底層問題從沒變過：誰擁有狀態、誰能改它
- 匯入 AI 自動化前，先問三個問題比先選工具重要一百倍
最近很多老闆問我，該選哪個 AI agent 框架比較好，某某某牌還是某某某牌。我通常先反問一句：你們的流程，壞掉之後知道要去哪裡嗎？多半換來一陣沉默。因為大家都在比工具新不新、模型強不強，卻沒人問過最基本的問題，出錯之後，這個流程要退回哪一步、誰來接手、資料會不會就這樣憑空消失。
框架名詞一直換，問題從來沒變過
這幾年 agent、workflow、multi-agent 這些詞換著花樣包裝，但拆開來看，做的事情跟幾十年前軟體工程解決的問題一模一樣。每個 agent 該是一個獨立單位，有自己的資料，不能隨便去改別人的東西，只能靠訊息溝通，這是老概念了。另一個是把每個狀態、每個轉換都寫清楚，系統只能照著設計好的路徑走，不會出現莫名其妙的行為。這兩件事聽起來很基礎，但我接過的案子裡，至少七成的 AI 自動化專案根本沒做到。
我看過不少企業的自動化流程，AI 幫忙寄信、幫忙下單、幫忙改資料，看起來很順，直到某一次網路斷線或 API 逾時，流程卡在中間，沒人知道現在是什麼狀態，也沒人知道該重跑整段還是接著跑。最後只能人工翻紀錄，一筆一筆對，比沒有自動化還累。
客戶現場邊講邊改，爽感背後要有配套
我也看過另一種做法很有效率，顧問到客戶現場，客戶邊講需求，AI 邊改邊測邊上線，兩個小時解決過去要來回好幾週的修改案。這種即時協作確實能大幅壓縮溝通成本，我自己也很推崇這種效率。但這裡有個前提容易被忽略，當場推上線這件事，背後一定要有明確的復原機制，改壞了能不能一鍵退回上一版，測試有沒有覆蓋到關鍵路徑，不是每個系統都適合玩這麼快。爽感是真的，風險也是真的，兩者要一起設計，不能只享受前者。
匯入前先問這三個問題
- 誰擁有目前的狀態，這份資料或這筆流程進度存在哪裡，誰有許可權改它
- 事件發生之後會走去哪一步，是有明確定義的下一個狀態，還是全靠模型臨場發揮
- 失敗之後怎麼恢復，是有清楚的復原點，還是隻能整段重跑然後祈禱這次不會又壞在同一個地方
這三個問題答不出來，代表這套 AI 自動化其實是個黑盒子，能用是運氣好，出事是必然。我們在幫企業做系統整合的時候，第一件事永遠不是選模型，而是先把這套流程的狀態圖畫出來，哪些是已知狀態，哪些是還沒定義、卻真的會發生的例外。多數專案的地雷都埋在那些沒被畫出來的例外裡。
AI 提供的是判斷力，不是責任感。真正該負責任的，是設計流程的人，不是那個被吹捧的模型。