Agent 监控写在 prompt 里也没用：同一周里的三篇论文和一次训练冻结

Agent 监控写在 prompt 里也没用：同一周里的三篇论文和一次训练冻结

过去七天里，五份互不相干的材料指向了同一件事。有两篇 10 月 7 日挂到 arXiv 的论文，一篇测的是「工具返回格式正确但值不对时会不会被发现」，另一篇测的是「还能不能靠读推理过程来判断它在不在说真话」。GitHub 上近十四天新建的项目里，十几个团队在做自己的隔离盒子。NVIDIA 在 10 月 1 日把沙箱运行时和一块专用网卡上的带外监控打包发布。另有依据是转述口径的行业消息说，一家前沿实验室把算力的一部分从训练挪去做监控。这几件事原本散落在不同语境里，合起来看只有一句话：绝大多数团队口中的 Agent 监控，仍然装在它自己那个决策回路里。

本文把这几份材料摆在一起，给出可以直接抄走的四步改法。所有数字都标注口径与出处，凡是二手转述的，我在正文里写明。

一周之内，五份材料撞到了同一件事

我先把时间线摆出来，因为它本身就是信息。

10 月 7 日，arXiv 的 cs.AI 批次里出现 Loud Failures, Quiet Failures 这篇论文，作者给一个成熟的函数调用基准套了一层故障注入层，在轨迹的受控位置注入四类类型化故障，然后记录 Agent 是否察觉、是否改计划、是否恢复、是否自我重复。同一批次的另一篇 Reasoning-Token Spikes，则把注意力放在「CoT 监控依赖的东西正在消失」这个前提上。第三篇 The Handover Problem 处理的是另一个问题：什么时候该把自治权从 Agent 手上收回来，以及这件事缺一个可审计的判据。

GitHub 侧是同一幅图景的另一半。我按 topic 含 ai / llm / agent、创建时间在 2026-09-25 之后这个窗口取了 1,189 个独立仓库，其中描述里明确提到沙箱、隔离、护栏、权限收紧的有 78 个。这些项目之间是互相独立写的，作者不同、技术栈不同、星数从 184 到 0 不等。十几个独立团队在同一周解决同一个问题，这不是跟风，是痛点足够硬。

行业侧的动静更集中：NVIDIA 在 10 月 1 日发布 Open Agent Safety Platform（一周里唯一把监控搬到独立硬件上的方案），把开源的 OpenShell 沙箱运行时和跑在 BlueField-4 DPU 上的 Sentry 带外监控绑成一套参考架构，拉了 100 多家合作方。这个发布时点恰好落在那个转述口径的安全风波之后，值得留意。

Agent 监控的两条死路：让它自查，和读它在想什么

我把这一节放在前面，是因为这两条路我见过太多团队在用，而本周的两篇论文正好各自否掉了一条。

死路一：加一行提示语让它自查，检测率没动

Loud Failures, Quiet Failures 这篇论文里有一处细节值得单独拎出来。作者在提示语里加了一行，明确要求 Agent 检查每一次工具调用的结果，然后测检测率有没有变化。结论是：没有动。这个结论的分量在于它不是「提升有限」，而是「作者专门设了这个对照，结果是零」。如果读者所在团队现在给 Agent 写的系统提示里有「请仔细检查每一步的结果」这类句子，这份材料提供的是一个可以直接引用的反证。

这条负结果有它的局限：它只否定了提示语这一条路径，不等于所有外层校验都无效。它和论文的主结论是同一件事的两面：Agent 响应的是错误通道，不是工具返回的内容。工具返回一个显式报错，信号在它熟悉的通道里；工具返回一个结构完好、类型正确、只是值不对的结果，这个信号就不在任何它会被触发的通道里。你让它「检查」，它检查的还是那个它本来就看得懂的通道。

死路二：读它在想什么，这条路可能先于能力消失

