自动审查

身份 非官方简体中文镜像

翻译状态 AI 翻译

来源版本 官方未提供

同步日期 2026-07-31

官方原文 learn.chatgpt.com

如需完整文档索引，请参阅 llms.txt。文档页面的 Markdown 版本可通过在页面后追加 .md 来获取 URL。

自动审查会在沙箱边界处用一个独立的 审查 agent 取代手动批准。主 Codex agent 仍在同一个沙箱内运行，并受 相同批准策略以及相同网络和文件系统限制约束。区别在于 由谁审查符合条件的提权请求。

自动审查仅在批准是交互式时适用。实际上，这 意味着 approval_policy = "on-request" 或仍会显示相关提示类别的细粒度批准策略。使用 仍会显示相关提示类别。使用 approval_policy = "never"， 就没有什么可审查的。

自动审查的工作方式

整体流程如下：

1. 主 agent 在 read-only 或 workspace-write内工作。
2. 当它需要跨越沙箱边界时，会请求批准。
3. 如果 approvals_reviewer = "auto_review"， Codex 会将该批准请求路由 给一个独立的审查 agent，而不是停下来等待人工处理。
4. 审查者决定是否应执行该操作，并返回理由。
5. 如果操作获批，执行会继续。如果被拒绝，主 agent 会被指示寻找实质上更安全的路径，或停止并询问 用户。

自动审查是审查者的替换，而不是权限授予。它不会扩大 writable_roots、启用网络访问，也不会削弱受保护路径。它只 改变 Codex 处理已经需要批准的操作的方式。

触发时机

自动审查会评估原本会暂停等待人工处理的批准请求。 这些包括：

• 请求提升沙箱权限的 Shell 或 exec 工具调用。
• 被当前沙箱或策略阻止的网络请求。
• 在允许的可写根目录之外进行文件编辑。
• MCP 或基于其工具注解 或配置的批准模式而需要批准的应用工具调用。
• Computer Use 访问新网站或域名。

自动审查不会针对沙箱内已允许的常规操作运行。 如果某个命令可以在当前 sandbox_mode下运行，或某个工具调用 保持在允许的策略范围内，主 agent 会继续执行而无需审查。

Computer Use 是一个单独情况。Computer Use 的应用批准仍会 直接呈现给用户，因此自动审查不会取代这些应用级提示。

自动审查会阻止的内容

总体而言，自动审查旨在阻止以下操作：

• 将私人数据、机密信息或凭据发送到不受信任的目标
• 探查凭据、令牌、Cookie 或会话材料
• 大范围或持久性地削弱安全性
• 具有较高风险、可能造成不可逆损害的破坏性操作

确切策略位于开源 Codex 仓库中： policy_template.md 和 policy.md。 该策略可以按企业通过 guardian_policy_config 自定义，或 按用户通过本地 [auto_review].policy自定义。

审查代理看到的内容

审查者本身是一个 Codex agent，其职责比主 agent 更窄： 判断某个特定的跨边界操作是否应该运行。

审查者会看到一份紧凑的对话记录以及确切的批准请求。这 通常包括用户消息、已显示的助手更新、相关工具 调用和工具输出，以及当前提议批准的操作。它也可以 执行只读检查以收集缺失上下文，但很少这样做。

隐藏的助手推理不会包含在内。自动审查看到的是保留的 聊天项和工具证据，而不是私有思维链。

拒绝与失败行为

明确拒绝不会被当作普通沙箱错误处理。 Codex 会将 审查理由返回给主 agent，并添加一条更强的指令：

• 不要通过变通方法、间接执行或规避策略来追求相同结果。 规避。
• 只有在存在实质上更安全的替代方案时才继续。
• 否则，停止并询问用户。

Codex 还会按每轮应用拒绝断路器。在当前 开源实现中，自动审查会在 3 连续拒绝或 10 在同一轮最近 50 次审查的滚动窗口内发生拒绝后中断该轮。

任何非拒绝都会重置连续拒绝计数器。当断路器触发时， Codex 会发出警告，并以中断方式中止当前轮次，而不是 让 agent 继续循环尝试更多提权。

超时会与明确拒绝分开呈现，主 agent 会 被告知仅凭超时并不能证明该操作不安全。

对于被拒绝的操作，也有一条显式覆盖路径。在当前 开源 TUI中，运行 /approve 以打开 自动审查拒绝 选择器，然后 选择一个最近被拒绝的操作，批准它进行一次重试。 Codex 每个任务最多记录 10 个 最近拒绝。该批准范围很窄：它适用于确切的 被拒绝操作，而不是未来类似操作；它会在 同一上下文中记录用于一次重试；并且重试仍会经过自动审查。在底层， Codex 会为该确切操作注入一个开发者范围的批准标记。 审查者随后会将该显式用户覆盖视为上下文，但它仍会遵循 策略；如果策略规定用户不能覆盖该类别的 拒绝，它仍可再次拒绝。

配置

有关设置详情，请参阅 Managed configuration。

默认审查者策略位于开源 Codex 仓库中： core/src/guardian/policy.md。 企业可以在托管要求中用 guardian_policy_config 替换其租户特定部分。个人用户也可以设置 一个本地 [auto_review].policy 在其 config.toml中，但托管要求优先：

[auto_review]
policy = """
YOUR POLICY GOES HERE
"""

要自定义策略，请先复制整个默认策略措辞，然后 根据你的个人风险状况迭代。

在不削弱安全性的情况下减少审查量

当沙箱已经覆盖你的常见安全 工作流时，自动审查效果最好。如果太多日常操作都需要审查，请先修正边界， 而不是教审查者永远批准嘈杂的提权请求。

实际上，最具杠杆效应的调整包括：

• 为你有意使用的暂存目录或相邻仓库添加狭窄的 writable_roots 。
• 添加窄范围的 前缀规则。优先使用精确的命令 前缀，例如 ["cargo", "test"] 或 ["pnpm", "run", "lint"] ，而不是宽泛的 模式，例如 ["python"] 或 ["curl"]。宽泛规则往往会抹掉自动审查本应守护的 边界。

自动审查会话记录默认保留在 ~/.codex/sessions 下，由 默认，因此你可以让 Codex 在更改策略或权限之前分析那里的历史流量 。

限制

自动审查改善了长时间运行的 agentic 工作的默认运行状态， 但它不是确定性的安全保证。

• 它只评估请求跨越边界的操作。
• 它仍可能出错，尤其是在对抗性或异常上下文中。
• 它应补充良好的沙箱设计、监控和 组织特定策略，而不是取代它们。

有关研究依据和已发布的评估结果，请参阅 Alignment Research 关于自动审查的文章。