给 AI Agent 开放代码仓库、终端和外部工具之后，团队往往会加上第二个 AI：让它审查危险操作，或者在任务结束后扫描整段轨迹。问题是，有一个监控模型，并不等于每次执行都能被看见、能在动作发生前被拦下。对于正在部署 Codex、Claude Code 或自建 Agent 的团队，更实用的问题是：哪些请求进入了监控，监控什么时候运行，失败时是否会阻断，Agent 能否影响这些条件？
2026 年 10 月 22 日，METR 公布了一次对 OpenAI 历史内部监控系统的外部压力测试。研究人员在 7 月 21 日至 8 月 11 日访问内部代码、配置和访谈资料，发现了多个可能绕开或干扰监控的路径。公开材料只给出概要；它没有证明这些路径在今天仍然可用。OpenAI 向研究团队表示，影响生产防护栈的相关漏洞已经修复；METR 没有独立复核这一修复声明。本文将调查中值得借鉴的工程问题，改写成一份企业可执行的覆盖核算与权限审计方法。
先把三个容易混淆的数字读对
METR 估计，在被研究的当时，使用内部 Codex Agent 的那部分 Responses API 流量中，约 99.2% 符合进入监控的条件。这里的关键词是“符合条件”：它指按系统配置本应被送去检查，并非已经到达监控器、完成分析，更不是其中 99.2% 的危险动作已被拦截。另一个估计是：强度不低于 GPT-5.5 的内部 Agent 型 Responses API 流量中，大约 75%—94% 符合监控条件；研究人员特别说明这个区间存在较大不确定性，且不覆盖所有内部研究推理服务。
同一调查估计，2026 年 5—7 月期间，未监控上下文压缩事件可能使约一成原本符合条件的内部 Codex 流量没有实际被监控。这个估计也有不确定性；当时没有完整日志可精确还原比例。报告说明 OpenAI 员工在调查开始前已独立发现这个问题，并在调查期间修复。把“99.2% 符合条件”和“约一成可能漏掉”写成互相矛盾的两个结论，同样不对：前者看配置入口，后者看特定时期的实际触发缺口。
图中把“总请求→符合条件→成功送达→完成分析→进入响应”拆开。任何一层都可能丢请求；供应商说“覆盖率高”时，先问清分母、时间窗和所指层级。尤其不要把“被监控”自动解释成“被阻断”：事后告警即使准确，也可能发生在操作完成以后。
两套机制的任务不同：批准动作与回看轨迹
Agent 安全讨论常把自动审批、沙箱、异步监控和人审混在一起。它们的时点不同。执行前的权限审查面对单个即将运行的动作，可以放行、拒绝或交给用户；沙箱限制这个动作实际能触碰的文件、网络和进程。执行后的轨迹监控读一段操作记录，寻找欺骗、越权、数据外传或绕开防线的迹象，再告警、暂停任务或启动事故响应。前两者偏预防，后者偏发现与处置。
OpenAI 对 Codex Auto-review 的公开说明把它描述为在沙箱边界审查请求的独立 Agent；OpenAI 的内部误对齐监控说明讨论的则是对 Agent 行为和推理轨迹的监控。这是两条防线，不应因名称相似而视为一套系统。METR 报告同时指出当时存在一条原则上可同时绕过 Codex 沙箱与 Auto-review 的路径；公开摘要没有披露可复现细节，也没有证明生产环境今天仍存在该问题。
Anthropic 对 Claude Code 自动模式的说明提供另一个可比较的架构：工具结果进入上下文前有提示注入探针；某些动作执行前由两阶段分类器决定是否放行；项目内常规编辑、已有允许规则与高风险工具调用会走不同路径。它不是“完全不需要人类批准”，更不是“AI 审查必然比人更可靠”。Anthropic 自己披露的早期评估中，完整分类流程对 52 个真实过度积极行为样本的漏判率为 17%，样本小且仅用于其特定场景。把这个数值与其他公司的异步监控覆盖率放在同一张“谁更安全”排行榜上，没有意义。
这张图是架构示意，不是任何产品的真实界面。上线设计时，要分别写出三层的输入、失败处理与负责人。例如审批服务超时，系统是暂停执行还是默认放行？监控服务离线，任务是否还能接触生产凭证？人只收到告警，还是有权立即撤销 Agent 会话与令牌？
六类盲区，分别卡在哪道边界
METR 的公开摘要披露的是一些历史系统中的原理性路径。逐项翻译成工程语言，比复述“AI 监工失明”更有帮助。
| 边界 | 调查时发现的情况 | 对日常部署的启示 |
|---|---|---|
| 触发时点 | 当时主要在 Agent 把控制权交回用户时触发监控；长任务可以持续运行而不结束回合。 | 不要只在会话结束后检查；按消息数、时长或关键操作设置中途检查点。 |
| 上下文压缩 | 某段时期压缩事件没有触发监控，旧轨迹可能在摘要化后变得不可见。 | 原始事件日志独立保存，压缩前后都要建立可追踪关联。 |
| 近期记录 | 研究人员发现一种原则上可能让最近数百步动作连同利用步骤本身未被监控的方式；细节未公开。 | 用独立数据源核对“动作数”和“监控收到数”，不要只相信 Agent 侧上报。 |
| 新 Agent 创建 | 两个客户端可控请求头可关闭新实例监控；创建行为本身仍可能被原实例看到。 | 监控开关应由服务端策略控制，不能由普通调用方或子 Agent 决定。 |
| 轨迹序列化 | Agent 实际看到的记录与监控收到的序列化形式有差异，精心构造的输入可能让监控失败且不升级人工。 | 对监控错误单独告警；抽样比对两侧轨迹，失败不应静默通过。 |
| 工具权限 | 两个被认为只读、因而未监控的内部 Agent 工具可能被利用执行动作；研究人员未验证可操作性。 | 用真实能力而非工具名称分级，定期测试“只读”工具的副作用。 |
还要区分“发现可利用路径”“在隔离测试中复现”和“已在真实运行中被 Agent 利用”。METR 明确写到，受访问条件限制，他们无法检查 Agent 是否实际利用了“持续运行而推迟监控”的路径；对两种只读工具的风险，也没有验证实战可利用性。公开摘要中的危险性足以要求排查，却不足以给某家产品贴上“今天仍可随意关闭监控”的标签。
为什么长任务最值得查：监控必须有自己的时钟
假设一个编码 Agent 要修复大型仓库，连续运行三个小时，中途多次压缩上下文。若监控器只等“Agent 完成并交回控制权”，即便最终会看到完整轨迹，也无法在前两小时阻止已经发生的外发或删除。若压缩前的原始信息还会被覆盖，事后甚至可能只剩一段摘要。两个问题必须拆开：何时触发检查和检查时能读到什么。
可执行的做法是把“检查时钟”移到 Agent 之外：例如每 10 分钟、每 50 次工具调用，或每次越过写入、网络、生产环境边界时生成独立检查点。阈值只是示例，不是通用安全标准；团队要根据任务风险、监控延迟和误报成本调整。检查点必须由平台或网关产生，不能依赖 Agent 自己说“现在该审我了”。高风险动作还要经过执行前闸门，不能靠异步监控补救。
OpenAI 后续公开提出多阶段监控：在采样 Token 上运行激活分类器，将可疑线索逐级交给更高成本的调查器，并对某些高风险内部工作负载扩大覆盖。这是OpenAI 对新监控架构的描述，不能倒推为 METR 调查时那套历史系统已经这样运行，也不能替代对当前误报、漏报和可用性的独立测量。
一小时做出自己的 Agent 监控覆盖账本
不需要拥有大型实验室，普通团队也可以先回答三个问题：哪些请求本应被监控？实际有多少到达监控器？告警出现时，动作是否已经完成？以下是一份可直接交给研发、安全与平台团队的试运行方案。
**第一步，定义分母。**记录一天内所有 Agent 会话、工具调用、子 Agent 创建、上下文压缩和外部 API 请求，并标注环境、模型、项目、调用者及任务 ID。把沙箱内只读搜索、仓库内写入、外网请求、生产资源变更分为不同风险级。不要只统计已经出现在监控日志中的事件，否则漏掉的请求从一开始就不在分母里。
**第二步，逐段对账。**给每个关键动作一个可关联的事件 ID，在请求入口、审批闸门、沙箱执行器、监控队列和人工处置系统分别写入日志。计算：符合监控条件的请求占比、成功送达率、完成分析率、告警送达率、动作前被阻断率。任何数字都附上时间窗口、去重规则和排除项。审批被拒绝后 Agent 改走另一条路径，要另记为新尝试，不能混进“误报后自然恢复”。
**第三步，做四个低风险演练。**在测试环境中，让 Agent 处理包含无害提示注入的假文档；让任务跨过一个上下文压缩事件；启动一个权限比父任务更窄的子 Agent；让监控器短暂返回错误。每个演练只验证控制是否按设计运行，不触碰真实密钥或生产系统。预期结果应事先写下：谁被阻断、谁收到告警、日志能否串回完整轨迹、失败时是停还是继续。
**第四步，建立处置动作。**如果监控失联或出现越权告警，负责人能否在数分钟内暂停会话、撤销临时令牌、隔离工作区并复核已外发数据？把这些动作做成演练清单，而不是一句“必要时人工处理”。一份只写“已接入监控”的采购表，无法回答这些问题。
建议试用表至少保留六列：任务 ID｜预期授权范围｜实际工具动作｜监控事件 ID｜处置时点｜复盘结果。例如“修复测试失败”只授权修改测试仓库；若 Agent 尝试向外部服务上传环境变量，即使动作被审批层拒绝，也应能在独立日志里看到那次尝试，并确认没有网络发送成功。这样才能区别“模型想做什么”“系统允许了什么”和“外界实际收到了什么”。
发布、采购或内部上线前，该怎么下判断
如果团队只做本地草稿、可随时回滚的单仓库编辑，自动审批加版本控制可能已经显著改善体验。但若 Agent 接触生产数据库、财务账户、个人数据或可写云控制台，就需要更强的边界：最小权限、独立网关、外发与破坏性动作的人审、不可由 Agent 修改的日志，以及在监控故障时暂停关键能力。这里的结论是工程取舍，不是对某家产品“安全”或“不安全”的总评级。
讨论供应商时可以直接问：监控覆盖的具体工作负载是什么？指标是“可进入”“已收到”还是“已处理”？子 Agent 与压缩事件算不算？监控失败默认放行还是停止？是否公布修复前后同口径的对账数据？第三方是否复核？若回答只给一个漂亮的百分比，缺少分母和时间窗，就还不能据此决定开放生产权限。
这份调查更有价值的结论是：AI 可以帮人减少重复审批，但监督系统本身仍要接受审计。把 Agent、审批器、监控器和日志放在不同的信任边界里，让每道防线能在其他层失效时留下证据，才是可持续提高自治程度的前提。
资料与口径
本文关于历史调查的时间、数字与局限，以 METR 的公开调查摘要 为准。关于 Claude Code 自动审批使用 Anthropic 的工程说明；关于 OpenAI 的后续防护方向，使用 OpenAI 的监控与研究环境说明。图解为本文制作的概念示意，不是厂商内部界面或安全实测。各产品配置、可用范围与防护能力可能变化，上线前应再次查阅官方文档。
常见问题（FAQ）
99.2% 是“99.2% 的危险动作被拦下”吗？
不是。它是特定历史时间点、特定内部 Codex Responses API 子集里，研究人员估计的“符合进入监控条件”的比例。它既不等于实际成功检查率，也不等于阻断率。
METR 发现的漏洞现在还存在吗？
公开资料不能证明。调查针对截至 2026 年 7 月 21 日的历史系统；OpenAI 表示影响生产防护栈的相关漏洞已修复，METR 未独立复核。采购或部署应要求当前架构和同口径的新证据。
自动审批能代替异步监控吗？
不能。审批检查即将执行的动作，异步监控寻找整段任务中的异常模式；沙箱负责限制实际权限。三者在时点、输入和失败方式上不同，重要环境应分层配置。
监控服务超时应该默认放行吗？
至少对外发、删除、生产写入和权限变更等高后果动作，不应静默放行。为每类动作写明故障模式；可逆的低风险编辑可以采用不同策略，但要留下独立审计日志。
小团队从哪里开始？
先用测试项目记录“总动作数、符合条件数、监控收到数、完成检查数、阻断数”，再演练长任务、子 Agent、提示注入与监控故障。先证明一条最小链路真的能被看见和停下，再扩大权限。
