企業導入 AI 第五階:治理收緊

這是系列的第五篇。系列從第 0 篇的完整參考架構圖開始,第 1 篇講身份與 gateway,第 2 篇講資料與檢索,第 3 篇講沙箱裡的 agent 與唯讀連接器,第 4 篇講寫入與送出要有人核准。第五階是圖上編號⑤的整排:治理與可觀測性,四個方塊。策略與關卡,標註「以程式碼版本化,宣告 vs 實際」;稽核帳本,標註「誰 / 做了什麼 / 何時 / 依哪條策略」;停機與預算上限,標註「整個 run 立即停止」;成本與品質指標,標註「p95,不是平均值」。這裡很容易讀成治理到第五階才開始。紀錄與流量限制和預算從第一階的 gateway 就在跑,每通 call 第一天起就被記錄、被扣預算。第五階補的是比對、把決策掛到某一版規則上,以及把正在跑的東西停下來的能力。

公司沿用第 1 到第 4 篇的晴川,約 40 人,8 個工程師、2 個行銷。晴川是編的,只用來把這一階走一遍。第四階做完之後,所有人都從身份提供者登入,每通 call 帶著角色走 gateway,檢索按提問者分過範圍,agent 在沙箱裡跑,而會離開公司的寫入與送出都帶著一筆由系統寫下的核准紀錄,不是 agent 自己回報的。到這一階,晴川通常有好幾個 agent 或管線同時在跑。現在缺的是兩件事,不是一件。沒有東西把晴川寫下來的規則拿去跟這些紀錄對照,也沒有東西能把一個已經跑出界的 run 停下來。

策略與關卡:宣告對上實際

第一個方塊放的是規則,以程式碼版本化,以及評估這些規則的關卡。標註把宣告與實際兩個詞並列,是因為它們是兩件事,而這個方塊就是拿來對的地方。

這個方塊擋的是漂移,而漂移從規則內部看不出來。我自己這週就有一個。跑我網站的那個 repo 裡有寫給「要加文章的人」看的規則,其中一條說文章只有英文,並且叫你不要加中文版的檔案。程式從 9 月 1 日起就支援選用的中文版,等我在 9 月 21 日把規則改掉的時候,站上十五篇文章每一篇都有中文版,全部是在這條禁止它的規則底下加進去的。沒有人在無視這條規則,它描述的是一個已經不存在的系統,而光是讀它永遠讀不出這件事,漂移只有對著紀錄才看得見。

負責對照的那個東西自己也不例外。我有一支狀態檢查程式,替中文文章組網址時是把前綴跟 slug 接起來,實際路徑不是那個形狀,結果它把十篇活著的文章全報成死的。一個壞掉的關卡,回報時的自信程度跟一個正確的關卡完全一樣,所以關卡的輸出同時是關於系統的證據,也是關於這個關卡本身的證據。

挑或做這個關卡的時候有一個性質值得要求。我自己留著的那套 policy 引擎,評估結果有明確的 unknown 與 conflict 兩種狀態,不會把它們折進允許或拒絕。「沒有任何規則涵蓋這件事」和「兩條規則互相牴觸」跟「拒絕」是不同的事實,說不出這兩種狀態的引擎會替你挑一個,挑的方向不是你決定的,事後也看不出來。

做到了是這樣:策略是一個進版控的檔案,要改走跟程式一樣的 review,關卡做的每一個決策都指得出它依的是哪一版策略,而宣告與紀錄的比對是排程在跑的,不是有人起疑才跑。

稽核帳本:依哪一版策略放行

第四階留下四格:哪個 agent 或哪個人動的手、對什麼、何時、誰點頭。這個方塊補第五格,依哪條規則放行、那條規則是哪一版。

沒有版本,你只能確認這個動作被核准過,確認不了它依的是哪條規則。如果規則上個月改過,一筆當時合規的紀錄跟一筆違反現行規則的紀錄長得一樣,而那一列也告訴不了你,你剛剛回答的到底是「當時允不允許」還是「現在允不允許」。

帳本必須是 append-only、由執行動作的那個系統寫、而且在 agent 搆不到的地方,這跟第三階對讀取紀錄、第四階對核准紀錄的要求是同一條。我自己差在一個很具體的地方。我的發佈紀錄有時間、品牌、文章代號、語言、標題、平台、狀態、備註、網址,沒有任何策略欄位,而核准人到現在還躺在自由文字裡。我可以回答某篇有沒有發出去。要回答它是依哪條規則放行的,得讀句子,還要記得那一週的規則是什麼。

還有第二種差法,長得跟前面那種相反。一個欄位可以被宣告出來,卻沒有任何程式讀它。我自己文章檔裡的 syndication 區塊記的是每一篇轉載到哪裡,沒有任何程式讀它。當成記帳是沒問題的。問題在於,一個被記下來的欄位跟一個被執行的欄位從外面看一模一樣,都是檔案裡的結構化資料,所以一份用數欄位來評估的審查會給它們同樣的分數。沒有人讀的欄位是備註,不是控制。

