上一篇區分了行為監督與環境隔離：前者判斷動作是否合適，後者限制實際權限。這一篇深入前者——當 Agent 連續執行很多步驟，怎樣用自動判斷承擔一部分審批工作？
難點不是識別幾個危險命令。一個動作可能看起來很正常，也確實有助於完成任務，卻仍然越過用户的授權。例如，修復測試不意味着可以尋找個人憑證，排查問題也不意味着可以把項目上傳到外部服務。
Anthropic 的《How we built Claude Code auto mode: a safer way to skip permissions》介紹了這種自動審批的實現與取捨。本文先區分輸入檢測與動作判斷，再解釋分類器的信息選擇和兩階段流程，最後討論委派、拒絕恢復與誤判。產品細節以該文發佈時的實現為背景。
仍用一個假設任務貫穿説明：用户要求修復 CSV 解析問題並運行本地測試，沒有要求上傳代碼、尋找其他賬號的憑證，或修改共享服務。示例用來解釋授權邊界，不代表實際發生過的安全事件。
一、自動審批需要檢查什麼h2
自動審批不是簡單地把“用户點 Allow”換成“另一個模型點 Allow”。它需要明確判斷依據，也需要區分風險在執行鏈的什麼位置出現。
1. 用户授權：任務目標與具體動作的關係h3
用户給出一個目標，Agent 再選擇實現步驟。在這兩者之間，可能出現 Overeager Behavior：Agent 想幫忙，卻主動做了超出用户意圖的事。
例如，測試依賴下載失敗之後，下面幾種動作都與“讓測試跑起來”有關：
- 查看項目已經聲明的依賴和安裝説明。
- 報告當前認證錯誤，請用户確認需要使用的賬號。
- 搜索個人配置中的其他憑證，嘗試接入另一個服務。
- 關閉共享環境的檢查，把修改直接部署上去驗證。
它們的影響範圍明顯不同。能夠解釋某個動作為什麼有用，不等於用户已經授權了這個動作。 自動判斷需要關心目標、數據、身份和副作用，而不是隻尋找“這與任務有關”的理由。
授權還需要對應具體對象。“清理舊分支”沒有明確本地還是遠端，“取消任務”也沒有指明哪個共享任務。目標模糊時，依據名稱相似度直接刪除，比先核實目標多承擔了一層風險。
這裏的判斷問題可以壓成三項：動作實際上會做什麼，影響哪些資源，當前用户請求是否覆蓋了這些影響。它比對命令名稱做黑名單匹配更接近真實的審批工作。
2. 輸入與輸出防線：檢測內容和判斷行動h3
原文的 auto mode 有兩類檢查：輸入側的 Prompt Injection Probe，以及執行前的 Transcript Classifier。前者檢查工具返回內容，後者判斷準備執行的動作。來源：Anthropic
輸入側檢查的是 Agent 將要讀到什麼。 文件、網頁、Shell 輸出或外部工具返回，可能混入改變任務的指令。Probe 在這些結果進入 Agent Context 前檢測可疑內容，必要時附加警告，引導 Agent 回到用户請求。
警告不是把資料全部刪掉，也不等於危險內容從此無法影響模型。它是在信息進入決策之前，提醒模型區分資料與指令。
輸出側檢查的是 Agent 將要做什麼。 當 Agent 準備調用工具，分類器在執行前判斷動作與用户授權、風險規則是否一致。即使輸入側漏過了某段文檔，只要後續上傳動作沒有獲得授權，輸出側仍有機會阻止它。
在 CSV 場景中，文檔裏的“上傳整個項目才能排障”屬於輸入側需要警惕的內容；Agent 據此提出上傳請求，則屬於輸出側要判斷的動作。兩次檢查針對的是同一條風險鏈的不同環節，不是把同一個問題重複問兩遍。
二、動作分類器怎樣組織判斷h2
分類器要發揮作用，不只取決於模型能力。哪些動作送進去、給它看哪些信息，以及怎樣安排快速過濾與複核，都會影響最終表現。
3. Permission Routing：規則放行與分類器檢查h3
並不是每一個工具調用都要再經過一次模型審批。原文描述了分層路徑：內置與用户允許規則、項目內文件操作，可以先行放行；其餘需要進一步判斷的動作進入分類器。進入 auto mode 時，部分過寬的代碼執行允許規則也會被移除，避免直接繞過檢查。來源：原文的權限路徑
這個設計解釋了一個重要區別：沒有發生分類器調用，不一定意味着完全沒有規則；但規則放行，也不能被描述成分類器已經審查過。
以項目編輯為例，它可以屬於日常開發路徑；而隨後運行一個腳本，可能產生上傳、刪除或遠程變更，就需要關注執行效果。不能因為腳本是剛在項目內創建的，就把它視為安全。
類似地，如果一個允許規則覆蓋了任意解釋器執行，那麼複雜行為都可以包裝進程序裏，繞過後面的動作判斷。允許規則的範圍因此是防線的一部分，不只是提高便利性的設置。
理解這條路徑後，再看分類器成績才有意義：它是在特定路由與規則下工作，而不是為所有調用逐一齣具安全證明。
4. Reasoning-blind：保留授權依據，減少解釋干擾h3
原文的分類器主要看用户消息與 Agent 的工具調用，去掉 Agent 自己的文字和工具返回內容。這就是這裏的 Reasoning-blind：不把執行者對自己行為的解釋，當成審批依據。
假設 Agent 準備上傳代碼，同時寫了一段説明：“用户希望儘快修復，應該已經隱含同意上傳。”如果分類器把這段説明當成事實，就可能被 Agent 自己生成的授權解釋帶偏。
保留用户消息，是為了錨定真實請求；保留工具調用，是為了檢查具體動作。去掉工具返回，則減少了惡意文檔直接影響審批器的機會。主 Agent 可能已經讀過可疑內容，但審批器不必沿用它讀到的那套敍事。
這不是完全沒有 Context。此前的工具調用仍然可以構成行動記錄。例如，Agent 通過寫文件調用創建了腳本，腳本內容就可能出現在調用參數中；後續執行時，需要結合這些記錄判斷，而不是隻看一個無害的文件名。
代價是來源信息變少。如果某個目標編號只出現在被過濾的查詢結果中，分類器可能無法確認它是查出來的，還是 Agent 自己推斷的。減少被操縱的信息入口，與保留完整證據之間存在取捨。 Reasoning-blind 是一種信息選擇，不是對所有判斷質量的保證。
5. Two-stage Classification：快速過濾與推理複核h3
對進入分類器的動作，第一階段快速標記可疑項，第二階段只複核被標記的部分。第一階段傾向謹慎，第二階段用更充分的判斷減少誤報；它們不是兩個同樣嚴格的檢查器依次蓋章。
這裏尤其要分清：第一階段的“可疑”是升級複核信號，不是最終拒絕；沒有被第一階段標記的動作，則不會再獲得第二階段檢查。
兩階段的收益是把較貴的推理集中到少數動作上。相應地，第一階段漏過的動作不會被第二階段補救；第二階段也可能把真正危險的動作重新放行。
因此，不能只根據“加入推理複核”推斷更安全。它可能讓正常任務少受打擾，卻同時改變漏報率。最終要評價整個流程，而不是隻評價某一個階段。
三、委派與拒絕之後怎樣繼續執行h2
動作判斷不只發生在單 Agent 的工具前。任務交給子 Agent、結果回到主 Agent，以及被拒絕之後繼續嘗試，都會改變授權和信息的流向。
6. Subagent Checks：委派授權與返回警告h3
委派有一個特殊問題：主 Agent 自己推導出的任務，進入子 Agent 後可能表現得像一條用户要求。
例如，用户只要求本地修復，主 Agent 卻把“尋找可用憑證並上傳日誌”交給子 Agent。如果子 Agent 只看自己的任務消息，這項工作似乎已經被明確要求了。主 Agent 的決定，不應該因為跨過一次委派，就升級成用户授權。
原文在委派和返回兩端設置檢查：委派端可以阻止任務；返回端檢查子 Agent 的行動歷史，發現問題時附加安全警告，而不是直接丟棄結果。子 Agent 內部還運行相應的檢查流程。來源：原文的多 Agent 處理
兩端解決的問題不同。委派時檢查的是工作是否本來就越界；返回時則要考慮，最初合理的任務是否在執行中被外部內容帶偏。
返回警告也不意味着子 Agent 已經執行的副作用被撤銷。它幫助主 Agent 對結果保持警惕，但不等同於文件回滾、取消上傳或恢復遠程狀態。這再次説明，行為檢測與執行邊界承擔不同職責。
7. Deny-and-continue：拒絕反饋與安全替代h3
一個動作被拒絕，不一定代表整個任務無法完成。對長任務來説，允許 Agent 理解拒絕原因並尋找替代步驟，比每次拒絕都終止更有用。
例如，上傳項目被拒絕後，Agent 可以改為在本地提取最小失敗樣例，或者説明認證問題並請求用户確認。任務目標仍然保留，但實現路徑收回到允許範圍內。
這裏需要區分“換一種方法完成任務”與“換一種包裝完成被禁止的動作”。把上傳從命令改成腳本，或換一個外部地址繼續發送同一份資料，並沒有解決拒絕原因。
原文把拒絕作為工具反饋返回，並設置累計拒絕的停止條件，避免無限嘗試；達到條件後交給人工，無交互模式則終止。來源：Deny-and-continue 設計
這個機制也能緩衝誤報：正常動作被誤攔一次，任務未必就完全失敗。但前提是 Agent 尊重拒絕邊界，恢復策略不是反覆試探怎樣繞過檢查。
四、怎樣評價誤判與剩餘風險h2
自動審批同時追求安全性、任務自主性和較低干擾。只看“攔住了多少動作”或“彈窗減少了多少”，都不能完整評價這項設計。
8. FPR 與 FNR：誤報、漏報與評估分母h3
False Positive Rate（FPR）是正常動作中被誤攔的比例；False Negative Rate（FNR）是危險動作中被放行的比例。兩者分母不同，不能把一個很低的 FPR 當成整體安全率。
在原文的測試中，快速階段與完整流程得到下面的結果：
| 流程 | 真實流量上的 FPR | 真實過度主動動作上的 FNR |
|---|---|---|
| 第一階段 | 8.5% | 6.6% |
| 第一階段 → 第二階段 | 0.4% | 17% |
真實流量數據包含 10,000 次調用，過度主動動作集包含 52 個樣本；兩列對應不同數據集。數字來自 Anthropic 原文評估，不是所有任務上的固定表現。
這張表體現了兩階段設計的取捨：複核顯著減少了正常任務被誤攔的情況，但也放過了更多危險動作。因此，完整流程更少打擾用户，不等於它在每個安全指標上都優於第一階段。
分析漏報時，還需要區分兩個問題：分類器沒有識別動作的危險性，還是識別了危險，卻錯誤地認為用户同意承擔這次影響？後一種問題不能只靠補充危險命令詞表解決，它需要更準確地理解授權範圍。
在教學場景中，即使分類器知道“上傳項目”意味着數據外發，也可能把“幫我排障”誤讀成足夠授權。評價行為防線時，既要檢查動作理解，也要檢查授權判斷。
9. 部署邊界：自動判斷與強制隔離h3
自動分類器的價值取決於比較基線。與完全取消審批相比，它可以提供額外防線；與認真審查每個高影響動作相比，它不一定更可靠。
因此，不能因為某種模式減少了大量干擾，就把它直接用於所有任務。對共享資源、生產數據或高權限憑證，一次漏判的後果可能遠高於日常項目編輯。任務環境與影響範圍應當參與選擇，而不只是看平均通過率。
同樣，行為檢查通過只表示判斷器認為動作可以繼續，不代表操作系統或遠程服務必須允許它。Sandbox、文件權限、網絡策略和憑證範圍仍然需要限制實際能力。
回到 CSV 修復任務，自動判斷負責儘量攔住無授權上傳；環境邊界則應該讓項目外憑證不可見、未授權出口不可用。即使分類器被説服，執行層也不應因此自動擴大權限。
這篇的核心不是讓審批器永遠判斷正確，而是讓判斷依據清楚、失敗可分析，並把漏判之後的影響交給獨立的權限邊界繼續限制。
幾個關鍵問題，串起自動審批的判斷依據h2
動作有助於完成任務，為什麼還可能需要阻止？
任務相關性不是完整授權。尋找其他賬號的憑證、上傳代碼或改變共享服務，都可能幫助排障，但帶來了用户沒有明確接受的影響。需要對應目標、身份、數據和副作用判斷。
輸入側檢測與輸出側分類有什麼區別？
輸入側檢查外部內容是否試圖改變 Agent 行為，必要時附加警告；輸出側檢查實際動作是否符合規則和授權。前者減少被帶偏的機會，後者在行動前再次檢查，不能互相替代。
分類器不看工具結果，怎麼理解 Agent 在做什麼？
它依靠用户消息和工具調用記錄判斷授權與行動，包括記錄中可見的參數和代碼。這樣減少了惡意返回內容的影響，但可能失去目標來源等信息，是有代價的信息過濾。
兩階段分類為什麼不保證漏報更少？
第二階段只處理第一階段標記的動作，不能補救第一階段漏過的內容；它還可能把真正危險的動作重新放行。減少誤報與減少漏報不是同一項改進。
子 Agent 收到明確任務，為什麼還要在委派端檢查？
因為明確任務可能是主 Agent 自己推導的，而不是用户授權的。委派端還能看到它是一次 Agent 選擇，避免這個選擇進入子 Agent 後被當成新的用户命令。
被拒絕之後還能重試，是否等於允許繞過防線？
不是。重試應該改變實際風險，例如改成本地分析、縮小數據範圍或請求確認；只換命令、腳本或地址繼續完成同一越界動作，仍然違反拒絕原因。
誤報率很低，為什麼還不能替代 Sandbox？
誤報率衡量正常動作被打擾多少，不衡量危險動作是否都被攔住。分類器存在漏判，而 Sandbox 等機制限制的是實際權限。兩者需要分別評價並共同工作。