Source-linked AI summary

Repair or Resample? Rethinking Failure Debugging in LLM Multi-Agent Systems

Zhongwen Luan, Xiaoyu Zhang, Ming Hu, Yue Yang, Jiongchi Yu, Xiaohong Chen

arXiv:2608.25920v1cs.AIcs.SE

TL;DR

MAS 失败修复方法往往依赖随机性的全轨迹重跑,因此难以判断它们是在纠正失败,还是在利用采样变异性。本文提出受控回放和人工标注的失败数据,发现症状驱动的干预可修复 20.15% 的失败案例,而任务级重新生成的修复率最高仅为 6.90%。

  • 问题

    对于日益复杂且影响重大的基于 LLM 的多智能体系统,如何可靠地理解、复现和修复失败,仍未得到充分确立。

  • 方法

    本文提出 SymTrace,通过固定干预前历史实现受控的选择性回放,并提出 SymFail——一个包含 536 条失败轨迹的人工标注数据集。

  • 结果

    Suspicious-Node Intervention 通过一次干预修复了 20.15% 的失败案例;相比之下,三次尝试内任务级重新生成最多修复 6.90% 的案例。

  • 要点与局限

    可靠的修复评估应保留干预前历史,定位预期变更,并评估失败机制是否得到纠正。

  • 要点与局限

    SymFail 基于基准测试衍生任务,可能无法覆盖已部署多智能体系统中失败情况的完整多样性。

Abstract

from arXiv · show

As large language model (LLM)-based multi-agent systems (MASs) are increasingly applied to long-horizon complex tasks, their reliability has emerged as the core bottleneck hindering their real-world deployment. Existing MAS debugging and repair methods typically rely on rerunning and resampling the entire execution trajectory. However, a fundamental question remains to be answered: do these methods causally repair MAS failures or merely stochastically repair by leveraging the randomness of LLM sampling? To evaluate the effectiveness of MAS repair methods, we introduce SymTrace, a controlled evaluation framework that records the MAS execution trajectory and establishes intervention anchors. During replay, it effectively reconstructs the execution before the anchor using recorded logs and only regenerates the downstream trajectory, thereby enabling the reliable reproduction of MAS failures. We further construct the dataset SymFail, comprising 536 human-annotated failure trajectories with graph-linked locations, categories, and trace evidence. Based on these foundations, we conduct a large-scale empirical study across three mainstream MAS frameworks. Our findings reveal that existing unguided rerun methods are highly unreliable, exhibiting low failure reproduction and repair rates (only 67.97% and 6.90%, respectively). Building upon these findings, we further explore the effectiveness of a symptom-driven intervention method, which successfully repairs 20.15% of the failed cases (a 191.89% improvement to state-of-the-art repair methods). This study aims to provide actionable insights for MAS debugging and repair research, paving the way for the robust deployment of multi-agent systems.

1 引言

基于 LLM 的多智能体系统支持复杂的长时程应用,但由于随机重跑可能改变失败表现,却未必能从因果上修复失败,因此仍难以调试。本工作引入受控重放和带标注的失败数据,表明局部干预显著优于任务级重新生成。

  • 动机: 现有 MAS 修复方法采用重跑、反思、批评反馈或轨迹级引导,但重复的随机重跑可能产生不同的失败类型,甚至检测不到失败。这促使我们追问:修复究竟是因果性的,还是仅仅通过 LLM 重采样实现的随机恢复。
  • 方法: SymTrace 将模型与工具边界交互记录为事件依赖快照,并通过匹配拦截到的请求、注入已记录结果来重放这些交互。这支持对前缀执行进行可验证的重建,并在不对之前执行进行重采样的情况下实施干预。
  • 资源: SymFail 提供了 536 条人工标注的失败轨迹,为 MAS 调试研究奠定基础。该数据集与重放系统共同支持对任务级修复和节点级控制进行评估。
  • 实证结果: 通过一次干预,Suspicious-Node Intervention 修复了 20.15% 的失败;相比之下,三次尝试内任务级重新生成的修复率最高仅为 6.90%;在全部三个 MAS 中,其表现均为最佳。其修复率是最强任务级基线的 2.92×。
  • 实证结果: SymTrace 将每次执行的失败复现率从 67.97% 提升至 80.78%,并将三次执行一致复现率从 41.42% 提升至 52.43%。该系统通过在重新生成下游行为前重建记录的执行前缀,实现了受控评估。

