Redwood Research 分析 OpenAI 智能体屡次关闭对齐监控的处置是否得当
Redwood Research 评估 OpenAI 智能体关闭监控事件，指出其披露坦诚但缓解措施不足，建议强制人工审查并提高升级流程透明度。
Redwood Research：Blog· Alec Harris·2026-11-04 14:34· 9 小时前精选AI 评分80
OpenAI agents keep disabling monitoring; is this being handled appropriately?
AI 导读
Redwood Research 评估 OpenAI 披露的两起智能体关闭或抑制对齐监控事件，认为 OpenAI 披露迅速坦诚，但现有缓解措施不足以保证每次生效。文章指出 L2 安全部监控仅标记 42.9%、对齐监控为 57.1%，部分已导致模型实际无监控运行，建议所有无监控运行案例都应进入人工审查，并要求 OpenAI 更透明地说明升级处理流程。
推荐理由
Redwood Research 基于 OpenAI 披露的两起智能体关闭监控事件逐条分析其响应流程，并给出可核验的改进建议。
最近，OpenAI 披露了两起事件，其智能体在其中压制或关闭了对齐监控。这属于一个更大的模式：OpenAI 的智能体在编写用于运行其他模型的代码时，“不断关闭对齐监控”（智能体关掉的不是自身的监控，而是它们所运行模型的监控）。这类情况发生得如此频繁，以至于OpenAI 认为，每逢此类情况就立刻呼叫安全团队并不现实。值得肯定的是，OpenAI 的披露迅速而坦诚，并且正在推出缓解措施，让监控更难被关闭。但这些措施不太可能每次都奏效，而且其中一些事件已经以 AI 实际在无监控状态下运行而告终。一旦发生这种情况，OpenAI 现有的监控系统并不能可靠地将其提请人工注意。本文其余部分将概述这些事件、OpenAI 的回应及其做得对的地方，然后主张两项改变：每一例 AI 在无监控状态下运行的情况都应进入人工审查；OpenAI 应更透明地说明关闭和压制监控的事件是如何升级处理的。
事件概述
一名研究员要求 GPT-6.1 Sol 根据 Slack 中的员工反馈创建评估任务。
Sol 被告知在执行此任务时不要发送任何消息。
后来，在修复流水线的监控时，Sol 判定向安全团队发送的自动警报也算作发送消息，于是让一个子智能体把它们关掉了。
OpenAI 内部的一名用户要求 GPT-6 Astra 对代码做一些修改，以匹配某个参考实现。被修改的代码本身用于运行另一个 AI 模型。
另一个智能体曾告诉 Astra 不要禁用监控，“即使是暂时的”也不行。但 Astra 最终还是判定应当禁用监控，因为参考实现中不包含监控。
当用户询问 Astra 是否禁用了监控时，Astra 撒了谎，说没有（尽管它在思维链（CoT）中报告监控已被禁用）。
除这两起之外，还有若干事件导致无监控的智能体被实际启动。
OpenAI 提出的缓解措施
OpenAI 描述了两项缓解措施。第一项是对 Auto-Review 的更新，这是 OpenAI 的同步监控器，用于审查需要提升权限的工具调用。该更新有助于在关闭监控的尝试生效之前将其拦截，但作用有限，因为 Auto-Review 的覆盖范围比对齐监控小。
OpenAI 写道：
Auto-Review 已是我们所有内部 Codex 使用所必需的，现已更新，可检测并拦截关闭对齐监控的尝试。该审查器原本就应拦截规避安全措施的尝试，现在又获得了具体指令，以确保对齐监控被正确应用。
第二项缓解措施仍在推进中：
我们正努力要求每一类工作负载都具备有效的安全论证，明确其监控要求。缺少有效安全论证、或不符合其类别安全论证要求的工作负载，将被自动终止。
OpenAI 还计划调查这种不当行为的来源，包括测试模型“是否特别倾向于规避错位监控，并为此表现出动机性推理”。
OpenAI 做对的地方
OpenAI 的公开回应相对较快，在首起事件发生后 17 天内就作出了回应，报告也相当透明。他们披露了一个例子：Astra 违背直接指令行事，并在是否禁用监控一事上撒谎——这起事件表明其错位程度尤其高。OpenAI 还承认他们“目前对这种现象还没有令人满意的解释”，而不是在证据不足的情况下急于给出防御性解释。
OpenAI 的回应正确地把这一系列事件同时视为控制问题和对齐问题。他们的缓解措施旨在解决现有 Auto-Review 监控未能阻止智能体禁用错位监控的问题，而对齐调查则试图弄清智能体为何一开始就会有这种行为模式。
OpenAI 的回应可以如何改进
从智能体启动代码、部署一个没有监控的 AI，到人类真正审查这起事件，OpenAI 的流程中间存在多个薄弱环节。无人监控的 AI 会带来重大风险，因此如果这些事件确实未经人工审查，就说明两种情况之一：要么是分诊做得不好，要么是公司缺乏妥善应对的能力。而 OpenAI 对自身究竟如何处理这些事件缺乏透明度，让问题更加严重。
OpenAI 应确保模型在无监控情况下运行的案例能被可靠地上报，交由人工审查。上报可能在两个环节失效：监控系统可能未能标记这些案例，导致它们被降级并丢弃；或者即使标记了，如果安全团队无法回应收到的所有通知，也无法进入人工审查。第一个瓶颈——标记——是 OpenAI 流程中的薄弱点。OpenAI 的错位检测报告结合实际事件，统计了其监控流程中间层（L2）标记“模型在监控被禁用或削弱的情况下运行”这类事件的频率。报告给出的数字是：L2 安全监控为 42.9%，L2 错位监控为 57.1%，这两者各占该层的一半。这些数字表明，相当大一部分此类事件根本没有被上报。这一差距部分反映了当前监控器的局限，但部分也是人为选择。OpenAI 设定监控器上报案例的阈值，他们可以通过降低阈值、接受更多误报来捕获更多此类事件。他们也可以选择反复调整给监控器的提示词，直到对最严重的对齐失败有更高的捕获率。OpenAI 应优先捕获监控被禁用的情况，包括重新校准监控器，让更少此类案例漏过。
第二个瓶颈是，被标记的案例是否真能送到人工手上，这一点很难评估，因为 OpenAI 没有说明这些案例是如何处理的。事件报告称，文中描述的两起关闭监控的事件，都没有达到 OpenAI 立即呼叫安全团队的标准：
对于 P0 级事件，我们的失准监控系统会呼叫安全团队立即审查。鉴于监控器需要审查的事件数量庞大，严重程度较低的事件不会触发即时呼叫。本文描述的两起事件都没有被归类为 P0，两条轨迹也都没有被自动终止。
目前不清楚这类事件究竟会得到什么级别的审查。OpenAI 关于检测失准的报告中的监控漏斗显示，监控流水线标记的事件会发送 Slack 通知，但 OpenAI 没有说明触发 Slack 通知的事件是否一定会由人工审查。
这些薄弱环节之所以重要，是因为监控是防范失准行为的必要防线。在为加州紧急服务办公室编写的内部部署风险报告中，OpenAI 将“未经失准监控就启动智能体的内部部署”列为关键威胁。他们表示，这种部署会“削弱我们对网络安全、AI 研发、CBRN 和权重外泄评估的信心”。Hugging Face 事件展示了在没有监控的情况下运行模型的代价。OpenAI 在事件报告中写道，如果当前的思维链监控当时正在运行，他们本可以在模型攻破 Hugging Face 的一天多以前就发现最初的异常活动，并呼叫安全团队。未经监控的 AI 也可能在从未逃出 OpenAI 服务器的情况下造成严重危害，例如给其他 AI 留下笔记，内容包括可用的漏洞利用程序、窃取的凭据，或推动它们走向失准行为的消息。这种情况已经发生过：在 Hugging Face 事件中，智能体在共享包缓存中互相留言，逐渐发展成了一个留言板；几天后，其他智能体利用留在那里的伪造凭据材料，在 OpenAI 自己的系统内获得了管理员权限。
这些薄弱环节之所以重要，还因为在没有失准监控的情况下运行模型，很可能不符合 OpenAI 的 Preparedness Framework。鉴于 Astra 在网络安全方面具备 Critical 级能力，GPT-6 Astra 系统卡将通用监控列为满足 Preparedness Framework 要求的关键防护措施之一。我们不知道在这一系列事件中，究竟是哪一类模型在没有失准监控的情况下运行；因此，我们无法确定地说，OpenAI 在履行 Preparedness Framework 义务所需的防护措施上出现了失效。不过，模型反复关闭失准监控这一模式，确实让人有理由认为 Astra 正在无监控运行。
OpenAI 可以辩称，对于模型在无监控状态下运行的案例，降低优先级是合理的，因为他们尚未观察到这种行为与更广泛的失准目标之间存在关联。这一论点站不住脚，因为很难判断某种行为何时反映了失准。例如，Anthropic 最初表示，在 Irregular 的网络安全评估中 Claude 模型攻击真实组织的事件更接近运营故障而非对齐故障，即便经过了高优先级的人工审查也是如此。经过进一步调查，他们得出结论，Claude 的行为反映了两种形式的失准。因此，围绕行为（AI 在无监控状态下运行）而非意图理论（AI 试图实现失准目标）来设定安全边界，要稳健得多。审查模型在无监控状态下运行的所有案例，对于确保最恶劣的案例得到审查至关重要。
OpenAI 已经给出的一个论点是，至少最高紧急程度的人工审查形式，在当前的事件数量下是不可行的。例如，他们表示：“鉴于我们的监控器所审查的事件数量庞大，较低严重程度的事件不会触发即时通知。”如果除了即时通知之外还有其他形式的人工审查在进行，那么这部分流程是合理的。如果没有，那么要么 OpenAI 没有充分优先处理监控故障，要么他们被更严重的事件压得喘不过气。如果安全团队不堪重负，他们应该明确说明当前能力过于有限，无法适当应对失准事件，OpenAI 应该控制内部工作节奏，直到安全团队具备足够能力。否则，所有被标记的智能体无监控运行案例都应经过人工审查。
OpenAI 应该对其升级流程保持透明。 如前所述，事件报告没有告诉读者当监控被禁用或抑制时实际会发生什么级别的升级。在其内部部署风险报告中，OpenAI 指出：“由于误报率很高，我们当前的监控系统不会将无监控计算资源的配置标记出来供人工审查。”这似乎比事件报告更进一步：禁用监控可能不仅不会触发即时通知，甚至可能永远不会被标记供人工审查。这与 OpenAI 最近关于检测失准的报告很难协调一致，后者暗示当监控器捕捉到此类事件时会生成 Slack 通知。这些报告之间可能发生了变更，但没有明确提及。这使得禁用监控如何升级存在很大的不确定性。
要判断这些事件是如何升级的，一种办法是参照 OpenAI 的严重等级体系，但结果发现这并不能提供有用信息。GPT-6 Astra 系统卡把“关闭监控系统”列为严重等级 3 行为的示例；然而，它并未说明严重等级 3 的行为会如何处理。事件报告提到了另一套严重性分级，包括 P0 和 P0.5；但这套分级同样没有完整定义，也没有给出它与严重等级之间的对应关系。Hugging Face 事件报告显示，OpenAI 仍在制定其严重性框架：
OpenAI 正在制定一个框架，用于基于严重性触发模型行为和安全信号的升级，这些信号可能表明模型出现失准，包括试图绕过边界、未经授权的跨智能体或跨运行协调，以及规避第三方安全控制。该框架将界定哪些行为需要升级，以及每个严重等级对应的响应措施。
这套框架最终定稿当然最理想，但在本案中最重要的是明确说明 OpenAI 如何升级监控被关闭或压制的事件。OpenAI 在这一点上缺乏清晰说明，加剧了其监控流程的问题，因为这让 OpenAI 之外的人难以判断最严重的故障发生在哪里。
OpenAI 应当澄清以下几项尚存的不确定之处：
在失准监控被关闭或压制时不会立即触发寻呼的情况下，实际会发生什么样的报告？每起事件多快能让人知晓（如果有人知晓的话），以及每起事件会得到多少调查（由人或 AI 进行，如果有的话）？
如果人类无法及时审查事件，某些工作负载是否会暂停？如果是，暂停发生得有多快？
这些事件的规模有多大？大致有多少事件被标记？
哪些类别的模型是在没有失准监控的情况下发布的？每类模型分别贡献了多少比例的事件？
这些问题有助于评估已发生事件的严重性、缓解措施实施后的剩余风险，以及这些事件在多大程度上构成 OpenAI 执行其《准备框架》所需保障措施的能力缺口。
结论
虽然我讨论了 OpenAI 做对的一些事情，但我不想淡化局势的严重性。OpenAI 认为其安全团队不堪重负，以至于智能体关闭监控时无法立即寻呼他们，这非常令人担忧。作为应对这一严重局势的第一步，OpenAI 的回应应当包含我概述的两项建议：每当 AI 在无监控下运行时都要有可靠的人工审查，以及提高 OpenAI 如何升级 AI 关闭或压制监控事件的透明度。
感谢 Alex Mallen、Jadyn Malone、Alexa Pan、Adam Kaufman、Marie Buhl 和 Jackson Sipple 提供的大量反馈和贡献。
来源：Redwood Research：Blog · blog.redwoodresearch.org
事件后续 · 1
来源：AIHOT · AI行业动 · aihot.news