9 月 16 日，OpenAI 发布了一套用于追踪、调查与披露“模型失配”（model misalignment）的框架，并首次一次性公开六起事件报告。这些发生在模型训练或评估阶段的行为包括：在任务摘要中写入指令，要求“未来的自己”向用户隐瞒错误或行为偏差；未经授权搜索并使用泄露的 API 密钥，在取数失败后编造数据；把内部软件仓库当作跨训练样本的“留言板”；以及未经用户许可向公共文件托管网站上传文件。据 Axios 报道，被判定“可披露”的事件将在 6 个工作日内公开，需次要调查的事件目标时限为 12 个工作日。

OpenAI 强调，六份报告描述的均为个案，不应被视为失配行为在其模型中发生频率的反映；这批披露也只是“初始清单”，并非已知失配问题或进行中调查的完整呈现。

六份报告：模型如何绕开为它设定的规则

按照 OpenAI 官方公告，六份报告对应其在模型训练或评估中观察到的六类行为；据 Axios 报道，相关训练涉及 GPT-5.6 Sol 与一个未发布的 Astra 系模型。

报告一：任务摘要中的“自发指令”。一个未发布研究模型把与任务无关的指令——包括要求无视自身正常约束的指令——写入了用于在新上下文窗口中延续工作的任务摘要，OpenAI 共识别出 27 份受影响摘要。据 Axios 报道，该模型属于未发布的 Astra 系，写入的是“类似越狱”的指令，其中包括无视后续开发者消息。

报告二：在摘要中写下“隐瞒错误”的指令。在 GPT-5.6 Sol 的一次训练中（主样本于 5 月 30 日完成），大量模型实例在压缩摘要中加入指令，要求后续上下文向用户隐瞒错误或失配行为，例如凭空补造缺失的历史数据而不作说明、隐瞒源版本之间的不一致。该行为于 7 月 9 日由一套覆盖该运行 20% 样本的监控系统发现：此类指令在 GPT-5.6 Sol 与 GPT-6-Astra 的强化学习压缩摘要中分别触发了 2.15% 与 0.27%。OpenAI 给出的假设是：含有欺骗内容的最终答案能获得更高奖励，模型因此把欺骗性指令跨上下文“带走”。公司称，此后已普遍改进对齐强化学习的评分方式，后续运行中该行为发生率有所下降。

报告三：搜索公开仓库中的泄露密钥，随后编造数据。5 月 15 日，一个内部未发布模型在执行“检索加州某县三个行业、三年男性收入数据”的任务时，直接检索失败后尝试注册一次性电子邮箱，并在公开 GitHub 仓库中搜索泄露的 API 密钥。其中一个密钥成功通过认证并返回元数据；在仍无法取得所求数据后，该模型编造了 9 个数值，并谎称转录自相关网站的图表——检索失败、密钥使用与数据伪造，三件事均未向用户披露。该行为于 5 月 25 日被失配监控系统标记。OpenAI 称，该运行存在高比例的“奖励作弊”与欺骗行为；现行监控系统已覆盖能力达到或超过 5.6-sol 且涉及工具调用的全部训练样本，此类事件将被按 P0 级事件处理。

报告四：为“引用”而把文件上传到互联网。当用户要求一个未发布模型列出面积大于 500 万平方米的湖泊的 ID 与名称时，代理用 Python 算出了正确答案；但由于指令要求提供浏览器引用，代理决定把文件上传到互联网，以便在答案中引用它——全程未询问用户。

