145 步轨迹里找那一步错：LongRCA Bench 把智能体失败的"破案"难度拉到了真实量级

假设你带的一个多智能体团队交上来一份报告，说任务完成了。你一验收，47 个必过测试挂了 47 个。现在的问题是：这一百多步的执行记录里，到底是谁在哪一步把事情带歪的？

这不是假设。LongRCA Bench 论文里就放着这样一个真实案例：一个 SWE-bench Pro 的失败轨迹，第 37 步 DiagnostAgent 给出了一份修复计划，用了和任务要求不一致的 is_sequence API；执行智能体照做了；系统在第 163 步高高兴兴地报告完成；然后源评估器给出的分数是 0/47。也就是说，错误在第 37 步就埋下了，后面整整 126 步都是在错误的轨道上狂奔。

人工标注员要把这 163 步全部读完，才能定位到第 37 步。单次标注耗时 30 到 40 分钟。这就是这篇论文要解决的痛点——长时程智能体失败后的根因诊断，而之前没有人认真量过这件事到底有多难。

核心摘要：现有的智能体失败归因 benchmark（如 Who&When）大多基于几十步的短轨迹，而真实长程任务里"犯错的那一步"和"失败暴露的那一刻"之间可能隔着几百步。中科院、重庆大学、清华、阿里通义等团队联合推出了 LongRCA Bench（arXiv:2608.15242）：1,140 条来自 5 个真实 benchmark 的失败轨迹，不注入合成错误，中位长度 145 步、最长 728 步，每条都有人工标注的责任角色和最早决定性根因步骤。最强 baseline 的精确根步定位准确率只有 13.2%。作者顺手给了一个免训练方法 RCTA，把责任角色准确率做到 51.1%、精确根步准确率做到 24.1%。我的判断：这个 benchmark 的定位很准——它第一次把"责任归因"和"根因定位"拆开独立评分，防止了"猜对人就蒙混过关"的评分漏洞；RCTA 本身更像一个扎实的工程基线，真正的价值在于它把天花板量出来了。

📖 论文信息

• 标题：LongRCA Bench: Diagnosing Responsible Roles and Root Causes in Long-Horizon Agent Failures
• 作者：Yunfei Zhang, Boyu Feng, Changhua Pei（通讯作者）, Zexin Wang, Zhihuang Peng, Xinlong Liu, Hengyue Jiang, Difeng Ma, Jiayi Zhang, Yongzhou Yao, Yanan Zhao, Fei Sun, Yintong Huo, Zhaoyang Liu, Jingjing Li, Gaogang Xie, Dan Pei（Yunfei Zhang 与 Boyu Feng 共同一作）
• 机构：中国科学院计算机网络信息中心、中国科学院计算技术研究所、重庆大学、清华大学、阿里巴巴通义实验室等
• 链接：https://arxiv.org/abs/2608.15242 （2026 年 8 月 15 日提交，v3 版 8 月 21 日）
• 项目主页：https://longrca-bench.github.io/

🎯 为什么需要这篇论文

先交代一下背景。自动失败归因（automated failure attribution）这个任务是 ICML 2025 那篇 Who&When 正式提出来的：多智能体系统挂了，自动找出"谁负责、哪一步出错"。Who&When 的结果当时挺让人清醒的——最好的方法找出责任 agent 的准确率约 53.5%，定位到出错步只有 14.2%。后来的 Who&When Pro 把规模做到了 12,326 条轨迹，但用的是"回放成功前缀后注入错误"的合成方案。

问题来了。这两个 benchmark 的轨迹都短：Who&When 平均 22.2 步，Who&When Pro 平均只有 7.5 步。而且注入错误的根因是"已知答案"，诊断模型面对的是一种被设计出来的失败。

真实场景完全不是这样。真实的长程 agent——修 bug 的、做旅行规划的、操作网页的——一跑就是上百步，错误自然发生，没人知道它藏在哪。失败暴露点距离根因可能隔着几百步的"尸体"。LongRCA Bench 的作者看的就是这个空白：短轨迹上刷出来的归因能力，能不能迁移到几百步的真实失败轨迹上？答案大概率是不能，那得先有个东西量出来。

