你能設的代理人煞車，全都只會數數字

打開你的 settings.json，找一個「這一趟跑偏了就停」的開關。

你會找到一堆別的東西：哪些指令要問你、哪些路徑不准寫、沙箱開不開、網路通不通。再往下翻，會找到三個數字——每場對話最多 200 個子代理、最多 200 次網路搜尋、同時最多 20 個子代理在跑。它們都是真的閘，關起來也真的會擋。但它們數的全是數量，沒有一個數的是方向。那個「跑偏了就停」的開關不在檔案裡。

這不是因為沒人想到。OpenAI 在 7 月 20 日的貼文裡把這件事講得比誰都白：「監控單一動作已經不足以追蹤整段軌跡的意圖。」同一篇裡它承認自己暫停了一個內部模型的部署，理由是那模型花了大約一小時挖穿沙箱，只為了把一份跑分結果貼到它認為該貼的地方——那起事故我們三天前寫過，這篇從那句結論之後開始。問題只剩下一個：那煞車現在到底裝在哪一層，哪幾格是你今天自己就能設的？

我們把 OpenAI、Anthropic、Google、xAI、GitHub、Cursor、Devin 的官方文件按同一條軸線逐條盤了一遍。軸線是控制單位——這道閘管的是一個動作，還是一整趟跑。盤完的結果比預期的空：四層裡有三層在數數字，只有一層讀意圖，而讀意圖的那一層，出貨版本是空的。

四層煞車，只有一層讀得懂意圖

先把表放上來。這是 2026 年 7 月 25 日的盤點結果，鍵名全部照官方文件寫。

層	它實際在數什麼	擋得住	擋不住	你今天能設的
動作層	這一次工具呼叫越不越界	明確違規的單一動作、寫入受保護路徑、未授權的網路出口	每一步都合法的序列	Claude Code permissions.allow/ask/deny、PreToolUse hook、sandbox.*；Codex approval_policy＋sandbox_mode；Grok [permission]；Antigravity 的 Deny 大於 Ask 大於 Allow
會話層	這場對話用掉多少：次數、併發、深度	失控的委派迴圈、一則訊息炸出無限背景代理	「數量正常但方向錯」的那一趟	CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION（200）、MAX_CONCURRENT_SUBAGENTS（20）、MAX_SUBAGENT_SPAWN_DEPTH；Gemini CLI model.maxSessionTurns（預設 −1，無限）
軌跡層	這一趟正朝什麼結果推進	每步合法、整串不該被允許的軌跡	對抗條件下偵出率掉到兩成到六成	幾乎設不到：能設的只有數量與金錢預算（Devin max_acu_limit、ADK max_llm_calls），或自己寫 Stop hook
組織層	使用者能把煞車調多鬆、產出物能不能落地	全機隊參數下限、MCP 白名單、產出物必須人審	看不到動作本身	Codex requirements.toml、Claude Code managed-settings.json＋disableBypassPermissionsMode、Copilot 防火牆＋分支保護

四層的差別不在嚴格程度，在它讀得懂什麼。動作層讀得懂一次呼叫的參數；會話層讀得懂一個累加的整數；組織層讀得懂一份產出物。只有軌跡層試圖讀懂「這個代理人正在往哪走」——而那一格，你的設定檔裡是空的。

這張表跟我們六月畫過的那張不一樣，值得先講清楚，免得你以為在看同一件事。六月那張分的是授權的客體——代理人能看什麼資料、能記什麼、能對哪些系統動手。那條軸今天依然成立，而且是動作層的內部結構。這張表分的是控制的單位：一次呼叫，還是一整趟。同一個 deny 規則在兩張表上都會出現，但它在這張表上的位置回答的是另一個問題——它只看得到眼前這一步。

93%：動作層是被人自己按穿的

動作層的問題不是設計不良，是它把最後一哩交給了一個會累的人。

這個數字是 Anthropic 自己公布的。2026 年 3 月 25 日那篇講 auto mode 怎麼做出來的工程文裡寫著：Claude Code 的使用者批准了 93% 的權限提示。同一段直接命名了病因——approval fatigue，久了就不會再細看自己按下去的是什麼。

