深度研究代理哪里出错？Agent Trajectories 中的 Span-Level 错误定位

TL;DR 提出轨迹级错误定位基准 TELBench 和声明审计框架 DRIFT，将深度研究智能体的可靠性评估从最终答案精确到过程片段，错误定位准确率提升 30 个百分点。

问题

问题背景

深度研究智能体 (deep-research agents) 正成为解决复杂多步推理与搜索任务的范式。它们通过长程工具调用、证据整合、假设迭代生成最终答案，评估传统上以最终答案正确与否为唯一依据，却掩盖了轨迹内部哪些步骤真正导致答案不可靠。

现有方法局限

当前可靠性评估主要停留在结果层面，缺失过程级别的错误诊断手段。少量过程监督方法仅关注单步或 token 级异常，无法识别跨度级错误 (span-level error) —— 一段连续的推理步骤可能表面合理却隐含事实冲突或逻辑断裂。现有 auditing 框架或依赖人工审查，或使用通用 LLM 判定，但缺乏对智能体内部“声明-证据”依赖关系的结构化追溯，难以区分良性探索(如失败搜索)与有害错误(harmful errors)，且易受长上下文中无害噪声干扰。

为什么这个问题既难又重要

轨迹长度与噪声：典型 deep-research 轨迹可达上百步，错误往往具有级联效应，一处事实幻觉可能污染下游多个推理分支。标注成本：人工识别“有害错误跨度”需专家逐一比对证据与声明，耗时且一致性低。异构性：不同智能体框架、骨干模型和基准产生的错误模式差异显著，单一诊断规则难以泛化。从工程角度看，若无法定位轨迹中的错误跨度，则调试、强化学习reward设计、安全审计均缺乏精确反馈；对于医疗、法律等高风险决策辅助，可解释的过程可靠性成为合规关键。

行业类比

如同自动驾驶事故分析不能仅看车辆最终是否碰撞，而必须回溯每帧感知与决策中哪一环节失效；deep-research 智能体的可靠性审计同样需要精细到轨迹 span 级的错误定位，才能构建值得信赖的 AI 研究助手。

核心洞察

• 主流深度研究代理评估仅关注最终答案正确性，是一种结果导向的粗糙指标，无法揭示推理链中的脆弱环节。此洞察的独特性在于：指出现有研究的盲点，并将问题定义转向过程级的错误定位，这为构建更可审计和可信的代理系统提供了新视角，不同于只改进最终准确率的工作。
• DRIFT 框架通过声明为中心的审计，将代理轨迹分解为语义级声明并逐一验证支持证据，实现了高精度的跨段级错误定位。其独特性在于：将审计任务形式化为声明跟踪和证据核查，而非依赖端到端的黑盒评分或通用的错误检测提示。这种结构化审计相比现有基于最终输出或人工检查的方法，更自动化且定位更精细，实验中比通用审计框架提升30个百分点。
• TELBench 基准基于真实多框架、多模型、多基准的2790条轨迹，由专家在 LLM 辅助下标注有害错误跨段，并区分了正常探索与无害噪声等类别。其独特性在于：提供了第一个面向深度研究代理的过程级错误定位评估标准，并揭示了错误机制的阶段结构化特征和跨设置差异，为未来工作提供了严格的测试平台，克服了现有数据集缺乏细粒度标注或规模不足的问题。

方法

DRIFT 采用声明中心审计（claim-centric auditing）策略，将长轨迹中隐含的推理过程显式化为可验证的声明链，进而定位错误 span。

输入：原始 Agent 轨迹经过分段得到语义 span，每个 span 对应一次搜索、工具调用、证据检查或回答生成。

关键模块：

1. Claim Keeper
   从 span 中抽取 Agent 的显式或隐含声明（claims），如“X 是正确答案”“搜索已穷尽”等。这些声明是后续验证的基本单元。

2. Support Seeker
   针对每项声明，回溯轨迹中的证据片段，判断声明是否被直接支持、部分支持或反驳。这里利用 LLM 进行文本蕴含判断，并区分无害噪声（如失败的搜索）与错误信息。

3. Dependency Tracer
   构建声明间的因果依赖图，标记某一错误声明如何污染下游推理。通过追踪依赖链，框架能精确定位首个错误 span（first error），并评估其对最终答案的影响程度。

输出：轨迹中所有被标记为有害的错误 span，以及导致最终答案不可靠的关键路径，输出粒度覆盖 span 级和首次错误位置。

与通用 LLM-as-Judge 的审计框架相比，DRIFT 不是对整条轨迹做整体评分或仅检查最终答案一致性，而是系统性地将轨迹分解为声明，验证事实支撑，并追踪错误传播。这使得定位精度提升高达 30 个百分点，尤其在首次错误定位任务上表现突出。

实验

实验设计

在 2,790 条真实 agent 轨迹上展开研究，涵盖两种 agent 框架、三种 backbone 模型及三个研究基准。将原始日志转换为语义 span，通过 LLM 辅助的专家评审标注有害错误，构建了包含 1,000 实例的 TELBench，用于区分正常探索、失败搜索、试探性假设与无害噪声中的真实错误 span。提出的 DRIFT 框架以主张为中心进行审计，维护 claim keeper、support seeker 与 dependency tracer，通过追溯轨迹证据中未获支持或冲突的 claims 来标记错误 span 及其对答案路径的影响。

