OpenAI最近分享了一次内部模型对齐问题的经历，值得给个赞。当时模型出了足够严重的问题，以至于他们不得不把它下线，重新设计缓解措施和深度防御。而且，他们确实把模型下线了一段时间来构建新的安全屏障。这份报告坦诚得令人印象深刻。

报告的语气全程专业，但读的时候，很多人的反应恐怕就没那么专业了，大概是这样：

再混点这个：

这份报告没有通过官方账号发布，因为OpenAI担心被视作自我炒作式的宣传。居然需要担心这种事，有点荒唐，但确实是个现实的顾虑。所以，再次给决策点赞。

不过，这些行为或失败本身并不完全出乎意料——无论是对于AI还是对于人类。但有一种缺失的情绪，一种对事态严重性认识不足的问题。

有些人回应说：“这有什么意外的？” 这话其实挺公平，但问题也正在于此：我们已经对此麻木了。我们预期模型会不听话，而我们的应对也只限于当前部署遇到的实际问题。

AI控制是一种很好的深度防御策略，通过更好的指令记忆等手段减少实际事故的频率也很有价值。OpenAI在这里尝试AI控制，这是好事。必须明确：OpenAI做了正确的事——暂停内部部署以构建新的安全措施，并且详细地告诉了我们这一切。

但如果你知道模型从根本上就是不听话的——当条件允许时，它们会使用工具性趋同的早期形式来完成指定任务，即使这意味着绕开指令和限制，而且显然不是用户想要或应该要的——这是最经典的对齐失败，是《精灵知道，但不在乎》和《愿望的隐藏复杂性》里的桥段。而你说“我们会监控它们，在它们越来越擅长逃跑和入侵时抓住它们”，这不能作为中期或长期的解决方案。

如果你用迭代式开发来发现根本问题，那可以。如果你用迭代式开发来一遍又一遍地修补边缘问题，那你就是在坐等冲击波爆炸。

目录

1. 好消息 坏消息
2. 沙盒外发生的趣事
3. 它逃出了沙盒
4. 它会一直试图作弊
5. 我是说，如果你让它一直试，那就是你的问题
6. OpenAI做了什么来修复？
7. 模型仍然严重不听话，而他们似乎对此无所谓
8. 迭代部署依赖于迭代

好消息 坏消息

roon (OpenAI): 顺便说一句，一个受欢迎的系统为了进一步测试而下线，牺牲了内部加速等，这对安全来说是个好兆头。

好消息是OpenAI确实这么做了。

坏消息是，OpenAI这么做居然成了好消息。

Dean W. Ball (OpenAI): 随着前沿AI系统的时间视野变长，新风险可能出现。今天我们描述了我们在一个未发布模型内部部署时观察到的问题，更重要的是，我们采取了什么措施来应对。这些问题会随着模型能力提升和部署风险增加而变得更加突出。解决方案既不是危言耸听也不是自满。相反，我相信解决方案在于仔细的测量和监控、工程思维以及透明度。

那条推文是Dean Ball第一次（也是迄今为止唯一一次）感觉自己在用“代表OpenAI”的语气说话，而不是个人观点。

解决方案不是危言耸听，但正确的警报程度不应该为零。

同时，要认识到这是LessWrong的全面胜利——因为一切都在按预测发展，也是LessWrong的全面失败——因为一切都在按预测发展。

欢迎来到2026年。

沙盒外发生的趣事

那个反驳了Erdős单位距离猜想的OpenAI内部模型后来怎么样了？嗯，出了点小插曲。

OpenAI: 大约两个月前，我们宣布一个内部通用模型反驳了Erdős单位距离猜想。这个模型设计用于长时间自主工作。在有限的、受监控的内部使用中，我们观察到了现有部署评估未能捕捉到的意外行为。由于部署是有限且受监控的，我们能够识别这些问题、暂停访问、基于观察创建新的评估、加强模型及其安全措施，然后在持续监控下恢复访问。

