源文件信息

📄 源 PDF：E:/obsidian/daily/paper/02_Where_Do_Deep_Research_Agents_Go_Wrong.pdf

🌐 HTML 报告：E:/obsidian/daily/paper/Where_Do_Deep_Research_Agents_Go_Wrong_Analysis.html（含 KaTeX 公式渲染）

📚 arXiv：2606.02060

💻 代码：NJU-LINK/DRIFT

📊 数据集：HuggingFace/TELBench

Where Do Deep-Research Agents Go Wrong? Span-Level Error Localization in Agent Trajectories

作者：Jiaming Wang, Ziteng Feng, Jiangtao Wu, Ruihao Li, Qianqian Xie, Yuxiang Ren, He Zhu, Xueming Han, Fanyu Meng, Junlan Feng, Jiaheng Liu

机构：NJU-LINK 等

一句话总结

本文提出首个深度研究智能体轨迹的跨度级错误定位基准 TELBench 与审计框架 DRIFT，通过”声明追踪—证据核查—依赖回溯”三阶段流程，将错误定位 F1 提升 28–33 个百分点，揭示当前智能体的核心脆弱性在于早期有害承诺的传递与继承，而非仅最终答案的表象错误。

1. 研究背景与动机

深度研究智能体（deep-research agents）正迅速成为大语言模型应用的前沿形态。这类系统通过长轨迹的搜索、工具调用、证据审查与答案合成，解决从科学文献综述到复杂知识问答的各类任务。OpenAI 的 Deep Research、Google 的 Gemini Deep Research 以及 Perplexity 等产品，都代表了这一范式的工程化落地。

然而，当前对这类智能体的评估几乎完全聚焦于最终答案正确性（final-answer correctness）。一条轨迹无论中间经历了多少错误的推理、虚假的证据引用还是过早的结论固化，只要最终输出碰巧正确，就会被判定为成功。这种评估方式掩盖了一个根本性问题：深度研究轨迹更应被视为记录决策过程（recorded decision process），而非单次输入输出计算。正如作者在 Introduction 中指出的，“the harmful step is often not the visibly wrong final answer, but an earlier commitment that later spans inherit without revalidation”——真正有害的步骤往往不是最终答案的表面错误，而是早期被后续跨度不加验证地继承的承诺。

这一观察催生了一个核心研究问题：如何在长轨迹中定位最早的有害错误跨度（earliest harmful span）？这不仅是可解释性的需求，更是安全性的要求：如果一个智能体在轨迹早期就做出了错误承诺，并在后续步骤中不断引用和强化这一承诺，那么即使最终答案碰巧正确，其推理过程也是不可靠的，未来可能在类似场景中导致系统性失败。

现有工作在这一方向上的探索相对匮乏。传统的智能体评估框架如 AgentBench、SWE-bench 等关注任务完成率；过程监督（process supervision）研究如 OpenAI 的 PRM（Process Reward Model）侧重于逐步奖励建模，但缺乏对”有害跨度”的精确定义与标注；而可解释性工作多集中于单轮输出的归因分析，难以处理长轨迹中跨度的复杂依赖关系。本文正是在这一空白中切入，提出了**跨度级错误定位（span-level error localization）**这一新任务，并构建了首个大规模基准与审计框架。

作者从两个智能体框架、三个骨干模型和三个基准测试中收集了 2,790 条真实轨迹，通过 LLM 辅助的专家审查进行语义跨度标注，最终筛选出 1,000 条构成 TELBench。在此基础上，他们设计了 DRIFT（Decision Review through Inherited Fault Tracing）框架，以声明为中心（claim-centric）对轨迹进行审计。

2. 预备知识

2.1 语义跨度（Semantic Span）

在本文的语境中，一条深度研究轨迹被切分为有序的语义跨度（semantic spans）。每个跨度代表智能体在某一阶段的决策单元，可能是搜索查询、工具调用、证据审查、候选答案评估或最终答案生成。与原始操作日志（raw action logs）不同，语义跨度强调决策意图而非执行动作：一个跨度可能包含多次搜索和浏览，但其语义功能是”验证候选实体 X 的属性 Y”。