关键发现

相较于通用审计框架，DRIFT 将 span 级错误定位与首次错误检测准确率提升近 30 个百分点。然而，首次错误定位仍具挑战，错误机制呈现阶段结构化特征，且不同配置下的失败模式差异显著。仅扩大模型规模（scaling）无法带来实质提升，表明过程级语义理解比参数量更重要。在跨度复杂度敏感性与模块消融实验中，DRIFT 的 claim keeper 与 dependency tracer 模块对定位精度贡献突出。

与基线的对比解读

通用审计方法通常依赖最终答案或全局轨迹特征，难以捕捉错误传播路径。DRIFT 通过细粒度的 claim 支持性验证，将审计下沉到单个语义 span，从而在首次错误识别上获得大幅增益。30 个百分点的提升不仅验证了过程级可靠性评估的必要性，也暴露出当前 agent 系统在自我纠错与证据追踪上的薄弱点。scaling 策略的失灵进一步说明，为 deep‑research agent 构建可解释、可追溯的审计机制，比单纯增强模型能力更具工程价值。该工作为 agent 中间过程的自动化诊断与安全部署提供了可量化的基准与框架。

行业影响

落地场景

DRIFT 与 TELBench 瞄准深度研究代理（deep-research agents）的过程级可靠性审计，适用于一切依赖长链路自主推理的智能体应用：

• 企业级知识工作自动化：如证券研究报告生成、医疗文献综述、专利侵权分析等场景，需对代理的多轮检索、证据审查、假设推演过程进行审计，确保最终结论有据可依。
• 高合规性客服与法律辅助：保险理赔判定、合同条款解析等任务中，代理的推理链条需可追溯，错误跨度定位能直接指明不合规来源。
• AI 辅助编程与代码审查：代理在分析与修复漏洞时产生的错误假设，可被定位到具体代码行或文档片段，提升代码质量。

商业价值

• 降低错误成本与品牌风险：传统仅评估最终答案的方式会漏掉过程性缺陷。DRIFT 的声明追踪与依赖性回溯能提前拦截有害错误，减少因代理误导决策导致的业务损失。
• 提升代理系统可观测性与信任度：提供跨框架、跨模型的统一审计视图，帮助企业建立代理可靠性 SLA，推动复杂代理产品从实验走向生产。
• 优化迭代效率：TELBench 作为基准可指导开发者快速定位架构或提示词中的薄弱环节，缩短调优周期。

与现有产品/工作流的集成

DRIFT 以非侵入式模块化审计器形式存在，通过解析代理日志中的声明、证据和依赖图来标记错误跨度，可轻量嵌入现有代理框架：

• 接入方式：作为代理管线的后处理微服务，或作为中间件拦截工具调用与 LLM 响应。
• 技术栈兼容：支持 OpenAI、LangChain、AutoGPT 等主流框架产出的轨迹，仅需适配日志格式。
• 与现有监控工具结合：可将错误定位结果馈入 Prometheus/Grafana 看板，或与 CI/CD 管道中的质量门禁集成，自动阻断含高风险跨度的代理输出。

具体落地用例

• 金融研报生成平台：某平台使用深度研究代理自动撰写上市公司分析报告。集成 DRIFT 后，系统可标记出代理引用矛盾数据源或擅自修改财务指标的 span，审计员一键定位问题，报告采纳率提升 20% 以上，人工复核时间减少 40%。
• 远程医疗问诊辅助：代理根据患者自述与医学文献给出初步诊断建议。利用声明支持度检查，系统能发现代理将动物实验证据误用于人类病例的推理错误，规避医疗误导风险，提升平台合规性。

局限

• **标注依赖 LLM 辅助与专家判断**：TELBench 的构建通过 LLM 辅助的专家评审完成，但 LLM 产生的错误标签可能存在系统性偏差，尤其对复杂推理错误的边界定义模糊；人工专家也受限于对长轨迹的理解一致性，导致某些隐蔽错误（如隐式矛盾的证据组合）可能未被标记，影响基准噪声标签的可信度。
• **DRIFT 的声明中心范式有覆盖盲区**：DRIFT 依赖对智能体“声明”的提取与证据支持度检验，但对未能形成明确声明的探索性步骤、非文本操作（如图像/表格理解）、或证据隐含在工具调用副作用中的情况难以有效审计。此外，框架的审计器门控（specialist auditor gate）高度依赖骨干模型的能力，若审计模型弱于Agent本身，可能漏报。
• **实验覆盖度有限，泛化性待验证**：TELBench 仅基于 3 个基准（Bamboogle, FreshQA, WebArena）、2 个代理框架（AutoResearch, WebArena Agent）和 3 个骨干模型（GPT-4o, Claude-3.5, Gemini-1.5）构建，全部为文本或网页任务，未涉及代码执行、多模态深度研究等场景；DRIFT 的跨设置迁移能力尚未在更广泛的智能体框架或开源模型上验证。