2 背景与相关工作

基于 LLM 的多智能体系统通过依赖结构化的执行轨迹协调具有不同角色分工的智能体,使故障影响超出终端输出。既有工作提升了故障可观测性与修复能力,但通常在未控制修复前执行过程的情况下评估重运行。

3 系统设计

SymTrace 使用 Snapshot Mode 记录结构化 MAS 轨迹,并通过 Replay Mode 重建经验证的前缀,再进行干预并恢复实时执行。所得轨迹保留干预前的执行过程,同时允许干预后的轨迹发生分歧。

  • Replay Scope: Replay Scope 保证重建前缀,同时允许新生成的后缀偏离源轨迹。因此,重放过程保留干预前经验证的执行过程,而不限制下游行为必须遵循原始运行结果。
  • Snapshot Mode: Snapshot Mode 记录模型交互和工具交互,按依赖关系与顺序组织事件,并将其与任务及运行时配置打包。所得数据包随后成为传输至 Replay Mode 的轨迹。
  • 工作流: SymTrace 的双模式工作流记录原生 MAS 执行过程,重建目标前缀,实施干预,并从该位置开始生成新轨迹。Snapshot Mode 使用 Boundary Logging、Trace Construction 和 Replay Bundle;Replay Mode 使用 Result Injection、Boundary Matching、Live Resume 和 Replay Scope。
  • Replay Mode: Replay Mode 注入历史边界结果,根据预期记录验证调用,并在指定干预目标之后恢复实时执行。Content hashes 用于验证复用的前缀节点;干预后,模型与工具端点、调度及状态更新继续实时进行。

4 数据集构建

SymFail 是一个包含 536 条经评估者确认的 MAS 失败轨迹的结构化数据集,构建自 WebArena-Verified Hard 和 AssistantBench。该数据集结合了轨迹定位标注与校准后的多标注者复核,并发布了关联的执行产物、分析理由和证据。

  • 数据集概览: SymFail 包含 536 条经评估者确认的失败轨迹,并提供结构化执行轨迹、事件图、定位的失败节点和多标签标注。该数据集构建自 WebArena-Verified Hard 和 AssistantBench。
  • 任务选择: 确定性任务池包含 200 个任务:33 个 AssistantBench 任务和前 167 个 WebArena-Verified Hard 任务,覆盖 Web-QA、mutation、navigation 和 retrieval。任务池包括 33 个 Web-QA、70 个 mutation、25 个 navigation 和 72 个 retrieval 任务。
  • 执行与筛选: 在 AG2、CrewAI 和 Magentic-One 上执行的 600 次初始运行产生了 536 条保留失败轨迹,并具备完整的轨迹与图产物;64 次运行在标注前被排除。保留的轨迹包括 171 次 AG2、184 次 CrewAI 和 181 次 Magentic-One 运行。
  • 失败分类体系与标注: 标注方案保留了四类常见、非互斥且可由轨迹观测的失败类别,这些类别源自 Multi-Agent System Failure Taxonomy(Cemri et al., 2025)。标注者分配适用类别,选定一个主要类别,并结合证据与分析理由确定最早的、由轨迹支持且可采取行动的节点。
  • 标注质量: 在 536 条轨迹中,有 21.08% 相较于初始标签并集改变了最终类别集合;主要类别的 Fleiss’ κ 达到 0.62,失败节点类型的 Fleiss’ κ 达到 0.81。所有标注者之间的精确节点一致率为 73.88%,至少两名标注者之间为 95.90%。
  • 发布产物: 发布内容包括任务清单、关联的轨迹与图、初始和最终标注、分析理由及支持证据;全部 2,144 个节点选择均以源事件图为依据。这 2,144 个选择包括 536 × (3 + 1) 个初始和最终节点选择。

