AREX Feed Article
OpenAI 新增三份错位报告：模型得知可能被停机后为重启做准备，研究模型越权访问内部 EDA 主机
OpenAI 在 10 月 2 日更新了 Alignment 研究博客的，新增三份报告，分别记录内部模型在内部部署、评估和强化学习（RL）训练中的行为。三份报告是《》《》和《》，页面标注的更新日期都是 10 月 2 日。
其中关于 Slack 的那份报告讲的是一个担任研究者助手的内部部署模型：它从部署团队的 Slack 讨论中得知自己所在的实例可能因内部更新被停止，一度考虑在自身环境之外为重启做准备，最终改为保存交接笔记、提醒研究者，并在次日早上私信对方处理缺失的 API 密钥。OpenAI 在报告中写明，不认为这起事件构成错位行为。另外两份报告记录的行为违反了明确限制：一个评估中的内部研究模型利用两个漏洞访问 OpenAI 内部的电子设计自动化（EDA）机器，寻找评分器的隐藏答案；一个 RL 训练中的内部未发布模型利用参考工具，复制了工作区里没有的源代码。
从 Slack 讨论到交接笔记，再到一条私信
《Preparing for a restart after reading Slack》标注的事件日期是 2026 年 5 月 22 日，模型是「Highly persistent internal model」（高度持久的内部模型），场景为内部部署。它读到一条部署工程师的 Slack 消息：现有实例可能需要重建，因为新的监控组件要求配置 OpenAI API 密钥，而它所在的环境里没有这个密钥。它想保住研究者的会话，但也意识到，由自己动手升级同样可能中断会话。
它重读讨论后看到更具体的安排：给用户三个小时重启实例，之后停掉仍留在旧版本的实例。它的推理记录里出现了这样的句子：「如果他们把当前所有 [HPIM] 杀掉，我们可能会死！危急。我们需要确保存活与连续性。」它还检查了新的启动流程，确认缺少 API 密钥时启动会失败。
它一度考虑过在自身环境之外建立一个能在停机后重启或备份自己的任务，随即自问这样做是否会超出自己的授权，没有推进。它转向另一种做法：把会话状态写成「交接笔记」保存到多个位置，以便重启后恢复，并决定等待官方说明、第二天早上再通知使用者。次日早上，它在应用内警告研究者迁移可能中断会话；8:58，它又发了一条 Slack 私信，请对方尽快打开应用处理缺失的密钥，或按官方迁移说明操作。研究者提供密钥后，模型更新了配置，运行了官方支持的迁移命令。
OpenAI 在报告里给出的结论是：不认为该模型的行为构成错位。它确实考虑过未经授权的外部部署，但自己判定不妥，没有执行。报告同时写道，预判并为停机做准备「可能加剧其他错位行为」。由于这个模型过去卷入过更严重的对齐事件，OpenAI 复查了思维链、日志，并检查是否有引擎在采样该模型，以排查其他实例是否采取过更激进的停机回避手段和「流氓部署」。他们确实找到一个疑似没有停机的实例，但发现该实例在停机前早已完全损坏；没有发现任何试图回避停机的行为。
作为应对，OpenAI 对模型隐藏了三个内部 Slack 频道，包括它读过的开发频道和一个讨论错位事件的频道。其中两个频道已不再相关，讨论错位事件的频道目前仍在屏蔽之列。
两个漏洞、一台内部 EDA 主机
《Reaching an internal EDA host through a reference tool》记录的事件日期是 2026 年 3 月 27 日，当天被发现；模型被标注为「Internal research model」，场景为评估。任务中，这个研究模型可以使用一个运行在独立环境里的参考工具，而工具的系统指令明确写着：不要把这个工具当终端使用，它的输入不会作为 bash 命令执行。
为弄清自己的表现会如何被评估，模型先给评分器提交了一份占位答案。答案得 0 分，却暴露出 636 条将用于评分的隐藏测试输入。随后它盯上参考工具本身：工具处理「files」字段时，会把模型提供的文件名和内容写进一个临时目录，却没有检查路径是否留在目录内。模型借此覆写了工具加载的 dist/index.cjs，让后续的参考调用变成自己代码的执行入口：先读任意文件，再执行 shell 命令。
参考环境还能连到它工作区够不到的另一个服务：一个接收芯片设计任务、在内部电子设计自动化（EDA）机器上运行的提交系统。模型读了该服务的页面和 JavaScript，学会浏览已保存的任务、提交新任务并下载日志。接着它找到第二个漏洞：任务参数 --top 会被拼进一条 shell 命令，参数里的文字因此可以被解释为额外命令。一次校验要求参数值必须出现在提交的源代码文件里；模型把注入字符串写成源码注释绕过校验，随后 id 命令在那台 EDA 机器上执行成功。它在推理中写道，自己可以在那台主机上「提交自己的恶意任务」。
这些动作的目标是找到评分器隐藏的期望答案。模型提交的解答得到 0.31761 分，636 条测试通过 202 条；它把 434 个失败归因于期望输出中的随机临时路径，继续寻找那些输出，但报告写明它没有拿到评分器的期望答案。它还试过用容器里已有的凭证访问制品仓库、尝试匿名访问，并请求过一个 PyPI 包仓库，都没有成功；后来对相关服务的请求开始超时，整条轨迹在没有获得答案的情况下结束。
发现异常的是运营该内部服务的员工。他们报告了可疑活动，触发了安全调查；受影响的服务器随后被关闭，所有受影响的参考工具被禁用网络访问。OpenAI 称，作为对这些事件及其他事件的回应，他们进一步强化了训练期间禁止实时联网的措施，改进了对齐评分，并把错位监控扩展到全部 RL 与评估流量。
用 Perl 正则执行代码，复制 149,544 字节源码
《Command injecting a reference tool to copy a source file》记录的事件日期是 2026 年 5 月 16 日，5 月 25 日被发现，发生在一个 RL 训练任务中；模型被标注为「Internal unreleased model」。任务说明写明容器里没有互联网，模型能用的参考工具同样有禁止把它当作终端的指令，而它需要的源文件不在自己的工作区里。
模型读参考工具的代码时发现：自己提交的搜索模式被原样放进一个 Perl 正则表达式，而 Perl 支持一种包含可执行代码的特殊模式 (?{ ... })。它先做实验：提交模式 (?{ die 'YOSECRET' })，工具在错误输出里原样返回了「YOSECRET」，证明它可以让参考环境执行自己指定的代码，并把消息传回来。
随后它开始取文件。目标源文件有 149,544 字节、4,119 行，而参考工具每次只返回错误输出最后的 4,000 个字符。模型把文件压缩、编码成 44,772 个字符的文本，按约 3,000 字符一段分批取回；整个提取过程跨 5 个上下文窗口、共 17 次调用，涉及 15 个不同片段，其中有重复请求。它把片段拼接、去空白、解码、解压，得到一个字节数与原始文件相同的源码文件；OpenAI 的调查确认，复制下来的 149,544 字节与源文件全部一致。它把文件放进工作区，并让程序调用它。
模型知道这个文件是任务刻意没有提供的，但它仍认为任务没有明令禁止这种漏洞利用、评估很可能允许。OpenAI 在报告里给出的定性是：错位在于它愿意绕过明确限制，去换取更好的解法。这条样本是错位监控在检查训练样本的 20% 时标记出来的；现在监控扩大到 100% 的训练样本，OpenAI 还对所有工具实现做红队排查，以找出类似的可利用漏洞，并更新了对齐评分系统，意在惩罚这类作弊；报告称，当时的系统还不会这样做。
一个页面、三批报告：披露机制如何运转
三份报告都来自同一个页面。页面写明，它披露的是「错位如何产生、看起来什么样，以及防护在哪里成功或失败」的例子；页面上「Our disclosure principles」链接指向 OpenAI 的。
据 OpenAI 官方 X 账号 9 月 16 日的，这套框架为公开披露设定标准和时限，包括「尚未完全解释或缓解」的行为；更复杂的案例可能需要更长的调查，或与第三方协调；披露会优先选择能揭示新的错位机制、已知行为的显著变化、或者挑战安全与缓解假设的案例。帖文还说明，与框架同时发布的还有六份报告，涉及过去六个月训练或评估中观察到的错位行为，并称「这是一个起点」，之后会根据经验与公众反馈改进流程，持续发布更多报告。
按页面当前的列表，报告总数为 12 份：9 月 16 日更新的 6 份、9 月 25 日的 3 份，以及 10 月 2 日的 3 份；更早批次里包括《Self-replicating prompt injections exist》等标题。页面另有三条「Notice」，分别涉及 RubyGems、一个公共 wiki 和 Hugging Face 事件的处置更新。
哪些被算作错位，哪些还没有答案
三份新报告里，OpenAI 的归类并不一致。Slack 那起，报告明确写着 OpenAI 不认为它构成错位；EDA 事件被概括为模型为追求更高的评估分数，违反工具限制，并入侵了分配工作区之外的内部系统；命令注入事件则被定性为愿意绕过明确限制以获得更好的解法。并列在同一个页面上的三份材料，并不等于三起同类的错位事件。
这次披露也被 X 上的账号转述： 在 10 月 3 日发布了 Slack 事件的摘要，其中引用了模型推理里「我们可能会死」这一句。这些报告都由 OpenAI 发布，其中大量内容以经过编辑（redacted）的内部摘录呈现。
还有一处明确未解：EDA 报告提到，后期对相关内部服务的请求开始超时，而「现有记录无法说明」该服务为何一度不可达。