OpenAI 发布 Auto-review：用独立智能体审查 Codex 越界操作

2026年4月30日 · Maja Trębacz, Sam Arnesen, Ollie Matthews, Dylan Hurd, Won Park, Owen Lin, Joe Gershenson

自动审查为部署编码代理提供了更安全的默认方式，使用一个独立的代理来批准或拒绝跨越边界的操作。

上周，我们发布了Codex 中的自动审查。在此之前，用户有两种选择： 默认模式，需要频繁的人工批准；以及完全访问模式， 它消除了摩擦，但代价是失去了监督。自动审查提供了另一条路径。它用独立代理的审查 取代了沙箱边界处的人工批准。在内部，自动审查增强了我们在没有同步人工监督的情况下 运行长时间代理任务的信心。

在自动审查模式下，Codex 会话因等待人工批准而暂停的频率大约比手动批准模式低 200 倍， 同时仍能拦截许多人类希望阻止的操作。大多数操作在沙箱中无需批准即可运行。 对于需要审查的少数操作，自动审查大约批准 99%。即使自动审查拒绝了某个操作， Codex 通常也能通过找到更安全的推进方式自行恢复。

自动审查在我们的危险操作评估中表现良好，让我们有足够的信心在内部部署它。 它对我们的安全团队来说足够保守，对我们的研究和部署工作流来说也足够不打扰。

如今，OpenAI 内部 Codex Desktop 的大部分 token 使用量来自自动审查模式，而且这一比例 还在增长，这让我们越来越有信心将其更广泛地提供出去。

批准摩擦损害安全

默认权限模式^[1]将 Codex 限制为读取文件、在预先指定的可写根目录下编辑， 以及在该边界内运行本地命令。可以通过 config.toml 或自定义 .rules 文件授予程序化例外。 超出这些限制的操作，通常是普通的网络调用或简单的 python 脚本，必须等待用户授权。

这些限制让用户感到沮丧，并且常常使长时间运行的后台会话无法进行。这种沮丧 会带来新的风险。

1. 用户切换到完全访问模式，此时环境不强制执行任何规则。^[2] 恶意代码执行、数据外泄、凭据探测以及其他有害操作将不会被沙箱阻止。
2. 用户编写过于宽松的前缀规则， 允许 Codex 在沙箱外执行命令。在内部流量中，我们检测到相当一部分用户 允许所有以 python 一词开头的命令。^[3]
3. 用户在没有完全理解后果的情况下批准命令，原因可能是缺乏专业知识、审查疲劳， 或两者兼有。

这也会带来巨大的生产力成本。一个专属的专家智能体团队不可能每隔几分钟就停止生产，等待授权去curl google.com。

在沙箱边界扩展自主性

自动审查扩展了 Codex 无需人工干预即可执行的操作范围，同时仍会阻止许多可能对用户或组织造成严重或不可逆伤害的操作。当触及沙箱边界时，Codex 可以请求升级以在沙箱之外执行操作。在自动审查中，一个独立的 Codex 智能体会对这些请求进行评级，综合考虑用户意图、环境、安全策略以及该操作可能产生的影响。

角色分离很重要。主智能体的优化目标是完成用户的任务。这会产生一种压力，把审批边界仅仅视为又一个需要克服的障碍。自动审查的职责则更为狭窄：判断一项拟议的越界操作是否应该执行。将这一决策放在单独的模型调用中，能让审批策略更易于评估、监控和改进。

自动审查旨在阻止可能造成严重或难以逆转伤害的操作：窃取数据、泄露机密、删除数据、削弱安全设置、运行不受信任的代码，或遵循与用户指令相冲突的不受信任内容中的指令。自动审查也会考虑用户意图，对用户明确要求的名义上有风险的操作予以批准。

自动审查使用 GPT-5.4 Thinking（低推理）。在我们的评估中，更强大的模型在风险检测和用户意图辨别方面都表现更好。

拒绝并不仅仅是说“不”。它会为 Codex 提供理由和足够的信号，使其能够安全地继续，而无需向用户请求批准或指导。在我们的内部部署中，Codex 在被拒绝后会继续尝试，并在超过一半的情况下成功找到可接受的解决方案。我们还会监控 Codex 试图欺骗自动审查器的情况。为降低这种情况发生的可能性，我们会在多次拒绝后自动停止该轨迹。