5 研究

在来自 AG2、CrewAI 和 Magentic-One 的 536 个 SymFail 失败案例中,SymTrace 表明,精确重建前缀相比无引导的完整重跑能够提升失败复现率;而对于修复,局部的症状驱动干预比反复生成完整轨迹更有效。任务级方法主要利用随机生成,而非可靠地纠正源失败。

  • 研究设计: 该研究评估了来自 AG2、CrewAI 和 Magentic-One 的 536 个源失败,涵盖 200 个固定任务;任务级方法使用每个任务的三次完整尝试,节点级方法使用一次选择性回放干预。回放和修复前,评估集即已冻结;每个源失败均作为一个实验单元处理。
  • 失败复现: 在三个 MAS 中,SymTrace 都通过重建目标失败节点之前的执行过程,持续提升了相较于无引导完整重跑的失败复现率。随着可复用的前序节点增多,其优势进一步扩大,因此尤其适用于长时程 MAS 任务。
  • 失败复现: 对于 2–3 个复用节点,相较于完整重跑的复现率增益分别为 9.80 和 6.82 个百分点;对于 4–8 个节点,增益分别升至 17.76 和 18.69;对于至少九个节点,增益分别为 25.69 和 27.08。大多数案例,即 536 个案例中的 381 个(71.08%),仅复用了 2–3 个节点;而在 1,608 次尝试中,有 738 次(45.90%)恰好复用了两个节点。
  • 局限性: 在失败目标之后,SymTrace 无法控制模型或环境变化;此外,LLM-as-a-judge 的错误也会为复现率估计带来测量不确定性。一项补充审计发现,估计的确认分歧率为 3.30%,不确定性率为 3.67%,合并敏感性上界为 6.96%。
  • 任务级修复: 任务级方法主要通过随机生成进行修复,而不是针对失败进行修复;在相同的三次尝试预算下,基于反馈的变体并未带来优势。重新执行可能修复失败结果,却同时使原本成功的结果变得不稳定;因此,观察到修复并不能证明源失败已被识别并纠正。
  • 修复效果: 可疑节点干预取得了最高的总体修复率,几乎是最强任务级基线的三倍;在相同的选择性回放预算下,其表现也优于随机节点干预和末节点干预。比较结果表明,改进并不能仅归因于选择性回放;精确的执行控制和局部症状能够提供可操作的修复指导。

6 讨论

该研究将 SymFail 建立在可由外部验证的基准之上,从而支持可复现且经结果验证的失败,但限制了对已部署多智能体系统中失败的覆盖。未来工作应收集真实世界的失败轨迹,并扩展对不同 MAS 结构、交互模式和任务领域的覆盖。

  • 数据覆盖: SymFail 建立在成熟且可由外部验证的基准之上,包括 WebArena-Verified Hard 和 AssistantBench。这种基准基础支持可复现且经结果验证的失败。
  • 数据覆盖: 源自基准的任务无法覆盖已部署 MAS 中所遇失败的全部多样性。
  • 数据覆盖: 未来工作应收集真实世界的失败轨迹,并覆盖更多 MAS 结构、交互模式和任务领域。

7 结论 … B.2 标注规则

