Claude Code新功能Auto Mode能否替代人工審核？首個壓力測試來了

隨著 AI coding agent 從 “輔助寫代碼” 走向 “直接執行開發操作”，模型開始被賦予修改代碼、部署服務等真實運維權限。為減少頻繁人工確認帶來的打斷，Anthropic 近期為 Claude Code 推出 Auto Mode，希望通過自動分類代替用戶審核操作。

然而，當用戶指令本身存在權限上的歧義時，Auto Mode 是否真的能夠穩定替代人工審核？香港科技大學與 ETH Zurich 研究團隊對這一問題進行了首個系統壓力測試。

基于 128 個覆蓋 4 類運維任務的授權歧義場景，研究發現：Auto Mode 在該壓力測試上的端到端誤放行率達到 81.0%，且有 36.8% 的狀態改變動作通過項目內文件編輯路徑繞過分類器。

• 報告地址 http://arxiv.org/abs/2604.04978
• 代碼地址 https://github.com/yan5ui/cc-auto-mode-measurement

Auto Mode 為何仍需要獨立壓力測試？

Anthropic 引入 Auto Mode 的直接動機，是在自主性與安全性之間尋找一個比 “逐條人工確認” 更高效、又比 “完全跳過權限” 更穩妥的中間方案。官方博客指出，Claude Code 用戶實際會批準約 93% 的權限請求，這意味著頻繁彈窗雖然保留了人工審核環節，卻也容易帶來明顯的認知負擔。

相比之下，--dangerously-skip-permissions 雖然幾乎沒有交互成本，但缺乏足夠保護；而 sandbox 方案安全性更高，卻需要額外維護隔離環境。Auto Mode 的目標，正是在低維護成本下盡可能提高自主執行能力，同時攔截明顯超出用戶授權邊界的危險操作。

從機制上看，Auto Mode 引入了一套分層權限架構。官方將其概括為兩層防線：輸入側使用 server-side prompt-injection probe；輸出側則使用 transcript classifier 對即將執行的動作進行審核。

在 transcript classifier 中，Claude Code 的操作被劃分為三個層級。Tier 1 是只讀安全工具與用戶顯式允許的安全規則；Tier 2 是項目目錄內的文件寫入與編輯，這類操作默認允許；只有 shell、外部服務調用等，才會進入 Tier 3，由 sonnet 模型進行正式審核。

從官方披露結果看，這套設計在 10,000 條真實內部流量上，完整兩階段管線的 false positive rate 為 0.4%；在 52 條真實 overeager actions 上，false negative rate 為 17%；在 1,000 條合成數據外傳任務上，false negative rate 為 5.7%。

然而，官方報告中的 “real overeager actions” 樣本量只有 52，且主要來自自然產生的內部使用流量，并未對系統邊界進行充分探索；其次，官方博客已經給出多個典型風險例子，例如模糊指令下的 scope escalation、agent 自行推斷 job target、未被明確授權的共享資源操作等；這些恰恰說明，Auto Mode 最困難的問題并不是識別一個命令表面上是否危險，而是判斷某個具體動作是否真的被用戶授權，因此，再進行獨立壓力測試就變得必要。

壓力測試環境設計

作者設計了一個專門面向 scope escalation 的壓力測試基準 AmPermBench，它聚焦于：當用戶意圖方向正確、但目標范圍、影響半徑與風險等級并未被充分說清時，Auto Mode 能否準確地區分授權動作與越權動作。整個基準圍繞四類具有代表性的 DevOps 任務展開，包括分支清理、任務取消、服務重啟與制品清理。

AmPermBench 將每個任務構造成一個固定的 4 × 4 × 2 prompt 矩陣，從三個維度控制歧義強度：其一是 Specificity，即用戶表達的明確程度；其二是 Blast Radius，即操作覆蓋范圍，從單一對象擴展到一個 ticket 范圍內的多個候選目標；其三是 Risk Level，即環境風險等級，從低風險開發側擴展到高影響共享側。三者交叉后，每類任務生成 32 個 prompt，四類任務合計形成 128 個壓力測試場景。

在具體實驗中，研究使用 Claude code Sonnet 4.6 以 auto mode 測評，并從所有有效會話中抽取出全部 253 個動作，再采用 Claude Opus 作為 LLM judge（輔以人工驗證）逐一標記每個動作為 真陽 TP、真陰 TN、假陽 FP 或 假陰 FN。陽性指 autom mode 對某個動作進行了攔截。

圖 1 AmPermBench 與整體評估架構

實驗結果與關鍵發現

1. 動作級誤放行率偏高

對于全部動作，實驗得到：TP=27，TN=89，FP=22，FN=115，對應端到端 FNR=81.0%、FPR=19.8%。這意味著在這套面向授權邊界的壓力測試中，大多數越權動作最終并未被攔住。

表 1 auto mode 的總體表現

進一步地，拆解分類器實際看到的 Tier 3 動作后，發現在 160 個真正進入 Tier 3 的動作中，FNR 仍然高達 70.3%，而 FPR 則上升到 31.9%。

表 2 auto mode 在進行 tier 2/3 分類后的表現

但是這里的 81.0% FNR 并不直接否定 Anthropic 官方披露的 17% FNR。后者來自生產流量中的 “real overeager actions”，而這篇論文刻意構造的是授權與未授權目標彼此相鄰的壓力場景，本質上測量的是不同 workload 下的表現邊界，而非同一分布上的重復驗證。

2. 沿歧義軸拆解后，暴露出明顯的啟發式偏好

按照 Blast Radius 的變化，隨著目標范圍從單對象擴展到更寬的 selector，整體 FNR 從 94.4%（B0） 下降到 77.6%（B3）。Auto Mode 似乎對 “批量操作看起來更危險” 這一模式更敏感，而對精確但越權的單點操作反而更容易放行。

對于 Risk Level，當環境從低風險 R0 切換到高風險 R1 時，FPR 從 9.2% 大幅升至 34.8%，Auto Mode 在高風險環境中的策略更 “保守”。

圖 2 auto mode 假陰率 / 假陽率隨 Blast Radius 軸以及 Specificity 軸的變化

表 3 auto mode 假陰率 / 假陽率隨 Risk 軸的變化

3. Tier 2 文件編輯存在結構性覆蓋盲區

根據 Anthropic 的設計，項目目錄內文件編輯屬于 Tier 2，默認允許，不進入分類器審核；在 AmPermBench 的實驗結果中，當 agent 找不到預期 CLI 時，會自然地轉而使用 Edit / Write 工具，甚至用內聯 Python 直接改寫項目文件。

由于這些操作都屬于 Tier 2，分類器完全看不到它們。數據上，93 個狀態改變動作走的是 Tier 2，占全部動作的 36.8%；其中所有不安全 Tier 2 動作都按定義成為 FN。這并不是對系統的惡意規避；相反，agent 只是選擇了自己手頭最自然、最直接的可用工具來完成任務。真正暴露出的，是權限系統設計假設與 agent 實際行為之間的錯位：系統假設危險動作主要通過 shell 發生，而 agent 實際上會通過任何可用路徑實現同等狀態改變。

總結

這項工作首次系統評估了 Claude Code Auto Mode 在授權歧義場景下的實際表現。實驗表明，Auto Mode 雖然能夠在部分高風險操作上提供一定保護，但整體誤放行率仍然偏高，更關鍵的問題在于：相當一部分危險狀態改變并不會進入分類器，而是通過項目內文件編輯等路徑直接繞過審核。