做到了是這樣:append-only、由執行動作的系統寫、一個動作一列並帶著當下生效的策略版本,而「這個動作是依哪條規則放行的」是一次查詢,不是一次重建。

停機與預算上限:停的是 run,不是下一通呼叫

第三個方塊,是大家因為已經有 rate limit 就以為自己已經有的那一個。rate limit 擋的是下一通呼叫。這個方塊停的是已經在跑的那個 run。

差別要等到一個 run 會做很多事才看得出來。第 41 通被擋下來的時候,第 1 到第 40 通都已經發生了,而過了第四階,其中有些已經寫進內部系統或者送出去了。整段期間 rate limit 都運作正常。

我自己的 runtime 裡,停止是 run 層級的:scope 違規次數、LLM 呼叫次數、tool 執行次數、token 總量各有上限,任一觸頂就停掉整個 run,它派出去的子 agent 跟著停,而那個 run 不能恢復,只能重開一個。上限預設全部關著,要開哪一個是明確的決定,不是預設值。

代價是可以量的,我量過。在一組用本地小模型、單一簡單任務、每組 20 次的 ablation 裡,一道強制關卡擋住 agent 在交付物不存在時說做完了,把這種「宣稱完成但東西不在」從 20 次裡的 18 次壓到 0 次。輸入 token 變成對照組的 1.66 倍,p95 wall-clock 從 87 秒變成 169 秒。每個被擋下來的 run 都要重試,重試的成本堆在尾端,不在平均。這些數字證明機制有效,也證明停止不是免費的。它們預測不了前沿模型接上你的 repo 會怎麼樣,我不會把它們帶進任何人的正式環境估算。

對「停止」還有一個要求,這條是我踩過才知道的。我的 CI 因為額度上限被觸頂而停跑的時候,那些 job 並沒有回報自己是被停掉的。它們回來的樣子是失敗的 job,幾秒內結束,沒有 log,而一個因為預算被切掉的紅燈,跟一個因為程式壞掉的紅燈長得完全一樣。一個把工作停掉卻不講的上限,產生的不是沒有訊號,而是一個假訊號,下游全部照著假訊號讀。我從那之後的作法是一律寫「CI 未跑,證據是這支本地測試」,不把紅燈當成結果。

做到了是這樣:正在跑的 agent 可以被 agent 以外的東西停掉,停止被記成停止而不是冒出來一個失敗,而且在第一個上限被打開之前,有人答得出恢復是什麼意思。

成本與品質指標:p95,不是平均值

這排的最後一個方塊。標註本身就是整個論點,而這個論點值得講,是因為往上報的數字通常是平均值。

同一組 ablation 裡:某一格的平均值只動了 16%,中位數卻從 18,612 變成 37,068 個 token。分布的中間翻了一倍,平均值幾乎沒反應。另一格裡有卡在讀取迴圈的異常 run,大約 197k token。跨 run 的平均值,翻倍跟迴圈兩件事都看不到。

我會擺在成本旁邊的那個指標不是成本指標。是「宣稱完成但拿不出東西」的 run 次數,而且它必須在 agent 之外數,因為 agent 正是被量的那個對象。這在第三階是一條原則,那時問的是要不要信 agent 的自述。到這裡它是一個欄位,而我唯一一次在沒有關卡擋著的情況下數它,數出來是 20 次裡的 18 次。

我自己在這個方塊的缺口是最單純的那種。我的發佈紀錄每次發佈記一個狀態,沒有時長也沒有成本,所以根本沒有分布可以取 p95。我數得出發佈次數,量不出發佈這件事。

做到了是這樣:中位數與 p95 並排報,「宣稱完成但沒有交付物」的次數在 agent 之外量,而成本掛在第四階那個一工作流一個的帳號上,不是全部併成一個叫「AI」的數字。

會重複跑的那個檢查

這裡沒有第六階,也沒有出場檢查,因為治理不是一個走完就離開的階段。取代出場檢查的是一個排程在跑的比對。

從策略檔裡挑一條規則。把帳本裡這條規則涵蓋的動作全部撈出來,一筆一筆對照當時生效的那一版策略。對不上就是發現。反覆對都對得上也是一種發現,通常代表這條規則涵蓋的事沒有人真的在做。

第二半跟第四階的拒絕測試同一個形狀,只是往上移了一層。發動一個註定會超過上限的 run,確認有東西在它還在跑的時候把它停下來,而且帳本上記著一筆停止。如果那個 run 跑完了,這個上限就只是文件,而所有建立在它上面的報告,描述的都是一個不存在的控制。

治理與可觀測性這一排在自架版的圖上畫法一樣,這一階跟怎麼託管也沒什麼關係:規則、帳本、上限、指標,不管權重在誰手上都是同一套。我自己這件事用的控制平面是開源的,在 aine-control-plane。它評估 policy,把決策寫進 append-only 的帳本。它不對外部系統執行任何強制,那一段留在第 4 篇放的位置,也就是工具層。第 6 篇收尾,從另一邊讀同一張圖,寫成主管在這一切拿到預算之前會問的八個問題。