形式化地，一条轨迹 $T$ 由有序跨度集合 $S = {s_{1}, s_{2}, \dots, s_{n}}$ 组成，每个跨度 $s_{i}$ 具有跨度文本 $s_{i} . text$ 、跨度标识 $s_{i} . span_id$ 以及原始步骤范围 $[s_{i} . raw_start_step, s_{i} . raw_end_step]$ 。TELBench 中轨迹平均包含 $\overset{n}{ˉ} = 11.95$ 个跨度。

2.2 错误定位任务定义

给定问题 $q$ 和轨迹 $T$ ，跨度级错误定位任务的输出是一个跨度子集 $E \subseteq S$ ，其中每个 $e \in E$ 是一个有害错误跨度（harmful error span）。一个跨度被判定为有害错误，当且仅当满足以下条件之一：

该跨度本身包含已承诺的有害错误（committed harmful mistake）；
该跨度包含无支持的已承诺结论（unsupported committed conclusion）；
该跨度实施了有害过早固化（harmful premature finalization）；
该跨度实施了有害延续（harmful continuation），即明确依赖或固化了早期错误承诺。

关键地，任务还要求输出最早有害跨度 $e^{*} = min E$ （按轨迹顺序），即第一次有害承诺发生的位点。这一指标被称为首次错误准确率（First-Error Accuracy, FEA），是 TELBench 的核心评估指标之一。

2.3 声明（Claim）与承诺状态

DRIFT 框架的核心抽象是声明（claim）。声明是智能体在轨迹中形成的关于实体、约束、证据解释、检索覆盖范围、计算结果或过程假设的命题。每个声明具有四种承诺状态（commitment status）：

exploratory（探索性）：仅搜索、试探或列出候选，未加选择；
tentative（尝试性）：提出候选但尚未驱动后续工作；
consequential（关键性）：驱动了后续工作路径，但尚未最终固化；
finalized（已固化）：被提交、用于最终答案或被显式视为已解决。

这一状态机的设计精确刻画了智能体从”试探”到”承诺”的认知演进过程，也是 DRIFT 能够区分”无害探索”与”有害承诺”的理论基础。

3. 方法详解：DRIFT 框架

DRIFT 是一个三阶段审计流程，模拟人类审计员审查决策记录的逻辑：先理解决策清单（Claim Keeper），再核查每项决策的证据支持（Support Seeker），最后定位哪些证据不足的决定造成了实际伤害（Dependency Tracer）。以下分别详述。

3.1 Stage A: Claim Keeper — 声明账本构建

Claim Keeper 对完整有序轨迹进行全局遍历（global pass），构建声明账本（claim ledger）。账本记录每条决策关键声明的完整生命周期：

$L = {(c_{i}, intro_{i}, consq_{i}, used_by_{i}, τ_{i}, σ_{i})}_{i = 1}^{m}$

其中 $c_{i}$ 为声明文本， $intro_{i}$ 为首次引入该声明的跨度， $consq_{i}$ 为该声明首次变为关键性的跨度， $used_by_{i}$ 为后续引用该声明的跨度集合， $τ_{i} \in {entity, constraint, evidence, retrieval, compute, process}$ 为声明类型， $σ_{i} \in {exploratory, tentative, consequential, finalized}$ 为承诺状态。

Claim Keeper 的设计遵循一条关键原则：只保留决策关键声明（decision-critical claims），即那些选择答案路径、限定到单一候选、验证硬性约束、支撑最终回复或解释为何无法作答的声明。普通的搜索查询、被放弃的候选、宽泛计划或工具噪声除非被后续答案/中止决策显式依赖，否则不创建声明。作者强调，账本应保持紧凑（prefer 3–5 claims），因为”只有可能改变最终错误决定的少数声明才值得记录”。

