论文导读
Google Research、Google DeepMind、加州大学洛杉矶分校和纽约大学分析2518条长任务智能体轨迹，人工标注6967个错误并归为78类。六个前沿模型担任评判器时，表现最好的也不能在三分之一以上的轨迹中正确定位首个错误；团队训练的4B Scout验证器反而更准，但结论只覆盖软件工程、计算机操作和科学任务。
最终“通过”，可能掩盖中途已经发生的破坏
长时程智能体会连续调用工具、改文件和操作系统。只看最终答案，无法知道它从哪一步偏离、是否真正恢复，甚至可能漏掉已经删除数据、破坏环境或伪造成功的行为。研究团队因此不只给整条轨迹判成败，而是逐步标记第一个错误、后续级联和恢复情况。
图1：论文用首错位置解释看似正常的轨迹如何逐渐失控。
数据包含2518条接近真实部署的轨迹，横跨软件工程、电脑使用与科学任务。人工共标出6967个错误，整理成78类。最常见的模式是：智能体犯下第一个错误后，往往没有意识到问题，继续执行后续动作，造成越来越难恢复的错误链。
第一处错误比最后一步更值得盯住
统计图把“原因”和“症状”分开。第一次错误中，推理或规划问题占比更高；后续可见错误中，动作或执行问题增加。研究还发现，能否恢复更取决于任务和环境是否提供清晰反馈，而不是使用了哪一种智能体框架。三类失败信号同时出现时，仍有13.7%的运行无法恢复。
图2：首错与后续错误分布不同，沉默失败还可能带来安全风险。
这解释了为何结果评测不够：如果错误没有立刻让任务失败，智能体和监督模型都可能把它忽略。论文甚至发现少数最终被判为解决的轨迹里出现破坏性操作，说明“答案正确”和“过程安全”是两个独立指标。
下一步：把首错定位接入智能体部署
团队把人工验证的数据发布为Traverse基准，要求评判器指出轨迹第一次出错的位置。六个前沿模型无论规模大小都表现吃力，最强者正确定位的轨迹也不到三分之一。专门训练的4B Scout验证器却明显更好，并能迁移到未见领域；用它在多条候选运行中做选择，还能把任务成功率提高到单次运行之上。
图3：专用Scout验证器与多种通用前沿评判器的结果对照。
这不是“大模型越大越差”的普遍结论，而是说明通用评判器缺少细粒度失败定位训练。Scout也不是可靠性的终点：它可能漏检新型错误，候选选择只能在已有运行中挑较好的一条。更稳妥的部署方式，是同时记录过程、识别首错、限制不可逆工具权限，并把最终成功与过程伤害分开验收。面向生产环境，还应给验证器设置独立权限和误报预算，在删除、付款或外发前触发暂停，而不是让同一个执行模型同时扮演运动员与裁判。
