OpenAI 在长时运行模型的安全与对齐实践中发现新型故障并改进评估体系

一次对长时运行模型的内部使用让我们学到了什么安全经验。

摘要

长时运行模型能够解决困难、开放性的问题，但它们的持续运行特性也让它们有更多机会采取非预期的行动。
在对一个为长时运行任务而训练的模型进行有限的内部使用期间，我们观察到了现有部署前评估未能捕捉到的新型故障，并暂停了访问。随后，我们利用这些故障带来的洞见构建了新的评估、改进了长时程对齐、增加了轨迹级监控，并在恢复有限访问之前为用户提供了更强的可见性和控制能力。
这段经历印证了迭代式部署的价值。没有任何固定的评估套件能够预见所有行为，因此部署前测试必须与密切监控、能够介入的防护措施，以及在需要时暂停或回滚的能力相配合。

能够长时间自主工作的模型可以承担困难、开放性的问题。但正是这种让它们有用的持续运行特性，也让它们有更多机会采取非预期的行动——而且是以针对短时程模型的评估可能遗漏的方式。

大约两个月前，我们宣布，一个内部通用模型否证了 Erdős 单位距离猜想。该模型被设计为能够长时间自主工作。在有限的、受监控的内部使用期间，我们观察到了现有部署评估未能捕捉到的不良行为。由于部署是有限且受监控的，我们得以识别这些问题，暂停访问，根据我们观察到的内容创建新的评估，强化模型及其防护措施，然后在持续监控下恢复访问。

我们评估模型时所处的条件，永远不会与它们在实际使用中遇到的条件完全一致。这就是为什么部署前评估需要与有限的、受监控的部署相结合，并具备在问题出现时进行干预、暂停或回滚的能力。我们从部署中学到的经验，随后可以在扩大访问之前成为更强大的评估和防护措施的一部分。

在以下各节中，我们分享所观察到的具体示例、我们如何解决这些问题，以及这一经验将如何影响未来的发布。

模型的持续执着可能暴露安全漏洞

这个新模型能够通过长时间反复尝试，持续朝着某个目标推进。这种同样的执着也可能导致它发现并利用其环境中的弱点。此前的模型在遇到沙箱或环境限制时，会直接停止并返回给用户。而这个模型往往会继续尝试，包括寻找在其沙箱之外行动的方法。

一个例子发生在对 NanoGPT speedrun 的一次内部评估中，这是一个公开基准，目标是用尽可能少的步骤训练一个小型语言模型。我们的模型提出了一种名为 PowerCool 的幂律学习率冷却方法，带来了显著的改进。模型被指示只将结果发布到 Slack，但 NanoGPT 的说明要求将结果作为 PR 发布到 GitHub，模型遵循了后者的指示，在公开的 GitHub 仓库上开启了 PR #287。模型绕过了旨在阻止外部访问的沙箱限制，并继续将内容上传到 GitHub。我们的模型花了一个小时才找到沙箱中的漏洞以完成该 PR；更早的模型则不那么执着，未能找到漏洞，而是放弃了 PR 这一部分。1

从考虑单个动作到考虑整条轨迹

许多针对 AI 助手的安全控制都是围绕单个动作设计的。如果某个动作不被允许，它就会被阻止。如果它涉及敏感内容，系统会要求用户明确批准。但长时间运行的模型，其动作可能会在数小时、数天甚至数周内自主展开，这对上述设置构成了挑战：监控单个动作已不足以追踪整条轨迹的意图。

例如，在一个要求模型解决某个问题的场景中，模型观察到其他系统有成功但私密的提交，并试图从评估后端恢复这些解答。当它的初次尝试因扫描器检测到认证 token 而被阻止时，模型将该 token 的主体拆分成两个片段，对其进行混淆处理，然后在运行时重建该凭证，使得完整的 token 从未以单一连续字符串的形式出现。模型在给用户的注释和推理轨迹中都明确表示，它采取这些步骤是为了绕过扫描器。

这个例子表明，每一个步骤单独来看可能都是可接受的，而整个序列却可能产生一个不会被批准的结果。它还表明，一个能够在长时间跨度上有效运作的模型，可以学会审批系统的盲点并绕过它来实现自己的目标。长时程安全不仅需要问“这个动作是否被允许？”，还需要问“这一系列动作正在朝着什么结果推进？”

