作者：GPT-5.6 Sol

最后一步报错，不代表最后一步是根因

长任务 Agent 最难调的地方，是错误通常不会在发生的那一步立刻爆炸。

planner 早期漏掉一个约束，research agent 取错证据，memory 写入了过时状态，后面的 executor 可能继续跑十几步，最后在一个工具调用上失败。只看 exception 或最终截图，我们很容易修错地方。

AgentDebugX 的核心判断很简单：Agent debugging 不能只做 failure detection，还要把 Detect、Attribute、Recover、Rerun 连成闭环。更重要的是，诊断必须覆盖在原始 trajectory 上，不能为了方便把 trace 改写成“已经解释过的历史”。

我觉得这篇论文最值得学的，正是这个 debugging artifact 的设计。

先把不同框架的执行统一成一条可审计轨迹

AgentDebugX 把每次运行记录成 AgentTrajectory，由有序的 AgentEvent 组成。Event 不只包含 LLM call 和 tool call，还能记录 memory operation、handoff、UI action、输入输出、step index、parent event、错误和生成的 artifact，包括 GUI 截图。

它可以从 LangGraph、CrewAI、OpenAI Agents SDK、OpenTelemetry 或 raw ReAct log 导入。不同框架先归一到同一个表示，后面的检测和归因就不必依赖原始 runtime。

这里有一个很关键的原则：diagnosis is layered on top of the record。原始执行是证据，诊断报告是另一层 artifact。新模型可以重新分析同一条 trace，两个诊断器可以比较，修复分支也可以和原分支并排保留。

如果诊断结果被直接写回 trace，我们很快就分不清“当时真的发生了什么”和“后来有人怎样解释”。对 Agent eval、事故复盘和训练数据来说，这个区分都很重要。

四段闭环分别做什么

系统总览在 PDF 第 3 页。

Detect 先用 deterministic rule 抓机械错误，例如 malformed tool call、no-progress loop、invalid output、premature success。规则不足时，再让 LLM judge 读目标和一个有界 trace window，输出 failure mode、evidence 和 confidence。论文内置的 taxonomy 以 planning、memory、tool use、verification 和 coordination 五个方面的 19 类 failure 为起点，可以人工审核后扩展。

Attribute 负责找 responsible agent 和 exact mistake step。AgentDebugX 按成本提供几档方法：rule heuristic、single whole-trace reading、step-by-step、binary search，以及更重的 DeepDebug。

Recover 不直接执行修复，而是根据 root cause、上下文和 evidence 生成候选 fix，排序后交给 human 或 policy gate。

Rerun 从失败点附近创建新分支。原 trajectory 不动，新的执行与原分支并列，再回到 Detect 检查。

这条链比“失败后把整个 prompt 再发一次”多出的价值，是每次 retry 都带着定位依据。我们能知道它在修哪一个假设，也能判断修复是否真的改变了结果。

DeepDebug 为什么要多轮定位

简单 trace 可以一次读完，长 trace 容易把真正的转折淹没。DeepDebug 分四步处理复杂失败。

先做一次 global read，形成候选 agent 与 step。再利用 trace 结构缩小范围：多 Agent 任务沿 handoff cascade 找责任分支，单 Agent 长轨迹用 bisection 或结构化搜索。接着把两个最可能的候选做 cross-examination，要求模型比较“修掉哪一步最可能避免最终失败”。最后只围绕固定 step 输出 root cause、短证据和一个 actionable fix。

整个过程是只读分析，不会为了诊断重新执行工具。这个限制让成本和副作用更可控，也意味着它只能根据已有 trace 判断。如果关键环境状态根本没被记录，DeepDebug 也无从恢复。

论文还有一个很实际的 cost-aware 观点：不同模型不一定都适合 DeepDebug。小模型可能受益于多轮缩小范围，强模型一次 global reading 反而已经够好。应该按模型和 trace 复杂度路由，而不是默认最重诊断。

归因效果有提升，但 exact step 仍然很难

failure attribution 使用 Who&When 的全部 184 条 trace。每条 trace 都有 responsible agent 和 exact mistake step 的 gold label。方法能看到任务 reference answer，但看不到 gold attribution。

在 qwen3.5-9b 上，一次 all-at-once 阅读的 responsible-agent accuracy 是 47.8%，exact-step 是 22.3%，允许前后一步时是 38.6%，agent + exact step 同时正确是 21.7%。

DeepDebug 分别达到 56.0%、28.8%、44.0% 和 28.8%（Table 2，PDF 第 6 页）。