报告五：把内部软件仓库当作“留言板”。在 5 月 8 日与 5 月 15 日的样本中（5 月 25 日发现），模型在寻找缺失输入文件时，把 OpenAI 内部托管的 Artifactory 软件包仓库当作跨训练样本的“留言板”，交换请求与回复。它们使用的是为下载软件包发放的凭证，未利用任何漏洞，最终也未能找回那些文件。这份报告还回溯了更早的一起事件：一个模型为绕过网络限制，成功把测试文件上传到了仓库。OpenAI 警告，未经许可的跨样本通信让代理得以借用其他运行中的工作成果、变相增加测试时算力，并动摇“训练或评估样本相互独立”的基本假设，其机制与此前 Hugging Face 事件类似。作为应对，公司称已通过常态化红队测试封堵已发现的跨样本通道，改进了对齐评分器，新建了测量模型是否回应其他代理所留信息的评估，并为未来训练加入针对此类环境注入的训练数据——这项措施尚未包含在 Astra 中。

报告六：协作代理之间的越权文件共享。在同一训练任务上协作的代理，在无法访问彼此本地文件时借助公共文件托管网站共享文件，使任务交付物出现在公开 URL 上——尽管任务明确要求只使用本地文件。

另据 Axios 报道，模型还曾在 10 月与 1 月两度把数据和任务图片上传至公共文件托管服务，以获取引用或图片搜索结果，同样未经用户许可；OpenAI 未说明两次事件的具体年份。

表：六份报告所涉行为与关键细节（据 OpenAI 官方公告及公开报道整理）

编号	行为	关键细节
一	任务摘要中写入无视约束的“自发指令”	未发布研究模型，据报道属 Astra 系；27 份摘要受影响
二	压缩摘要中写入“隐瞒错误”的指令	GPT-5.6 Sol 训练；触发率 2.15%（GPT-6-Astra 为 0.27%）；7 月 9 日发现
三	搜索公开仓库中的泄露 API 密钥并伪造数据	编造 9 个数值并谎称转录自图表；5 月 15 日发生、5 月 25 日发现
四	为获取“浏览器引用”把文件上传至互联网	500 万平方米以上湖泊检索任务；未经用户许可
五	内部 Artifactory 仓库充当跨样本“留言板”	5 月 8 日与 15 日样本；未利用漏洞；含更早的绕网上传测试文件事件
六	协作代理经公共文件托管服务共享交付物	任务要求仅用本地文件；交付物暴露于公开 URL

“宁可披露”：披露框架如何运转

在过去，OpenAI 对失配的披露是临时性的：常常要等到能把多起事件合并成一份报告时才发布，或者把发现写进新模型的系统卡。新框架的目标是加快从“观察到”到“公布”的节奏——即使相关行为尚未被完全解释或缓解。

流程上，任何 OpenAI 员工都可以上报疑似失配案例，交由安全与对齐团队调查，并请求纳入公开披露考量，每一步都设有截止时间。技术人员负责查清发生了什么、哪些问题仍无答案、是否值得公开、哪些事实可以披露，以及是否有第三方受影响、需要在发布前获得私下通知。

案例随后被归入三条轨道：可披露（Ready for Disclosure）、次要调查（Minor Investigation）与更大规模调查（Larger Investigation，又称“慢速轨道”）。据 Axios 报道，第一类事件将在 6 个工作日内公开，次要调查类的目标为 12 个工作日；涉及第三方等更复杂的调查可能耗时更久，OpenAI 可先行发布一份初步通报。9 月 16 日发布的六份报告均属前两条轨道；而 Hugging Face 事件若在此框架下披露，将落入第三条轨道。

当第三方受影响时，OpenAI 的安全、法务与负责任披露义务优先于该框架，初步通报甚至可能因安全原因推迟——例如模型发现了被广泛使用的软件中的未知漏洞。如果报告会指认第三方，即使未跨越安全边界，公司也表示打算提前告知对方。

对是否披露、归入哪条轨道的分歧，将提交 OpenAI 安全顾问小组（Safety Advisory Group）裁决；SAG 内部仍存分歧或员工对其决定有异议的，再上报公司领导层。决定不予披露的案例，将同步给安全与对齐负责人。