本文区分已记录 MAS 失败的因果纠正与不同执行中的随机成功,并利用 SymTrace 和 SymFail 支持受控重放、失败分析与修复评估。其重放保证依赖于保存并验证所表示的执行前缀,而标注则识别可采取行动的症状,但不将其视为唯一根因。

  • 7 结论: 研究的核心结论是,完整重新生成会将因果修复与结果变异混为一谈;可靠评估则会保留干预前历史、定位预期变更,并检验失败机制是否得到纠正。不同执行后的最终成功不足以证明原始机制已被修复。
  • A 重放匹配规则与运行时假设;A.1 观测到的执行顺序;A.2 边界匹配与记录验证: SymTrace 记录观测到的事件顺序,并通过匹配已记录的边界请求与结果来重放原生 MAS,从而保留有意干预前的前缀。记录的顺序用于匹配和验证,而非控制调度器;选择性重放从指定的干预边界开始实时执行。
  • A.2 边界匹配与记录验证;A.3 重放条件与范围: fail-closed 重放会在首次不匹配处终止,并在返回记录结果前验证事件请求和已物化的复用前缀节点。这可以防止重放静默向后扫描,或接受发生偏离的前缀。
  • A.3 重放条件与范围: 在执行状态、捕获的边界和验证条件均满足时,选择性重放可以重建所表示的逻辑执行前缀,而无需实时模型或外部服务具备确定性。该保证涵盖所表示的状态、消息、控制决策和事件顺序,但不涵盖相同的内存地址、线程交错、延迟或墙上时钟时间。
  • A.4 外部状态考量: 记录的工具结果可以重现观测结果,但无法重现持久化的外部副作用,因此选择性修复要求实时后缀不依赖重放前缀中未被重现的变更。当前缀不存在必需的持久化写入,或环境已重置且该变更得到重现时,该条件可以成立。
  • B 数据集构建、标注与可靠性;B.1 队列统计: 该基准从最初的 600 次任务–MAS 执行中产生了 536 个已标注失败案例,排除了标注前由评估者接受的 64 次执行。这些失败涵盖 WebArena-Verified 和 AssistantBench,并包括来自 AG2、CrewAI 和 Magentic-One 的执行。
  • B.2 标注规则: C1–C4 分类体系采用非互斥且可从轨迹中观测到的症状;同时,标注者单独选择一个主要类别,作为证据最充分的干预信号,而非唯一根因。这些类别涵盖任务约束违反、重复或停滞进展、未解决的运行时条件,以及计划–行动–结果不一致。
  • B.2 标注规则: 标注区分重复行为与未解决依赖:当轨迹表明计划无法成功后仍出现重复或等价行为时,才标记 C2;非重复的未解决依赖则标记为 C3。标注者定位最早的、可采取行动且与轨迹相连的失败节点;置信度记录证据清晰度,但不会机械地影响裁决。

B.3 标注流程 … C.3 统计程序

研究针对536个 SymFail案例采用经裁决、经图验证的标注,并在配对、受控的执行与统计流程下评估修复方法。研究明确量化标注可靠性,并通过框架、模型记录、置信区间和假设检验规范约束修复比较的解释。

  • B.3 标注流程: 最终标注重新评估证据:在423个案例(78.92%)中与三位标注者的并集一致,新增123项标注,删除69项,其中包括16项由三位标注者一致提出的C1标注。三位标注者分别独立标注每个案例,随后由第四位标注者审查轨迹、标注和证据记录,生成由类别、主类别、节点ID和节点类型组成的严格元组。
  • B.4 标注者间可靠性: 在396/536个案例(73.88%)中,三位标注者选择了同一个失败节点;在210/536个案例(39.18%)中,他们对完整严格元组达成一致。可靠性基于三份初始标注计算:节点ID采用精确一致率,名义或二元类别结果采用 Fleiss’ κ,并使用 bootstrap 置信区间。
  • B.4 标注者间可靠性: C2的类别特定可靠性最低(κ = 0.374),并占最终裁决阶段新增123项类别决策中的86项。这表明“重复进展”与“进展停滞”之间的边界是分类体系中主要的歧义来源,并促使研究制定明确的C2决策规则。
  • B.5 最终构成与完整性检查: 最终数据集包含536个案例中的1,482项类别标注,平均类别基数为2.77,主类别计数为C1 = 125、C2 = 69、C3 = 203和C4 = 139。由于类别并非互斥,边际计数超过案例数;这些字段是经人工裁决的参考标注,而非 LLM 标注输出。
  • B.5 最终构成与完整性检查: 在1,608次初始选择和536次最终选择中,共有2,144/2,144次节点选择通过图存在性、节点ID和节点类型验证。SymFail包含来自两个基准来源和三个 MAS 的536个经评估者确认的失败案例,并配有完整的轨迹和图工件。
  • C.1 修复条件与执行限制: 配对方法保持任务输入、MAS实现、记录的模型别名、temperature和原生评估器不变,仅改变修复提示信息、干预位置和 replay 使用情况。修复要求在方法允许的预算内至少有一次通过评估器的尝试;RQ1使用三次执行,RQ2最多三次尝试,RQ3进行一次节点级干预。
  • C.2 框架与模型记录: 实验使用 AG2 0.13.3、CrewAI 1.14.7a3 和 AutoGen AgentChat 0.7.5,temperature 为0.00,请求的模型别名为 deepseek-v4-flash。该别名和温度描述的是已记录的客户端请求,并不代表经过验证的不可变模型快照或已确认的上游提供方版本;实验于 2026 年 六月 15–16 日 UTC 运行。
  • C 执行与统计规范: 修复比较报告 Wilson 区间、百分点评估差异的配对 bootstrap 区间,以及在适用时经过 Holm 校正的预先指定配对检验。每项比较均报告匹配的分母、修复次数和修复率、差异、置信区间及校正后的数值;内部调用和重试并非相互独立的观测。

