最近看到一個很有意思的企業 AI 方向：讓 Agent 閱讀過去的服務工單，找出反覆出現的處理方式，再產生可以送審的自動化流程。這條路比單純做工單摘要更接近真正的生產力，但也讓我想到一個常被忽略的問題——歷史上做過很多次的事，不一定就是公司希望永久執行的標準流程。
工單很像企業營運留下的腳印。它記錄誰遇到什麼問題、工程師查了哪些資訊、執行哪些操作，最後怎麼關單。累積久了，裡面確實藏著大量可以自動化的模式。某種帳號問題每週都有人手動處理，某類告警總是經過固定三步排除，某個資料異常每次都要查相同幾張表；如果 AI 能把這些重複工作整理出來，再轉成可執行流程，價值非常直接。
但腳印只證明有人這樣走過，不代表那是一條正式道路。
工單資料會放大例外，而不是描述全貌
工單天生偏向記錄「出事的部分」。正常完成的工作不一定留下詳細文字，異常、抱怨、繞路和人工救火反而會被完整寫下來。因此，直接從工單頻率學習，很容易把例外處理誤認成標準作業。
更麻煩的是，許多工單解法是當下環境的產物。工程師可能因為舊系統限制，先手動改一個欄位；可能在正式修補前，用重啟服務暫時恢復；也可能為了趕上營運時限，採用一次性的資料修正。這些做法在當時或許合理，卻不一定通過完整的權限、安全與資料一致性檢查。
如果 Agent 只看見「這個操作成功關閉了很多工單」，便把它包成自動化，等於把人類多年來吸收的技術債加速執行。原本一週發生一次的人工繞路，可能變成一天跑數百次的系統行為。自動化沒有消除問題，只是讓問題變得更快、更安靜。
從處理紀錄到執行流程，中間需要一次升級
我會把工單探勘產生的結果視為「流程候選」，而不是可直接部署的腳本。兩者之間至少要補上四類資訊。
第一是意圖。這個處理是在恢復服務、修正根因、暫時繞過，還是單純補齊資料？同一組操作在不同意圖下，允許的重試、時效與後續追蹤完全不同。
第二是前置條件與適用範圍。哪些系統版本、資料狀態、使用者角色與時間窗口可以執行？歷史工單常把這些條件留在工程師腦中，自動化卻必須把它們寫成機器能檢查的契約。
第三是完成定義。關單不等於問題真正解決。除了某個指令成功、某個欄位更新，還要確認服務恢復、資料前後一致、監控沒有再次告警，必要時也要觀察一段時間。否則 Agent 只會很有效率地把票關掉。
第四是失敗與退場方式。執行到一半失敗怎麼補償？遇到未知狀態要停在哪裡？誰可以中止？如何回復原值？如果流程無法回答這些問題，它還只是被整理過的操作紀錄，不是可以承擔營運責任的自動化。
審批不能只讓人看一段生成的程式
讓 AI 產生流程後交給人審，方向是對的；但審批畫面如果只展示一段腳本，實際上很難判斷風險。審查者需要看到的不是「程式看起來會跑」，而是這個候選從哪些工單歸納而來、成功與失敗各有多少、是否集中在特定版本、曾經有哪些人工修正，以及它會讀寫哪些系統與資料。
我會要求每個候選自動化至少附上一份小型證據包：來源樣本、模式覆蓋率、排除條件、預期副作用、所需權限、驗證步驟與回復方案。這些資訊不一定都由 AI 自己決定，但 AI 很適合先整理差異，讓人把注意力放在真正的風險與例外上。
部署也不該從「人工」直接跳到「全自動」。比較穩健的路徑是先做觀察模式，只判斷但不執行；接著由 Agent 產生操作草稿，由人確認；再限定低風險範圍半自動執行；最後才依據真實成功率、人工覆判率與例外分布，逐步擴大權限。每一階段都要保留停止條件，而不是把自動化比例當成唯一 KPI。
被自動化的流程仍然需要負責人
我最擔心的一種情況，是流程由歷史資料生成、由平台執行，最後卻沒有人真正擁有它。原本的處理方法可能來自某位資深工程師，工單由另一個團隊管理，Agent 平台又由資訊部門維運；一旦規則失效，大家只知道「AI 以前都是這樣做」。
所以每個正式自動化都應該有流程擁有者、技術維護者、版本、適用期限與定期檢查點。來源系統改版、風險政策調整、錯誤率升高或人工覆判增加時，流程應自動降級成待審模式，而不是繼續依賴過去的成功紀錄替自己背書。
從工單學習，是企業 AI 很實際的一條路。它把散落在工程師經驗裡的重複工作變得可見，也讓改善不必永遠等人有空整理文件。但它真正有價值的地方，不是把歷史操作原封不動地重播，而是協助我們找出值得標準化的候選，再把意圖、邊界、驗證、責任與退場補完整。
我會把這件事看成流程治理的前移：AI 負責從大量腳印裡找路，人負責決定哪一條路值得鋪成道路。兩者沒有分清楚，企業得到的可能不是自動化，而是一套會自己複製技術債的機器。