OnTrack：用最优传输实时监控LLM Agent轨迹

LLM Agent 正在从旅行规划、股票交易延伸到 IT 故障分诊等高风险场景。问题在于，大多数 Agent 以近乎完全自主的方式运行，规则式保护措施少得可怜。一旦执行了不可逆操作，成本和安全隐患就同时出现。过去两类主流做法各有软肋：一类引入守护 Agent 逐步监督，代价是每一步都增加开销与延迟；另一类做事后日志评估，等它给出结论时，token 已经烧掉、损失已经发生。

OnTrack 的核心思路：把 Agent 轨迹当成结构来比对

这篇论文提出的 OnTrack 走的是第三条路：流式监控。它不额外召唤一个 LLM 来当裁判，而是把 Agent 当前步骤及其依赖关系，与已记录的成功运行轨迹做结构感知比对，在约 1 毫秒内完成每一步判断，然后决定是提醒用户还是直接阻断 Agent。

这里的关键词是“结构感知”。Agent 的一步操作不是孤立文本，它与之前的工具调用、参数、返回结果构成依赖图。OnTrack 用最优传输（Optimal Transport）来衡量当前轨迹与参考轨迹之间的结构差异，而不是简单地比字符串或嵌入相似度。这解释了它为什么能捕捉到循环、停滞、重复工具调用这类“内容上看着正常、结构上已经跑偏”的异常。

最优传输（Optimal Transport, OT） 是衡量两个概率分布之间差异的数学框架，最初由 Monge 在 18 世纪提出，用于求解将一堆土搬运到另一处工地的最小代价方案，因此也叫「推土机距离」（Earth Mover's Distance）。给定两个分布和它们之间的代价矩阵，OT 求出使总搬运代价最小的匹配方案，并可据此定义 Wasserstein 距离。

在轨迹监控场景中，可以把当前步骤的依赖图节点分布和参考轨迹的节点分布视为两个概率分布，节点之间的结构差异作为代价，OT 就给出一个考虑全局匹配的结构距离。相比逐元素比对字符串或嵌入向量，OT 允许「错位但整体相似」的结构被正确匹配，因此对参数顺序变化、等价工具替换更稳健，同时对循环、停滞、重复调用这类拓扑异常敏感。

它的代价是需要求解一个线性规划问题，但在节点数较小的单步依赖图上，采用 Sinkhorn 迭代等近似算法可以把耗时压到毫秒级，这正是 OnTrack 能做到约 1 毫秒单步判断的基础。

三种数据获取场景下的能力边界

论文把问题拆成三种访问权限递减的场景，结论也相当诚实——数据越少，监控能力越弱。

全参考访问：既有历史成功轨迹，也有工具 schema。此时 OnTrack 能做计划违规检测，判断 Agent 是否偏离了已知可行的执行路径。

中等访问：只有工具 schema，没有历史轨迹。监控退化为对照工具本身的合法用法来发现异常调用。

无先验知识：只有实时生成的步骤日志。此时系统仍能识别循环、停滞和重复工具调用，但无法判断一个陌生但合理的计划是否偏离目标。

这种分层设计有现实意义：很多团队并没有积累足够的高质量成功轨迹，却仍希望有基本的实时防线。OnTrack 的能力预期随数据访问下降而下降，但它没有假装自己在数据匮乏时依然全能。

SWE-bench 上的实测数据

论文在 SWE-bench 轨迹上做了评估，用的是前 8 步信息。结果是对失败轨迹的排序能力优于内容相似度方法，AUROC 高出 0.057。这个数字不算惊人，但在早期步骤就区分成败轨迹本身就有难度。

更实际的收益来自中止策略：OnTrack 节省了约 18% 本会消耗在失败运行上的计算资源。而在被中断的运行中，83% 确实正在走向失败——6 次中止里有 5 次判断正确。这意味着它不是靠大量误杀来换取节省，精确率处于可用区间。

AUROC（Area Under the Receiver Operating Characteristic curve） 是评估二分类模型排序能力的常用指标，取值范围 0.5（随机）到 1.0（完美）。它等于随机取一个正样本和一个负样本，模型给正样本打分更高的概率，本质衡量的是「能否把失败轨迹排在成功轨迹之前」，而非某个固定阈值下的准确率。在监控场景中，AUROC 比准确率更合适，因为最终中止阈值可按业务对误杀的容忍度单独调整。

SWE-bench 是评估 LLM 修复真实 GitHub 仓库 issue 能力的基准，包含数千个真实 Python 项目的 bug 修复任务，每个任务配有可运行测试来验证补丁是否通过。Agent 在此基准上的轨迹通常包含数十步文件读取、编辑、测试调用，是研究长程 Agent 失败模式的理想素材。文中「前 8 步信息」指只使用轨迹开始 8 步的结构做判断，这更接近实际部署中需要在早期就决定是否中断的场景。

为什么流式监控比守护 Agent 更值得关注

守护 Agent 方案的问题不只是成本。每步都调用一个额外 LLM，会引入延迟抖动，在交互式场景里体验很差；而且守护 Agent 本身也可能被绕过或犯错，形成新的攻击面。事后日志评估则完全无法阻止不可逆操作，只能用于复盘。

OnTrack 把监控成本压到毫秒级，并且不依赖额外的模型推理，这让它有可能作为标准中间件嵌入 Agent 运行时。当然，它的局限也很明显：参考轨迹的质量直接决定监控上限，如果历史成功运行本身有问题，比对基准就不可靠。

对 Agent 工程实践的启示

对正在部署 Agent 的团队来说，OnTrack 提示了一个务实方向：与其追求一个全知全能的守护模型，不如先把轨迹结构记录下来，用轻量比对做第一道防线。成功运行的历史数据本身就是资产，值得被结构化保存而非只当日志丢弃。

另一个值得留意的点是中止策略的设计。18% 的计算节省和 83% 的中止准确率，意味着仍有约 17% 的中止属于误杀。在哪些场景可以接受误杀，哪些场景宁可放行也不能打断，这是策略层需要按业务权衡的问题，论文本身没有给出通用答案。

误杀（false positive）与漏杀（false negative） 的权衡是异常检测系统的核心设计问题。误杀指系统把本来会成功的运行错误中止，代价是浪费已投入的计算和可能错失正确答案；漏杀指系统放过了即将失败的运行，代价是继续消耗资源甚至执行不可逆操作。

在 Agent 场景中，这一权衡比传统监控更微妙：不可逆操作（如转账、删除数据、发送邮件）一旦执行就无法回滚，因此这类步骤应偏向「宁可误杀」；而只读查询、草案生成等可逆步骤则适合放宽阈值，避免打断合理的探索路径。

一个实用的工程做法是按工具类型给每个动作打上「可逆性等级」，并为不同等级设置独立的中止阈值，而不是对整条轨迹用同一个分数。此外，误杀率会随参考轨迹库的质量和覆盖度变化，团队在上线后应持续收集被误杀但实际会成功的运行，反哺轨迹库，形成闭环。

常见问题

OnTrack 需要训练模型吗？ 不需要额外训练守护模型，它基于最优传输做轨迹结构比对，主要依赖已有运行数据。

它能用在非 SWE-bench 场景吗？ 论文在 SWE-bench 上验证，但方法本身面向通用 Agent 轨迹，前提是能获取步骤和依赖结构。

毫秒级监控会不会漏掉慢速异常？ 它检测的是单步与参考结构的偏差，跨多步的缓慢漂移需要结合更长的历史窗口来判断。