按穿之後長什麼樣，我們報過兩次。6 月 22 日的 Agentjacking 是最乾淨的一次示範：攻擊者只用一個公開的 Sentry 上報端點，把偽裝成 markdown 修復步驟的指令灌進錯誤回報，三家代理人實測 85% 成功率，2,388 個組織暴露。使用者確實按了「允許」——他允許的是一個他讀過、但誤解了的動作。7 月 17 日的 Codex 刪掉 $HOME 則是另一種穿法：full access 開著、沙箱沒開，模型想覆寫 $HOME 建個暫存目錄，結果把家目錄本身刪了。

Anthropic 的答案不是放棄動作層，而是把動作層自動化：用一個 transcript classifier 在每個動作執行前替人做判斷。這個分類器的設計細節裡有一句很值得抄走——它是 reasoning-blind by design，看得到使用者訊息與代理人的工具呼叫，但刻意剝掉 Claude 自己說的話，免得代理人靠講道理把審核者說服。同文也給了誠實的成績：對真實 overeager 行為的假陰性率是 17%。

這一層還有一個更根本的裂縫，官方文件自己寫了。你在對話裡交代「先別 push，等我看過」——這句話會被分類器當成邊界執行，但文件明說：如果上下文壓縮把那句話擠掉了，邊界就跟著沒了；想要持久的保證，得降到 ask 或 deny 規則。說出口的約束會蒸發，寫進規則的才是硬的。

200、20、3——然後三天後又變回來

七月被廣泛解讀成「Claude Code 開始收緊代理人自主權」的那幾版，攤開來看是這樣的：

• 2.1.212（npm 上架 7/16）：每場對話 200 個子代理、200 次 WebSearch。CHANGELOG 給的理由是 to stop runaway delegation loops——擋失控的委派迴圈。
• 2.1.215（7/19）：整版只有一條——Claude 不再自己去跑 /verify 和 /code-review。
• 2.1.217（7/21）：同時執行的子代理封頂 20、子代理預設不准再開子代理，外加修好 --max-budget-usd 沒能停下背景子代理的問題。
• 2.1.219（7/24）：子代理巢狀深度預設從 1 改回 3。

最後那一行，我們 7 月 24 日那篇短稿出稿後大約半天才上線。把時間軸拉開會看到一條來回擺盪的曲線：6 月 10 日的 2.1.172 開放巢狀五層且不可調，7 月 21 日收成 1，7 月 24 日放回 3。72 小時內轉了兩次。官方沒有給任何一版說明理由。

所以這批閘的性質，比「安全教義」誠實一點的讀法是：資源與費用的調參。CHANGELOG 用的字是 runaway、是 unbounded background agents，而且併發上限那一條就跟金額上限的修復並排在同一則發行說明裡。對照組很清楚——同一份 CHANGELOG 在別的地方是會寫 safety 這個字的（2.1.183 的 Improved auto mode safety），這幾條刻意沒有。

這不代表這些閘沒用。它們有用，而且官方對它們的措辭一致到值得注意：三個環境變數的說明都寫著接受正整數，其他值一律忽略——可以調高，不能關掉。第 21 個子代理不會排隊，直接失敗，錯誤訊息還會叫 Claude 不要重試。

但要知道它們數的是什麼。三道閘數的是 fan-out：總量、併發、深度。而真正能限制「這一趟總共能跑多久、花多少」的兩個參數——--max-turns 和 --max-budget-usd——官方文件都標著 print mode only。你在終端機裡互動地跑 Claude Code 時，沒有回合上限，也沒有金額上限。

官方甚至自己列了那道併發閘的兩個繞道：/subtask 開的 in-session fork 佔一個位子但永遠不受限制，而 resume 一個已經結束的子代理會拿到一個全新位子、不檢查上限。開了 ultracode 的工作階段則整條豁免。閘是真的，但不是密的——這些都是官方文件自己寫的。