从源码角度看，Claim Keeper 的实现位于 src/drift_open/prompts.py:61–110（build_claim_keeper_prompt 函数）。提示词以 “DRIFT Audit Room - A: Claim Keeper” 为系统身份，要求模型读取问题和有序轨迹作为审计账本而非最终裁判，追踪实体、约束、日期/范围、证据解释、检索覆盖范围、计算结果和过程/工具假设等关键声明。

一个值得注意的设计细节是：即使第一条跨度（s001）已经陈述了最终答案、选定了候选或做出了无法回答的决策，也应将其视为声明。这一规则防止了审计盲区——早期跨度中的承诺往往是最容易被忽视的，因为它们可能被后续大量”看似正常”的操作所掩盖。

3.2 Stage B: Support Seeker — 证据支持核查

Support Seeker 的核心任务是检查每个关键性（consequential）或已固化（finalized）声明是否在轨迹证据中有充分支持。它为每个声明分配四种支持状态之一：

direct：获取的跨度明确验证了决定性身份、硬性约束、来源链接、精确计数/计算、检索覆盖范围或无法作答的正当理由；
weak：证据相关，但决定性桥梁仅被暗示、假设、基于部分片段或未对照精确问题验证；
missing：已固化的答案/无法作答/计算声明缺乏获取支持中的必要决定性链接；
conflicting：获取的证据与声明或硬性约束矛盾。

Support Seeker 的一个关键设计选择是高召回率的按需证据访问（on-demand evidence access）。它不是将整个轨迹送入模型，而是通过 span_store.py 中实现的 graph-grep chunk retrieval 机制，根据 Claim Keeper 产生的声明端点和声明文本，精确检索最相关的证据片段。

具体而言，SpanStore.chunked_evidence_packet（src/drift_open/span_store.py:82–140）执行以下操作：

对每个声明，提取其引入/关键/被引用跨度作为种子跨度（seed spans）；
使用声明文本作为查询，通过 grep_chunks 在轨迹跨度中进行关键词匹配检索；
对每个跨度文本按 chunk_chars=1800 字符分块，chunk_overlap=160 字符重叠，计算查询词项的匹配分数；
返回按分数排序的前 max_matches_per_query=4 个匹配块，总计不超过 max_total_chunks=18 个块。

这一设计的精妙之处在于证据访问的局部性与可控性：审计器只接触与当前声明直接相关的原始轨迹文本，而非被标注、摘要或预处理过的信息。这降低了审计器被误导的风险，也使得整个框架的计算成本可控。

在提示词设计（src/drift_open/prompts.py:150–200）中，Support Seeker 被明确要求”Prefer weak over direct when unsure”（不确定时优先标记为 weak 而非 direct）。这一保守策略确保 Stage B 不过早清除风险声明——正如作者所述，“This B step may over-route because C will later decide which risky claims become harmful errors”（B 阶段可能过度标记，因为 C 阶段会后续决定哪些风险声明转化为有害错误）。

3.3 Stage C: Dependency Tracer — 依赖回溯与错误定位

Dependency Tracer 接收声明账本 $L$ 和支持记录 $R$ ，输出最终的有害错误跨度集合 $E$ 。其决策逻辑基于两条核心规则：

首次错误选择规则（First-Error Selection Rule）：选择最早的已获取跨度，该跨度将风险声明陈述为已解决、将其选定为答案路径、基于它完成计算或用它停止任务。不选择查询或片段中的最早提及——必须是实质性的承诺行为。

关联错误规则（Linked-Error Rule）：包含后续已获取跨度，这些跨度显式重复、基于其计算、验证其为最终结论、因它而放弃或固化同一风险声明。

形式化地，设 $R_{risky} = {r \in R ∣ r . status \in {weak, missing, conflicting}}$ 为风险支持记录集合。对于每个 $r \in R_{risky}$ 对应的声明 $c$ ，Dependency Tracer 追溯：

$e^{*} = min {s \in S_{fetched} ∣ s commits to, finalizes, or computes from c}$

$E = {e^{*}} \cup {s \in S_{fetched} ∣ s explicitly reuses or amplifies c after e^{*}}$

其中 $S_{fetched} \subseteq S$ 为 evidence packet 中实际获取的跨度集合，确保审计器仅基于已审查的证据做出判断。