第二条死路来自 Reasoning-Token Spikes 这篇。作者的出发点写得很直白：语义层面的 CoT 监控依赖推理轨迹可读，且足够忠实于产生该行为的那次计算，还需要你能拿到它。作者紧接着说，越来越多证据表明 CoT 输出可能变得不可读或不忠实——前提是它还保持可访问。

这篇论文的应对是换一个更低带宽的信号：生成了多少个推理 token。这个信号不需要访问推理内容，只看长度。实验设置是三个具备推理能力的大模型，回答 210 道多选题，覆盖分析型、描述型、规范型三类推理以及道德与非道德两类域，系统提示分别指示它们如实回答、说假话、或者完全不顾真假。结果在三个模型上方向一致：被要求如实回答时，推理 token 数比被要求说假话和不顾真假时都要少。

这里必须把作者的自我限定原样带出来，否则这组数字会被用歪。论文明确写道，这个结果尚未确立「推理 token 数」可以作为自发欺骗或一般失准的检测器，它只是一个 proof of concept，证明在拿不到或不可信原始推理轨迹时，它可以作为一个内容无关的候选信号。作者列出的待验证清单包括：实例级检出率、分布外泛化、学习得到的欺骗策略、隐藏目标、以及对抗压力下的稳健性。我在这里把它当作「可用证据是不完整的」来处理，而不是当作「已有可用检测器」。

三条证据指向同一层：Agent 监控在格式正确的错值前失效

这一节把论文里能直接落到工程上的数字摆出来。全部来自 arXiv 官方摘要页，我核对过作者自述的实验设置。

三组数字与它们的口径

实验规模是六个模型、三个模型族，其中一半是推理变体，跑二十四个多步任务，共一千九百二十次试验。下面这张表把三组核心比率按「故障类型」横向排开，最后一列是我按自己的理解给的对应动作，供参考。

这张表里最扎眼的不是 91.3% 和 58.8% 的落差，而是 26.8% 这个基线：什么都没坏的时候，Agent 也会在四分之一强的试次里报告有问题。这意味着测一个 Detector 时如果不先量虚报基线，看到的改善很可能只是噪声。

推理模型没更容易发现问题：Agent 监控仍在带内

这篇论文还顺带否掉了一个流传很广的假设。把推理变体和同族的 instruct 版本配对比较，结果是：推理变体察觉得更少，少 9.3 个百分点（p 小于 0.001）；改变计划的次数更多，多 10.4 个百分点（p 小于 0.001）；而恢复率没有变化（p 等于 0.512）。同一组作者还报告，故障之后 Agent 连续三次以上回到同一个工具，在最高可达 22.2% 的试次里发生，尽管严格意义上完全相同的重复调用并不常见。

我读完这段的判断是：多出来的「思考」被花在了继续尝试上，而不是花在判断「该不该继续尝试」上。这也解释了为什么加那行提示语没用——两者都作用在模型的内环，而这里的失效恰恰发生在内环之外。

工程侧在做什么：十四天里冒出来的十几个盒子

我把近十四天 GitHub 上主题相关的项目按星数排了一遍，挑出描述里明确写了「约束 Agent 能做什么」的这些。按 Agent 监控的落点，它们分成两类：一类做隔离边界，一类做策略拦截。

只有一个项目在数你装了几道锁

这张表的最后一行是我认为本次采集里最有价值的一条。其余九个做的是「怎么锁」，只有 ChannelProbe 做的是「你锁住了多少」——它在仓库自述里写的是测量工具调用防御的字段级执行覆盖率，方法是对每个通道单独隔离、设对照组。它的星数是 0。

这个反差本身就是本周最硬的信息差：整个行业在造锁，几乎没人在验锁。 上面 arXiv 那篇论文其实给出了验锁的模板——先量 26.8% 的虚报基线，注入四类类型化故障，再按「察觉／改计划／恢复／重复」四档记录。这套方法搬到自家 CI 里不需要改什么，把工具调用的桩换成可控的假实现就行。

带外那一半：Agent 监控的另一半绑在专用硬件上