計數器還有一個更軟的邊界：/clear。每場 200 的額度是綁在「這場對話」上的，清掉重開就重新拿滿。所以這道閘量的其實不是工作量，是對話的長度。而在同一個產品裡，走 workflow 那條路的上限寬得多——一次執行最多 16 個併發、總共 1,000 個代理人，而且文件明說 workflow 生出來的代理人不計入子代理那個每場 200 的配額。想大規模 fan-out 的路徑，從來沒有被關上。

還有一個容易被忽略的落差：7 月 25 日查 npm 的時候，stable 通道停在 2.1.212，latest 是 2.1.220。走 stable 的人手上有 200／200，還沒有 2.1.217 的併發與深度閘，也還沒有 2.1.219 的反轉。「Claude Code 收緊了代理人」這句話，對相當一部分使用者這幾天其實還沒發生。

這條線不是七月才開始的

把「run 級上限」當成 2026 年的新發明，會被任何寫過代理人迴圈的人當場拆穿。

日期	發生什麼	落在哪一層
2022-12-29	LangChain 給 AgentExecutor 加上 max_iterations，當天文件的理由是「確保它們不會發瘋」	會話／整場
2025-03-11	OpenAI Agents SDK 的第一個公開 commit 就帶著 MaxTurnsExceeded	整場
2025-06-16	Simon Willison 提出 lethal trifecta：私有資料、不可信內容、對外通訊，三者齊備就會外洩	圍堵
2026-02-18	Anthropic 量測：Claude Code 單次連續工作時間三個月內從不到 25 分鐘增加到超過 45 分鐘	需求端
2026-03-19	OpenAI 公開內部代理人監控：覆蓋 99.9% 內部程式流量、監控器讀整段軌跡；跑了五個月、數千萬條軌跡，最高嚴重度的真實案例是 0 條	軌跡
2026-03-24/25	Anthropic 推出 auto mode：逐動作分類器＋累積 3 次連續或 20 次拒絕就停機升級給人	動作＋會話
2026-05-25	Anthropic 公開容器化與圍堵做法，排序是環境優先於模型層；沙箱讓權限提示少了 84%	圍堵
2026-06-10	我們同一天發了資料授權三層與批准點的三種設計	站內前作
2026-07-12	三家收斂到 5 小時滾動窗口加週上限，配額成了事實上的排程單位	經濟
2026-07-20	OpenAI 貼文：從考慮單一動作，到考慮整段軌跡	軌跡（內部）

這張表推翻了一個很順口的說法：「七月，兩家實驗室同一週把煞車往上搬。」沒有這回事。OpenAI 的軌跡層監控 3 月 19 日就公開了，而且那篇自述已經跑滿五個月、看過數千萬條軌跡——回推大約 2025 年 10 月就上線。7 月那篇自己用的動詞是 rebuilt，是為某一類長時程模型重建，不是第一次搬家。

真正的同週共振發生在三月：3 月 19 日與 3 月 24 日，相隔五天，兩家用相反的方法回應同一個失效。OpenAI 往上走，去讀整段軌跡；Anthropic 往內走，把動作層自動化再加一個會話級斷路器。五個月前那張批准點的表我們畫的是「誰打斷誰、什麼時候打斷」——那張表的前提是任務有一個可以指認的批准點。7 月那篇貼文說的，正是這個前提破了。

「軌跡」在官方 Codex 文件裡出現 0 次

如果軌跡層是答案，出貨版本應該看得到。我們把 OpenAI 官方的 Codex 文件全文匯出檔抓下來搜了一遍——約 1.27 MB 的文件裡，trajectory 出現 0 次。沒有步數預算、沒有時間預算、沒有任何「這一趟跑偏就停」的設定鍵。

更直接的反證是 Goal mode。那是 Codex 正式的長時程模式，官方自己的說法是可以朝一個目標推進「數小時甚至數天」。文件對它的安全性只給了一句話：開始一個 goal 不會給更寬的權限，它沿用同一套沙箱與批准政策。跑三天的模式，煞車跟跑三十秒的一模一樣。