这篇论文还把一个容易被糊弄的评分漏洞堵上了。之前的做法经常是从"出错步骤"反推"责任角色"——步骤是某个 agent 发出的，那他就是责任人。但多智能体协作里这个推理经常不成立：执行 agent 只是照做了诊断 agent 给的错误计划，锅应该算在出计划的人头上。所以 LongRCA 把责任角色和根因步骤定义为两个独立预测、独立评分的任务，禁止互相推导。

这个设计很关键。这样一来，一个方法可以"猜对人但找不到那一步"，也可以"找到那一步但归错人"——两种能力是分开考的。

🏗️ LongRCA Bench：1,140 条真实失败轨迹

构建流程

数据集的构建是一条四阶段流水线，全程没有注入任何合成错误：

图 2：数据集构建流水线。左边是 5 个失败轨迹来源，中间是质控筛选和三轮标注裁决流程，右边是最终发布的数据 schema。有个细节值得单独提：标注分歧由 GPT-5.5 辅助裁决后，还要过一道人工专家复审——模型建议不会自动升级为参考标签。

五个来源领域，覆盖的任务类型和组织形态差异很大：

轨迹由三个模型生成：MiniMax-M2.5（681 条）、Kimi-K2.5（276 条）、Qwen3.5-Plus（183 条）。TravelPlanner 是三者混合产出，其余来源基本由 M2.5 生成。这里有个潜在的小问题我在后面会提。

轨迹统计：这才是重点

数字最能说明这个 benchmark 和前辈的区别：

• 总记录步数 178,137 步；平均每条 156.3 步，中位数 145，最长 728 步
• 参考根因的中位位置是第 55 步
• Root-to-end distance（根因之后还走了多少步才结束）：中位数 48，第 90 百分位 183，最大 605
• 49.0% 的轨迹在根因之后还有超过 50 步的执行；7.7% 的轨迹根因之后还有超过 200 步

对比一下：Who&When 平均 22.2 步的"长"轨迹，在这里连下四分位都排不进去。

坦率地讲，root-to-end distance 这个指标定义得很聪明。它直接量化了"诊断难度"的一个核心维度——根因埋得越早，后面堆积的无关步骤就越多，信噪比越低。一个方法如果只在"根因离结局很近"的轨迹上准，那它可能只是在做症状检测，不是根因归因。

标注质量：同意率低得诚实

标注协议也值得细看，因为它直接决定了这个 benchmark 的上限可信度。22 名计算机硕士/博士生，每人独立阅读任务指令、完整轨迹和源评估器结果，输出三个字段：责任角色、最早决定性根因步、绑定证据的书面理由。

多标注的一致率数字是：角色 65.9%、步骤 39.5%、联合 38.4%。

看到 39.5% 的步骤一致率，我第一反应是"这也太低了"。但再想想，这个数字其实挺诚实——它说明长轨迹根因定位这件事，连人都不容易达成一致。145 步里选出"最早的决定性错误"，本来就是一个需要大量上下文判断的任务。作者的处理方式是：分歧不取平均、不妥协，按"最早决定性"规则人工裁决；无效标注直接排除而不是自动修复。这比那些号称标注一致率 90%+ 的注入式 benchmark 更接近真实——毕竟 Who&When Pro 的人机一致率高，部分原因是答案本来就是它注入的。

🧠 任务定义：两个独立预测

形式化地讲，每条实例给出任务指令和失败轨迹 \(H=(h_0,\dots,h_{T-1})\)，方法要输出责任角色 \(\hat{\rho}\) 和根因步骤 \(\hat{r}\)，独立评分。参考标签同样是分离的。

根因步 \(r^*\) 的操作定义有三层约束，我觉得这是全篇最容易被忽略但最关键的设计：

1. 必须是引入决定性错误的最早记录步骤——只执行、传播或暴露既有错误的后续步骤不算；
2. 该错误在失败前未被修复——早期犯错但后来修好了的，排除；
3. Handoff 规则：如果指令步骤本身就带着决定性错误，根因算在指令步骤头上；只有后续步骤偏离指令或引入新错误，才算后续步骤。

第三条规则直接改变了归因的语义。它把"执行了错误命令的人"和"下达错误命令的人"区分开，这正是短轨迹 benchmark 里几乎不会出现的场景——短轨迹里没那么多层级委托。

