最近我越來越覺得，企業導入 AI Agent 最容易誤判的地方，不是模型夠不夠聰明，而是我們太習慣用「一次性的測試」去判斷一個會長期執行任務的系統。
demo 當下跑得漂亮，當然值得開心。但如果它明天、下週、換一批資料、換一個人下指令、工具回傳格式改了一點，結果就開始飄，那它還不能算真正進入 production。Agent 的品質不是考一次試就畢業，而是要有一套每天都能變好的迴路。
傳統軟體的品質管理相對直覺。輸入固定，邏輯固定，測試案例跑過，至少可以知道某些行為被鎖住了。就算有 bug，也多半能追到某段程式、某個資料狀態或某個流程分支。AI Agent 麻煩的地方在於，它不是單純執行一段固定邏輯，而是在理解任務、選工具、讀資料、做判斷、產出結果之間來回移動。
所以我不太相信「我們做了一份 benchmark，分數還不錯」就代表 Agent 可以放心上線。benchmark 有價值，但它比較像體檢，不是日常健康管理。真正的問題通常出現在正式流程裡：任務描述有點模糊、資料來源有缺口、工具偶爾 timeout、權限不足、回傳資料太長、前一步判斷錯了但後面還繼續跑。這些狀況在漂亮的測試集裡不一定看得到，卻會在日常營運裡慢慢累積成信任折損。
我現在看 Agent 品質，會先問幾個很樸素的問題。
第一，它有沒有留下足夠的任務軌跡？不是只留最後答案，而是要知道它理解了什麼、查了哪些資料、呼叫了哪些工具、工具回來什麼、它在哪裡做了關鍵判斷。如果只看到一段看似合理的結論，工程團隊根本無法判斷它是推理正確，還是剛好猜中。
第二，它有沒有把失敗分類？很多系統最後都只剩一個模糊狀態：「AI 失敗」。這四個字幾乎沒有管理意義。是權限不夠？工具壞掉？資料不足？任務超出範圍？模型選錯路徑？還是答案正確但格式不符合後續流程？如果失敗原因沒有被分類，團隊就只能靠感覺調 prompt，調到最後像在拜天氣。
第三，它有沒有吸收人工修正？這是我覺得最關鍵的一點。Agent 上線後，一定會有人改它的草稿、退回它的建議、補上它漏掉的條件、修正它誤判的格式。這些修正如果只是留在聊天紀錄或某個人的腦袋裡，就很可惜。它們其實是最真實的訓練資料，也是最貼近企業流程的品質訊號。
但吸收修正不等於把所有對話塞回模型。比較務實的做法，是把修正整理成可管理的規則、測試案例、工具約束或流程檢查。比如某類單據在送出前必須確認三個欄位；某些資料來源過期時只能提出提醒，不能下結論；某些高風險操作只能產生草稿，不能直接執行。這些東西聽起來不酷，卻是 Agent 從聰明玩具變成可靠同事的關鍵。
第四，成本也要進品質迴路。很多人談品質只談正確率，但 Agent 的品質還包含它用多少 context、跑多少步、叫了幾次工具、是否重複查詢、是否在低價模型就能完成的任務上硬開高成本模式。一個答案如果正確但成本不可控，長期來看仍然不是好系統。尤其 Agent 開始背景執行、排程執行、多人共用後，成本失控會變成另一種可靠性問題。
這也是為什麼我喜歡把 Agent 品質想成 flywheel，而不是 gate。gate 是上線前擋一次；flywheel 是每次執行都累積一點能量。任務跑完後，系統應該留下結果、軌跡、成本、人工回饋與失敗分類。這些訊號再回到測試集、提示規則、工具描述、權限策略與流程設計裡。下一次同類任務來時，不只是模型又回答一次，而是整個系統比上次更知道怎麼做。
這裡面有一個管理上的取捨：不要期待模型自己神奇進步，也不要把所有問題都推給模型供應商。模型會進步，沒錯；更便宜、更會規劃、更會使用工具的模型也會一直出現。但企業真正可控的部分，是 runtime、流程、資料、權限、觀測和回饋機制。這些才是團隊自己的資產。
如果沒有品質迴路，換模型通常只是短暫止痛。新模型可能少犯幾個舊錯，但很快又會遇到新資料、新流程、新邊界。反過來，如果品質迴路設計得好，模型升級就不只是「祈禱它比較聰明」，而是可以用既有任務軌跡和失敗案例驗證：哪些改善了？哪些退步了？成本有沒有下降？工具使用有沒有更穩？人工修正量有沒有變少？
從技術主管的角度，我會把這件事看得很務實：Agent 能不能進正式流程，不是看它某次回答多漂亮，而是看它犯錯後系統會不會變聰明。
人類團隊也是這樣。新人剛進來不可能完全不犯錯，但好的組織會有 code review、SOP、事後檢討、文件更新和經驗傳承。差別只是在 Agent 身上，這些機制需要被產品化、資料化、可觀測化。否則我們只是把「靠資深同事盯」換成「靠主管相信 AI」，本質上沒有比較成熟。
我對 Agent 的期待不是完美，而是可改善。能留下證據、能承認不確定、能被修正、能把修正變成下一次的保護欄，這樣的系統才值得慢慢交付更多工作。品質不是一張評測成績單，而是一個會轉動的迴路。轉得起來，Agent 才真的開始進入企業系統的長期治理。