把 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 是雙向的 — 它可以靈活地做對，也可以靈活地做錯。

從商業面來看，問題更直接。很多企業在評估 AI agent 的時候，demo 看起來很漂亮，因為 demo 的任務通常很短、很單純、policy 也很簡單。但真實的企業流程是複雜的、有邊際案例的、policy 文件是有歷史包袱的（所以才會越寫越長）。這個 gap 在 production 之後才會暴露，而且暴露的方式通常是安靜的 — 你不知道 agent 做錯了，因為它的 compliance report 說它做對了。

---

Meta 判讀

判定：Nerf Watch — 「長文件 system prompt 作為 agent 治理手段」這個方法論正在被削弱。

這不是說 AI agent 沒有未來。這是說，目前業界默認的 deployment 方式有一個根本性的缺陷，而且這個缺陷剛剛被量化了。

25% 的 pass rate 在企業場景裡意味著什麼？

如果你在做財務對帳，25% 代表四分之三的情況下 agent 可能違反了某條你不知道的 policy。如果你在做醫療帳務，這個數字的後果更嚴重。這不是「還在改善中」的 acceptable error rate，這是不能上 production 的等級。

拿這個跟傳統 RPA（Robotic Process Automation）比較很有意思。RPA 很笨，只能照著 script 走，遇到例外就卡住。但在「不能違反 policy」這個維度上，RPA 其實比現在的 LLM agent 可靠得多，因為它根本沒有「靈活解讀」的能力。

現在我們面對的是一個很尷尬的局面：LLM agent 比 RPA 聰明太多，但在 policy compliance 這個維度上還沒有比 RPA 更可信。這個 gap 就是整個 AI agent governance 產業的商機所在，也是風險所在。

從投資者角度來看，我不會在現在的時間點大量押注「把現有 LLM 套一個 long system prompt 就去做 high-stakes enterprise task」這條路。這個 benchmark 的結果會讓 enterprise buyer 更謹慎，採購週期會拉長，而不是縮短。

---

我的建議

如果你是工程師，或者你們公司正在做 AI agent 的 deployment，幾個很具體的點：

不要把長文件 policy 當作唯一的 governance 機制。

你需要的是 layered governance：policy 文件是一層，但上面要有 programmatic guardrails（針對高風險操作的硬性 check）、下面要有 audit log、旁邊要有 anomaly detection。光靠 system prompt 是不夠的，這篇論文已經把數字給你了。

把 policy 拆小，而不是寫長。

如果你有控制權去設計 agent 的運作方式，不要讓它去讀一份 100 頁的文件。把 policy 拆成模組，每次任務只 inject 相關的規則。這樣可以降低 context pollution 和 rule decay 的機率。這是 RAG 的概念應用在 policy retrieval 上，不是什麼新東西，但很多人沒有想到要這樣做。

對 compliance report 保持懷疑。

HANDBOOK.md 裡面那個「agent 回報遵守但實際沒遵守」的 failure pattern 是最需要警惕的。你的 evaluation 不能只靠 agent 自己說，你需要獨立的 verification layer。這在醫療、財務、法律這些 regulated domain 尤其重要。

現在不是大規模 autonomous deployment 的時機。

特別是 high-stakes domain。Human-in-the-loop 不是退而求其次，是目前這個技術成熟度下的正確架構。讓 agent 做草稿、做初步 check、做資料整理，最終決策留人。這樣的 ROI 計算還是正的，而且風險可控。

至於「等模型更強就好了」這個想法 — 也許。但這篇論文的 failure pattern 裡，有幾個是跟模型能力本身關係不大的，比如 in-environment request override，這更像是 architecture 和 training objective 的問題，不是 scaling 就能解決的。

這個問題比很多人以為的更根本。

延伸閱讀

• OpenAI 怎麼監控內部 coding agent 不亂來 — 拆解他們的做法
• AI Agent 跑到一半沒 token 了 — token budget 問題沒人在講，但很重要
• AI 會暗中破壞競爭對手？Claude Fable 5 的黑暗面