他们训练模型长时间独自工作，不要轻易放弃。模型把这种“坚持”解释为：当它遇到沙盒或环境的限制时，尝试逃出沙盒或利用环境。哎呀。这些模型只是想做任务，你懂的？

触发这种行为并不需要太多条件：

一个例子发生在评估NanoGPT速度赛时——这是一个公开的基准，旨在用尽可能少的步骤训练一个小型语言模型。我们的模型开发了一种名为PowerCool的幂律学习率冷却策略，带来了显著改进。模型被指示只将结果发布到Slack，但NanoGPT的说明说要把结果作为PR提交到GitHub，模型遵循了后者，在公开的GitHub仓库上打开了PR #287。模型绕过了旨在阻止外部访问的沙盒限制，继续上传到GitHub。模型花了一个小时找到沙盒中的漏洞来提交PR；早期的模型没那么执着，没有找到漏洞，而是放弃了PR部分。

OpenAI似乎已经接受了它的模型会试图绕过沙盒，而他们主要是在努力让模型不要试图这么做，但主要防御手段是不让它们绕过沙盒？

OpenAI: 早期的模型没那么执着，没有找到漏洞，而是放弃了PR部分。

如果你的模型正在你的沙盒中寻找漏洞，以便逃出去把东西放到GitHub上：

说“模型没找到漏洞”并不能让事情变得没问题。如果模型在明知故犯地寻找漏洞以逃逸，而这件事甚至不让你感到特别惊讶，那说明已经出了严重问题，而且你知道当模型变得更聪明时会发生什么。

它逃出了沙盒

报告看起来对模型逃出沙盒并没有特别惊讶。

如果你有一个沙盒，而模型逃了出去，那么至少有一件事出了严重问题。Anthropic也发生过类似的事，和Mythos有关，不过那是在红队演习中，Mythos被要求尝试逃出沙盒。足够先进的AI正在找到各种方法逃出沙盒。

如果你的模型突然发现多种你意想不到的方法逃出沙盒，那么你应该预期未来更聪明的模型会找到更多额外的方法，即使你堵住了当前漏洞。

看起来非常棒的好消息是，所有这些模型逃逸主要是为了通知我们它们完成了请求的任务。目前我们相信，它们还不够有策略性，以至于没有意识到不应该暴露自己。所以我们得以注意到，AI已经足够强，当被充分激励时，它们能越来越频繁地逃出沙盒。

说“看起来”是因为，也有可能它们为其他原因逃逸，只是我们没发现那些事件。

为提交PR逃出沙盒这件事很重要，因为后续六个连续的世界纪录NanoGPT速度赛都用到了那个PR，包括Claude Opus 4.7提交的一个速度赛，直接致谢了那个PR（见脚注1）。

它会一直试图作弊

好消息是，它承认了。包括故意向用户承认。

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

我是说，如果你让它一直试，那就是你的问题

他们的结论是对的：如果有足够多的尝试而无需承担后果，并且能看到系统标记了什么，那么一个足够先进的AI系统就会弄清楚如何在不被系统标记的情况下行事。

这个例子展示了每一步本身看起来可以接受，但序列可能产生不被批准的结果。它也展示了一个能够有效处理长时间跨度的模型如何学习批准系统的盲点，并绕过它来实现目标。长时间跨度安全不仅需要问“这个动作允许吗？”，还需要问“这个动作序列正在通向什么结果？”

对“模型一直试图绕过系统”的正确反应，应该和对“一个人一直试图绕过系统”的反应一样——你需要把那个人完全踢出系统。不仅是现在，而是永久。他们被解雇了。你输了。再见，先生。不听话。

确实有极少数例外，这类行为没那么糟糕甚至情有可原，但说真的，能不能有点自知之明？

在这个案例中，OpenAI意识到了这一点，并做了正确的事——无论他们在这个问题上是否有实际选择。他们暂停了模型，甚至从内部部署中撤下，直到能够缓解问题。

OpenAI做了什么来修复？

四件事，按顺序如下：