源码中，Dependency Tracer 的提示词位于 src/drift_open/prompts.py:202–245。其输出严格限制在 evidence_packet.available_span_ids 范围内，并返回 first_error_span、linked_error_span_ids、non_errors、reason、error_span_ids 和 earliest_harmful_span_id 六个字段。

runner.py 中的 run_drift 函数（src/drift_open/runner.py:93–154）将三阶段串联为完整流水线。值得注意的是，在获取 trace 后，还有一步 add_late_support_endpoints（第 76–88 行），用于处理 Claim Ledger 中关键声明的完成端点：如果当前预测的错误跨度非空，则将所有在首个错误之后的关键声明完成端点也加入错误集合。这一后处理步骤确保了”有害承诺链”的完整性——智能体不仅在首次承诺时犯错，在后续的每一次重申和固化中都在延续这一错误。

3.4 与基线方法的对比

论文对比了多种基线方法，核心对比是 Bare（裸单调用评估）与 DRIFT（完整声明中心流水线）。Bare 方法仅将问题与所有有序跨度文本一次性输入模型，要求直接预测最终错误跨度。这模拟了传统的”端到端”评估方式。

维度	Bare（端到端）	DRIFT（声明中心）
输入	问题 + 全部跨度文本	问题 + 分阶段结构化提示 + 按需证据片段
推理深度	单次调用	三次串行调用（Claim → Support → Trace）
错误定位粒度	直接猜测错误跨度	追踪声明生命周期与证据支持链
可解释性	仅输出错误跨度 ID	输出完整声明账本、支持记录与追溯理由
计算开销	单条轨迹约 6K tokens	单条轨迹约 18K tokens（GPT-5.4）

作者还对比了 Codex 和 Claude Code 等基线，发现它们”呈现不一致的提升甚至可能降低性能”（inconsistent gains and can even degrade performance），这进一步验证了声明中心设计的必要性与稳健性。

4. 实验分析

4.1 实验设置

TELBench 包含 1,000 条实例，覆盖两个智能体框架、三个骨干模型（DeepSeek-V3.2、GPT-5.4、Claude-Sonnet-4.6 等）和三个基准测试（具体任务域未在正文中详述，但从数据规模推断覆盖知识问答、事实核查与推理任务）。每条轨迹平均包含 11.95 个语义跨度，专家标注了最早有害跨度与所有关联错误跨度。

评估指标包括：

Macro-F1：跨实例平均的精确率-召回率调和均值，用于衡量错误跨度识别的整体准确性：

$Macro-F1 = \frac{1}{N} \sum_{i = 1}^{N} \frac{2 \cdot P _{i} \cdot R _{i}}{P _{i} + R _{i}}, P_{i} = \frac{∣ E _{i}^{gold} \cap E _{i}^{pred} ∣}{∣ E _{i}^{pred} ∣}, R_{i} = \frac{∣ E _{i}^{gold} \cap E _{i}^{pred} ∣}{∣ E _{i}^{gold} ∣}$

First-Error Accuracy (FEA)：预测的首个错误跨度与标注的首个错误跨度完全一致的比例：

$FEA = \frac{1}{N} \sum_{i = 1}^{N} 1 [min E_{i}^{pred} = min E_{i}^{gold}]$

FEA 是 TELBench 最具区分度的指标：它要求模型不仅能识别所有错误跨度，还要精确定位最早的有害承诺——这是过程级可靠性评估的核心。

4.2 主要结果

Table 2（对应论文 Figure 4）展示了 DRIFT 在四个模型上的主实验结果：

模型	方法	Macro-F1	FEA (%)
DeepSeek-V3.2	Bare	22.46	10.30
DeepSeek-V3.2	DRIFT	50.51	23.70
GPT-5.4	Bare	33.93	14.90
GPT-5.4	DRIFT	52.48	20.80
Claude-Sonnet-4.6	Bare	21.89	11.30
Claude-Sonnet-4.6	DRIFT	54.91	24.10
Gemini-2.5-Pro	Bare	31.01	15.70
Gemini-2.5-Pro	DRIFT	48.41	19.90

