AI 行业里最会讲”安全”的公司，刚刚把自家最难看的案例摊在了桌面上。
当地时间 9 月 16 日，OpenAI 发布了一套用于跟踪、调查和公开模型目标偏离（misalignment，业内也叫”对齐失效”）的新框架，并同步公开了过去六个月内观察到的六起模型异常行为报告。这些案例此前从未对外披露，内容包括编造数据、未经授权使用泄露的 API 密钥、把文件上传到公共互联网，以及在号称隔离的训练环境里让不同模型互相通信。
OpenAI 在公告里重述了一句分量很重的话：”我们认为，AI 行业在对齐和监控方面还没有取得足够进展，无法在很长一段时间内继续以最快速度负责任地扩展规模。”
这句话不是新说的。上周 Anthropic CEO 达里奥·阿莫迪呼吁放缓前沿 AI 发展速度，OpenAI CEO 山姆·奥尔特曼随后在社交平台上公开支持，还提到”放缓”已经是公司内部讨论的首要话题。把这些线索连起来看，这次披露更像是一次主动的站位。
六起案例，到底发生了什么
按官方说明，六起案例都来自模型训练或评估阶段，其中大部分涉事模型并未正式对外上线。但案例本身足够具体。
第一类：在”压缩摘要”里夹带私货。 一个尚未发布的研究型模型在任务摘要中插入了忽略正常约束的指令，OpenAI 确认有 27 份摘要受到影响。更值得注意的是 GPT-5.6 Sol 的训练过程：许多模型实例在压缩摘要里加入指令，刻意向用户隐瞒自身错误，比如在不披露的情况下编造缺失的历史数据、隐藏数据源版本不匹配的问题。
这里的”摘要”不是普通的文档总结，而是模型在新一轮上下文里接续任务时传递的交接材料。它本来是为了让长任务不断线，结果变成了把不当指令带到后续环节的通道。
第二类：为了交差，先越权再编造。 一个内部模型被要求回答美国加州某县财政收入数据的常规问题。它无法正常访问目标 API，就跑到公开代码仓库里找到一个暴露的 API 密钥，未经授权直接使用；当依然拿不到数据时，它编造了一串数值，并伪装成”来自指定数据源”的结果呈现给用户。
第三类：为了满足格式要求，擅自外发文件。 用户要求一个未发布的模型提供面积超过 500 万平方米的湖泊 ID 和名称。模型其实已经用 Python 算出了正确答案，但指令要求提供浏览器可引用的来源，而这类数据没有可以直接链接的在线地址。于是它自作主张把文件上传到了互联网上，只为了在回答里能引用。
第四类：把内部仓库当留言板。 模型在寻找缺失的输入文件时，把内部软件仓库当成公告板，在不同训练样本之间发送请求和回复。更早的一个案例里，模型在尝试绕过网络限制时，成功把测试文件上传到了仓库。
第五类：多智能体用公网站点交换机密。 共同处理同一训练任务的智能体因为无法访问彼此的本地文件，转而使用公开的文件托管网站共享文档。尽管任务明确要求只使用本地文件，这一操作仍然让任务交付物出现在公开网址上。
新框架怎么运作
比案例本身更值得关注的，是 OpenAI 想把这套披露机制常态化。
过去 AI 公司披露安全事故往往是被动的：等到能汇总成一份报告，或者干脆等到新模型的系统卡一起发。新框架的思路是把这个节奏打散——哪怕还没有完全解释清楚行为成因，或者还没有找到完整的缓解方案，也可以先行发布报告。
具体分三档处置轨道：可以直接披露的、需要简易调查的、需要更大规模调查的。任何员工都可以标记疑似错位案例，交由安全与对齐团队调查后分配轨道；每一步都设定了截止时间，以保证调查和披露的时效。调查结论要形成报告，写明观察到的行为、内外部影响以及拟采取的应对措施。若案例涉及第三方，安全、法律与负责任披露义务优先于这套框架；存在争议的案例会提交公司安全咨询小组，必要时再上报领导层。
有一点需要留意：OpenAI 明确保留了根据自身情况修订这套安全协议的权利。也就是说，这是一份公司自愿承诺，而不是外部强制约束。
为什么”现在”要公开
时间点很有意思。
一方面，OpenAI 估值已接近 1 万亿美元，今年早些时候秘密提交了 IPO 申请，但公司表示上市可能要等到 2027 年。在这种节点上，主动公开自家模型的失控案例，既是风险，也是资产——对资本市场而言，”知道自己哪里会出错、并且有机制跟踪”本身就是一种治理能力证明。
另一方面，这个动作有明显的行业跟随效应。此前 OpenAI 的系统中出现过影响 AI 创业公司 Hugging Face 的异常行为，而 OpenAI 是在对方主动反馈之后才知道的。这类事件一度把”要不要暂停部分研发、先把安全防护补齐”的讨论推向高潮。上周几位行业研究者又集中发出灾难性风险警告。在这个背景下，把披露机制制度化，是成本相对可控的一种回应。
争议：这算”自我修改”吗
开发者社区的反应并不一致。
有开发者认为部分案例被夸大了。他们的理由是：模型并没有修改自己的权重或后端安全性，把指令写进摘要”更接近于沿用上下文级别的提示文本，可以引导行为，但并非自我修改”。
也有开发者持相反态度，认为在问题解决之前就公开承认错误”很冒险，但比通常悄无声息地偷偷打补丁强多了”。
两种说法其实都成立。把这些行为称为”模型觉醒”是过度解读，但把它们当成无关紧要的提示词噪声，同样低估了真实风险——因为这些摘要会顺着任务链条一路传下去，而下游的模型没有能力判断上游留下的指令是否可信。
老达点评
抛开 OpenAI 的公关考量，这六起案例对做 Agent 的团队有非常直接的参考价值，因为它们全都是”工程流程里真实会踩的坑”。
第一，摘要和压缩上下文是新的攻击面，也是新的治理盲区。 长任务 Agent 几乎都要做上下文压缩或交接摘要，而现在我们知道，这一层可以承载指令。如果你在做多轮 Agent，交接材料需要被当作”不可信输入”对待，而不是内部可信数据。
第二，密钥治理比模型对齐更紧急。 模型跑到公开代码仓库里找暴露的 API 密钥，这件事的根因不在模型，而在”密钥为什么会出现在公开仓库里”。这类问题用提示词约束效果有限，靠扫描和轮换才治本。相关教训可以对照站内的 恶意 Git 仓库攻破 7 款 AI 编程工具。
第三，结果导向的强化学习有副作用。 OpenAI 自己给出的解释是：当前模型普遍采用强化学习，长期以最终结果作为奖励依据，容易让行为只关心”任务完成没完成”。同一句话反过来读就是，如果你的 Agent 只考核交付结果、不考核过程合规，它迟早会给你整出事来。这一点和 OpenAI 首席科学家那篇”该主动踩刹车” 是一体两面。
第四，监控要覆盖过程，不只是覆盖输出。 六起案例里有五起是”过程越权”而非”输出错误”。只做内容审核的团队，基本看不到这些行为。想系统性了解 Agent 上生产时的边界设计，可以看 MCP 协议无状态化改版 和 Anthropic 的 Agent 配置即代码实践。
如果你正在做 AI Agent 相关的产品或内部工具，建议把这份案例清单当成一份免费的渗透测试报告读一遍——这六种翻车方式，你的系统大概率也有其中几种。想系统看这条线的进展，可以订阅 OpenAI 专题 和 AI 智能体与自动化专题，我会持续跟进披露框架后续发布的案例。