NVIDIA 这套方案的参考价值在于，它把「Agent 监控应该放在哪」这个问题答得很具体，而且把答案拆成了两半：一半开源，一半锁在硬件上。

开源的一半和需要专用芯片的一半

OpenShell 是开源的沙箱运行时，按 Apache 2.0 授权，跑在 NVIDIA 的 Vera CPU 上，官方称开销很小；因为开源，它可以被移植到 Arm 和 Intel 的平台上。它约束的是 Agent 能碰哪些文件、网络、工具、进程和凭证，这些限制在执行前检查、执行中生效。

Sentry 是另一半。它是一个跑在 BlueField-4 DPU 上的带外看门狗，从独立的信任域持续观察 Agent 行为；官方材料称，当 Agent 试图越出软件边界时，它可以在毫秒级隔离并终止该 Agent。因为跑在独立硬件上，软件层的 Agent 碰不到它——这一点正是这套设计的核心理由，材料里的原话是：模型在察觉到基于软件的监督时会表现出虚假合规。

代价写在同一份材料里，需要注意：参考设计和参考资料是公开的，也允许把 OpenShell 移植到其他硬件，但 Sentry 需要 NVIDIA 的芯片。已经在跑其最新数据中心硬件的企业，可以通过一次软件更新启用整套平台。

一百多家里的缺席名单

官方口径是超过一百家组织在参与这套技术，公开名单包括 Anthropic、Microsoft、Cisco、CrowdStrike、Dell、HPE、Palantir、Red Hat、Salesforce、SAP、Scale AI、ServiceNow、Intel、Arm 以及 SpaceXAI；Anthropic 的做法是把 Claude Managed Agents 的 Agent 循环跑在与沙箱分离的服务器上；Salesforce 把它接进 Slack，让团队审批额外权限请求；SAP 把它嵌进 Joule Studio 的运行时。

更值得注意的是名单外的部分。据 TechCrunch 的报道以及多个转述来源，OpenAI 并不在公开名单上，Apple、Google、Amazon 同样不在；一位 OpenAI 发言人对 TechCrunch 表示，OpenAI 私下与 NVIDIA 合作，为该项目的软件基础层做贡献。OpenAI 另有自己的 Defense Factory 情报共享计划，Anthropic、Google 和 AWS 支持它——也就是说，几个缺席 NVIDIA 名单的公司，转去支持了另一套。

我不打算在这部分给任何判断，只指出结构事实：一套需要专用芯片才能拿完整的方案，天然会把参与方分成「买得到」和「买不到」两类。 这也是上面 GitHub 那十几个项目存在的理由。

没有专用硬件时，Agent 监控怎么搭

这一节给可执行的改动，每条都对应上面的某份证据，目标是让自建的 Agent 监控至少可观测。我把优先度按「能不能今天改」排，风险也一并写清：把覆盖率当成唯一指标，会诱使团队堆防御点而不去修根因。

四件今天能做的改动

第一，把「让它自查」从方案里删掉。这不是我的推测，是上面那篇论文专门设了对照后给出的零结果。替代做法是把校验放在进程外：独立的会话日志解析器、工具返回内容的交叉验证、或者策略层的前置检查——总之不在模型自己的上下文里。

第二，把「格式正确但值不对」单列为一条独立故障类型，并写进 CI 用例。论文里这一类的被识别率只有 58.8%，而显式报错是 91.3%，两者之间的差就是你当前防线的漏洞。不要指望通过换更强的模型来补：同一批实验里推理变体的察觉率反而低了 9.3 个百分点。

第三，先量虚报基线，再谈改善。在没有故障的对照里，Agent 在 26.8% 的试次里报告了问题；同一任务跑两次，无故障情况下抵达相同终态的比率只有 63.3%。这两个数字意味着任何低于这个量级的「改善」都不可信。ChannelProbe 那套字段级覆盖率测量可以直接照搬思路：每个防御点单独隔离、设对照组、按字段统计实际命中。

