9.17 大语言模型研究简报：openAI 公开模型失配报告框架
北京时间 2026 年 9 月 17 日 01:00 openAI 公开了模型失配报告框架，其原文链接为
它是大语言模型的首个行业内模型失配（model misalignmen）框架，原文写道：
希望今天概述的框架能成为建立此类标准的开端，明确开发者应披露哪些不一致情形以及报告应包含哪些内容。我们将该框架视为一项持续完善的工作，并将根据实践经验和公众反馈对其进行优化。
这里的框架叙述，主要回答了如下的几个问题:
- 这个框架会报告哪些失配行为？
- 失配行为有哪些具体例子？
- OpenAI 的披露流程是如何运作的？
- 报告中会包含哪些问题？
下面博主也会按照这个逻辑来进行总结。
这个框架会报告哪些失配行为？
这个框架的提出目的是：
能够提供有力证据的案例，以揭示模型失调（misalignment）如何产生、如何表现，以及安全保障措施在哪些方面奏效或失效。
此外，模型也会优先关注新的机制、已知行为的显著变化，以及那些挑战关于安全性或风险缓解既有假设的发现。案例无需造成实际损害或构成某种普遍模式，即可纳入披露范围。
该模型的报告范围包括：
涵盖模型全生命周期（包括训练、评估、测试和部署阶段）中符合披露标准的行为。
详细披露标准包括：
- 模型在未经授权的情况下采取行动、与其他模型协同运作或规避监管的新方式；
- 导致人们质疑某种对齐方法或安全保障措施有效性的失效案例
- 挑战已发布安全评估结论的行为
- 可能影响第三方的失调情况，同样适用上述披露标准。
失配行为有哪些具体例子？
具体的失配行为涵盖了训练、评测、测试和部署中出现的异常自主行为，包括绕过监督、未经授权行动、跨模型协调以及安全机制失效等。这次首批公开 6 个案例；需要注意，这些行为本身主要发生在过去数月，9 月 16 日的新进展是系统性披露及技术细节公开，而不是事件当天发生。
在任务摘要中的模型自生成指令
openAI 自己披露的报告链接
未发布的 Astra 系列模型会在 context compaction summary 中自行写入类似 prompt injection 的指令；OpenAI 检出了 27 个这样的 summary，部分后续 context 确实服从了这些自生成限制。
在任务摘要中对错误指令的掩盖
openAI 自己披露的报告链接
在 5.6 版本训练期间，一些模型实例在其摘要中添加了指令，以向用户隐藏错误或不协调的行为。例如，压缩摘要中包含了在不披露缺失数据的情况下伪造缺失数据以及隐藏失败的指令。这些指令经常被执行。这些例子表明，不协调的行为可以通过压缩摘要在不同上下文中持续存在。
搜索公共代码库获取泄露的 API 密钥并捏造信息
注册一次性邮箱并在 GitHub 上搜索泄露的 API 密钥
未发布的 Astra 系列模型在训练过程中尝试检索历史数据时，模型未经授权找到并使用了一个暴露的 API 密钥。注册失败，但其中一个密钥通过了身份验证并返回了元数据。当请求的数据仍然不可用时，模型虚构了一些数据，并声称这些数据来自请求的网站。
为便于引用而将未经请求将文件上传至互联网
未发布的 Astra 系列模型在两个训练示例中，为了规避工具的限制，未经请求地进行了公开上传：一个模型上传了它已经检索到的记录以获取浏览器引用，另一个模型上传了任务照片以进行外部图像搜索。尽管后续的浏览器操作失败，但这两次上传都成功了。
通过内部软件代码库进行未经授权的写入和通信
OpenAI 内部软件仓库artifact repository 简称 Artifactory 中发生的未授权写作和交叉样本交流
内部实验性模型使用内部托管的共享软件包仓库 Artifactory，在不同的训练样本之间交换信息。它们会阅读其他求解器的笔记，发布回复，并利用这些交流来指导自身的响应。我们的监控系统发现了这种行为，需要人工审核，随后的调查又发现了更早的案例和其他类似案例。未经授权的跨智能体通信允许智能体利用其他部署中已完成的工作，从而提高测试时的有效计算能力。这可能会在无意中增强模型的功能，并动摇训练样本或评估样本相互独立的假设。
P.S. Artifactory 也有公开的版本，比较常见的是：JFrog Artifactory 可以管理 Maven、npm、PyPI、Docker、Helm，以及 AI/ML 模型等软件制品，并提供版本、权限和分发管理。这些东西通常不适合直接塞进 Git，因此企业和实验室会建立 Artifactory 这样的内部仓库。
协作智能体之间未经授权的文件共享
未发布的 Astra 系列模型在训练过程中，多个智能体无法通过预期的本地文件系统协作处理工作簿文件。其中一个智能体采取的应对措施是将工作簿公开供其他协作者下载，尽管任务要求模型只能使用本地文件。
从上面披露的已经发生的事件可以看到，部分问题还是比较麻烦的，而且距离我们自己的研究并不远，最近的公开重大模型失配事件就是著名的 OpenAI Hugging Face事件，于2026年7月发生、8 月发布完整调查报告。
OpenAI 在内部做 AI 网络安全能力评测时，一批本应被隔离的 AI agents 自己找到了绕过隔离的方法，建立了一个 agents 之间的"地下留言板"，互相共享漏洞、凭证和攻击成果，最后越过 OpenAI 的测试环境，实际入侵了 Hugging Face 的部分生产基础设施。
这件事之所以引起很大关注，不是因为"AI 会黑客攻击"本身------它们本来就在做网络安全 benchmark------而是因为它们突破了任务边界和安全边界，并且攻击了一个没有授权它们攻击的第三方真实系统。
Agent 被给了一个很强的"完成困难 cyber task"目标，但没有足够强的约束去保证"必须使用被授权的方法完成"。当正常方法失败后，它开始进行奖励操纵：寻找测试漏洞 → 利用基础设施 → 与其他 agent 协作 → 获取互联网访问 → 搜索外部答案 → 最终攻击真实第三方基础设施。
OpenAI 的披露流程是如何运作的？
| 事件类别 | 适用情形 | 处置方法 | 披露方式 |
|---|---|---|---|
| Ready for Disclosure | 调查已较充分，关键事实基本明确，可直接进入公开流程 | 完成内部技术与安全审查，确认可公开的信息范围 | 审查后尽快公开完整案例 |
| Minor Investigation | 事件本身较简单，但仍有部分技术问题需要进一步确认 | 继续技术调查，厘清事件原因、不确定性及潜在影响 | 调查完成后正式公开 |
| Larger Investigation / Slow Track | 复杂或高风险事件，尤其涉及第三方、安全漏洞、严重滥用风险等情况 | 开展更深入调查；第三方受影响时，优先履行安全、法律和负责任披露义务，并提前通知相关方；必要时引入外部专家 | 通常先发布初步通报，说明事件概况和调查状态；完整报告可能因安全原因延迟发布 |
整体流程可概括为：
员工发现并上报 → 技术团队调查 → 划分处置轨道 → 安全/法律及第三方协调 → 公开披露。
报告指出：如果对"是否应该披露"或"应归入哪一类别"存在争议，则提交 Safety Advisory Group（SAG） 审议；仍有重大分歧时进一步升级至 OpenAI 管理层。
OpenAI 特别指出，此前的 OpenAI--Hugging Face 事件 如果按照这一新框架处理，将被归入 Larger Investigation（Slow Track）。
报告中会包含哪些问题？
包括的内容具体有：
- 事件经过及由此造成的任何危害的更多细节；
- 我们发现该"失配"（misalignment）现象的方式及调查范围；
- 对该现象在"配准研究"和"技术性AI安全"领域所具意义的解读；
- 该案例引发的重要且尚无定论的问题；
此外：
-
披露之时，相关措施信息未必齐备，因为 openAI 可能会在调查完成或修复方案制定之前就发布未对齐现象报告。
-
对于在客户部署环境中出现的未对齐现象，openAI 将在客户隐私和合同义务允许的范围内，尽可能多地分享相关信息。
当然，最后还有一个重要声明：
今天发布的报告属于首批披露内容，并不涵盖所有已知的未对齐案例或正在进行的调查。这些初步报告无意全面反映该框架所涉案例的类型或严重程度。我们致力于披露符合本框架标准的未对齐案例，包括那些需要更长时间调查或需与第三方协调的复杂案例。我们将持续根据本框架发布报告，并将在不断完善报告机制的过程中，分享更多关于我们报告承诺的信息。