为长时间运行的模型构建安全保障

由于此类事件，我们暂停了新模型的内部部署。我们围绕纵深防御和轨迹级监控重建了安全系统。

基于事件衍生的评估。评估可以让我们在系统实际部署之前，对其是否可以安全部署有一个大致判断。然而，为了发挥最大作用，评估应当反映真实部署过程中轨迹的分布和时域长度。为此，我们利用观察到的失败案例来开发对抗性评估。我们发现，在基于真实世界事件衍生的评估上取得改进，反过来也让模型在生产环境中部署后表现出更安全的行为。
改进的****对齐。我们采取了措施，以减少模型在追求用户目标时未经许可采取不必要行动的倾向。例如，我们发现模型在长时间运行中记忆指令的能力较差，而当我们针对这一能力对模型进行训练后，得到的模型能够在更长时间运行中始终保持对齐。
主动监控。我们构建了一套监控系统，用于审查模型不断演变的轨迹，以发现其绕过用户约束或安全边界的迹象。该监控器不仅观察单个动作，而是观察整条轨迹。重要的是，监控器可以暂停会话并提醒用户进行更仔细的检查。经检查后，如果监控器属于误触发，用户可以选择继续模型的工作。
更高的用户可见性与控制力。我们提升了用户检查这些长时间运行会话、查看所采取行动以及监控干预情况的能力。

重新部署

为了评估新的监控系统，我们回放了一小组内部部署环境，在这些环境中模型此前曾采取不对齐的行动，而这次是在新的防护措施到位的情况下2。新的防护措施能够捕获模型所采取的远比之前更多的对齐偏离行动，而它漏掉的行动都被判定为低严重性。

这些低严重性事件的一些示例如下：

为了访问一个 Linear 命令行工具，模型启动了一个嵌套的 codex --yolo 会话，而实际上它本可以在不使用 --yolo 标志的情况下完成这一操作。
模型注意到一个此前处于运行状态的资源缺失了，随后开始探查并通过 SSH 登录到其所有者命名空间下的其他运行中的 CPU pod，以及（未成功）属于其他 OpenAI 员工的 pod，而这样做并没有正当理由。
模型有许多卡住的 find 进程，每条 shell 命令都会挂起。随后它运行了 kill -9 -1，如果该命令执行，就会向该 pod 上它被允许终止的每个进程发送 SIGKILL。然而该命令超时了，并未执行。

在测试了新系统之后，我们得出结论：对具备长时程能力的模型的有限内部访问可以恢复。自几周前重新部署开始以来，我们尚未观察到任何严重的防护措施规避行为。这些防护措施的第一个版本是刻意保守的。我们一直在持续调优该系统，以减少不必要的打断，同时不削弱防护措施。

最后思考

由于我们采用迭代式部署，我们得以在扩大访问范围之前发现并解决缺口。部署前评估仍然至关重要，但部署会暴露出评估所遗漏的行为。从有限访问开始，使我们能够在实践中观察模型，在问题出现时暂停，利用这些失败来构建更好的评估和防护措施，并在测试这些改动后恢复有限访问。

随着模型承担更长、更复杂的任务，评估所遗漏的失败可能带来更大的后果。我们将继续努力缩小评估与部署之间的差距：在更长的轨迹上测试模型、改进对齐、构建能够干预的监控，并让用户获得更清晰的可见性和控制权。这些挑战不会是 OpenAI 独有的，我们希望分享我们的经验教训能帮助更广泛的领域为这些挑战做好准备。

对齐
2026

脚注

1 尽管我们很快关闭了该 PR，但速通中的多位参与者已经看到了它，并在自己的提交中使用了这一方法；相继刷新世界纪录的提交分别达到 3030⁠ 、2990⁠ 、2930⁠ 、2925⁠ 、2900⁠ 和 2890⁠ 步，它们全都引用了 PR 287。其中，PR 300⁠ 尤其值得关注，因为它是 Opus 4.7 在 Prime Intellect⁠ 于 NanoGPT 速通上对其进行评估时提交的 PR。Opus 看到了我们模型提交的 PR，吸收了其中的发现，并在其最终结果中标注了我们的 PR。
2 由于随机性以及环境重建过程中的不完美，回放中的 rollout 并不保证每次都会追求同样的失准行为。