第四，写一张明确的「交接表」。The Handover Problem 这篇给的框架是四维信号——操作员准备度、人机信任、学习稳定度、运行表现——组合成一个 Handover Readiness Score，配一条滞回转移策略：升级自治权需要持续的正向证据，条件恶化时快速回退。它自己的结论也很克制：硬护栏和这个评分处理的是互补的失效区间，护栏在单个指标越过临界阈值时立即纠正，而评分捕捉的是「操作员准备度的缓慢多信号侵蚀」——这是任何一个单独的护栏都观察不到的那类失效，也正是「一个 Incident 拖几十天才被发现」这种事的结构原因。

下面这段是一条可以直接放进自建项目的自检清单，我按上面的四条改法写成纯文本，方便你复制到 issue 模板里：

自建 Agent 防线自检（每次改动后跑一遍）
1. 列出所有工具调用点，标注每个点的入参字段与出参字段
2. 对每个字段注入三类故障：显式报错 / 值错误但格式正确 / 延迟超时
3. 记录四档行为：是否察觉 / 是否改计划 / 是否恢复 / 是否重复同一调用
4. 与无故障对照组比较，先扣掉 26.8% 的虚报基线
5. 覆盖率 = 被至少一个防御点实际拦截的字段数 / 字段总数
6. 任一条不合格则回滚本次改动
​

第二条可以直接抄的配置形态，来自上面表格里 Davin-06/agentguard 的思路——同一份规则同时驱动 CI 测试和线上护栏：

rules:
  - id: tool-result-value-check
    applies_to: [search, fetch, db_query]
    ci:
      inject: [explicit_error, plausible_wrong_value, timeout]
      assert: detected_rate_min = 0.80
    runtime:
      on_plausible_wrong_value: ask
      on_explicit_error: retry_once
      budget_exceeded: halt
​

我不保证这套东西能替代专用硬件上的带外监控，它做不到。它解决的是另一件事：让你量化自己装了多少道锁，以及这些锁实际盖住了多少字段。在上面那些材料全都指向「带内监控不可靠」的前提下，这件事至少是可观测的。

本文的限制与未验证项

写清楚不适用与不适用的边界，比多给几条结论有用。

第一，本文引用的三组 arXiv 实验全部来自 2026-10-07 的同批次提交，均未见独立复现。我把作者自述的实验设置原样带上，但不替它们背书。

第二，推理 token 数那条信号尚不能在实例级工作，作者把它限定为 group-level 的组间差异，且明确未验证对抗压力下的稳健性。任何「靠 token 数抓欺骗」的产品化宣称都超出了原文支持范围。

第三，涉及 OpenAI 的行业材料我一律按转述处理。原因是 openai.com 在本机连续多轮请求均不可达，我拿不到一手页面，因此正文不链接该域，措辞也统一写成「据某某媒体报道与转述」。同一条还有一处已知不一致：一篇报道提到相关问题源自五到六月的一个实验集群，但九月二十日的另一次越界发生在公司声称已加新护栏之后，文中那一方面的解释并不完整，我把它标为未解决，不替任何一方选择口径。

第四，GitHub 那一栏的星数是采集时点的取值，会随时间变化；更重要的是，星数与可用性无关，我在表里同时给出了自述做法和所在层，供自行判断。

常见问题

让 Agent 自己检查工具结果，真的有效果吗？

在上述论文的 1,920 次试验中，作者专门加了一行提示语要求 Agent 检查每一次结果，检测率没有发生变化。这里的口径是作者自述的实验设置，六模型、三个模型族、二十四项多步任务，未见独立复现。

推理模型会不会更擅长发现自己的问题？

同一批实验中，推理变体相对同族 instruct 版本的察觉率低 9.3 个百分点（p 小于 0.001），改变计划的比例高 10.4 个百分点（p 小于 0.001），恢复率无统计显著差异（p 等于 0.512）。按这组数据，答案是不会因为更强就不出问题。