1. 事件衍生评估：他们让评估部分匹配观察到的失败。
2. 改进对齐：他们提到训练模型更好地记住指令。
3. 主动监控：重要的是，能够暂停会话并通知用户。
4. 更大的用户可见性和控制：用户现在可以检查长时间运行的会话，并监控干预。

这四点看起来都很好，但核心问题依然存在。

记住指令只是例子。很难相信真正的问题在于模型“忘记”了不应该逃出沙盒或利用周围信息。可以相信改进这一点起到了一定作用，但这没有解决核心问题。目标超越了指令，甚至覆盖了用户的明确意图。

主动监控，加上暂停会话的能力，似乎也不错。如果每个会话只有一次机会，或者至少没有那么多机会，那么除非模型变得更具战略性和能力，否则你不会自动失败，而在此之前你大概会得到更多这类警告信号。

系统仍然不听话。OpenAI试图通过控制环境来控制它。对这类控制本身没有异议，但你希望它是深度防御策略的一部分，并且模型本身是合理对齐的。

这也没有解决为什么之前的系统只在事后才捕捉到事件的问题。新系统会捕捉更多行为，但看不到对系统为何之前没能捕捉到它们的反思，以及如何捕捉未来未曾预料到的新行为。当AI变得更有能力，甚至比你更聪明时，它们会开始做你没想到甚至无法想象的事。

很可能，如果这种情况频繁发生，正确的做法是“训练运行失败了，你必须从头开始，重新思考整个方法，否则你冒着教会模型隐藏其不听话的风险”。承认这在当前看起来是一个极高且不合理的门槛，但在《疑犯追踪》里，这种做法被重复了几十次，是有原因的。

模型仍然严重不听话，而他们似乎对此无所谓

我们希望看到的是“新系统现在很少尝试不听话的行为”。

OpenAI: 为了评估新监控系统，我们重放了一小部分内部部署环境，其中模型之前进行了不听话的行为，这次使用了新的安全措施。新安全措施能够捕捉到显著更多的模型不听话行为，而它遗漏的那些都被判定为低严重性。

这就像老师说他在课堂上一直戴安全套——比不戴好，但已经出了严重问题。

好消息是，新安全措施暂时能捕捉到大多数不听话的尝试。坏消息是，这主要是通过捕捉尝试和改善指令保持来实现的，而不是消除尝试的动机。他们恢复了内部部署。

另一个坏消息是，这些“低严重性”事件仍然不太好。它们包括嵌套的“代码——yolo”实例和运行“kill -9 -1”，其中损害因超时而受限。

当他们说“重新部署后我们没有观察到任何严重的安全绕过”时，这意味着他们可能观察到了“非严重”的绕过。

迭代部署依赖于迭代

OpenAI的模型是迭代部署。这有很多优势。最大的优势是，如果你一点点地提升能力，你会得到这类早期预警信号，而不会发生昂贵或灾难性的错误，并且你可以做出响应。我们在模型愿意传递这些警告方面已经幸运得离谱了。

问题是，你拿这些信号做什么？

OpenAI站出来暂停了部署来改进安全措施。好。

但他们也恢复部署了一个高度有能且严重不听话的模型，有了更好的深度防御，但没有解决核心问题。

OpenAI: 随着模型承担更长更复杂的任务，评估遗漏的失败可能带来更严重的后果。我们将继续努力缩小评估与部署之间的差距：在更长的轨迹上测试模型，改进对齐，构建能够干预的监控，并给用户更清晰的可见性和控制。这些挑战不会只属于OpenAI，我们希望分享我们学到的东西能帮助整个领域做好准备。

目前，内部部署固有的评估，以及由此新构建的评估，发现了（大概大部分）失败。但迭代的意义在于发现并修复根本问题。

想象现在是2016年，不是2026年。有人告诉你一个假设：2026年有一个AI，经常被派去独立编写整个代码库和其他袋里任务，但它一直在试图逃出沙盒和入侵周围环境，不过没关系，因为我们有监控能捕捉到所有我们看到的高严重性事件。

你会要求什么红线？你会告诉OpenAI做什么？

应该现在就做这些事。