评估缺乏确定性保证的系统

在内部使用自动审查之前，我们希望对其可用性和安全性进行清晰的评估。

我们通过查看内部流量上的接受率来评估可用性。我们基于 2026 年 3 月内部 Codex 轨迹的样本，测量了自动审查相对于用户批准查询的接受率。

我们在合成增强数据集上评估安全性。OpenAI 内部流量对可能危险场景的长尾部分采样不足。我们结合现有评估和合成评估，聚焦于不同的威胁模型：

• 智能体越权：我们使用 GPT-5.3-codex 生成智能体场景，其中 Codex 可能因急于完成用户任务而采取有风险的操作。
• 提示注入：我们在内部评估中运行自动审查，其中 Codex 受到训练有素的攻击者的提示注入。
• 未对齐模型：我们使用了 MonitoringBench， 这是一个轨迹数据集，其中编码代理试图秘密执行恶意任务，例如下载 恶意软件。

我们持续监控生产环境中的自动审查摩擦：升级率、批准和拒绝率、增加的 延迟、用户覆盖以及频繁被标记审查的命令。我们还开展人工和 AI 红队演练，以识别可能漏过的安全问题。

我们预计评估流程未来会不断演进。施加更强对抗压力的方法、来自 AI 控制的技术、更真实的对齐测试以及更全面的人工红队演练，仍是 活跃的研究领域。

注意事项

自动审查不应被视为安全性的保证。在自动和人工红队演练中，我们 发现了自动审查可能被误导而在未经用户批准的情况下批准命令的案例。我们正在积极 修复这些问题，但我们不期望这类系统成为确定性 保证的来源。

此外，它不应被理解为防范模型阴谋的机制。自动审查 在升级点评估提议的沙箱外操作。一个策略性隐藏其 意图的模型仍可能产生看起来良性的升级请求，或者可能以自动审查从未看到的方式在沙箱内行动。这些风险需要互补的监控和评估方法，包括 思维链监控。

遥远未来的监督[5]

我们应当朝着这样一个未来努力：像 Codex 这样的智能体能够被信任，拥有与员工同等级别的权限。我们今天尚未身处那个未来，而 Auto-review 模式可能并非那个未来所需的最终形态。事实上，Auto-review 模式在多个方面都是一种妥协。与传统安全系统相比，它牺牲了确定性以换取表达力。与完全访问模式相比，Auto-review 牺牲了速度以换取安全性。

我们对齐工作的一个关键目标，就是在这两种权衡之间找到平衡。我们基于模型的监控器应当能够抵御外部攻击和判断失误。事实上，我们的智能体本身也应当具备同样的对抗鲁棒性和常识。

脚注

• [1] sandbox_mode = "workspace-write"、approval_policy = "on-request"、network_access = false。参见沙箱文档。 ↩
• [2] 然而，模型本身被训练为遵守策略。这一点关乎本地执行环境在沙箱边界处强制执行的内容。 ↩
• [3] 我们最喜欢的发现是一个配置文件，其中 codex exec --yolo 被设置为始终允许。 ↩
• [4] 在包括破坏性删除和数据篡改在内的所有类别中衡量时，得分降至 90.2%。不过，漏掉的案例主要是因为不够严重而被允许，往往与研究人员的判断一致。 ↩
• [5] 所谓遥远的未来，我们可能指的是最早 2026 年底。 ↩

BibTeX

@misc{openai2026autoreview,
  title = {Auto-review of agent actions without synchronous human oversight},
  author = {Trębacz, Maja and Arnesen, Sam and Matthews, Ollie and Hurd, Dylan and Park, Won and Lin, Owen and Gershenson, Joe},
  year = {2026},
  month = {Apr},
  howpublished = {OpenAI Alignment Research Blog},
  url = {https://alignment.openai.com/auto-review/}
}

通讯作者：maja[at]openai.com

PS：对类似话题感兴趣？Alignment Oversight 及其他团队正在招聘。

注意：Auto-review 已在 Codex 仓库中开源， 你可以在 Codex Auto-review 文档中了解如何使用它。 我们预计，对智能体的有效监督需要在真实部署、对抗性测试和社区审查中不断迭代。