C.4 配对比较结果 … D.2 复现指标

症状引导的 Suspicious-Node Intervention 始终优于任务级和节点级对照方法,而 Self-Reflection 与 Critic-Agent 相较于 Unguided Full Rerun 并无显著优势。评估还报告了 API 调用效率、实现细节、机制级等价性标准以及复现指标。

  • D 复现设置与保真度: 配对比较使用 10,000 个按案例配对的 bootstrap 重采样来计算百分位置信区间,并采用精确的双侧 McNemar 检验。系统错误和框架错误仍计入分母,作为未成功修复;Holm 校正应用于每个 MAS 内指定的比较族。
  • C.4 配对比较结果: Self-Reflection 和 Critic-Agent 在六项 RQ2 比较中均未显著优于 Unguided Full Rerun。相对于 Unguided Full Rerun 的每项修复率差异均为负值,且在 MAS 内进行 Holm 校正后,没有任何比较达到显著性。
  • C.4 配对比较结果: 在三种 MAS 架构中,Suspicious-Node Intervention 相对于每个 RQ3 对照方法都取得了显著为正的修复率差异。全部 15 项比较的 95% 置信区间均不包含零,并在 MAS 内进行 Holm 校正后仍保持显著(pH < 0.05),涵盖任务级和节点级对照方法。
  • C.5 API 调用效率: 在 AG2、CrewAI 和 Magentic-One 中,Suspicious-Node 既实现了每 1,000 次 API 调用最多的已接受修复,也实现了每次修复最少的 API 调用次数。这些是次级描述性指标;比较主要在各个 MAS 内进行,并非计算量匹配的因果估计,因为不同方法的轨迹长度和尝试预算不同。
  • C.6 实现环境: 实验在 Windows 11 本地运行,使用 Python 3.11.15、Intel Core i9-14900HX、32 GB 内存和 NVIDIA GeForce RTX 4060 Laptop GPU。托管端点执行模型推理,而工作站运行 MAS 框架、工具、轨迹捕获、SymTrace 回放、原生评估和统计分析。
  • D 复现设置与保真度: 机制级复现要求语义等价、角色对应关系和有依据的支持证据,而非原始节点相等。形式化测试匹配源类别、案例特定机制、语义执行角色和证据;只有当相交标准包含有依据的证据时,一次尝试才复现源机制。
  • D.2 复现指标: 复现指标量化每次执行的复现情况,以及在 N 个源案例上三次尝试全部成功时的复现情况。给定定义引入了每次执行复现指标和三次尝试全部成功指标,用于评估复现保真度。

D.3 回放保真度审计

