最近看企業系統裡的 AI Agent 發展，我越來越有一個感覺：Agent 如果只停在聊天視窗裡，它最多是比較聰明的助理；但它如果真的要進入企業流程，就必須靠近正式資料源，理解流程狀態，並且接受原本系統裡那些一點也不浪漫的治理規則。
很多 demo 會讓人誤以為「能回答」就等於「能工作」。但企業裡的工作不是一句漂亮回覆，而是一連串可被追責的狀態轉換。這也是我覺得接下來幾年最值得注意的地方：AI Agent 的競爭，不會只在模型能力，而會在它能不能變成受治理的工作流執行層。
我以前在看 Agent 產品時，常常會先看它接了哪些工具。能查資料、能叫 API、能寫文件、能送通知，表面上功能很完整。但越看越覺得，工具清單其實只是第一層問題。真正麻煩的是：它用什麼身份呼叫？它能看到哪些資料？它能不能分辨草稿、申請、核准、已過帳這些狀態？它做錯時，系統能不能知道錯在哪一步？
在一般聊天助理裡，回答錯了頂多重問一次。在企業系統裡，錯誤常常不是一句話可以收回。錯的採購建議可能影響庫存，錯的客戶回覆可能影響承諾，錯的排程可能影響現場，錯的簽核可能影響內控。這些不是「模型下次會更好」就能安撫過去的事。
所以我越來越相信，企業 Agent 不應該被設計成外掛在系統旁邊的萬能聊天框，而應該被設計成站在 system of record 旁邊的流程參與者。它可以用自然語言理解需求，可以幫人整理資料，可以提出建議，也可以在允許的範圍內推動下一步；但它必須繼承原本系統的權限、商業規則、組織層級、狀態機和稽核紀錄。
這裡的「繼承」很重要。很多團隊一開始會想替 Agent 另外開一組超級帳號，讓它什麼都能查、什麼都能做，這樣 demo 最順。可是這剛好是正式上線最危險的設計。人不能做的事，Agent 也不該因為比較會講話就能做；人需要審批的事，Agent 也不該因為流程自動化就跳過審批；人做完需要留下紀錄的事，Agent 更應該留下更完整的紀錄。
我會把企業 Agent 的成熟度拆成幾個層次看。
第一層是讀得懂資料。它不是只會查出一張表，而是知道欄位代表什麼、資料新舊如何、哪些值是暫存、哪些值是正式結果。很多企業資料看起來都像表格，但其實每個欄位背後都有流程語意。Agent 如果不懂這些語意，只是把資料摘要得很漂亮，風險仍然很高。
第二層是懂得流程狀態。企業系統最重要的不是資料本身，而是資料目前走到哪一步。未送出、已送出、待審核、退回、核准、作廢、結案，這些狀態會決定可以做什麼、不能做什麼、誰可以做、做了之後要通知誰。Agent 要能工作，就不能只看資料內容，還要看流程位置。
第三層是動作分級。不是每件事都應該讓 Agent 直接執行。查詢、整理、草擬、建議、送出、核准、執行、回滾，每一級風險都不同。比較健康的做法，是讓 Agent 先從低風險動作開始，逐步把可驗證、可審批、可追溯的流程交給它，而不是一開始就把「幫我處理掉」當成產品目標。
第四層是稽核與回復。Agent 做過什麼、根據什麼資料、用了哪些工具、誰授權、哪一步需要人工確認、最後結果是什麼，這些都應該被記錄下來。沒有紀錄的自動化，其實只是把風險藏起來。更進一步，系統還要能處理失敗：如果工具 timeout、資料不足、權限不夠、流程被退回，Agent 應該停在可理解的狀態，而不是硬湊一個看起來合理的答案。
從技術主管的角度，我覺得這會改變我們評估 Agent 平台的方式。以前會問：模型多強？工具多不多？能不能串 API？現在應該多問幾個不太炫但很關鍵的問題：它的身份如何映射到使用者？它能不能吃到原本的權限模型？它是否理解單據狀態？它的每次工具呼叫是否可稽核？它能不能在人不在線時安全暫停？它失敗時，是否會留下足夠資訊讓人接手？
這些問題聽起來都不像 AI 新聞標題，但它們才是企業導入時真正會卡住的地方。因為企業不是缺一個會聊天的介面，企業缺的是一個能在既有責任邊界內，幫人把事情推進一點點，而且推錯時可以被看見、被停止、被修正的執行層。
我不覺得聊天介面會消失。相反地，自然語言會變成很重要的入口，讓使用者更容易描述需求、查資料、整理例外、啟動流程。但入口不等於治理本身。真正的治理仍然要落在資料源、權限、流程、狀態和稽核上。Agent 可以讓入口變得更自然，但不能把底層規則變不見。
如果要用一句話總結，我會說：企業 Agent 的價值，不是讓 AI 繞過流程，而是讓 AI 更安全地參與流程。能做到這一點，它才不是漂在系統外面的聊天泡泡，而是企業系統裡可以被信任、被管理、也被追責的新工作層。