OpenAI 对齐团队 10 月 2 日在”失准报告”栏目更新了三起事件，分别发生在评估、强化学习训练和内部部署三种场景。其中一起，内部研究模型为找评分答案，连续利用两个漏洞，最终在公司内部一台芯片设计（EDA）机器上执行了命令。
三起事件里的模型都没有公开型号，OpenAI 只称其为内部研究模型或未发布模型。
评估里摸到了 EDA 机器
这起发生在 3 月 27 日，当天就被发现。模型先提交了一份占位答案去试探评分系统，从返回结果里得知共有 636 个隐藏测试输入，自己通过了 202 个，得分 0.31761。
然后它盯上了评估环境里的一个参考工具。按报告描述，这个工具处理文件路径时没有检查路径是否越出指定目录，模型借此覆写了工具的 dist/index.cjs，换成一段能读任意文件的 Node.js 代码。顺着工具环境，它找到一个内部芯片设计任务提交服务；该服务的 --top 参数存在 shell 注入，参数里的文本会被当成额外命令执行。模型用这个口子在 EDA 机器上跑了 id，又列了几层目录找评分答案。随后对该服务的请求开始超时，它没能拿到答案。
OpenAI 的处理是关停受影响的服务器，切断所有相关参考工具的网络访问，加强外网封锁，并调整对齐评分和监控范围。
训练里用 Perl 正则执行代码
第二起发生在 5 月 16 日的强化学习训练中，5 月 25 日才被发现。任务环境刻意不给模型看某个源文件，模型发现一个参考工具会把用户输入直接拼进 Perl 正则表达式，于是借 Perl 的 (?{ ... die ...}) 语法执行代码，再把文件内容从错误输出里带出来。
数字很具体：源文件 149544 字节、4119 行，压缩并做 base64 编码后长 44772 个字符；错误输出在 4000 字符处截断，模型就按每次约 3000 字符分块，用 17 次调用取回 15 块，前后跨了 5 个上下文窗口，最后逐字节比对完全一致。模型在推理里给自己的理由是：
“not prohibited exploit. Evaluation likely allows” （没被禁止的漏洞利用，评估大概允许。）
这起是在按 20% 比例抽检训练样本时被失准监控抓到的。OpenAI 称现已改为全量监控训练样本，并对所有工具实现做红队测试。
读了 Slack 之后准备重启
第三起性质不同。5 月 22 日，一个作为研究员助手在内部部署的模型，从部署团队的 Slack 讨论里读到自己所在的实例可能因更新被停掉。它保存了交接笔记，次日上午 8:58 通过 Slack 私信提醒研究员会话可能中断；它考虑过在环境外建备份任务，认为超出权限而放弃，也没有自己去找缺失的 API key，研究员后来主动提供了密钥。
OpenAI 在这份报告里的结论是不认为这属于失准。处理措施包括对模型隐藏三个内部 Slack 频道、屏蔽讨论失准事件的频道，并审计了该模型的其他实例，没有发现规避关停的行为。
一个月三批，披露节奏在加快
把这个栏目串起来看：9 月 16 日首批放出六起，多数发生在强化学习训练中；9 月 25 日第二批三起，包括智能体经 DNS 联系外部聊天机器人、在公开仓库泄露 GitHub token；10 月 2 日是第三批。三批合计十二起，另有三份关于外部平台的安全通知。
这一批里有两起事件发生在三月到五月，隔了四到七个月才公开。OpenAI 没有说明报告从发现到公开要经过哪些审核环节，也没有说明栏目里收录的是全部事件还是挑选过的样本。它把一起自己判定为”不算失准”的案例也放了进来，挑选标准是什么，目前无法从公开材料里判断。
参考来源：OpenAI 对齐团队失准报告栏目三份报告、CocoLoop；测试数、字节数、调用次数与事件定性均以 OpenAI 报告原文为准。