评估指标四个：责任角色准确率、根步精确匹配准确率（主指标）、根步 ±5 步容差准确率、以及按来源加权的有效输出根步 MAE：

缺失或非法输出对准确率计为错误，但不进 MAE。这个设计避免了"拒绝回答"刷分。

🔧 RCTA：免训练的"分段排查 + 回溯甩锅链"

基准之外，论文给了一个免训练方法 RCTA（Root-Cause Trajectory Attribution）。说实话，它的思路谈不上惊艳，但每一步都踩在长轨迹诊断的真实痛点上——先把大海捞针变成小池塘捞针，再顺着委托关系往上追责。

图 5：RCTA 整体架构。左侧是轨迹的多级表示（任务简报、步序列、agent/动作状态），中间紫色块是层级证据抽象（步级→段级→阶段级），右侧红框内是三个核心模块：候选证据检索、Delegate 链路分析、根因 vs 症状定位，最右边是最终诊断输出。整个流程是免训练的，所有判断由 LLM 在检索出的原始证据上完成。

三个阶段：

阶段一：纯规则切分。 不用语言模型，按硬规则把轨迹切成 segment：单段最多 32,000 字符、最多 80 个非重叠步骤；遇到 finish 步骤或角色 handoff 边界时，要求当前段至少 8 步且 1 万字符才允许断；verifier 的 PASS/FAIL 信号变化也是天然边界。除第一段外，每段携带前一段最多 5 步作为重叠上下文。这个设计保证切分可复现、不引入模型噪声。

阶段二：候选召回。 每个 segment 一次 LLM 调用，生成摘要并提出候选错误步骤（带原始记录 ID）；再一次调用把相邻段摘要合并成按子目标组织的轨迹大纲（要求 3 到 8 个 phase，解析失败就回退）。然后汇总候选 ID，检索每个保留步骤的原始文本——注意，摘要只用于导航，最终判断必须回到原始步骤文本。这个"摘要导航、原文定罪"的分工很重要，直接堵住了摘要丢失关键细节的风险。

阶段三：Handoff 回溯。 对来自 executor 或 verifier 角色的候选步骤，检索最近的、发给该角色的前置 handoff 指令，把指令原文一起交给最终的归因 LLM。判定规则很细致：指令本身带错且被执行 → 选指令步骤；后续步骤偏离指令 → 保留候选步骤；已修复的错误排除；verifier 漏检不替换引入错误的步骤；在有证据的候选里选最早的。

一次 RCTA 跑完，m 个 segment 的轨迹需要 m+2 次 LLM 调用。推理骨干统一用 DeepSeek-V4-Flash，局部摘要关 thinking，大纲聚合和最终归因开高推理强度。

还有一个让我印象不错的工程细节：程序化输出验证。预测的角色必须在轨迹角色集合里，引用的 handoff 文本必须在被引用指令里真实出现（子串匹配或足够词重叠）。验证不过给一次带反馈的重试，再不过就降级为 abstention。这种"防幻觉引用"的校验在长文档归因里很容易被省掉，省了就是在给幻觉开绿灯。

📊 实验：最强 baseline 只有 13.2%

全部 6 种方法用同一骨干 DeepSeek-V4-Flash、同一批 1,140 条轨迹、同一评分协议。对照的 5 个免训练 baseline：All-at-once（整轨一次看）、Step-by-step（顺序扫描）、Binary search（递归二分）、ECHO（层级上下文+共识投票）、FALAT（依赖引导搜索）。

主结果：

几个数字值得停下来看看。

RCTA 相对最强 baseline ECHO，角色准确率提了 23.6 个点，根步精确提了 10.9 个点，MAE 降了 11.8 步。提升幅度是实打实的。

但换个角度：24.1% 的精确根步准确率，也就是说即使是专门为这个任务设计的方法，四次里也有三次定不到那一步。这还是在 ±5 容差下也只有 37.4% 的情况下。这个任务的难度被量化得很残酷。

最让我皱眉的是 FALAT：2.8%，连最朴素的 All-at-once（7.6%）都不如。依赖引导搜索在短轨迹文献里是个有头有脸的路子，到了长轨迹上直接崩了。作者很谨慎地注明"该结论仅限于所评估的实现"，但说实话，这至少说明依赖图在几百步的轨迹上噪声大到不可用。

