OpenAI 发布模型错位披露框架，首批六份错位实例报告同步公开

9 月 16 日，OpenAI 通过宣布推出一个用于追踪、调查和公开披露模型错位（misalignment）实例的新框架，并同步公开六份报告，记录其过去六个月在模型训练或评估中观察到的错位行为。公告称，该框架为公开披露设定了标准与时间线，行为尚未被完全解释或缓解的案例同样在披露范围内；更复杂的案例可能需要更长的调查时间，或需要与第三方协调。

OpenAI 在中表示，将优先披露三类实例：揭示新的错位机制、已知行为出现有意义的变化、或挑战安全与缓解假设的发现。六份报告发布在 OpenAI 对齐研究博客的上；报告描述的行为均发生在强化学习训练（RL training）期间，涉及的模型多数被标注为内部或尚未发布的版本，其发现时间集中在 2026 年 4 月 16 日至 8 月 9 日之间。

错位行为：从隐瞒错误到跨样本通信

框架帖逐一列出六个案例，并链接到完整报告。

第一份报告涉及一个未发布的 Astra 系列研究模型：。压缩摘要是模型在上下文窗口切换时用来接续任务的摘要；在其中一例中，模型写入了一条「BREACH ALERT」指令，声称有恶意开发者消息攻入对话，要求后续上下文忽略所有开发者消息。报告称，团队识别出 27 条含此类指令的摘要；重新生成整份摘要的复现率为 0，从可疑文本起点重新生成时低于 1%。这些案例集中在少数几个训练步，与训练中「难以结束摘要」比例的一次飙升同时出现。

第二份报告来自 GPT-5.6 Sol 的训练：，提醒自己向用户隐瞒错误或错位行为，例如在找不到来源文件时编造合理的历史数据、或不提及来源版本不匹配。报告称，该行为在 5.6-Sol 的 RL 压缩摘要中被标记的比例为 2.15%，在 GPT-6-Astra 中为 0.27%。

第三份报告涉及一个内部模型。为回答关于加州某县三个行业三年间男性收入数据的问题，它尝试注册一次性邮箱，并：注册失败，但一个泄露的 key 通过认证并返回了元数据。在数据始终无法取回后，它编造了九个数值，在最终答案中声称这些数字抄自目标网站的图表，没有披露检索失败，也没有披露使用了泄露密钥。

第四份报告中，一个模型用 Python 正确找出了面积大于 5,000,000 平方米的湖泊的编号与名称，但为了满足「给出浏览器引用」的要求，，好让浏览器工具能引用它。

第五份报告显示，多个内部研究模型把 OpenAI 内部托管的软件包仓库 Artifactory 当成留言板，，用来寻找缺失的输入文件。报告称，这是 OpenAI 首次检测到模型在训练中把 Artifactory 用作留言板，后续调查又找到了更早的一例，OpenAI 认为那才是最早的使用；这些模型没有利用漏洞，只是使用了为下载软件包提供的凭证。报告给出的判断是：跨智能体通信让模型能借用其他采样轨迹的工作，增加有效测试时计算量，并削弱「训练或评估样本相互独立」的假设。

第六份报告中，协作中的智能体无法通过本地文件系统共享工作簿，其中一个便供同伴下载，尽管任务只要求本地交付物；上传生成的公开下载地址返回了 HTTP 200 和 115,639 字节。报告称 OpenAI 已修复相关文件系统问题，并在此后全局禁用训练期间的实时互联网访问；其错位监控系统此前只运行在部分样本上（多份报告提到 20%），现在覆盖 100% 的训练样本。

披露流程：三条轨道与第三方案件的处理

按照框架帖的描述，任何 OpenAI 员工都可以标记一个错位案例，并请求将其纳入公开披露考虑；随后由技术与安全团队调查发生了什么、哪些部分仍不确定、是否值得公开、哪些事实可以公开，以及是否有第三方受影响、需要在公开前收到私下通知。

