最近看企業導入 AI Agent 的案例，我越來越覺得：第一個 Agent MVP 不應該選「最有想像力」的題目，而應該選一個關得起來的問題。所謂關得起來，不是把功能做小而已，而是它的資料來源、適用範圍、例外路徑、責任邊界都能被畫出來。這聽起來不浪漫，但通常比較能真的上線。
很多企業談 Agent，第一個直覺會往大流程想：幫我處理訂單、幫我排生產、幫我自動核准、幫我跨系統完成交易。這些方向當然有價值，但如果一開始就把 Agent 放到核心交易流程裡，其實很容易把問題搞得太大。它不只要懂文件，還要懂權限、狀態、金額、例外、責任歸屬，以及各系統之間那些沒寫在文件裡的默契。
我比較偏好從另一種題目開始：高頻、規則明確、文件齊全、錯了可以升級給人，而且成效可以量化。
例如內部政策問答、作業規範查詢、常見申請流程說明、費用規則判斷、文件補件提醒。這些事情看起來沒有「自動完成交易」那麼酷，但很適合作為企業 Agent 的第一個落地點。原因很簡單：它們每天都在消耗人力，而且大多數答案本來就應該存在文件或 SOP 裡。Agent 的角色不是憑空創造決策，而是把分散的規則整理成可對話、可追溯、可更新的工作介面。
這類 MVP 的第一個好處，是邊界清楚。
一個旅費政策 Agent，只回答旅費規則、申請條件、文件需求與例外處理入口；它不需要一開始就直接幫使用者送出付款、不需要改會計資料、不需要繞過主管核准。它可以很明確地說：「這個情境符合一般規則」、「這個需要補某份文件」、「這個屬於例外，請轉給負責窗口」。這種數位圍欄很重要，因為企業系統最怕的不是 Agent 不夠聰明，而是它不知道自己什麼時候不該繼續。
第二個好處，是資料治理比較能起步。
政策文件通常會遇到版本、適用對象、例外條款、過期內容與權限問題。這些麻煩本來就存在，只是以前被藏在信箱、群組與老員工的腦袋裡。把它做成 Agent，反而逼團隊整理出幾件事：哪份文件才是 source of truth？不同部門看到的規則是否一樣？舊版文件如何退場？答案引用要不要附來源？使用者問到文件沒有寫的情境時，誰負責補規則？
這些問題不像模型參數那麼新潮，但它們才是企業 AI 能不能長期運作的地基。沒有這一層，Agent 再會聊天，也只是把舊知識庫換成比較有禮貌的搜尋框。
第三個好處，是成效容易量化。
一個好的 Agent MVP 不應該只用「大家覺得很方便」來驗收。政策問答這種題目，可以看得很具體：同一類信件或工單下降多少？平均回覆時間縮短多少？轉人工比例是多少？哪些問題 Agent 常常答不出來？哪些文件被引用最多？哪些例外最常發生？
這些指標會讓 Agent 從一次性專案變成改善迴路。不是上線後就結束，而是每週看錯誤分類、補文件、調整回答範圍、修正升級規則。久了之後，團隊得到的不只是一個問答機器人，而是一張流程知識的熱點地圖：哪裡最常讓人困惑，哪裡最常產生例外，哪份 SOP 寫得最不清楚。
我常覺得企業導入 AI 的難題，不是缺少大型願景，而是太容易跳過「可控的小成功」。大家想看端到端自動化，想看 Agent 幫忙把跨系統流程跑完，想看 AI 像數位員工一樣自己處理所有事情。可是從技術主管角度，我會先問幾個比較掃興的問題：它錯了會傷到什麼？誰能停下它？它引用哪份資料？使用者怎麼知道答案不是亂講？哪些情境必須升級給人？
如果這些問題答不出來，我寧願先不要把 Agent 放進核心交易。
這不是保守，而是順序。企業 Agent 的成熟路線不一定要從「只讀」永遠停在「只讀」，但第一步最好先在可觀測、可回復、可審計的範圍裡建立信任。先讓它回答政策、整理文件、引導補件、分流例外；等到團隊真的掌握資料品質、權限邊界、錯誤處理與人工接手，再逐步讓它產生草稿、預填表單、提出建議，最後才是受控地提交或執行。
這條路比較慢，但比較像真的在建系統。
我喜歡把第一個 Agent MVP 想成一個小型實驗室：不是為了證明 AI 什麼都能做，而是為了證明組織有能力讓 AI 在邊界內做事。它測的不是模型 IQ，而是公司的流程 IQ：文件是否可信、權限是否清楚、例外是否有路、錯誤是否能被修正、成效是否能被量化。
等這些能力長出來，再談更深的自動化，才不會只是把一個聰明但沒受過管理的角色丟進企業流程裡亂跑。
所以，如果現在要選企業 Agent 的第一個題目，我不會問「哪個流程最大、最炫、最能展示 AI」。我會先問：「哪個問題每天都在消耗人，但我們可以把它安全地關在一個範圍裡？」
能被關起來，不代表價值小。很多時候，正因為關得起來，它才有機會真的跑起來。