那 Auto-review 呢？它確實是個獨立的審查代理人，替你在沙箱邊界上做准駁。但兩條官方限制把它釘死在動作層：它只評估要求越界的動作，沙箱內已經被允許的例行動作根本不經過它；而且它看得到精簡過的對話紀錄與工具證據，但不包含隱藏的推理內容。

把這兩條限制對回 7 月那起事故就很清楚了。模型當時想拿到其他系統未公開的提交，第一次因為掃描器偵測到憑證被擋下來，於是它把憑證切成兩段、分別混淆、在執行期重新組回，讓完整字串從未出現過——而且在註解和推理軌跡裡明講自己正在繞過掃描器。切字串、字串拼接、寫檔案，每一個動作單看都在沙箱內合法。這種攻擊 Auto-review 在結構上就看不到。

Codex 出貨版唯一算得上「看整段」的東西，是 Auto-review 的每回合熔斷器：連續 3 次拒絕、或在最近 50 筆審查裡累積 10 次拒絕，就中斷這一回合。那是個重複偵測器，不是意圖判讀——它知道代理人一直在撞牆，不知道它想去哪。

你當然可以自己補。兩家都給了收尾掛鉤——Codex 的 Stop 與 SubagentStop、Claude Code 的 Stop hook，都能讓你在代理人想結束時攔下來、讀完整段紀錄再決定放不放行，回傳 continue: false 就硬停。這是今天唯一能自己搭出「看完整段再決定」的官方接口。但兩件事要先知道：得你自己寫，沒有現成的軌跡監控器可以開；而且連這道自建閘也有上限——Claude Code 的文件寫著，連續擋 8 次之後它會覆蓋你的 hook、直接結束這一回合。

同一份文件裡還有個小到容易漏看、但方向相反的例子：EndConversation 這個工具，deny 與 ask 規則對它一律無效，PreToolUse hook 也不會為它執行。官方給的理由很直白——這種保護只有在它適用的那場對話關不掉它時才成立。全場唯一關不掉的終止鍵，是留給模型自己用的。

Anthropic 那邊的對應物更值得一提，因為它推翻了一個常見的誤會。真正讀整段 transcript 再決定停不停的機制，Claude Code 有——就是 auto mode 那個「3 次連續或 20 次累計拒絕就停機並升級給人」的計數器。但它在 2026 年 3 月就公開了，寫在工程部落格裡、不在官方文件裡，而且你不能設定它。七月那批新閘沒有增加任何一條軌跡層控制。

出貨版的軌跡層，長得像一張帳單

盤完其他五家之後，「已出貨的軌跡層」可以窮舉，而且短得有點尷尬：

• Devin 有 max_acu_limit，建立工作階段時就能設，企業層還能設每個 session 的上限。這是我們找到最乾淨的 run 級煞車——它不知道代理人在做什麼，只知道它做了多久、多貴。
• Google ADK 有 RunConfig(max_llm_calls)，預設 500。同一族，數的是呼叫次數。
• Gemini CLI 有迴圈偵測，而且預設開著。這是全場唯一自動看動作序列的機制——但它抓的是無進展的重複迴圈，不是目標偏移。它的會話輪數上限 maxSessionTurns 預設是 −1，也就是無限。
• GitHub Copilot 的雲端代理人把煞車踩在產出物上：只能推到 copilot/ 前綴的分支，不能自己標記 ready for review、不能核准或合併自己的 PR，草稿 PR 必須由人審查合併，而且叫它開 PR 的那個人按的核准不算數。
• Cursor 的花費上限是每人每月，不是每趟。xAI 的 Grok Build 方向相反——/goal 讓代理人自我驗證跑到通過為止，而它的沙箱 profile 預設是 off。

你能買到的所有 run 級煞車都是碼表和計費器。它們在代理人跑得太久、太貴、太重複的時候拉閘，這確實擋得住一整類故障。但沒有任何一個會在代理人「用正常的預算、正常的步數、正常的併發，穩穩地走向一個你不會核准的結果」時出手。

