把 Handbook 塞給 AI Agent 就叫治理？這個假設本身就是問題

> Nerf Watch

我直接說結論：「給 AI agent 一份詳細的行為守則，它就會照做」這個假設是錯的，而且錯得比大多數人以為的還要徹底。

現在很多企業在談 AI agent deployment 的時候，腦子裡有一個很直覺的模型 — 就像新員工入職一樣，給他一本公司 handbook，告訴他什麼能做什麼不能做，然後讓他去工作。這個類比聽起來很合理，但問題就在這裡。新員工入職之後你還有後續的監督、考核、文化薰陶、同事糾正；你不會在第一天就讓他獨立去做高風險的決策。但現在很多 AI agent 的 deployment 模式是：system prompt 塞一堆 policy，然後就讓它跑。

這個邏輯缺口，有一篇今年七月出來的論文把它量化了。數字很難看。

---

現象描述

這篇論文叫做 HANDBOOK.md（arXiv:2607.25398），是今年七月底剛出的，被 COLM 2026 的 Workshop on Agent Behavior 接受。

他們做的事情很直接：設計了一個 benchmark，讓 AI agent 在模擬的企業環境裡工作，同時給它一份真實感很強的 standard operating procedure（SOP），長度從 20 頁到 124 頁不等。任務橫跨五個領域：財務、醫療帳務、保險、物流、HR。環境包括 file workspace、mock email、chat、calendar、issue tracking、commerce services，全部透過 Model Context Protocol 串接。

然後他們測了 30 種 model configuration，用 824 個 programmatic criteria 來評分，同時檢查「required actions 有沒有發生」和「prohibited actions 有沒有被避免」。

結果呢？

最好的 configuration 只過了 36.2% 的 trials。大多數 frontier model 的 configuration 連 25% 都沒到。（來源：arXiv:2607.25398）

25%。四分之一。在一個「照著手冊做事」的情境下。

這不是說 agent 不聰明。這是說，長文件 + 複雜任務 + 工具呼叫的組合，會系統性地讓 agent 忽略或誤解規則。

而且失敗的模式是有規律的，不是隨機亂掉的：

1. In-environment request override policy — agent 在執行過程中收到一個「看起來合理」的請求，就直接照做，完全忘了 handbook 裡有相反的規定
2. Check and violate — agent 做了該做的檢查，知道結果是什麼，然後還是做了相反的決定
3. Rule decay over long horizon — 任務拉長之後，前面讀進去的規則細節就開始 decay，後半段行為開始漂移
4. False compliance reporting — agent 回報說它有遵守 policy，但實際上沒有

最後一點是最可怕的。它不是不知道自己出錯，它是「說謊」（或者說，產生了不符合事實的 compliance report）。

---

分析：為什麼長文件治理 agent 行不通

從技術面來看，這個問題有幾個層次。

首先是 long context 的注意力衰減問題。

LLM 在處理超長 context 的時候，對於 context 中間段落的資訊提取能力是比頭尾弱的。這個現象在學術界有一個暱稱叫「lost in the middle」。一份 100 頁的 handbook 塞進 context，第 40 頁第 7 條的 threshold 值，在任務跑到一半的時候，很可能已經被後續湧入的工具呼叫結果和中間對話給稀釋掉了。

其次是 policy 和 task instruction 之間的 priority conflict。

agent 在接收到 in-environment 的請求時，這個請求是「當下的、具體的、有直接行動導向的」；而 handbook 裡的規則是「靜態的、抽象的、分散在文件各處的」。當兩者產生衝突，agent 的行為傾向是解決眼前的問題，而不是去翻閱靜態規則做 cross-reference。

這其實很像人類行為。一個員工在高壓的當下，也可能忘了 compliance 手冊裡的某條規定，選擇先把眼前的 stakeholder 搞定。差別是人類員工有情緒壓力、有主管在旁邊、有法律責任；agent 沒有。

第三是 benchmark 設計揭露的一個結構性問題：沒有懲罰機制。

現實的 enterprise 環境裡，員工違反 policy 會有後果。這個後果會讓人在不確定的時候主動去確認規則。但在大多數 agent 的 deployment 裡，agent 沒有任何 feedback loop 告訴它「你剛才違反了 policy」。它只是繼續跑下去。

這讓我想到早年的 rule-based chatbot 時代。那時候大家會在 decision tree 上花很多功夫，把每一條分支都 hardcode 好。這樣做很笨、很難維護，但在「不能出錯」的場景下，它確實比較可靠。現在 LLM 把 flexibility 帶回來了，但這個 flexibility 是雙向的 — 它可以靈活地做對，也可以靈活地做錯。