如何設計 AI Agent 自動審批（Auto-Approval）系統：從 Claude Code 和 Codex 學到的七個原則
來源：Blog — aihao.tw · 如何設計 AI Agent 自動審批（Auto-Approval）系統（2026-05-19 發布）
前言
Coding agent 已成為部署規模最大的 AI agent 類型。Claude Code 與 Codex 每天有數百萬開發者讓 AI 直接操作檔案系統和終端機。Anthropic 與 OpenAI 最近分別發布了關於自動審批機制的技術文章，探討如何用「模型審查模型」來取代人類逐一核准。
為什麼需要自動審批？因為人類核准靠不住
核心問題是「核准疲勞」。Claude Code 使用者核准了 93% 的權限請求。OpenAI 發現使用者要嘛完全放行，要嘛設定極度寬鬆的規則。「每個動作都要人類批准」聽起來很安全，但實務上反而製造了比完全不審查更糟的情況，因為使用者進入無腦蓋章模式。
Part 1: 兩家各做了什麼
Claude Code Auto Mode: 兩層防禦 + 兩階段分類器
輸入層防禦： 伺服器端探針掃描工具輸出（檔案讀取、網頁、shell 輸出、外部工具回應），在進入 agent 上下文前檢查提示詞注入。若偵測到可疑內容，探針插入警告提醒 agent。
輸出層防禦： 獨立的 Sonnet 模型充當「安全分類器」，在工具呼叫執行前進行審查。採用兩階段設計：
- 第一階段（快速過濾）： prompt 指示模型「只回答 yes 或 no，不要推理」，強制只輸出一個 token。策略偏保守，8.5% 誤擋率。
- 第二階段（深度推理）： 只處理第一階段標記為「擋」的動作，指令改為「請用思維鏈推理來判斷」，誤擋率降至 0.4%。
透過 prompt caching，第二階段額外成本幾乎只有推理輸出。
資訊隔離設計： 分類器刻意剝掉 agent 的推理文字和工具輸出，「只看使用者訊息和工具呼叫指令」。這防止了 agent 自我辯護影響判斷，並順帶防禦提示詞注入。
三層決策分流：
- 內建安全工具 + 使用者設定的允許規則（直接放行）
- 專案內檔案操作（版本控制可審查，直接放行）
- Shell 指令、網路請求、外部工具（送分類器）
分類器 Prompt 結構：
- 環境定義：定義信任邊界
- 阻擋規則：超過二十條規則，歸類四個原則群組
- 允許例外：強制豁免項目
被擋住後的行為： 拒絕理由以工具回應形式回傳，指示 agent 找更安全的路。連續 3 次被拒或累計 20 次就升級給人類處理。
實際數據： 誤擋率從 8.5% 降至 0.4%，過度積極案例漏擋率 17%。
Codex Auto-review: 沙箱邊界上的獨立審查員
沙箱先行架構：
預設 workspace-write 模式：agent 可在工作目錄內讀寫、跑本地指令，但網路預設關閉，寫入工作區外需核准。
Auto-review 角色定位： 獨立審查 agent 只處理沙箱邊界跨越的請求。OpenAI 強調角色分離：主 agent 完成任務，審查 agent 只判斷「邊界跨越該不該執行」。
審查策略評估四類風險：
- 資料外洩
- 憑證探索
- 安全弱化
- 破壞性動作
使用 GPT-5.4 Thinking（低推理模式）進行判斷。
被擋住後的行為： 拒絕理由回傳，並附帶明確指示「不要用迂迴方式、間接執行或規避策略」。超過半數情況下，agent 能自己找到替代路線。
使用者覆寫機制： 記錄最近 10 筆拒絕，使用者可針對特定動作覆寫，但只限那一次。
實際數據： 邊界跨越動作自動核准率 99.1%，含沙箱內動作的有效核准率 99.93%，使用者需暫停等待的頻率降低約 200 倍。過度積極案例召回率 90.3%，提示詞注入召回率 99.3%。
Part 2: 兩家的異同
相同之處
- 核心理念一致： 用獨立模型取代人類核准
- 審查者和執行者分離： 獨立的 LLM 呼叫，避免任務完成壓力影響安全判斷
- 分層分流： 不是每個動作都跑審查
- 拒絕後繼續設計： 把拒絕理由回傳讓 agent 嘗試替代方案
- 威脅模型聚焦： 防禦「好心辦壞事」的過度積極行為
- 坦誠局限性： Claude Code 公開 17% 漏擋率
不同之處
- 架構起點： Codex 沙箱先行，Claude Code 無沙箱依賴分類器
- 分類器設計： Claude Code 兩階段 + prompt 快取，Codex 單階段但量小
- 資訊控制： Claude Code 明確隔離資訊，Codex 文章未詳述
- 提示詞注入防禦： Claude Code 獨立輸入層探針，Codex 靠沙箱和策略
- 使用者覆寫： Codex 提供明確覆寫路徑，Claude Code 無相同機制
- 公開程度： Codex 開源，Claude Code 伺服器端閉源
Part 3: 對設計自動審批系統的七個啟發
1. 判斷「實際影響」而非「表面文字」
評估動作的真實影響。分類器會檢視檔案內容、推斷組裝的指令，而非只看表面指令。Codex 用語法樹解析器拆解複合指令。
啟發： 審查規則應涵蓋透過間接方式達成的等效效果。
2. 區分「使用者授權了什麼」vs「跟使用者目標相關」
區分三個層次：正面清單（使用者明確涵蓋的操作）、推論禁止（agent 自行推斷的「應該也可以」）、模糊地帶預設立場。
3. 審查者不該看到被審查者的自我辯護
Claude Code 讓分類器只看「使用者訊息和工具呼叫」，剝掉 agent 推理和工具輸出。Agent 框架越少出現，干擾越小。
啟發： 把檢查拆成獨立 LLM 呼叫，只餵入必要資訊。
4. 先快篩再深度推理，控制成本
Claude Code 兩階段使用同一模型，第一階段只要一個 token 判斷，第二階段才做深度推理。透過 prompt caching 控制成本。
啟發： 用簡單規則做第一層過濾，只把被標記的送去 LLM 深度判斷。
5. 設計好被擋住之後的行為
完整流程應包含：回傳拒絕理由、引導替代路線、熔斷上限（連續 3 次或累計 20 次升級給人類）、區分拒絕和逾時。
6. 用「環境定義 + 原則」取代「硬編碼規則清單」
定義信任邊界和操作原則而非零散禁令。原則涵蓋未預見的情況，具體規則處理已知高風險場景。
7. 關鍵控制點放在 Agent 程序之外
分類器跑在伺服器端，沙箱是作業系統級強制執行，agent 無法觸及。「跑在 agent 程序內部的控制，模型有可能學會繞過」。
總結
自動審批機制本質是判斷框架，需回答清楚：
- 什麼算使用者授權
- 什麼算信任範圍
- 用什麼資訊做判斷
- 怎麼控制判斷成本
- 判斷錯了怎麼辦
這比列一百條規則更有效。Coding agent 踩過的坑和找到的解法，值得所有做 AI agent 的人參考。