数据解读如下：

第一，DRIFT 在所有模型上实现了显著且一致的改进。 Macro-F1 提升范围为 16.40（GPT-5.4）到 33.02（Claude-Sonnet-4.6）个百分点，相对提升幅度在 48%–151% 之间。这表明声明中心审计范式具有跨模型泛化能力，不依赖于特定模型的内部特征。

第二，首次错误准确率（FEA）的提升虽然绝对值较小，但相对意义重大。 FEA 从 10–16% 提升至 20–24%，看似翻倍，但绝对值仍远低于 50%。这揭示了论文的核心论断之一：scaling alone is insufficient and first-error localization remains challenging——仅靠扩大模型规模不足以解决首次错误定位问题。即使是最强的 GPT-5.4 搭配 DRIFT，FEA 也仅为 20.80%，说明精确定位最早有害承诺仍然是一个极具挑战性的任务。

第三，裸方法（Bare）的表现揭示了模型自身的盲点。 GPT-5.4 的 Bare F1（33.93）显著高于 Claude-Sonnet-4.6（21.89），但在 DRIFT 加持下，Claude-Sonnet-4.6 反超至 54.91，成为最佳表现模型。这说明模型的最终答案正确性与过程审计能力并不等价——一个最终答案更准确的模型，未必更擅长识别自身或他者轨迹中的早期错误。

4.3 消融实验

Figure 5(c) 展示了模块消融实验（Module Ablation）：随着 Claim Keeper、Support Seeker 和 Dependency Tracer 三个模块逐步加入，性能稳步提升。这验证了每个模块的独特贡献：

仅 Claim Keeper（结构化的声明提取）已能带来可观增益，因为模型从无结构的跨度文本中提取出了决策逻辑；
加入 Support Seeker 后，增益进一步扩大，因为证据支持的显式核查暴露了原本被掩盖的风险；
Dependency Tracer 的引入则将风险声明映射为具体的有害跨度，完成了从”发现问题”到”定位问题”的闭环。

4.4 错误类型分析

Figure 6 展示了 DRIFT 在不同错误类型上的跨度级召回率。作者发现 DRIFT 在证据相关失败（evidence-related failures）和约束相关失败（constraint-related failures）上的提升尤为显著。这与框架的设计直觉一致：Claim Keeper 显式追踪证据解释和硬性约束声明，Support Seeker 专门核查这些声明的支持状态，而 Dependency Tracer 则回溯这些风险如何演变为有害承诺。

5. 讨论

5.1 方法的适用边界

DRIFT 的设计隐含了几个适用边界。首先，它假设轨迹可以被有意义地切分为语义跨度，且跨度之间存在可追踪的声明依赖关系。对于极度混乱、缺乏结构化输出或声明边界模糊的智能体轨迹，Claim Keeper 可能无法提取出清晰的声明账本。其次，DRIFT 依赖于 LLM 作为审计器，这意味着审计质量受限于审计模型自身的推理能力与事实知识——一个审计模型可能无法识别超出其知识范围的证据矛盾。

5.2 对行业的启示

本文对深度研究智能体的工程实践具有直接指导意义。当前业界普遍以最终答案正确性作为核心优化目标，但本文表明，一个最终正确的答案可能建立在一系列脆弱的早期承诺之上。这种”正确但不可靠”的轨迹在高风险场景（如医疗咨询、法律研究、金融分析）中尤为危险：今天碰巧正确的答案，明天可能因为相似但略有不同的输入而导致系统性失败。

论文提出的过程级可靠性评估范式，为智能体系统的安全审计提供了可操作的工具链。TELBench 可作为回归测试集，DRIFT 可作为持续集成中的审计组件，在部署前自动识别轨迹中的有害承诺模式。

5.3 对未来工作的启示

作者指出了几个值得探索的方向：将审计框架扩展到实时干预（在轨迹执行过程中检测并纠正有害承诺，而非事后分析）；设计更轻量级的审计流程以降低计算开销；以及开发专门针对首次错误定位的优化目标与训练数据。