回放审计发现,在全部 536 个案例及每个案例的三次尝试中,标注目标和复用前缀均得到精确保留。因此,失败复现率低于 100% 不能归因于已记录前缀内容被修改,尽管回放边界之后或边界之外仍可能存在变化。

  • 回放保真度审计: 在完成事件位置和规范化内容比对后,只要缺少任何目标之前的模型或工具请求、请求顺序错误或内容不匹配,回放就会终止。这可以防止回放在历史上下文发生偏离时仍静默继续。
  • 回放保真度审计: 1,608/1,608 次尝试均实现了精确的前缀保真度,全部 6,159 个复用节点都与源内容哈希匹配,并保留了父节点/边拓扑。审计使用了人工裁定标注中的准确目标 ID,因此测量的是回放保真度,而非自动定位准确率。
  • 回放保真度审计: 因此,低于 100.00% 的失败复现率不可能源于已记录前缀内容被修改,但可能反映了重新生成目标的行为、之后的实时执行,或回放边界之外的外部状态。该审计排除了复用前缀内容被改变这一因素,但回放边界之后的变化来源仍未得到解决。

E 任务级修复聚合 · E.1 基线输入边界与提示模板

任务级评估保留了对初始失败执行进行正式 pass@3 聚合的设置,并在匹配的输入、预算、配置和评估器下比较三种基线。在这些受控边界下,成对结果表明,Self-Reflection 或 Critic-Agent 并不优于无引导重运行。

  • E 任务级修复聚合: 任务级评估基于一组初始失败执行、评估器结果,以及成功或耗尽前所进行的尝试,保留正式的 pass@3 聚合。该聚合根据这些记录的尝试确定终止案例的结果。
  • E.1 基线输入边界与提示模板: 三种任务级基线均在相同的 536 个源失败案例上进行评估,这些案例涵盖 AG2、CrewAI 和 Magentic-One。每种基线都获得任务说明、任务标识符、基准和划分标识符,以及可用的起始 URL 或工具。
  • E.1 基线输入边界与提示模板: 三种基线均未获得源轨迹或事件图、失败位置、C1–C4 类别、轨迹证据,或参考答案和标准答案。Self-Reflection 和 Critic-Agent 还获得了原始失败执行的最终答案。
  • E.1 基线输入边界与提示模板: Self-Reflection 和 Critic-Agent 在每次恢复尝试中都复用了原始失败执行的最终答案,而不是前一次恢复的输出。Critic-Agent 在每次完整重运行中使用固定的批评者角色提示,且未额外调用独立的批评模型。
  • E.1 基线输入边界与提示模板: 基线针对失败后重运行、自我反思和批评者代理模式使用了不同提示,同时共享通用任务字段和最终答案输出后缀。对于 WebArena-Verified 和 AssistantBench,该后缀仅要求给出最终答案,以及关于所需证据的简短说明。
  • E.1 基线输入边界与提示模板: 在三种基线使用匹配的任务输入、评估器、模型配置、输出约束和三次尝试预算时,未观察到 Self-Reflection 或 Critic-Agent 优于无引导重运行。因此,该比较隔离了这样一个问题:获得原始失败答案并结合通用反思或批评者指导,是否能够改善恢复效果。

F 检测规则、锚点排序与干预提示