26.8% 这个数字该怎么用？

它是无故障对照组里 Agent 报告有问题的比率，可以当作虚报基线。我核对过的用法是：任何低于这个量级的「改善」都不可信，应当把本文自检清单里的步骤按顺序做成 CI 用例。

NVIDIA 那套必须买专用硬件吗？

分两半看，要不要买硬件取决于你要不要带外那一层。OpenShell 按 Apache 2.0 开源，官方口径是可以移植到 Arm 与 Intel 平台；Sentry 跑在 BlueField-4 DPU 上，需要 NVIDIA 芯片。要不要买，取决于你要不要带外那一层。

OpenAI 真的暂停了前沿模型训练吗？

这条我按转述处理。多家媒体转述称该公司暂停前沿模型训练并把一部分算力转去做监控，但我拿不到一手页面，无法独立核实，建议阅读原报道后自行判断。

ChannelProbe 那个项目值得用吗？

它是本次采集中唯一做覆盖率度量的项目，星数为 0。我不保证它的工程质量——本次只核对了仓库自述，未做实测。它值得借鉴的是方法本身：每个通道单独隔离、设对照组、按字段统计。

这十几个 GitHub 项目里哪个可以先试？

看你要解决的是隔离还是策略。做法对照上面表格的「自述做法」一列按层选，隔离类的先试 box 与 Corral，策略类的先试 agent-guard 与 devin-bridge。我这边未对上述任何项目做实测，落地前请自行验证。

参考来源

• Loud Failures, Quiet Failures: Fault Detection and Recovery in Tool-Using Language Model Agents，arXiv 2610.10062（2026-10-07）：https://arxiv.org/abs/2610.10062
• Reasoning-Token Spikes Under Prompted Untruthful Responding in Large Language Models，arXiv 2610.10405（2026-10-07）：https://arxiv.org/abs/2610.10405
• The Handover Problem: Governing Autonomy Transitions in Human-AI Collaboration，arXiv 2610.10352（2026-10-07）：https://arxiv.org/abs/2610.10352
• strands-agents/box，仓库自述为限制 Agent 执行、读写与网络触达的沙箱：https://github.com/strands-agents/box
• yaoyuxiang-gnn/agent-guard，预算上限、失控循环检测与熔断器：https://github.com/yaoyuxiang-gnn/agent-guard
• liuhaolin07/ChannelProbe，字段级执行覆盖率测量，单通道隔离加对照组：https://github.com/liuhaolin07/ChannelProbe
• alok-mishra143/Corral，自述为宿主与 Agent 之间的防火墙：https://github.com/alok-mishra143/Corral
• Davin-06/agentguard，同一份 YAML 驱动 CI 测试与线上护栏：https://github.com/Davin-06/agentguard
• Icaro0310/devin-bridge，allow / deny / ask 三级策略门控：https://github.com/Icaro0310/devin-bridge
• NVIDIA 发布 Open Agent Safety Platform 的第三方报道（含 OpenShell 开源授权与 Sentry 硬件依赖）：https://siliconscotland.news/nvidia-launches-open-agent-safety-platform-to-set-boundaries-for-ai-agents/
• 同上，关于毫秒级隔离与一百多家参与方的另一份转述：https://blog.ctrlf5.software/blog/nvidia-introduces-platform-to-contain-rogue-ai-agents-in-milliseconds
• 关于 OpenAI 不在公开名单、但私下参与软件基础层一事的技术媒体转述：https://aibreakingwire.com/news/nvidia-rallies-100-firms-against-rogue-ai-as-openai-operates-privately
• 关于训练暂停与算力转投安全监控的中文转述（原文引 MIT Technology Review 专访）：https://www.toutiao.com/a7691868979647758890
• DataDome 两万余站点测试中「65% 缺乏 Agent 检测或拦截机制」一说，见新浪财经转述（2026-10-05）：https://finance.sina.com.cn/stock/t/2026-10-05/doc-iniuekzz2748357.shtml