一个监控模型能识别危险行为，前提是它确实看到了那段行为。METR 与 Redwood Research 对 OpenAI 内部 Agent 监控的评估，把注意力从判别器本身移到整条监控链：哪些推理流量进入范围，什么事件触发检查，轨迹如何送达，以及告警后谁负责处理。这是 AgentOps 可靠性的一次具体工程剖面。

原文：Red-Teaming OpenAI’s Internal Agent Monitoring Systems · David Rein、Adam Kaufman / METR · 2026-10-22

高权限访问，看的是历史系统

两名外部研究者在 7 月 21 日至 8 月 11 日开展三周驻场试点，获得内部代码、监控提示与配置、文档访问，并访谈约十二位研究和工程人员。产出是一份 61 页内部报告；公开文章只是约定发布的高层摘要。它评估的是 7 月 21 日及此前的系统，没有覆盖当时正在进行的扩展。

这决定了数字应如何使用。报告适合说明真实监控基础设施可能在哪些交接点失效，却不能回答今天所有内部 Agent 有多少受到监控。文章同时说明，OpenAI 后来表示影响生产防护栈的已发现漏洞均已修复；METR 没有重新评估这些修复和后续覆盖变更。历史发现与当前状态需要分别陈述。

“有资格被监控”不是“完整检查过”

研究者估计，当时至少 GPT-5.5 能力级别模型的内部 Agentic Responses API 流量，约 75%–94% 符合监控条件，且区间两端都存在较大不确定性。内部 Codex Agent 对应子集中，符合条件的比例估计为 99.2%。这些分母不同，不能用后一数字替代全部内部推理。

“符合条件”指按设计应送入监控，后续仍可能遇到触发遗漏、实现错误、限流或执行失败。其他内部研究推理服务的流量也不包含在该估算中。报告另称试点开始时 RL 训练运行未被这套系统覆盖，尽管研究者被告知此前 3 月至 6 月有部分 rollout 接受过监控。评估对象的边界本身就是主要发现之一。

工程上可以把覆盖拆成几道关：产生了多少执行、其中多少应监控、多少触发请求、多少送达完整轨迹、多少成功判定并进入处置。即使最后一道模型判断准确，前面漏掉的执行也不会自动补回来。这样的分层记账比一个总覆盖百分比更容易定位责任和故障。

压缩事件与结束回合触发之间的空隙

报告估计，5 月至 7 月未监控上下文压缩事件，使符合监控条件的内部 Codex 流量中约一成没有受到监控。这个比例不确定，因为历史日志缺少确定精确占比所需的信息。OpenAI 在试点开始前已独立发现此问题，并在试点期间修复。

当时监控在 Agent 将控制权交回用户时触发。如果压缩不触发检查，持续调用工具而不结束回合就可能长期推迟检查。这里的失效发生在事件调度：每次动作都看似被允许继续，监控却一直等不到它依赖的边界。按每若干消息或若干分钟检查，是报告提出的设计方向；具体间隔仍要权衡延迟、成本和可接受的未审查窗口。

这也解释了为什么服务本身健康不等于覆盖完整。研究者看到的信息显示，监控请求错误率低于 0.2%，试点中的一个 24 小时窗口没有 load shedding。这两个数字只描述已经进入相应链路的请求，无法否定触发之前的盲区。

轨迹表示和控制权限也属于监控面

公开发现还包括可在原理上绕过沙箱与自动审批的路径、影响近期动作可见性的漏洞、Agent 与监控器所见序列化差异，以及可由客户端控制的绕过监控入口。报告对部分细节做了删减，也明确区分已验证行为与未实际验证的可能性；因此应把它读成防御面检查，不能把每个条目都说成已发生的生产利用。

其中可迁移的教训是表示一致性。工具结果、历史消息、压缩摘要与监控请求之间若使用不同编码或删减规则，同一个执行可能在两边呈现不同语义。只证明“传了完整文本”还不够，还要检查角色、来源和顺序是否保留。报告称除少数例外，监控器能看到 Agent 所见的完整轨迹，这是一项正面观察，但并未消除具体表示漏洞。

监控闭环的下一层要求

报告建议交叉核对推理日志与监控日志，保留易检索且抗篡改的记录，明确事件响应负责人，定期红队，并隔离 Agent 执行环境与监控控制面。它们共同指向一个目标：被检查的执行不应轻易改变自己何时受检、提供什么证据或是否留下记录。

公开原文没有适合解释机制的配图，本篇以触发、送达和响应三条关系展开。对于运维团队，最有价值的后续问题是：长时间运行的 Agent 是否有独立于回合结束的检查节奏，压缩前后的动作能否对账，监控失败是阻断、重试还是静默放行。公开摘要不能估计实际恶意行为发生率，却已经说明，监控可靠性必须作为分布式工程系统来验证，不能仅依赖一个判别模型的能力成绩。

用对账解释为什么平均数会骗人

设想一个长任务经过多次工具调用、一次上下文压缩，最后才返回用户。若只按最终回合计数，它可能只对应一次监控；若按推理请求计数，分母又会大得多；若按真正产生外部影响的动作计数，关注的风险窗口还会改变。这是指标定义的例子，不是报告中额外测得的数据。比较覆盖数字之前，必须先问清它在数请求、消息、轨迹还是动作。

这种差异也影响告警响应。异步监控即使随后成功识别问题，相关动作也可能已经完成。降低检测延迟、限制动作能力和可靠保存证据各解决不同问题：前者缩短未发现窗口，中者约束影响范围，后者支持追查。公开报告没有提供从异常动作到人工处理的完整延迟分布，因此不能仅凭低请求错误率判断事故能否及时止损。

报告还提醒，外部研究访问深度与公开透明度不是同一回事。这次允许深入代码和配置，因而能发现只看外部行为难以定位的缺陷；公开披露却受到事先约定和删减条件限制。读者能得到工程问题的类别与部分量化线索，无法据此重建内部系统全部实现或独立验证每一项修复。对后续评估，更有价值的是持续明确评估版本、流量分母与修复后的再检查结果。