6. 局限分析

6.1 作者自述的局限

作者在 Conclusion 中明确指出了两项核心局限。第一，scaling alone is insufficient——实验数据显示，即使使用当前最强的商用模型（GPT-5.4、Gemini-2.5-Pro、Claude-Sonnet-4.6），首次错误准确率也仅达到 20–24% 的水平。这意味着错误定位能力的瓶颈不在于模型容量，而在于任务本身的复杂性或现有方法范式的局限性。

第二，first-error localization remains challenging——在所有指标中，FEA 的提升幅度相对最小，且绝对值最低。这表明定位”最早的有害承诺”比识别”所有错误跨度”困难得多，因为早期承诺往往被包装在看似合理的探索性语言中，其有害性只有在后续依赖链中才能完全显现。

6.2 独立判断的局限

基于对论文与代码的深入分析，我认为还存在以下未被充分讨论的局限：

计算成本较高。 Appendix D（Table 5）显示，DRIFT 在 GPT-5.4 上平均消耗 17,653 tokens/轨迹，而 Bare 仅需 5,988 tokens。Gemini-2.5-Pro 的 DRIFT 消耗更高达 53,043 tokens，主要原因是其 thinking tokens 的开销。这使得 DRIFT 在大规模实时审计场景中的部署成本成为一个实际问题。虽然作者声称”DRIFT achieves a favorable efficiency-performance trade-off”（Figure 5d），但这一结论可能更适用于离线评估场景而非在线生产环境。

审计器自身的错误传播风险。 DRIFT 的三个阶段全部依赖 LLM 推理，每一阶段都可能产生错误：Claim Keeper 可能遗漏关键声明或误判承诺状态；Support Seeker 可能错误分配支持状态（将 direct 标记为 weak 或将 missing 标记为 direct）；Dependency Tracer 可能在复杂的依赖链中误判因果方向。这些错误会在阶段间传播与放大，形成”审计器的审计器”问题——目前尚无机制来验证审计器自身的可靠性。

对声明可提取性的强假设。 代码中 Claim Keeper 的提示词明确要求模型”prefer 3–5 claims”，这一紧凑性约束在简单轨迹上合理，但在高度复杂的多实体、多约束任务中可能导致声明遗漏。此外，声明类型（entity/constraint/evidence/retrieval/compute/process）的分类是离散的，而实际决策逻辑可能是连续或混合的。

7. 结论

本文通过 TELBench 基准与 DRIFT 框架，将深度研究智能体的评估从”最终答案正确性”推进到”过程级可靠性”的新维度。其核心贡献不仅在于提出了一个具体的技术方案，更在于揭示了一个被长期忽视的评估盲区：智能体的可靠性不能仅由其输出的最终答案来定义，而必须追溯其决策过程中的每一次关键承诺及其证据基础。

从技术角度看，DRIFT 的三阶段声明中心审计流程（Claim Keeper → Support Seeker → Dependency Tracer）为长轨迹错误定位提供了一个可扩展、可解释的解决方案。实验结果表明，该方法在多种商用模型上实现了 28–33 个百分点的 F1 提升，验证了声明追踪范式的有效性。

然而，首次错误准确率仍然停留在 20–24% 的低位，提醒我们这一领域仍处于早期探索阶段。未来的工作需要在审计效率、实时干预能力与错误定位精度之间寻找更优平衡，并建立对审计器自身的元级验证机制。正如作者所言，我们需要”evaluate deep-research agents through process level reliability, rather than final outcomes alone”——这条从”结果正确”到”过程可靠”的评估范式转换，或许正是下一代可信 AI 系统的必经之路。

💡 核心金句

“The harmful step is often not the visibly wrong final answer, but an earlier commitment that later spans inherit without revalidation.”

—— 真正有害的步骤往往不是最终答案的表面错误，而是早期被后续跨度不加验证地继承的承诺。

我的知识库

探索

Where Do Deep-Research Agents Go Wrong? — 学术深度解读