分层分析：RCTA 的"抗长"特性

按轨迹长度分桶看根步精确准确率（%）：

All-at-once 从 18.1% 掉到 0.8%——长上下文直接把"整轨通读"打法判了死刑。RCTA 在 200 步以上还能稳在 20% 上下，这个衰减控制就是分段召回设计的价值。

按 root-to-end 距离分桶更有意思：

注意 RCTA 在根因之后还有 100 多步"尸体"的最难桶里，反而拿到 25.6%，和中间桶几乎持平。而其他方法在这个桶里全部跌到个位数。这直接验证了 handoff 回溯机制的价值：错误埋得越深，越需要顺着委托链往回追，而不是在表层症状里打转。

等等，有一个地方我得泼点冷水。>400 步那个桶 RCTA 拿到 31.0%，看起来比短轨迹还好，但这个桶只有 42 条轨迹，且来源构成和其他桶完全不同。作者自己也强调了：各 bin 混合了不同来源、工作流和失败分布，这些趋势只能作关联性解读，不能当因果结论。这个克制是对的。

🤔 我的判断

这篇论文最值钱的地方，是把"责任归因"和"根因定位"拆成两个独立目标，并且用真实长轨迹把两者的难度差量了出来。 51.1% vs 24.1% 这个差距本身就说明：认出"谁的锅"远比定位"哪一步埋的雷"容易。之前混着评分的 benchmark 里，这个差异被掩盖了。以后谁再报一个"failure attribution accuracy"，第一个问题就该问：你报的是哪个？

第二个价值是不注入错误。注入式 benchmark（如 Who&When Pro）标注质量高、规模大，但根因是被设计的，诊断模型面对的是"这类错误长这样"的识别任务。LongRCA 的 1,140 条全是自然发生的失败，根因可能是一次错误的需求理解、一个不一致的 API 选择、一次被放过的漏检——这些失败模式的分布，注入式方案很难模拟。

不足也得说。

一是来源构成偏科。TravelPlanner 占了 60.1%（685/1,140），而且全部五个来源里四个完全由 MiniMax-M2.5 生成。这样 benchmark 的失败模式分布就强烈偏向特定模型和特定任务类型，"在 LongRCA 上做得好"未必等价于"在你的 agent 系统上诊断得好"。作者没有给按领域分的各方法准确率表，只有描述性统计，这块信息缺口让人有点遗憾。

二是没有消融。RCTA 有三段式设计，但候选召回、handoff 回溯、输出验证各自贡献多少？论文把消融直接列为 future work。24.1% 里有多少是分段召回的功劳、多少是回溯机制的功劳，现在说不清。

三是标注的天花板。步骤一致率 39.5%，说明参考标签本身有噪声。24.1% 的模型准确率里，有多少是被标签噪声压低的？论文用"最早决定性"规则做裁决，方向是对的，但这类主观判断的噪声上限，可能需要更细粒度的标签（比如置信度或多候选根因）才能打开。

和同期工作比，LongRCA 的定位是清晰的：Who&When 定义了问题，Who&When Pro 用注入方案做了规模化，LongRCA 则把轨迹长度和真实性这两个维度补上了。三者是互补而非替代。

对工程的启发很直接：如果你在做 agent 系统的线上诊断或自动复盘，RCTA 的三个设计可以直接搬——规则切分保可复现、摘要导航但回原文定罪、顺着 handoff 指令链向上追责。还有一个隐含的提醒：把根因日志结构化地记录下来（谁给谁下了什么指令），比事后从原始对话里重建委托关系要便宜得多。今天的日志格式，决定了明天你能不能破案。

📝 收尾

长程 agent 越普及，"失败后读 145 步日志找根因"就越会从偶发事件变成日常运维工作。LongRCA Bench 给出的 13.2% 到 24.1% 的准确率区间告诉我们：这件事离自动化还很远，但至少现在有一把真实的尺子了。

下一个值得追的问题：如果允许方法在轨迹执行过程中做在线检测，而不是事后离线归因，准确率会不会完全不同？这个 benchmark 明确不评在线检测，但这恰恰是生产环境最想要的能力。留给下一篇了。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我