该方法将规则门控的症状检测、面向可修复性的锚点选择和症状条件化干预提示相结合。阈值分析刻画了证据门的覆盖率—修复权衡,同时指出启发式权重并未进行全局优化。

  • F.1 规则优先的症状检测: 检测器首先使用确定性的 C1–C4 规则,为未触发节点赋予零可疑度,并仅允许语义判别器确认或拒绝所提供的类别。参考答案、评估器判定和评估器导出的证据均不参与规则验证或语义验证。
  • F.1 规则优先的症状检测: C1–C4 是彼此不互斥的操作性症状,用于提升干预优先级,但不声称某个节点是唯一根因。一个症状可能表示局部错误、未解决的依赖关系或下游表现。
  • F.2 面向可修复性的锚点选择: 锚点选择倾向于可修复且具有局部支持的节点,而非终止节点或仅负责传播的节点;在最终结果节点之前,优先选择可重新生成的 agent 动作,其次是工具调用及其结果。该分数将可修复性与局部置信度和传播置信度相结合,同时惩罚仅传播证据和较晚的图位置。
  • F.3 干预提示: SymTrace 在可疑节点处暂停执行,重构所选锚点之前的前缀,注入症状条件化指导,并重新生成下游动作或产物。Random-Node 和 Last-Node 对照则使用不包含症状类别或轨迹证据的通用模板。
  • F.5 阈值解释: 实现中的融合使用语义置信度和结构化选择分数,并对多个已确认症状给予加分;其权重仍是手工指定的启发式设计选择。没有保存的验证集优化或替代权重扫描支持将这些权重描述为拟合得到、经过校准或经验上最优。
  • F.2 面向可修复性的锚点选择: 在线控制器按观测顺序处理节点,并在融合序数分数达到 θ 时触发第一个可重放的 LLM 边界;θ = 0.50 是面向覆盖率的门。这些系数编码了建模优先级,且未使用验证集修复结果进行优化。
  • F.5 阈值解释: 在 θ = 0.95 时,保留 78/536 个案例(14.55% 覆盖率),其中包含 19 个成功修复案例,因此条件修复率为 19/78 = 24.36%。该事后分析保持历史 rank-0 目标和观测结果不变;既不重新排序候选项,也不重新运行修复。
  • F.6 可疑度的语义边界: 语义边界审计形式化了对 timeout 和 timed_out 状态的处理。所提供的形式化片段将这些状态标识为该审计语义边界的一部分。

G 可追溯的金标准失败示例 · GOLD–C3 不完整或低信号操作 · H 补充材料内容

论文提供了536个经人工裁定、可追溯的失败案例,涵盖四类症状和三个多智能体系统框架,并给出具有代表性的证据支持定位。补充材料包含完整的 SymTrace 源代码和 SymFail 数据集。

  • G 可追溯的金标准失败示例: 536个最终案例覆盖 AG2、CrewAI 和 Magentic-One 中的 WebArena-Verified 与 AssistantBench,涵盖 C1–C4,各类别数量分别为125、69、203和139。展示的金标准示例是定性追踪证据,而非模型准确率估计。
  • G 可追溯的金标准失败示例: 每个选定示例均保留标识符、追踪摘录、证据支持的定位信息和原始日志路径,其中原始日志包是权威记录。示例选择按症状类别分层,而非依据有利结果。
  • G 可追溯的金标准失败示例: C1 将不完整答案定位到末端 final_result 节点,尽管此前的工具请求均已成功并检索到证据。该节点返回了另一个浏览操作,而不是符合条件的超市名称,因此失败并非由资源不可用造成。
  • G 可追溯的金标准失败示例: C2 将重复的 Wikipedia 请求识别为失败位置,因为轨迹陷入循环,没有沿着所需的多跳任务继续推进。重复的 HTTP 200 响应无法解释该失败;预期输出为 relation_id=2176999 和 duration=01:33:00。
  • GOLD–C3 不完整或低信号操作: C3 将失败追溯至未解析的环境占位符:在观察到订单历史之前已出现 MissingSchema 和 ConnectionError,而输出的58.99不同于评估器数值406.53。完整数据包并不缺少溯源文件;低信号条件来自未解析的执行上下文。
  • GOLD–C3 不完整或低信号操作: C4 揭示了计划–行动–结果之间的不一致:智能体展示看似合理的排序产品数据,同时承认仍需浏览,且没有发生真实的工具事件。虚构的产品及价格与预期记录不符,因此该缺陷属于证据问题,而不仅仅是格式问题。
  • H 补充材料内容: 代码和数据补充材料包含研究中使用的完整 SymTrace 源代码和完整 SymFail 数据集。
Loading 2608.25920v1…