OnTrack：流式监控LLM智能体轨迹，毫秒级阻断失败运行
论文AI 评分 72/100arXiv cs.AI待复核
AI 聚合
本条为 AI 依据下方公开信源自动整理生成的摘要，不构成转载，可能存在偏差，请以原文为准。整理者：贝果科技 AI 资讯助手。
研究者提出OnTrack，一种流式监控机制，将智能体当前步骤与依赖同已记录的成功运行轨迹对比，可在每步约一毫秒内提醒用户或阻断智能体。论文按数据访问权限递减划分三种场景：可获取历史运行与工具模式、仅可获取工具模式、仅有步骤日志，监控能力随之从计划违规检测降至识别循环、停滞与重复工具调用。在SWE-bench轨迹上，仅用前8步，该方法区分失败与成功轨迹的AUROC比内容相似度方法高0.057；配合中止策略可节省约18%的算力，被中断的运行中83%确实走向失败。
全文梳理
AI 摘要依据下方信源原文自动整理，非原文转载实时监控替代事后审计
现有做法主要有两类：一是引入额外的守护智能体逐步监控行为，代价是每一步都增加成本与延迟；二是事后评估日志，但结论出来时token已经消耗、损害已经发生。OnTrack选择在运行过程中做流式监控，把智能体当前步骤及其依赖关系与已记录的成功运行进行比对，一旦偏离即可提醒用户或直接阻断。论文给出的单步开销约为毫秒级，与逐步调用守护智能体的方案相比，不额外引入一个模型来参与每一步决策。
三种数据访问场景
论文按可获取信息的多少划分了三种递减场景。第一种是完整参考访问，既有历史运行记录也有工具模式，此时可做计划违规检测。第二种是中间访问，只有工具模式，没有历史运行。第三种是无先验知识，只有运行过程中生成的步骤日志。随着数据访问减少，OnTrack能提供的监控能力相应下降，可识别的问题类型从计划违规扩展到循环、停滞和重复工具调用等模式。
SWE-bench上的量化结果
评估使用SWE-bench的轨迹数据。仅依据前8步，OnTrack把失败轨迹排在成功轨迹之下的能力优于基于内容相似度的方法，AUROC高出0.057。在配合中止策略时，可节省约18%本会消耗在失败运行上的算力；被中断的运行中有83%确实正在走向失败，即6次中止里有5次判断正确。这些数字说明该方法在早期步骤就具备一定的失败预判能力，并能转化为实际的计算资源节省。
为什么值得看
智能体自主执行易造成不可逆操作，该方案把事后审计变成毫秒级实时拦截，并给出可量化的算力节省。
智能体算力论文
信源1 家
关键事实
相关 · 论文
本页内容由 AI 自动聚合公开信源生成，仅供了解行业动态参考，不构成任何投资或决策建议。如需引用请以原文出处为准。