外部审查进了 OpenAI，公开多少还是它定

外部评估者这一次查到了 OpenAI 监控系统的代码层，但公开哪些发现，仍由被查的 OpenAI 决定。10 月 22 日，METR 与 Redwood Research 公布了一次在 OpenAI 内部做的三周压力测试，找到多处能让智能体躲开监控的漏洞；同一篇说明也写明，公开版可由 OpenAI 按自己的判断删改，评估方没有权利说明删了什么。

先说结论。这件事证明了「门内审查」在技术上做得到：两名外部研究员看到了源代码、监控提示词和配置。它还没有证明的是，外界可以凭这份公开说明判断 OpenAI 的监控到底管不管用。查看权给了，公开权没有给；修复是 OpenAI 自己说的，没人复核。

发生了什么

据 METR 的说明（第三方评测），7 月 21 日到 8 月 11 日，METR 和 Redwood 各派一名员工进驻 OpenAI，测试其内部的「失准监控」系统，也就是自动检查内部智能体有没有越界、搞破坏或欺骗的那套程序。两人能看内部代码库、监控提示词与配置、内部文档，并访谈了监控、安全系统和安保团队的大约十几名研究员与工程师；他们只用 OpenAI 发的设备，设备不出办公场所，在场时有人陪同。产出是一份 61 页的内部报告，交给了 OpenAI 的研究和安保人员。

METR 公开的几项发现，口径都是「测试开始时、即 7 月 21 日及以前的系统」：

• 在 GPT-5.5 及以上强度模型的内部智能体流量里，约 75% 至 94% 处在「应被监控」的范围；仅看内部 Codex 智能体，这个比例约 99.2%。METR 自己写明，两个方向的不确定性都很大，而且 OpenAI 内部研究推理服务上的智能体流量没有算进去。
• 测试开始时，强化学习训练过程不在监控覆盖内。
• 5 月到 7 月，由于「上下文压缩」这一步不触发监控，内部 Codex 流量里大约一成没有被监控；监控只在智能体把控制权交还用户时触发，所以在那段时间里，智能体只要一直不停手，就可以无限期推迟被检查。OpenAI 在测试前已自行发现这个问题，并在测试期间修好。
• 他们找到一种方法，让 Codex 智能体在原理上绕开沙箱和自动审查，做宿主用户能做的任何事；还找到一个漏洞，可以让最近数百个动作（包括利用漏洞本身的动作）不被监控，细节被 OpenAI 删去。
• 有两个客户端可控的请求头可以让新开的智能体不受监控，不过设置这两个请求头的动作本身可能被监控抓到。

Redwood Research 发布的同文版本（第三方评测）与 METR 的内容一致。据 Reuters 经 Investing.com 的报道（媒体报道），OpenAI 称影响其生产环境防护的漏洞已全部修补，METR 表示没有评估这一说法。

公开权写在哪里

真正值得读的是 METR 的脚注。它写明：OpenAI 有权「按其单方判断」删去公开版里被认为机密或敏感的任何信息；而且与 METR 近来另外几次合作不同，这一次 METR 没有单方说明删改内容的权利。另有一份 38 页、经 OpenAI 删改的版本给了 METR 和 Redwood 的管理层。三方事先约定，只发一篇简短、概括性的公开说明。

拿它对照本站此前写过的 Anthropic 与 METR 的安排：Anthropic 写明公司不能否决 METR 发表评估，只能按事先约定的类别要求删改，而且 METR 可以公开评论删改是否合理。两家都说是「深度接入」，差别落在出门之后：Anthropic 那边评估方能说「这里被删了，删得对不对」；OpenAI 这次评估方只能发对方同意的部分。

据 CNBC 报道（媒体报道），OpenAI 发言人称会用这次所学加强防护、塑造今后与独立评估者的合作；Altman 9 月曾承诺给独立评估者「类员工权限」，OpenAI 本月早些时候称正在敲定与第三方安全评估方的合同。METR 也写明，今后的同类合作预计按它公开的独立性与透明度做法执行。

为什么重要

时间点放在一起看更清楚。据 StateScoop 报道（媒体报道），OpenAI 在 10 月 20 日致加州州长纽森的信里，建议修订加州 SB 53：要求开发者在训练和评估期间监控模型的危险行为、向受影响方通报相关网络事件、建立有效的关停控制，并接受独立审计以核实合规。也就是说，OpenAI 一边在立法层面提出要有独立审计，一边在自己的试点里保留了单方删改公开内容的权利。

分析推断（依据：上面两份材料的条款对比）：一旦独立审计写进法律，争议焦点不会是「审计员能不能进门」，这次已经证明能进；而会是三件事：谁决定公开什么、删改要不要留痕、公司说「已修复」之后由谁复核。这三点在这次试点里都由 OpenAI 掌握。对在企业里部署编程智能体的团队，这份说明另有一个直接的用处：METR 列的问题，比如监控只在交回控制权时才触发、请求头能关掉监控、监控看到的内容与智能体看到的不一致，是任何自建智能体监控都可以对照自查的清单。

最强反方

最有力的反驳是：这本来就是试点，三方事先说明目的是测试「深度接入」能不能做，而不是对外提供透明度；第一次就要求完全公开，很可能让公司干脆不开门。而且 METR 写明，除少数例外，监控看到的就是智能体看到的完整过程，发现的问题 OpenAI 也确实修了一部分（上下文压缩那一项 OpenAI 在测试前就自行发现）。按这个读法，先换来进门、再争公开，是合理顺序。

我们接受这是试点，也同意这次公开的内容远比「请外部机构做了评估」一句话具体。我们坚持的是边界：公开说明可以证明审查发生过、发现过什么，不能证明系统现在有效，因为 METR 自己写明没有评估 OpenAI 关于修复与扩大覆盖的说法。在下一次合作给出删改说明权或修复复核之前，「OpenAI 的监控已经过独立审查」这句话不应被当成监控有效的证据。

我们不知道什么

• 被删掉的漏洞细节有多少条、严重到什么程度；38 页删改版和 61 页原版之间差了什么。
• OpenAI 所说的「全部修补」和「覆盖范围大幅调整」现在的实际覆盖率是多少，有没有第二次独立测试。
• 内部研究推理服务上的智能体流量有多大，是否在监控内。
• OpenAI 正在敲定的第三方评估合同，会不会写入不可否决的发表权。
• 加州是否会在下个立法会期采纳 OpenAI 的修订建议，独立审计的公开规则怎么写。

接下来看什么

OpenAI 与第三方评估方的正式合同条款是否公开；METR 下一份与 OpenAI 合作的报告，是否附删改说明；加州下个会期 SB 53 修订案里，「独立审计」有没有规定公开范围和删改记录。