AI Agent 能讀什麼、能做什麼？權限與人工核准要先寫下來

先把「看得到」和「做得到」分開

很多討論會把權限說成能不能登入。對 Agent 來說，至少要再拆兩層。一層是讀取：哪些客戶、訂單、文件、對話可以進到它的上下文。另一層是動作：它可以搜尋、建立草稿、寫回欄位、送通知，還是只能把結果丟給人。讀得到不代表做得了；這兩件事用同一個開關，最後通常會往「什麼都讓它做」傾斜。

讀取範圍也不該等於整套資料庫。客服 Agent 若只處理售後，不一定要看到完整成本或未公開的報價策略。業務輔助若只整理需求，也不該一開始就能改成交狀態。範圍愈小，例外愈好找；等第一條流程穩定，再決定要不要開放下一層。

有一家內勤同時處理詢問和訂單變更的公司，原本希望 Agent「看得到所有資料比較聰明」。實際盤點後發現，真正需要的是訂單狀態、最近一次出貨與客戶聯絡方式。把成本、折扣權限和人事資料一起餵進去，既幫不上這條流程，也讓之後的稽核變複雜。最後是先縮範圍，才把第一版做成可驗收的試點。

• 讀取：資料表、欄位、文件集合與時間範圍
• 動作：搜尋、摘要、建檔、更新、通知、轉單
• 禁止：價格生效、付款標記、大量匯出、刪除與覆寫關鍵狀態

核准點要放在「對外面生效」之前，不是放在事後檢討

人工核准最常見的失敗方式，是做完才請人看紀錄。那時客戶可能已經收到訊息，或內部狀態已經改了。比較能用的做法是：對內整理、對內建草稿可以自動走；只要會被客戶看到、會改帳務、會改變履約狀態，就先停在待確認。

核准介面也要夠具體。只顯示「AI 建議回覆如下」不夠。負責的人應看到原始輸入、引用資料、準備送出的內容，以及系統認為不確定的地方。若還要寫入 CRM，就把將被更新的欄位列出來。人不是來欣賞文筆，而是來判斷這一步能不能代表公司。

誰能核准，也要對應現有職權。報價草稿可以是業務；超過折扣門檻應到主管；涉及退款或合約則不是客服 Agent 該決定的事。Agent 不創造新的權力結構，它只是把既有職權變成系統裡能執行的關卡。

身分要跟真人帳號分開，但責任仍要落在人身上

Agent 不該共用某位同事的個人帳號去打 API。共用帳號會讓操作紀錄變成「看起來是小陳做的」，權限也會隨著那個人的職務異動一起亂掉。比較清楚的做法是給 Agent 獨立身分，只授予這條流程需要的最小權限，並且能隨時停用。

獨立身分不代表責任消失。系統可以記錄是 Agent 提案、哪一位使用者核准。對外承諾的名義仍是公司與該名核准者。這點對客服和業務特別重要：客戶問「是誰答應我的」，答案不能是模型版本號。

AgentTech 實作時會把身分、角色、資料範圍和工具清單當成同一份設計，而不是模型接上以後再補防火牆。也會保留緊急停止：發現它開始寫入錯誤欄位或呼叫不該碰的工具時，先停這條流程，不影響其他系統功能。

權限會過期，文件與規則也會過期

第一版權限寫完，不代表可以放著一年不管。人員異動、新增商品線、開放新通路，都可能讓原本合理的範圍變太大。建議在試點結束、以及之後每次擴大功能時，重新看一次可讀資料和可執行動作。多出來的權限愈晚收，愈沒人敢動。

知識來源同樣會過期。價目表、服務條款、內部 SOP 若沒有負責人與有效日期，Agent 引用舊內容時，看起來仍會很有把握。權限設計因此也包含「它可以引用哪些已核准來源」，而不只是資料表白名單。

• 每個 Agent 對應一條流程，避免一個萬能機器人
• 擴大範圍時重審資料、工具與核准點
• 停用帳號、撤銷工具與下架過期文件要有人負責

第一階段可以很窄，但必須寫成驗收條件

權限文件不必一次寫成資訊安全論文。對中小企業來說，能讓雙方簽字確認的通常是一張表：這個 Agent 為了哪件工作存在、可讀什麼、可做什麼、哪些必須等人、日誌要留哪些欄位。表愈短愈好，短到主管看完知道自己在放行什麼。

驗收時不要只請人「問兩句試試看」。比較有用的是準備幾筆真實會發生的例子：資料齊全、資料缺漏、超出範圍、以及高風險請求。看它會不會停、會不會亂寫、會不會把不該顯示的欄位帶進回覆。這些例子之後也會變成回歸檢查，避免下次改提示詞時把關卡弄丟。

若你已經有客製系統，這份權限表應盡量和現有角色對齊，而不是為 Agent 另創一套沒人懂的權限語言。對齊之後，維運、稽核和人員訓練才不會變成兩套平行世界。