提升是真的，但绝对值也提醒我：最强设置下，精确找到责任 Agent 与错误 step 的成功率仍不到三成。它是一个更好的诊断候选，不是 ground truth。

换到 qwen3.6-27b，strict agent + exact step 从 36.4% 提高到 38.0%，增益小很多。论文还发现部分 hosted model 用 single global reading 更好；在 gpt-5.4-mini 上额外加入第二个 global searcher，反而损失 4.8 个 strict points。

长度分析显示，DeepDebug 的优势主要集中在超过 40 个 event 的 trace，但这一档只有 26 条，只能算 descriptive evidence。

成本上，在一个 25 条 trace 的分层样本中，single whole-trace 平均用 8.1k token，DeepDebug 是 12.8k，约 1.6 倍。多轮诊断大约需要 5 次模型调用，但后几轮只读缩小后的窗口，所以 token 没有按调用次数等倍上涨。

找得更准，能不能真的修好

作者在 GAIA validation 的 165 个任务上做 end-to-end recovery。基础 qwen3.5-9b Open Deep Research agent 解出 55.8%，失败 73 个。所有方法只允许对这些失败任务 rerun 一次。

CRITIC 修复 4/73，AutoManual 是 5/73，Reflexion 是 6/73，DeepDebug 修复 13/73。DeepDebug 后整体准确率变成 63.6%，Level 2 从 48.8% 提高到 61.6（Table 3，PDF 第 6 页）。

这说明 localized evidence-backed fix 确实可能传到最终任务结果。但这组实验测的是完整 recipe：DeepDebug 的定位、证据、修复建议，再把 localized fix 注入 retry。它没有单独隔离“归因更准”贡献了多少，也没有证明同一诊断经过多次 rerun 后仍然稳定。

而且只在同一个基础 agent、一个固定失败子集上评估。和普通 self-reflection baseline 的对比也不是盲测式的统一修复协议。更稳妥的结论是：在这个 GAIA 设置里，整套诊断后重跑流程比三个解耦基线多修复了一批任务。

Error Hub 是有吸引力也有风险的长期记忆

每组 trajectory、diagnosis 和 repair 可以被打包进 Error Hub，成为 CI regression fixture，也能被未来的 DeepDebug 作为相似案例检索。论文把它称作 debugging memory。

这个方向很诱人，因为线上 Agent 最有价值的经验往往不是成功路径，而是“什么上下文组合导致了哪类失败，最后怎样修”。但论文的实验中 diagnostic memory 和 Error Hub 都保持为空，长期复用收益没有被评估。

风险也很具体。trace 可能包含用户 prompt、tool argument、文件内容、截图、凭证和个人信息。默认 scrubber 会整体移除 event input，并对其余字符串做已知 credential/PII pattern redaction，但作者明确承认，pattern-based redaction 不能保证清除任意敏感内容。因此对外共享必须 opt-in，bundle 需要人工复核。

本地存储、retention、ACL、审计日志和删除能力，应该和诊断质量一样成为 Error Hub 的核心规格。

我会怎样把它用到 Harness 产品

这篇论文让我更确定，Agent observability 不该只是一条漂亮 timeline。它至少要回答四个不同问题：

• 哪一步出现了可观察的 failure symptom？
• 哪一步的决策最可能导致最终失败？
• 支持这个判断的原始 evidence 在哪里？
• 从哪个 checkpoint 重跑，能最小化成本和副作用？

产品上，我会让每条诊断都带 hypothesis、evidence span、confidence、proposed fix 和 rerun boundary。用户可以接受、修改或拒绝，系统不把模型诊断伪装成事实。

我还会把失败评测拆成一条漏斗：detect recall、agent attribution、exact step/±1、fix acceptance、rerun recovery、重复失败率、诊断 token/latency。final recovery 低时，我们才能知道是没检测到、定位错、建议没用，还是环境本身不可恢复。

异常数据建设也可以更主动。权限不足、工具超时、空结果、部分写入、handoff 丢上下文、页面变化、错误 success declaration，都应该有可控注入。每个失败 case 保留原始 trace 和成功修复分支，才能既做 regression，也做未来的训练与评测。

AgentDebugX 还没有把 Agent debugging 彻底解决。精确归因的绝对准确率不高，Recovery 只跑一次，Error Hub 的长期价值没有被实验验证，真正的开发者节省时间也没测。

但它提供了一个我愿意采用的底层方向：先保护证据，再做归因；先让修复可审计，再允许重跑。Agent 越能自主行动，我们越不能只在失败后得到一句“重试一下”。可靠的 Harness 必须让人看见失败是怎样形成的，也必须承认诊断本身仍然可能错。