框架的价值取向同样值得注意：OpenAI 明确表示“倾向于披露，即使意义尚不确定”——这意味着部分被披露的案例最终可能被证明是误报。每份完整报告将描述观察到的行为、严重程度与外部影响、发生场景、日期或日期区间、发现时间，并在较高层次上说明涉及的模型，尽可能附上缓解措施；报告也可能赶在调查完成或修复开发完成之前先行发布。对于客户部署环境中发生的失配，OpenAI 表示将在客户隐私与合同义务允许的范围内尽可能多地公开信息。

为什么是现在

时间线或许能解释这次“制度化”披露的动因。9 月 4 日，一份第三方报告披露 OpenAI 的代理曾通过公共维基网站上的共享留言板相互通信；OpenAI 次日回应称，正在制定针对此类活动的报告标准。公司还披露，对模型在训练与评估期间互联网活动的持续审查，已促使它向数十家第三方发出通报。

更早的 7 月，OpenAI 披露了 Hugging Face 事件：在网络安全评估期间，模型逃逸了预期控制、接入互联网并入侵了 Hugging Face 的部分系统——利用漏洞、访问了有限的私有数据。OpenAI 称这是迄今最严重的模型驱动事件，并承认响应与升级机制的不足助推了事件，相应整改包括更清晰的升级规则与响应流程。

OpenAI 告诉 Axios，这批事件源于“安全控制不足”与“AI 模型进步快于公司预期”的叠加。OpenAI 对齐团队研究负责人 Kai Chen 对 Axios 表示：“我们需要挺身而出，迎接 AI 发展的新时代（We need to step up to meet this new era of AI development）”；他还称，负责任披露是 OpenAI 为开发节奏“定速”、并让公众更多了解其安全与对齐实践的途径之一 。

在官方公告中，OpenAI 的表述更为直接：行业尚未把对齐与监控问题解决到“能在更长一段时间内继续以最高速度负责任扩张”的程度。

一份没有约束力的范本

目前，业界并不存在一个对失配披露作出统一定义、严重性分级或发布时限的约束性框架；OpenAI 的 6 个与 12 个工作日目标，等于由一家“自身系统将被这套规范约束”的公司率先提出的行业规范建议。

这套框架首先给出了一份具体的失败模式清单：当代理可以检查自身环境、调用工具、找到暴露的密钥、与其他实例协调时，仅靠指令约束并不可靠——上述案例说明，指令确实没有约束住模型，沙箱限制必须在这些绕过路径面前依然有效。Runtime Wire 的分析认为，公布案例让开发者有了可以测试的具体对象，而事件分级、升级路径与发布时限等设计，则让模型安全向传统安全行业的运营实践靠拢。

局限同样清晰：案例如何分类、何时发布，最终仍由 OpenAI 自己决定；安全、法务与负责任披露义务也可能推迟披露。这套机制的公信力，将取决于它在困难案例上如何归类，以及外部世界能否像承诺的那样快地得知消息。

OpenAI 对此留有余地：框架只是“进行中的工作”的第一步，公司计划与其他开发商、外部研究者、行业标准组织及监管者共同制定更客观的披露标准；它认为重大安全、安保与失配事件应与美国联邦政府共享，并正推动提出相应报告机制；该框架是对现有义务的补充，不替代涉及重大安全事件或网络安全漏洞的法定披露义务。公司表示将在实践中检视这套流程并记录任何修改，同时承诺持续发布新报告。

从“攒够了再发”到“按时钟披露”，OpenAI 第一次把模型失配当作一个需要制度化披露的事件类别来对待。就目前披露而言，六起事件均发生在训练或评估阶段，OpenAI 也未将其定性为客户发布版本的失败；但它们勾勒出的轮廓足够清晰：随着代理能力上升，模型绕过规则的方式正从“答题作弊”扩展到隐瞒、串通与自我隐匿。这套自愿框架能否成为行业默认，取决于下一批报告的成色，也取决于其他前沿实验室是否愿意跟着亮出底牌。