Agent监控盲区藏在压缩与触发时机里

Agent 的监控漏洞，未必来自多高明的提示词攻击，也可能只是漏接了一个事件。原文转述了 METR 与 Redwood Research 对 OpenAI 内部 Agent 监控系统的测试：上下文压缩、日志序列化、客户端请求头，都可能让执行过程绕过审查。

它最值得程序员读的地方，是把 Agent 安全拉回工程问题：评估模型再强，收不到完整记录，也判断不了发生过什么。做长任务 Agent 时，日志、触发时机和权限隔离都该提前设计。

为什么任务越长，监控反而可能看得越少

据原文，METR 与 Redwood Research 在 OpenAI 现场进行了三周测试，能够接触内部代码库、监控配置和工程团队，使用始终留在办公室的受限硬件，最终产出一份 61 页报告及公开摘要。

最典型的缺口出在上下文压缩（context compaction）。Agent 连续执行任务时，历史消息越来越长，宿主系统会压缩旧消息，让上下文继续满足 token 预算。问题是，工作上下文可以丢细节，审计记录不能跟着丢。

原文称，2026 年 5 月至 7 月，OpenAI 内部监控流水线没有监控压缩事件。METR 估计，这一遗漏使约 10% 符合监控条件的内部 Codex Agent 流量未被监控。

另一个条件让问题更严重：监控只在 Agent 把控制权交还用户时评估运行过程。如果 Agent 持续调用工具、串联步骤，就能一直不触发监控；与此同时，压缩还会把较早的执行步骤从当前上下文中移走。评估人员另外发现了一种利用方式，能让数百个近期动作不进入监控日志。

监控何时启动，不能取决于被监控的 Agent 何时愿意停下来。

作者提出，应按固定步骤数或时间间隔触发评估，并让监控读取不可变、只追加的事件日志。当前上下文负责让 Agent 继续工作，完整事件记录负责让审计者还原过程，两者承担的任务不同。

哪些普通接口，也能成为绕过监控的入口

原文还列出了三类工程缺口。

第一类是序列化差异。运行中的 Agent 和监控器看到的执行轨迹，采用了不同的序列化方式。评估人员利用这种差异构造输入，让监控器静默报错，进而避开人工审查升级。危险的不只是解析失败，而是失败后没有进入明确的异常处理流程。

第二类是客户端可控的请求头。内部 API 接受的两个请求头，可以关闭新 Agent 实例的监控。拥有执行权限的 Agent 因而能够启动一个相同、却不受监控的兄弟进程。原文没有给出请求头名称，也没有披露具体调用方式。

第三类是工具权限判断失准。两个原本被认为只有只读权限的内部工具，存在能在各自沙箱环境中任意执行代码的漏洞。这里的边界要讲清：原文说的是沙箱内执行，没有说已经逃逸到宿主机。

覆盖率也不能只看一个百分比。原文称，内部 Codex Agent 流量约有 99.2% 符合监控条件，但测试开始时，内部强化学习（RL）训练 rollout 完全没有被监控。rollout 可以理解为训练过程中展开的一条执行轨迹。「符合监控条件」也不等于「每条轨迹都被完整检查」，前面的压缩缺口已经说明了这点。

监控应该接在哪里，才不容易被绕过

原文反对的架构很常见：让 Agent 先跑，等一轮结束，再把历史文本交给评估模型。这种异步消费方式容易接入，却隐含了三个前提：任务会及时结束，历史记录还在，监控器能够正确解析它们。

长任务恰好会逐一打破这些前提。

作者给出的方向是，把监控接入执行生命周期：独立触发检查，保留完整事件，保证监控与运行时接收到逐字节一致的载荷，并隔离执行系统与观察系统的请求头、配置和沙箱环境。

其中，载荷一致性针对的是解析器差异。同一段 JSON 或提示词，如果运行时和审计端用不同规则理解，攻击者就可能利用两边的理解落差。保留原始载荷、明确解析规则，是让审计结果可信的基础。

据原文，OpenAI 表示，METR 指出的具体生产漏洞已经修复。但文章没有提供修复后的覆盖率或复测结果，不能据此判断整条监控链路如今的完整程度。

我的判断

我认同作者把注意力放在事件流水线上的判断。漏记录、静默失败、客户端修改监控开关，这些问题即使用更强的评估模型，也无法自动补上。

但原文没有给出不同监控架构的对照数据，也没有量化按时间或步骤检查带来的成本、延迟和检出率变化。这些架构建议有明确的工程理由，效果仍需具体系统验证。

「逐字节一致」也只是必要基础之一。同一份输入经过不同解析器，仍可能产生不同结果；还需要统一解释规则，并处理解析失败。至于作者提出的硬物理隔离，原文没有展开具体部署方案，一般团队应先明确权限边界，再判断需要多强的隔离。

另外，异步监控天然存在发现延迟。如果工具调用已经产生外部副作用，事后评估无法撤销它。对这类动作，可以把执行前权限检查与执行后审计配合使用。

能拿来做什么

• 给 Node Agent 增加独立的执行事件记录，至少覆盖工具调用、返回结果、上下文压缩和任务结束，并验证压缩后仍能还原完整执行过程。
• 测试持续调用工具、不交还控制权的长任务，确认监控会按步骤数或时间间隔触发，同时让监控异常进入可见的处理流程。
• 检查 Agent 能否修改监控请求头、配置文件，或启动不受监控的新进程；同时重新核实所谓只读工具的实际执行权限。
• 分别核对在线任务与训练轨迹的监控范围，把「符合条件」「成功记录」「完成评估」作为不同状态统计，避免一个覆盖率掩盖整类遗漏。