什麼是 AI Agent 治理(Agent Governance)?上線前該建立的五道防線

AI Agent 治理(Agent Governance),指的是一套讓自主代理在生產環境中「可授權、可觀測、可干預、可歸責」的制度與技術控制——它管的不是模型多聰明,而是當 Agent 開始自己決定要呼叫哪個工具、動哪筆資料、回覆哪個客戶時,你有沒有辦法及時看見、及時喊停、事後說得清楚為什麼。

我先講一個現場。去年底我們接手一家製造業客戶的採購 Agent,它能自動比價、開請購單、回信給供應商。上線兩週,一切安好。第三週,它把一封「請報最新交期」的信,連同內部成本結構一起寄給了外部供應商——因為有人在知識庫裡放了一份含成本的比價表,而 Agent 判斷「這對回信有幫助」。沒有人做錯事。系統也沒當機。它只是照著它被允許的權限,做了一件沒人想到要禁止的事。

這就是為什麼 AI Agent 治理不是上線後的加分項,而是上線的前提。Chatbot 答錯,使用者重問一次就好；Agent 是會「行動」的,它動了資料、發了信、改了單,錯誤是有後果、會外溢的。下面是我們現在每個 agentic 專案上線前,一定要先架好的五道防線。

第一道:權限與範圍邊界

先回答一個問題——這個 Agent「不准」做什麼?我們的做法是預設拒絕:每一個工具、每一張資料表、每一個對外動作,都要被明確授權才開放,而不是先全開再來補洞。高風險動作(付款、發外部信件、刪改主檔)一律走人類覆核。範圍寫得越窄,後面四道防線要扛的就越少。

第二道:可觀測性與追蹤

如果一件事出錯了,你要能在五分鐘內回答「它當時想什麼、呼叫了什麼、拿到什麼、決定做什麼」。這代表每一次工具呼叫、每一段檢索、每一個中間推理,都要留下結構化的 trace,而不是只記最後那句回覆。沒有 trace 的 Agent,等於一個不寫工作日誌的員工——出事那天你只能猜。

第三道:上線前評測(Evals)

Demo 過了不代表能上線。我們會為每個 Agent 建一組固定的評測集:正常案例、邊界案例,還有一批專門設計來「引它犯錯」的對抗案例(例如上面那封含成本的信)。每次改 prompt、換模型、加工具,都要重跑這組 evals,守住一條可量化的通過線。沒有數字,你對「它變好了還是變壞了」的判斷,全是感覺。

第四道:即時護欄與熔斷

評測是上線前,護欄是執行中。輸入端擋 prompt injection 與越權指令,輸出端擋敏感資料外洩與不當內容;再加上限額——單位時間動作數、金額上限、連續失敗次數,一旦異常就自動熔斷、轉人工。Agent 可以自主,但要有一個它自己關不掉的煞車。

第五道:人類介入與歸責

最後一道是把責任種回組織裡:誰負責這個 Agent、誰能改它的權限、出事時誰有權喊停、決策紀錄保存多久。這些在金融與醫療客戶那邊往往還牽涉稽核與法遵。技術能攔住 90% 的問題,剩下 10% 靠的是「有一個人知道自己該負責」。

這五道防線的順序不是隨便排的:邊界收斂風險,觀測讓風險可見,評測擋住劣化,護欄處理即時異常,歸責兜住剩下的長尾。少一道,其他四道都會被迫超載。

我們在 Tenten 做 FDE 前線部署時,工程師進場的第一週通常不是急著把 Agent 做得更聰明,而是先把這五道防線的當前狀態盤一遍——因為對決策者來說,一個上線後沒人敢碰、也沒人扛得起的 Agent,再漂亮的 Demo 也只是庫存。能維運、有人在用,才算真的上線。