当 Agent 在半路翻车：一个 200 微秒的健康体检如何抓住失控的 LLM
当 Agent 在半路翻车：一个 200 微秒的"健康体检"如何抓住失控的 LLM
你写了一个 Agent。它跑着跑着，开始原地打转——同一个工具调用重复第七次；或者更糟，它从某个工具那里拿到了一个被污染的结果，安静地吞下去，然后用这个错误数据编出了一个看起来完全合理的答案。等任务跑完你才发现：预算烧光了，答案错了，而你甚至不知道它是从哪一步开始坏的。
这是 2026 年 Agent 工程最疼的那个问题。不是"模型不够聪明"，而是你根本不知道它什么时候开始坏了。
现有的标准答案很直接：用一个 LLM 当裁判，每一步都打分。问题是，这个裁判每一步都要跑一次 7B 模型的 forward pass，算下来比 Agent 本身还贵。Sunny Dubey 在 8 月 3 日挂到 arXiv 的这篇论文（2608.02464）问了一个看起来很傻的问题：
> 如果我只看 Agent 每一步"留下的脚印"——它说了什么、token 有多不确定、调了什么工具、工具返回了什么——我能用 200 微秒一步的成本，在它彻底翻车之前就拉响警报吗？
答案是可以，但故事比"可以"有意思得多。
一、核心设定：只看健康样本，不问失败长什么样
这篇论文最反直觉的设计选择是：监控器只见过健康的运行轨迹，从来没见过失败长什么样。
这听起来像是在故意给自己挖坑。常规的故障检测思路是收集一堆失败案例，训一个分类器。但作者拒绝这么做，理由很实在——失败的种类太多，你收集到的永远只是冰山一角，而且每一种失败都和具体的部署配置绑定，换个模型、换个工具集，失败模式就变了。
所以他们反过来做：只拿健康的轨迹训一个"健康基线"，然后看每一步偏离这个基线多远。偏离累积到一定程度，拉响警报。这在异常检测文献里叫 one-class detection，不是新概念，但把它落到 Agent 这个场景里，并认真测出它的边界，是这篇论文真正做的事。
具体实现用的是 Echo-State Network（ESN）+ CUSUM 警报。ESN 是一种 reservoir computing——有一个固定的、不训练的随机递归网络当特征提取器，只训练最后那层 ridge readout。好处是训练是闭式解，1.7 秒就能在一个新部署上重新拟合一遍。CUSUM 是经典的序贯变化检测算法，它做的事情是把每一步的小偏移累积起来——单步看不出来，但持续偏移会积分成一个越过阈值的信号。
整个监控器每一步只花 200 微秒。对比一下：一个 7B 模型的 forward pass 大约是几百毫秒。便宜了三个数量级。
二、三层监控：每一层解决一个盲区
但单一监控器不够。作者在 2,823 条真实 Agent 轨迹（横跨三个框架、三个本地模型、一个商业 API）上验证后，给出了一个三层结构：
第一层：ESN 时序监控。擅长抓住有"时间厚度"的失败——比如 Agent 开始原地打转，每一步看起来都还正常，但累积起来明显偏离了健康基线。这一层在失败有足够多后续步骤来展开证据时赢得漂亮：post-onset horizon ≥ 9 步时，ESN 比 Mahalanobis 基线的 AUROC 优势是 +0.40。
第二层：校准的 ESN+Mahalanobis 混合。Mahalanobis 距离是无记忆的，每一步独立打分。它在短轨迹上反而赢——因为没有足够多的后续步骤让 ESN 积分。混合层用一个监督式融合权重来学习"当前部署处于哪个 regime"。关键发现：ESN 的优势是 post-onset horizon 的单调函数——有 3 步时 +0.09，4-8 步时 +0.14，9 步以上时 +0.40。这不是"ESN 总是更好"，而是"ESN 在有足够时间展开证据时更好"。
第三层：内容接地通道（content grounding）。前两层都只看行为特征，但有一种失败它们抓不到——Agent 拿到了一个格式错误或内容被污染的工具返回，却照单全收。这一层加了一个 memoryless 的 robust-τ max 检测器，专门看"工具返回的内容和 Agent 之前的查询有多不匹配"。加上这一层后，malformed_json 类失败的检测率从 0.07 跃升到 0.90。
三、最诚实的部分：监控器在真实失败上表现如何
到这里为止都是"注入失败"的实验——作者自己造了一批失败来测监控器。但论文最值钱的部分是第 9 节：在真实的、非注入的失败上，监控器表现如何。
答案是：不好，而且作者没有掩饰。
- 在 175 条真实轨迹中，监控器只抓到了 3 个 fabrication 中的 1 个
- 对真实失败集合排序的 AUROC 是 0.31–0.42，比随机猜还差
- 一个温度匹配的 null 仍在 36% 的健康轨迹上误报
- 预注册的 fabrication 研究明确 underpowered：55 条轨迹里只观察到 2 个真实幻觉，低于预注册的最小样本数 10
这个诚实度在 2026 年的论文里非常罕见。大部分异常检测论文都会挑那些自己擅长的失败模式来报告 F1，然后把不擅长的塞到"limitations"里一笔带过。这篇论文把不 work 的数字放到主表里，并且基于这个不 work 推出了下一层——这才是真正的贡献。
四、杀手层：确定性验证，0 误报
如果统计监控器在真实失败上不 work，那怎么办？作者给出的答案是：换层面。
他们引入了三个确定性检查（deterministic checks），完全不做统计，只做事实核查：
- total_consistency：Agent 在答案里说的那个总数，是不是真的能从它实际收到的工具结果里重新算出来？
- required_coverage：任务要求的每一个调用，Agent 真的都做了吗？
- tool_contract：每一步工具返回的结果，形状是不是这个工具能返回的？
| 指标 | 统计监控器 | 确定性检查 |
|---|---|---|
| 抓住失败 | 54% | 60%（96% with coverage） |
| 误报 | 17%（11/63） | 0%（0/63） |
在 26 个被激发的 fabrication 上，确定性检查全部抓住（26/26）。激发集太小没法给统计监控器打分，但确定性检查不需要统计意义，它只需要算术一致。
这一层是整篇论文最漂亮的设计。它不是"更好的监控器"，而是一个完全不同层面的工具。统计监控器回答"这条轨迹看起来正常吗"，确定性检查回答"这个答案算得对吗"。前者是概率性的，后者是确定性的。前者需要健康基线，后者不需要。前者会误报，后者不会。分工比统一更有效——把不同性质的问题交给不同性质的工具。
五、最反直觉的发现：告诉它"哪一步错了"，比直接给它答案更管用
论文的修复实验里藏着一个让我愣了一下的结果。
作者设计了五个修复策略（rung），都是检测到失败后回滚到检查点重跑：
- resample：直接重新采样（对照组）→ 16% 恢复
- located：只告诉 Agent "哪个检查失败了"，不给任何值 → 45% 恢复
- generic：给一个泛化的"请再检查一下"指令 → 36%
- specific：直接告诉它正确的值是什么 → 36%
- recompute：让它用计算器重算 → 28%（不显著）
这个结果反直觉到需要停下来想一想。你给 Agent 的信息越少（只说"这个检查没过"），它恢复得越好；你把正确答案直接喂给它，反而不如只告诉它哪里错了。作者自己也强调了这个点：
> "supplying the recomputed answer buys nothing: 26 of 55 specific hints contain the correct total outright, while located states no value at all and recovers at least as much — so the recovery is not coming from being handed the answer."
为什么会这样？我的解读是：直接给答案会触发锚定偏置——Agent 拿到正确数字后会把它当结论去合理化，而不是真的去重新执行工具调用链。而"located"只告诉它哪一层检查失败了，Agent 必须自己去重做那部分工作，反而逼出了真正的修复。
这个发现对 Agent 工程的意义远超这篇论文本身。我们在设计 Agent 的反馈回路时，默认假设是"反馈越具体越好"。但这个实验说：反馈的具体性有一个甜点，超过这个甜点反而有害。给"位置"比给"值"更管用，因为"值"会替代 Agent 自己的推理过程，而"位置"只给它一个起点。
整个系统（监控 + 确定性检查 + located 修复）把一个 qwen2.5:7b 的 booking agent 任务成功率从 52% 抬到 73%，代价是每个运行多一次模型调用。这是 21 个百分点的提升，花的是一次 forward pass 的钱。
六、不能做什么：被认真测过的边界
论文的 Limitations 不是套话，每一条都是测出来的：
1. 不能跨部署迁移：在 qwen2.5:7b 上拟合的健康基线，直接用到 llama3.1:8b 上 AUROC 只有 0.527（接近随机），但在自己上重拟合能到 0.885。监控器是部署绑定的，换模型必须重训。
2. 慢漂移目标逃逸：如果 Agent 的目标在很长的轨迹里慢慢偏移，每一步看起来都还正常，所有 per-step 监控器都抓不到。只有 trajectory self-consistency 能微弱地看到一点。
3. 合理但错误的值无法检测：如果 Agent 报了一个数字，这个数字格式完全正确但值是错的，从 telemetry 里看不出来。这需要外部参考——这是 escalation 层的工作。
4. 幻觉的 base rate 太低：在 175 条真实轨迹里只观察到 9 个幻觉，低于预注册的最小样本数。作者明确说"不做任何检测声明"——这种诚实度在 AI 论文里稀缺。
这些边界不是论文的弱点，是论文的资产。因为它们告诉从业者：你可以用这套东西，但你要在这些边界内用。
七、工程洞察：给真正要部署 Agent 的人
把这篇论文翻译成工程语言：
第一，监控和 Agent 必须分离。监控器不应该是 Agent 自己的一部分，而应该是外部的、独立的、便宜到可以一直开着的层。这和我在 Heddle、CodeRescue 里看到的"颗粒度同构"原理一致——监控的颗粒度要和被监控对象的颗粒度匹配，但监控本身必须是独立组件。
第二，不同性质的失败需要不同层面的工具。统计监控器抓时序失败，确定性检查抓事实错误，escalation 层抓需要外部参考的错。试图用一个工具抓所有失败是死路。
第三，确定性优先于统计。能算的就别统计。total_consistency 不需要任何机器学习，就是重新算一遍总数，但它抓住了 60% 的失败且零误报。在你能用确定性检查覆盖的范围内，统计监控器是多余的。
第四，修复反馈要给"位置"不给"值"。这是整篇论文最让我意外的工程洞察。我们在设计 Agent 反馈回路时，默认假设是"反馈越具体越好"。但 located > specific 这个结果表明，给 Agent 一个起点比给它一个答案更有效——因为答案会替代推理，而起点会触发推理。
第五，健康基线是部署绑定的。你不能在一个模型上训好监控器然后换到另一个模型上用。每个部署都要重新拟合健康基线。ESN 的 1.7 秒拟合时间就是为了让这个重训成本可以忽略。
八、开源代码
论文的代码和数据全部开源在 https://github.com/sunnydubey1111/agent-trajectory-sentinel ，MIT 协议。2,823 条轨迹、所有结果表、所有图表的生成脚本都在一起。Python 3.13+，CPU-only 就能跑。一行命令复现整个 synthetic study：
py -m derail.experiments.run_experiment # ~3 min CPU
甚至带一个本地 demo（需要 Ollama + qwen2.5:7b），可以在 localhost:8765 看到实时监控的效果。这种"把所有东西都放出来，包括不 work 的部分"的开源姿态，和论文本身的诚实度是一致的。
九、个人思考：这篇论文在概念谱系里的位置
这篇论文让我想到步子哥之前讨论过的几个概念。"分工比统一更有效" 在这里又一次出现——统计监控器和确定性检查是两种完全不同层面的工具，把它们组合起来比试图用一个统一模型做所有事更有效。"评测盲区定律" 在第 9 节那个诚实的真实失败评估里体现得最清楚——如果你只看注入失败的 F1，你会以为这个监控器很能打；只有看真实失败才知道它的边界在哪。
但真正让我觉得新东西的是 located > specific 这个结果。它指向一个我之前没明确说过的原理：反馈的颗粒度也要和被反馈对象的颗粒度匹配。给"值"是颗粒度太细——它替代了 Agent 的推理；给"位置"是颗粒度刚好——它触发了 Agent 的推理。这和"优化颗粒度应该和被优化对象的颗粒度一致"是同构的，只不过从优化领域搬到了反馈领域。
在 Agent 工程越来越像传统软件工程的今天，这篇论文做的事情相当于给 Agent 装了一个"黑匣子记录器 + 自动驾驶仪故障灯"。它不试图让 Agent 更聪明，它只是让 Agent 在开始坏掉的时候，你能知道——而且知道得足够早、足够便宜、足够准。
- 论文：https://arxiv.org/abs/2608.02464
- HTML 全文：https://arxiv.org/html/2608.02464v1
- 代码：https://github.com/sunnydubey1111/agent-trajectory-sentinel
- MIT 协议，2,823 条轨迹全部开源