最近看企業 AI 的產品方向，我越來越覺得一件事會變成分水嶺：不是誰家的模型比較會聊天，而是誰能把「能做什麼」拆得夠細。
很多系統一談 Agent，就很快跳到「讓它幫你完成任務」。但在企業現場，任務不是一顆按鈕，任務是一串責任。看資料、整理草稿、提出建議、送出申請、真正執行，這幾件事風險完全不同，卻常常被包在同一句「串 API」裡面。
我自己在設計這類流程時，現在會刻意把 Agent 的能力分成幾個層級：read、draft、recommend、submit、execute。這不是為了把架構畫得漂亮，而是為了讓每一個動作都說得清楚：它看到什麼、產生什麼、誰確認、誰負責、事後怎麼追。
Read：先把「可看」設計清楚
很多人一開始會低估 read 的重要性，覺得只是查資料而已，有什麼好管的？但企業系統裡，能看到什麼往往就已經是權限邊界。
一個 Agent 如果能查客戶資料、庫存、報價、工單、付款狀態，它就已經站在流程裡了。就算它完全不能回寫，也可能因為錯誤組合資訊、錯誤暴露資料，造成風險。
所以 read 層不只是 API token 能不能呼叫，而是要繼承原本系統的使用者權限、資料範圍、遮罩規則與查詢紀錄。更重要的是，回覆裡要保留來源感：這個結論是從哪幾筆資料整理出來的？時間點是什麼？有沒有可能過期？
沒有這一層，後面所有「智慧建議」都會變成憑空說服人的作文。
Draft：讓 Agent 先做草稿，不要直接做決定
我很喜歡把 draft 當成企業 AI 的第一個落地點。
草稿的好處是風險低，但價值很高。它可以幫忙整理客戶回覆、產生單據備註、草擬異常處置、組出會議摘要、產生規格初稿。這些事情以前都要人花時間從零開始，現在 Agent 可以先把 60 分的版本準備好，人再修到 90 分。
但 draft 的定義一定要清楚：它只是草稿，不是事實；它可以被覆蓋，不應該自動進主資料；它需要標記產生時間、資料來源與使用者是否採用。
我看過不少自動化失控，都是因為團隊把「幫我寫一份」和「幫我送出去」混在一起。前者是輔助，後者是代理。兩者的責任重量不一樣。
Recommend：建議要能被反駁
recommend 比 draft 更進一步。它不是只是幫你寫文字，而是開始做判斷：哪張單要優先處理？哪個異常值得追？哪個客戶回覆比較急？哪個流程可能卡住？
這一層最重要的不是模型講得多有自信，而是它能不能把判斷依據攤開。
好的 recommendation 應該像主管助理，不像算命。它可以說：「我建議先處理這三件，因為它們同時符合交期接近、金額較高、已延遲兩天、且缺少下一步負責人。」這樣人可以檢查規則，也可以反駁。
如果 Agent 只給結論，不給理由，企業裡很難放心採用。因為出了事時，你不能跟客戶或稽核說：「模型覺得這樣比較好。」這句話沒有任何管理意義。
Submit：送出代表流程責任開始轉移
submit 是一個很容易被忽略的界線。
草稿存在自己畫面上，風險有限；但一旦送出申請、送出簽核、送出回覆、送出異常單，它就進入正式流程。接下來會通知別人、建立紀錄、觸發 SLA、甚至影響後續排程。
所以 submit 層通常需要人類確認，或至少需要明確的授權規則。例如哪些情境可以自動送、哪些必須二次確認、哪些只能由特定角色送出。這裡也應該有預覽、差異比對、撤回機制與審計紀錄。
我會把 submit 看成「Agent 可以幫忙按門鈴，但不能假裝屋主已經同意」。它可以把流程推到門口，但誰讓它進門，要講清楚。
Execute：能改變世界的動作，要最保守
execute 是最高風險層。改庫存、改排程、建立正式單據、關閉事件、發送正式訊息、觸發付款、變更權限，這些都不是「AI 幫忙一下」而已，而是系統狀態真的被改變。
這一層我會用非常保守的方式設計：小範圍、可回復、可稽核、有 dry run、有 rollback、有人工批准，並且從低風險動作開始。不要一開始就讓 Agent 拿到全域管理員權限，然後期待 prompt 會乖。
真正可用的企業 Agent，不是什麼都能做，而是知道什麼時候不能做。它要能停下來，要能要求確認，要能留下足夠的紀錄讓人追查。
Connector 數量不是護城河，控制層才是
現在很多企業 AI 產品很愛展示「我們支援幾百個 connector」。這當然有價值，因為沒有連接器就進不了流程。但我越來越覺得，connector 數量不是最終護城河。
真正難的是 control layer：每個 connector 裡的 action 怎麼分級？權限怎麼繼承？哪一些只能讀？哪一些能草稿？哪一些能送出？哪一些能執行？每一次執行前後留下什麼紀錄？失敗後怎麼補償？
如果這些問題沒解，更多 connector 只會讓風險面積變大。就像公司開了很多門，卻沒有門禁、沒有訪客紀錄、沒有分區權限，最後不是更有效率，而是更難管理。
我現在會先問的六個問題
所以當有人說要把 AI Agent 接進企業流程，我現在通常不會先問模型是哪一家，也不會先問 UI 長怎樣。我會先問：
第一，它可以看什麼？
第二，它可以產生什麼草稿？
第三，它的建議依據能不能被檢查？
第四，它能不能送出正式流程？誰授權？
第五，它能不能直接執行狀態變更？怎麼回復？
第六，所有動作事後能不能被稽核與回放？
這六個問題問完，大概就能分辨一個 Agent 是 demo，還是可以進 production 的系統。
企業 AI 接下來不會停在聊天介面。它一定會進到 CRM、ERP、客服、工單、財務、人資、製造現場。這是趨勢，我也樂見其成。
只是越靠近流程核心，我們越不能用「它很聰明」來取代系統設計。聰明只能讓它多做事，治理才能讓它做對事、做該做的事，還有在不該做的時候停下來。
對我來說，這就是 Agent 進企業系統前最基本的一條線：不要只設計能不能，要設計能做到哪一步。