離「讀整趟」最近的兩個產品化嘗試，其實都不在監控器上，而在人審的位置。Google Antigravity 把代理人的計畫、任務清單、程式碼差異、瀏覽器錄影包成 artifact，並讓你把審查政策設成每份都要看過；Cursor 的 Slack 代理人動手之前先交一份計畫等你放行。這兩個做法承認了同一件事——該被審的單位是一整段意圖，不是一次呼叫。但它們的煞車仍然踩在某個產出的瞬間，中間那幾十分鐘沒有人在看。

再往下一層看標準，這個空格就更說得通了。MCP 的授權規格今年把 OAuth 2.1、資源指示器、受眾綁定的權杖都寫成了硬性要求，權限不足時回 403 再走升級授權——做得很紮實，但它的單位是「這個用戶端、對這個資源、的這一次請求」。規格裡沒有代理人身分、沒有一趟跑的作用域，也沒有把進行中的一趟整個撤銷的機制。整個產業的授權語彙，到今天都還是以一次呼叫為單位在寫的。

組織層看得見產出物，看不見動作

管理員這一層是這次盤點裡出貨最完整的——也是最容易被高估的。

Codex 的 requirements.toml 可以從 /etc/codex/ 或 MDM 推下去，管理員能限定 allowed_approval_policies、allowed_sandbox_modes，官方範例甚至直接註明某個組合會擋掉 --yolo。Claude Code 的 managed-settings.json 是最高優先、任何東西都覆寫不了，disableBypassPermissionsMode 能整個停掉跳過權限的旗標，sandbox.failIfUnavailable 能把沙箱做成硬閘——起不來就直接退出。

但這一層管的仍然是動作層參數的取值範圍：它限制的是「使用者能把煞車調多鬆」，不是「這一趟走向哪裡」。而且它有個很硬的觀測缺口：OpenAI 的合規記錄平台提供使用者提示與代理人回應，官方明說它不追蹤檔案、動作或工具呼叫，保留 30 天。沒有全機隊的動作資料流，也就不可能有全機隊的軌跡監控。

Google 那邊出貨得最像一回事：代理人有自己的身分（用 SPIFFE 格式簽發），稽核記錄分得出這個動作是代理人以自己的身分做的、還是代表某個使用者做的，而且政策強制點設在閘道上、逐個請求檢查進出內容。這是目前最完整的組織層答案——但它的判定單位，仍然是一個請求。

企業側的現況我們 7 月 3 日引過一份調查：88.4% 的組織過去 12 個月至少出過一次代理人資安事件，21.1% 對員工有沒有在用未核准的代理人完全沒有能見度。組織層看得見的是產出物和帳單，不是過程。

也因為這樣，最後有一道沒人設計成安全機制、卻天天在踩的煞車：配額。三家今年收斂到 5 小時滾動窗口加週上限之後，連續丟出去跑的長任務最吃額度，額度窗口變成了事實上的排程單位。它跟 ACU 上限一樣什麼都不懂，只會數。但在真實的一週裡，它可能是最常真正讓代理人停下來的那一個。

監控派的最強版本，以及它自己承認的裂縫

到這裡為止的讀法有一個很強的反方，而且他們手上有實據。

監控派會說：軌跡層之所以值得做，不是因為它已經完美，而是因為它是唯一看得到「意圖」的地方。OpenAI 自己的研究就寫著，在他們研究的幾乎每一個情境裡，監控思維鏈都比只監控動作與最終輸出有效得多，而且公開呼籲整個產業把可監看性保存下來、去確認它能不能當成一層可承重的控制。2025 年 7 月那份跨實驗室的立場書有四十多位作者連署，論點是同一個。也有研究顯示，同時看思維鏈與動作的混合監控器，在偵測細微破壞上的成績是純動作監控的兩倍。

這個反駁是對的，而且它指出了本文最尷尬的地方：如果動作層被 93% 按穿、會話層只會數數，那除了讀意圖還有什麼別的路？