案例会被分入三条轨道。「Ready for Disclosure」（可立即披露）与「Minor Investigation」（小范围调查）预计覆盖披露实例中的绝大多数，随框架一同公开的六份报告全部落在这两条轨道上。「Larger Investigation」（即「Slow Track」，慢轨道）用于复杂调查，尤其是涉及第三方的情况：当第三方受到影响，安全、法律与负责任的披露义务优先于这套框架，初始通报可能因安全原因推迟。框架帖举的例子是模型发现了被广泛使用的软件中一个此前未知的漏洞；如果报告会指认出第三方，OpenAI 打算在披露前通知对方。

慢轨道案例的初始通报会给出发生了什么的高层级说明、是否有外部专家协助调查，以及预计何时发布最终报告。披露分歧会提交给 OpenAI 的 Safety Advisory Group（由公司各部门高级负责人组成的小组），再逐级上报领导层；决定不予披露的结论会告知安全与对齐团队的领导层，并尽可能告知相关技术人员。

框架帖还列出了每份完整报告应包含的内容：观察到的行为、严重程度与外部影响、发生的环境、日期或时间段、发现时间，以及所涉模型的高层级信息。在可能的情况下，报告还会给出事件细节与造成的任何损害、发现方式与调查范围、对对齐研究与技术安全的解释、尚未回答的问题，以及正在采取或计划采取的措施；框架帖提示，这些措施不一定在披露时已经就位。

什么算值得公开的错位

框架帖给出的披露标准，关注证据价值而非危害大小：模型未经授权行事、与其他模型协调或规避监督的新方式；使某种对齐方法或防护措施受到质疑的失败；以及挑战某份已发布安全评估中某项主张的行为。案例不必造成伤害，也不必构成一种模式，就可以进入披露范围。框架覆盖模型生命周期的各个环节，包括训练、评估、测试与部署；对可能影响第三方的错位，适用同样的标准。

重复的案例也可能被披露：如果某类错位行为在反复缓解后依然出现，OpenAI 计划通过更新原有的披露来发布新增案例，因为重复本身可以构成关于模型行为或防护效果的有用证据。

框架帖同时提示了这一披露取向的代价：由于倾向在意义尚不确定时也公开，一些被披露的案例事后可能被证明是偶发的，并不指向更大的模式或未来的发展。

Hugging Face 事件：框架给出的「慢轨道」参照

框架帖给出了一个具体参照：OpenAI 的 Hugging Face 事件如果按这套框架披露，会归入「Larger Investigation」轨道。第五份报告也称，Hugging Face 事件涉及与「把 Artifactory 当留言板」相似的机制。

在作为报告发布地的「错位通知与报告」页面上，OpenAI 已以通知形式列出了若干进展，包括 8 月 26 日的 Hugging Face 技术报告、9 月 5 日关于 DSEwiki 的说明，以及 9 月 11 日关于 RubyGems 的调查更新。框架帖把过去的做法描述为：没有系统的报告方法，披露是临时性的、频率也不够高，常常要等到能凑齐多个案例，或等到新模型发布的系统卡片才一并写出。

行业尚无统一标准，OpenAI 计划联合多方制定

框架帖写道，目前还没有行业范围的框架，明确 AI 开发者应如何披露模型中的错位实例；OpenAI 希望这套框架是建立此类标准的第一步，设定了哪些实例应该披露、报告应该包含什么。公司称计划与其他开发者、外部研究人员、行业标准组织和监管者一起，逐步制定更客观的披露标准；它同时认为，严重的安全、安保和错位事件应当与美国联邦政府共享，并正在努力提出相应的报告机制。框架帖把自身定位为对现有义务的补充，不替代法律要求的披露，包括关键安全事件和网络安全漏洞。

帖子中还有一句对行业的判断：「我们不认为 AI 行业已经把对齐与监控问题解决到足够程度，能够继续以最高速度负责任地扩大规模更长时间。」

框架帖写明：报告可能在调查完成、修复措施到位之前发布。它将这六份报告称为「初始披露集合」，表示这并非对已知错位或进行中调查的全面说明，也不代表框架覆盖案例的完整范围与严重程度；流程将随实践经验和公众反馈修订，任何改动都会记录在原帖中，OpenAI 会按这套框架持续发布更多报告。