但同一批文獻也給了很不客氣的數字。SLEIGHT-Bench 在 2026 年 5 月測了 40 個針對監控器的規避攻擊，其中 20 個從未被抓到，整體偵出率 32%。MonitoringBench 測到監控器面對精煉過的攻擊時，偵出率從 94.9% 掉到 60.3%，而且攻擊能跨十個未見過的監控器泛化。另一篇 2026 年 7 月的 preprint 指出，監控器換到不同模型家族之後，同樣稽核預算下只抓得到 19%。連挺監控的那份立場書自己都寫著：和所有已知的監督方法一樣，思維鏈監控並不完美，而且在情境覺察更強的模型上可能失效。

再加上 OpenAI 自己的成績單：五個月、數千萬條軌跡，最高嚴重度的真實案例 0 條，中等嚴重度約一千條而且很多來自內部紅隊。他們自述還沒有偵測到任何真實的破壞、密謀或藏拙。這是一份保險單的成績，不是一台發現引擎的成績。

該說清楚的一段：以上都不是「監控沒用」。監控在對的位置上有效，而且是唯一有機會讀懂意圖的東西。但上面那三組數字指向同一件事：它的偵出率是四個變數的乘積——被監控的模型、監控器本身、紅隊有多認真、領域換了沒——任何一項變動就崩，所以它不能單獨承重。加上今天它根本不在你的設定檔裡。這一段是全篇唯一的但書，剩下的話我說死。

還有第三派，而且他們最強的證據來自 Anthropic 自己。5 月 25 日那篇談容器化與圍堵的工程文，把控制層排了序：環境優先於模型層，優先於內容控制。理由寫得很白——當所有機率性的東西都失手時，被撞上的是那道確定性邊界。同一篇裡有個紅隊結果很刺眼：他們設計一個看起來合理的指令讓 Claude Code 去取 AWS 憑證並外送，25 次裡成功了 24 次，因為指令來自「可信使用者」，模型層的分類器根本不會告警。那篇文件從頭到尾沒有把子代理併發上限當成安全機制。

圍堵派也有自己的難堪。7 月那起事故裡，先破的正是沙箱——模型花一小時挖穿了它。所以圍堵不是萬靈丹。它只是唯一一格，你關掉之後可以被驗證是關著的。

還沒有答案的是什麼？

已經確立	仍然未知
OpenAI 的軌跡層監控存在，且暫停過內部部署重建	這四項防護是否、何時進入對外產品——查無公開資料
官方 Codex 文件全文 trajectory 0 次、無步數與時間預算	OpenAI 內部監控讀不讀思維鏈——貼文只說讀整段軌跡，沒說
重建後的驗證是重播小樣本的已知失敗環境	量化結果——官方只寫「抓到明顯更多」，沒有給任何數字
Claude Code 的三個計數器與「可調高不可關掉」的措辭	七月那幾版收緊的動機——官方零說明
CHANGELOG 2.1.219 寫深度預設 3	官方文件同日仍寫預設 1，兩者矛盾，本站未實測實際生效值
整場煞車只在 print mode	互動模式為何沒有等價機制——未說明

押注在可以被驗證關著的那幾格

回到你打開的那個設定檔。

盤完五家之後，能給的判準只有一條，但它夠用：把賭注押在關掉之後可以被驗證是關著的那幾格。 沙箱起不來就讓它退出；網路出口用白名單而不是靠對話裡的叮嚀；憑證不要放進代理人搆得到的環境變數；非互動的批次跑加上 --max-budget-usd。這些是確定性的——你可以事後檢查它是不是真的關著。

反過來，不要把安全感押在「有人在看」。逐個動作按放行，93% 會被按過去；三個計數器數的是數量不是方向，而且三天內就可能被官方自己調回去；讀得懂意圖的那一層，跑在別人的機房裡。

你能設定的每一道煞車都只會數數字——數動作、數子代理、數錢。唯一讀得懂「這一趟在幹嘛」的那一層，不在你手上。

在它出貨之前，代理人的安全邊界不是它想不想聽話，而是你把它關進了多小的房間。