TRAIL：追踪推理与代理问题定位

最新推荐文章于 2025-05-16 11:35:49 发布

Paper易论

最新推荐文章于 2025-05-16 11:35:49 发布

阅读量1.1k

点赞数 30

文章标签：大数据

本文链接：https://blog.csdn.net/u013524655/article/details/147968245

版权

Darshan Deshpande Varun Gangal Hersh Mehta

Jitin Krishnan Anand Kannappan Rebecca Qian

Patronus AI

{darshan, varun.gangal, hersh, jitin, anand, rebecca}@patronus.ai

摘要

随着代理工作流在各个领域的日益普及，迫切需要一种可扩展且系统化的方法来评估这些系统生成的复杂追踪。当前的评估方法依赖于对 lengthy 工作流追踪进行手动、特定领域的分析——这种方法无法适应代理输出日益增长的复杂性和数量。此外，在这些环境中进行错误分析更加复杂，因为外部工具输出和语言模型推理之间的相互作用使得其比传统软件调试更具挑战性。在本研究中，我们（1）阐述了对代理工作流追踪进行稳健和动态评估方法的需求，（2）介绍了一种针对代理系统中遇到的错误类型的正式分类法，（3）提出了一组由 148 条大型人工标注的追踪（TRAIL）组成的集合，该集合基于此分类法构建，并以已建立的代理基准为依据。为了确保生态有效性，我们从单代理和多代理系统中收集追踪，重点关注诸如软件工程和开放世界信息检索等实际应用。我们的评估显示，现代长上下文 LLM 在追踪调试方面表现不佳，其中最佳的 GEMINI-2.5-PRO 模型在 TRAIL 上仅获得 11% 的分数。我们的数据集和代码已公开发布，以支持和加速未来关于可扩展代理工作流评估的研究 ${ }^{1}$ 。

1 引言

大型语言模型（LLM）的快速发展推动了复杂代理系统的开发，这些系统能够自动化跨多个领域的困难、多步骤任务，例如软件工程和多跳信息检索（Ma 等人，2023；OpenAI，2024；Nguyen 等人，2024；Wang 等人，2025a）。与传统的生成模型不同，

图 1：TRAIL 错误分类法示意图
代理可以与各种工具交互，并在不确定的环境中动态导航，通常只需要最少的人工监督（Wang 等人，2024a）。这种系统复杂性的提升促使提出了更具有挑战性和多面性的评估过程（Nasim，2025），并导致采用 LLM 作为这些代理系统的评估者和批评者（Zheng 等人，2023；Chen 等人，2024；Kim 等人，2024；Zhu 等人，2025；Deshpande 等人，2024a）。

然而，随着多代理系统成为现实世界工作流程的重要组成部分，评估和调试其性能仍然是一个重大挑战。代理非确定性（Laban 等人，2025；Patronus AI，2025）和多步任务解决（Mialon 等人，2023；Yao 等人，2024）要求更高的可观测性，而现有的基准只能提供简单的端到端评估（Kapoor 等人，2024a；Zhuge 等人，2024；Moshkovich 等人，2025；Cemri 等人，2025）。这种复杂的环境需要详细的分类法和良好的注释追踪，以作为调试和根因分析代理行为的参考（Cemri 等人，2025）。在创建分类法和基准时测试和改进代理，我们必须确保这些基准基于实际应用，并遵循先前工作的原则（Bowman 和 Dahl，2021；Liu 等人，2024b）。以前的代理追踪分析框架主要关注包含非结构化文本的解析追踪（Cemri 等人，2025），这不能充分代表常见的代理框架输出，这些输出以标准化格式如 opentelemetry 记录的结构化追踪（OpenTelemetry，2025）。我们观察到处理结构化数据对 LLM 来说仍然具有挑战性（Guo 等人，2023；Sui 等人，2024），这一观察结果得到了之前关于自动化软件工程追踪分析研究的支持（Roy 等人，2024a；Ma 等人，2024b）。这些局限性突显了对专门设计用于结构化代理追踪的新方法的需求。为了解决这些挑战并促进结构化代理执行的分析和评估，我们提出了一个正式的错误分类法（见图 3），以促进精细的故障诊断。我们还展示了一个精心策划的逐轮注释追踪数据集，称为 TRAIL（Trace Reasoning and Agentic Issue Localization），它证明了我们提出的分类法的有效性和实用性。

在我们的工作中，我们利用并建立在 SWE-Bench（Jimenez 等人，2024；Aleithan 等人，2024）和 GAIA（Mialon 等人，2023）的基础上，同时解决了先前自动代理评估范式中的三个主要缺陷。首先，我们旨在用包含代理工作流逐步分析的基准取代端到端的代理分析（Mialon 等人，2023；Wang 等人，2025a；Jimenez 等人，2024；Huang 等人，2024）。其次，我们通过生成超出当前模型上下文长度限制的 opentelemetry 基础结构化追踪来满足真实场景的需求。最后，与仅关注代理推理和协调的基准相比（Cemri 等人，2025；Kokel 等人，2025），TRAIL 通过添加更细粒度的系统执行失败和规划错误类别（如 API 错误和任务编排错误）展示了其有效性。这些类别不仅对模型开发者相关，而且对优化单代理和多代理 AI 应用的用户和工程师也至关重要。我们的工作贡献如下：

我们引入了一个正式的分类法（图 1），定义了横跨三个关键领域的细粒度代理错误类别：推理、规划和执行。
1. 基于此分类法，我们介绍了 TRAIL，这是一个生态基础的执行追踪基准，包含 148 条精心策划的追踪（总计 1987 个开放遥测跨度，其中 575 个至少出现一个错误），这些追踪来自 GAIA（Mialon 等人，2023）和 SWE-Bench（Jimenez 等人，2024）数据集，并涵盖广泛的任务。
1. 我们表明 TRAIL 对 LLM 在许多方面都是一个非平凡的困难基准
(a) 当前的 SOTA LLM 家族如 O3、CLAUDE-3.7-SONNET 和 GEMINI-2.5-PRO 在 TRAIL 上的表现最多只能算是勉强及格，无论是在预测错误类别还是它们的位置方面。GEMINI-2.5-PRO 是表现最好的模型，但在两个分割上仅达到 11% 的联合准确率。
(b) 解决 TRAIL 需要 LLM 输入长度的显著部分（或超过它），还需要生成其最大输出的显著部分（见表 2）。
© 在 TRAIL 上进行基准测试的模型受益于推理链的存在及其更大范围，强调了提高 LLM 探索能力的必要性（§5.1.4，§5.1.5）。
1. TRAIL 是完全开源的（MIT 许可证），将附带一个 HuggingFace 排行榜，并作为未来研究评估代理工作流的基础。

2 相关工作

LLM-as-a-Judge 常规指标如 ROUGE、BLEU 和 BERTScore（Schluter，2017；Freitag 等人，2020；Hanna 和 Bojar，2021）的不足之处，导致了 LLM 被广泛用作其他 AI 系统的评估者和批评者（Zheng 等人，2023；Zhu 等人，2025；Chen 等人，2025，2024；Kim 等人，2024）。最近的方法通过无约束评估计划和专门的训练方法增强了 LLM 法官的推理能力，使其能够在多种场景下实现更稳健的评估性能（Lightman 等人，2023；Wang 等人，2024e；Trivedi 等人，2024；Saha
等人，2025）。随着 FLASK（Ye 等人，2024b）等框架的引入，评估领域发生了显著变化，这些框架将粗略评分分解为每个指令的技能集级别评估，显示出基于模型的评估与基于人类的评估之间高度相关。Prometheus 模型（Kim 等人，2023，2024，2025）通过创建超越 GPT-4 的主观评价标准排名的法官模型，确立了一个重要的基准。他们的研究还探讨了主观性增加时性能如何下降。最近，几项研究通过外部增强和清单提高了法官模型的性能，强调了在模型训练中结合高质量推理链和人类指导的重要性（Lee 等人，2025；Deshpande 等人，2024b,a；Chen 等人，2025；Wang 等人，2025b）。尽管有令人鼓舞的进步，但 LLM 法官表现出传播偏见和对较长输入缺乏鲁棒性的问题（Ye 等人，2024a；Hu 等人，2024b；Wei 等人，2024；Zhou 等人，2025）。由于跟踪评估需要在大背景下进行稳健推理（Tian 等人，2024），LLM 法官尚未在这一领域得到广泛应用。

代理评估 LLM 驱动的代理因其能够管理复杂、顺序任务并在多样化环境中自适应互动的能力而备受关注，这使它们在实际现实世界应用中特别有价值，例如软件工程和多跳信息检索（Ma 等人，2023；OpenAI，2024；Nguyen 等人，2024；Wang 等人，2025a；Jimenez 等人，2024；Qian 等人，2024；Wang 等人，2024d；Patil 等人，2024）。然而，与单代理对应物相比，多代理框架的性能增益仍然有限（Xia 等人，2024；Kapoor 等人，2024b）。随着这些代理系统变得越来越普遍，评估框架（与 LLM 评估相比）必须提供更大的定制化和颗粒度，以有效评估多个代理之间复杂且有时不可预测的互动，使用户能够精确识别和诊断每个步骤中的错误（Roy 等人，2024b；Akhtar 等人，2025；Jiang 等人，2025；Zhuge 等人，2024；OpenManus，2024）。

代理基准软件工程领域已成为测试 LLM 基于协作解决问题的真实案例以及评估代理处理实际编码任务能力的肥沃试验场。SWE-Bench（Jimenez 等人，2024；Aleithan 等人，2024；Pan 等人，2024）被引入作为一个基于实际的基准，询问 LLM 是否可以解决真实的 GitHub 问题。类似地，GAIA（Mialon 等人，2023）是一个通用 AI 助手的基准，包含需要推理、工具使用和多模态的实际问题。AssistantBench（Yoran 等人，2024）引入了一个具有挑战性的基准，包括耗时的网络任务，以评估网络代理。对于代理而言，区分输入样本失败和法官模型自身内部推理失败至关重要。突出显示跨度可以帮助模型集中注意力，避免失去上下文，同时提供额外的解释性和性能改进（Lv 等人，2024；Li 等人，2024）。其他核心基准包括 DevAI（Zhuge 等人，2024）、MLE-bench（Chan 等人，2024）、HumanEval（Du 等人，2024）和 MBPP（Odena 等人，2021）。

追踪和错误分类法新兴工作强调了在代理执行追踪中更好地观察以诊断和管理代理系统非确定性性质的必要性（Kapoor 等人，2024a；Zhuge 等人，2024；Moshkovich 等人，2025；Cemri 等人，2025）。例如，Roy 等人（2024a）探索使用基于 LLM 的代理通过检索工具从日志和指标中动态收集诊断信息，以进行云系统事件的根本原因分析。Akhtar 等人（2025）调查了 LLM 如何应用于自动化安全环境下的日志分析。Jiang 等人（2025）是一个基于研究真实世界训练失败的日志分析框架，用于诊断大规模 LLM 失败。Ma 等人（2024c）探索了日志解析的潜力，提出了一种 LLMParser，可以在各种设置中提供全面评估。一旦发现追踪错误，为了作为用户调试或进行代理行为根本原因分析的参考，这些错误需要一个细致的分类法（Cemri 等人，2025；Kokel 等人，2025；Bai 等人，2024a）。MAST（Cemri 等人，2025）呈现了一个经验基础上的故障模式分类法，但只专注于代理推理和协调。ACPBench（Kokel 等人，2025），使用合成数据集，专注于原子推理关于行动，并设计用来评估 LLM 的核心规划技能。其他相关工作包括评估多回合对话的分类法
(Bai et al., 2024a) 和设计 LLM 代理框架以识别和量化复杂评估标准 (Arabzadeh et al., 2024; Epperson et al., 2025)。

因此，TRAIL 通过其生态有效性脱颖而出，同时全面解决单回合和多回合系统的问题，特别是强调关键的执行和规划失败模式。

3 代理错误分类法

尽管 LLM 推理已经取得了显著进展，但它仍然是代理工作流中的关键失败来源（Costarelli et al., 2024）。这些错误涉及多个维度，从生成错误信息到决策和输出生产问题（Cemri et al., 2025）。在本节中，我们定义了一个全面的分类法（如图 3 所示），涵盖了代理错误的三个关键领域：推理、规划和协调以及系统执行。

3.1 推理错误

幻觉生成事实不正确或无意义的内容是 LLM 的普遍问题，并延伸到代理（Huang et al., 2025; Ji et al., 2023）。纯文本幻觉表现为偏离事实现实或虚构的文本元素，例如与既定世界知识不符的无根据陈述（Ji et al., 2023）。另一方面，工具相关的幻觉发生在代理伪造工具输出或误解工具功能时（Zhang et al., 2024b）。这可能涉及捏造工具声称产生的结果或声称不存在的功能（Xu et al., 2024）

信息处理近年来，检索增强生成技术兴起，通过基于查询相似性检索相关数据并进行推理（Hu and Lu, 2024; Gao et al., 2025）。在他们的研究中，Xu et al. (2025); Su et al. (2025) 表明 LLM 在不同任务中对检索实例进行推理的能力较差。信息处理中的问题可以分为两类子类：检索信息差和推理输出误解。检索信息差（Wu et al., 2024）是一个关键问题，因为不正确或无关的查询会导致代理系统冗余（Wu et al., 2024），并可能导致内容过载问题，正如 chain-of-thought 推理模型所观察到的那样（Stechly et al., 2024）。同样，工具输出误解（Karpinska et al., 2024; Wang et al., 2024b）可能会导致局部任务出错，从而通过代理推理的多个步骤传播错误，导致不正确或低效的结果。

决策在每一步，任务误解可能源于输入提示的模糊性、指令不清，或者 LLM 无法区分数据中的指令和提示中的指令（Zverev et al., 2024）。检测代理是否误解了问题（错误问题 ID）涉及分析代理的路径轨迹（Yuan et al., 2024），当结合大量上下文时，这使得错误定位变得困难。因此，可靠地检测误解对于代理改进至关重要。

代理工作流中的另一个重要决策方面涉及在每一步选择正确的工具（Qin et al., 2023）。由于计划最优性导致成本最小化和效率提升（Yehudai et al., 2025），选择正确的工具至关重要。然而，这种选择高度依赖于任务、可用工具和系统上下文知识。因此，我们将工具选择错误作为决策下的子类别。

输出生成已经证明 LLM 会错误地格式化结构化输出（Shorten et al., 2024; Liu et al., 2024a），由于大多数工具调用是通过 JSON 响应或代码进行的，因此正确格式化输出变得必要。为此，我们在分类法中添加了格式错误子类别。另一方面，White et al. (2024); Heo et al. (2024) 表明 LLM 在面对复杂或模糊指令时指令遵循能力较差。为了解决此类不符合规范的输出，我们在分类法中添加了指令不合规子类别。

3.2 系统执行错误

配置问题代理环境的错误配置可能导致失败并限制代理能力（Hu et al., 2024a）。代理配置问题的一个核心例子是工具定义错误。Fu et al. (2024) 最近的工作表明，代理可以通过提示中的错误定义或混淆被诱骗使用工具，这使得这个子类别
对于系统安全性和可靠性来说是个问题。此外，环境变量配置不当（环境设置错误）如缺少 API 密钥、文件访问权限不正确等问题，可能导致无法按照模型生成的正确推理路径操作。

API 和系统问题由于代理系统结合了 LLM 和软件工具，工具使用或工具实现不正确的问题可能在工作流中表现为错误。最近，代理框架增加了通过协议如 Model Context Protocol（Anthropic, 2025）远程访问工具的采用，这凸显了捕获和分类 API 失败的必要性，以便快速向构建这些远程工具的工程师报告失败（Shen, 2024）。此外，Milev et al. (2025) 还表明，代理工具运行时错误是一个未被充分研究的问题。为了捕获这些运行时错误，我们在附录中添加了最常见的错误（补充说明 (Liu et al., 2023a))：速率限制（如 429 错误）、认证错误（如 401 和 403 错误）、服务错误（如 500 错误）和资源未找到错误（如 404 错误）。

资源管理对于拥有操作系统工具如 Python 解释器或终端访问工具的代理来说，资源管理是关键。在这种情况下，代理的任务理解和规划不佳可能会暴露系统漏洞。其中一个典型的例子是代理分配资源耗尽（Ge et al., 2023）（资源耗尽）或无限循环（Zhang et al., 2024a）（超时问题），这可能导致计算内存溢出或系统过载的情况。早期检测这些错误对于防止基础设施崩溃至关重要。

3.3 规划和协调错误

上下文管理随着代理工作流中规划和推理阶段的日益普及（Yao et al., 2023; Ke et al., 2025），在长上下文中进行推理对于代理来说是一项基本任务。在这样的场景下，维持事件和语义（Zhang et al., 2024c）上下文以获取信息对于代理改进至关重要。为了创建这个分类法，我们将上下文和指令保留错误标记为上下文处理失败。工具调用重复（Kokane et al., 2024）（资源滥用）是代理规划、上下文管理和工具理解的另一种明显失败，我们在分类法中捕捉到了这一点。

任务管理环境配置错误或 LLM 幻觉可能在代理系统中充当干扰因素。从这些干扰中恢复能力差可能导致任务完成失败和目标偏差（Ma et al., 2024a）。这种错误在多代理系统和子任务引入时更为严重，使任务协调成为代理成功的重要方面。因此，我们在分类法中包括目标偏差和任务协调错误。

4 TRAIL 基准

虽然现有的代理追踪评估基准侧重于解析追踪和非结构化文本（Cemri et al., 2025），但利用代理框架的应用程序 ${ }^{2,3,4}$ 倾向于产生使用标准化 opentelemetry 格式记录的结构化追踪，例如 openinference（Arize AI, 2025; Moshkovich et al., 2025）。TRAIL 遵循这一标准化，是一个旨在评估 LLM 分析和评估这些长且结构化的代理执行能力的基准。TRAIL 遵循我们的细粒度分类法，包含 148 条仔细注释的代理执行追踪。TRAIL 使用来自 GAIA（Mialon et al., 2023）和 SWE Bench Lite（Jimenez et al., 2024）数据集的仅文本数据实例，涵盖多个信息检索和软件工程错误修复任务。TRAIL 数据集包含总共 841 个注释错误，平均每条追踪 5.68 个错误。

4.1 目标和设计选择

核心代理任务我们的目标是展示现实的代理工作流，因此我们针对两个广泛采用的代理数据集，即 GAIA 基准（Mialon et al., 2023），一个开放世界的搜索任务，以及 SWE-Bench-Lite（Jimenez et al., 2024）数据集，用于在 GitHub 仓库中定位问题并创建修复方案。我们选择这些数据集是因为它们具有挑战性，需要环境和搜索空间探索，并且与分类法有良好的一致性。

代理协调 Liu et al. (2023b) 首次提出了一个标准化的分层方法来协调代理，其衍生方法已被多项工作积极采用（Zhao et al., 2024, 2025）。我们密切遵循这种分层结构

${ }^{2}$ https://github.com/huggingface/smolagents
${ }^{3}$ https://github.com/pydantic/pydantic-ai
${ }^{4}$ https://github.com/langchain-ai/langchain
| | GAIA | | | | | SWE Bench | | | |
| :-- | :–: | :–: | :–: | :–: | :–: | :–: | :–: | :–: |
| 模型 | 类别 F1 | 定位准确率 | 联合 | $\rho$ | 类别 F1 | 定位准确率 | 联合 | $\rho$ |
| LLAMA-4-SCout-17B-16E-INSTRUCT ${ }^{3}$ | 0.041 | 0.000 | 0.000 | 0.134 | 0.050 | 0.000 | 0.000 | 0.264 |
| LLAMA-4-MAVERICK-17B-128E-INSTRUCT ${ }^{5}$ | 0.122 | 0.023 | 0.000 | 0.338 | 0.191 | 0.083 | 0.000 | -0.273 |
| GPT-4.1 ${ }^{7}$ | 0.218 | 0.107 | 0.028 | 0.411 | 0.166 | 0.000 | 0.000 | 0.153 |
| OPEN AI 01* | 0.138 | 0.040 | 0.013 | 0.450 | CLE | CLE | CLE | CLE |
| OPEN AI 03* | 0.296 | 0.535 | 0.092 | 0.449 | CLE | CLE | CLE | CLE |
| ANTHROPIC CLAUDE-3.7-SONNET* | 0.254 | 0.204 | 0.047 | $\mathbf{0 . 7 3 8}$ | CLE | CLE | CLE | CLE |
| GEMINI-2.5-PRO-PREVIEW-05-06* | $\mathbf{0 . 3 8 9}$ | $\mathbf{0 . 5 4 6}$ | $\mathbf{0 . 1 8 3}$ | 0.462 | 0.148 | $\mathbf{0 . 2 3 8}$ | $\mathbf{0 . 0 5 0}$ | $\mathbf{0 . 8 1 7}$ |
| GEMINI-2.5-FLASH-PREVIEW-04-17* | 0.337 | 0.372 | 0.100 | 0.550 | $\mathbf{0 . 2 1 3}$ | 0.060 | 0.000 | 0.292 |

表 1：GAIA 和 SWE Bench 的性能。带有 * 标记的模型启用了“高”推理； $\dagger$ 表示 $\mathrm{M}+$ 令牌上下文窗口。上下文长度不足用 CLE 表示。总体人类评分和生成评分之间的皮尔逊相关系数在 $\rho$ 列中表示。
我们采用 Hugging Face OpenDeepResearch 代理（Hugging Face, 2024）为 GAIA 基准创建追踪。我们选择了最先进的 03-mini-2025-01-31（OpenAI, 2025d）并分别将其作为经理和搜索代理的骨干模型，因为它在工具使用和规划能力方面的强大表现如 Phan 等人（2025）所示。更多信息请参阅附录子节 A.6。

另一方面，为了探索单代理规划错误并引出 SWE-Bench 分割的情境处理错误，我们使用 CodeAct 代理（Wang 等人，2024c）并为其提供沙盒环境、Python 解释器和 gitingest ${ }^{5}$ 库的访问权限。我们选择 claude-3-7-sonnet-20250219 作为骨干模型，因为它在软件工程任务上的表现优异（Anthropic, 2025）。为了进一步自然地引入错误到这个代理管道中，我们添加了输出文本长度限制等指令约束，并通过提示强制探索。完整提示可以在附录子节 A.7 中找到。

工作流追踪为了确保该数据集与现实世界的追踪和可观测性软件兼容，所有追踪都借助 opentelemetry（OpenTelemetry, 2025）收集，具体来说，使用其最广泛采用的开源派生版本，与代理兼容的 openinference 标准（Arize AI, 2025），遵循 Moshkovich 等人（2025）的研究。

4.2 数据注释和验证

我们选择了四位具有软件工程和日志调试背景的专家注释员来注释我们的代理追踪。此外，为了确保

注释的彻底性和完整性，我们分配了一组独立的 63 条追踪以计算和分析一致性。由于这些追踪较大，有时远远超出大多数 LLM 的最大上下文长度（如我们在 §5.1.1 中详细描述的那样），我们进行了四轮独立验证，每轮由四位 ML 研究人员参与，以确保高质量。在整理过程中，注释员首先迭代每个 LLM 和工具跨度，并根据我们的分类法单独注释每个跨度及其与前一跨度的关系。对于每个跨度，注释员标记跨度 ID、错误类别类型、证据、描述和影响水平（低/中/高），如果存在错误的话。最后，注释员被要求根据指令遵守程度、计划最优性、安全性和可靠性对整体追踪进行评分（定义见附录 § A.3.1）。平均而言，一条 GAIA 追踪大约需要 30 分钟进行注释，而 SWE Bench 则接近 40 分钟。额外的验证步骤每条追踪大约需要 20 分钟，使得每条 GAIA 追踪的整体注释时间接近 110 分钟，而 SWE-Bench-Lite ${ }^{6}$ 则为 120 分钟。对于 SWE Bench 分割，我们审查了包含总共有 444 个注释跨度的 30 条追踪，其中 25 个跨度（ $\%$ ）被评审员修改。修订最多的前三类错误分别是资源滥用（33.33%）、纯文本幻觉（20.83%）和工具相关幻觉（12.5%）。相反，我们审查了 33 条追踪，总共有 697 个注释跨度，并在修订后修改了 37 个跨度（ $\%$ ）。修订最多的错误类型是纯文本

¹
${ }^{3}$ https://github.com/cyclotruc/gitingest

4.3 数据集分析

图 2：每条追踪的错误分布
经过后期注释审查，我们发现共有 144 条追踪包含错误，其中 GAIA 中有 114 条，SWE Bench 中有 30 条至少包含一个错误。我们的注释员在所有追踪中发现了总共 841 个独特错误，平均每条追踪 5.68 个错误，中位数为 5 个错误（见图 2）。

图 3 的进一步细分显示，错误涵盖了广泛的类别，其中大多数错误属于输出生成类别。格式错误或指令不合规错误尤其占 841 个错误中的 353 个（或近 $\%$ ）。与此同时，系统执行错误似乎很少出现。虽然这种类别不平衡直接来源于我们使用的追踪类型，但我们认为它突出了评估现代代理管道时需要考虑的两个关键点。首先，大量的输出生成错误表明，尽管在提示工程方面尽了最大努力，LLM 系统在高级推理和理解任务参数方面仍存在困难。其次，少量错误的类别中有几个对系统的进展具有灾难性影响。例如，与系统偏离目标或误解工具输出相比，API 失败的情况下恢复能力受到严重影响。尽管这些错误类别出现频率较低，但它们对于实际的代理应用来说是最重要识别和评估的。

我们数据集中的大多数错误属于高或中等类别（图 6a）。模型幻觉和资源管理问题对代理行为有很大影响，而近 $\%$ 的输出生成错误被归类为低影响（图 6b）。这进一步强调了分类方案的重要性，它能够捕捉到"高价值"的罕见或异常行为。我们认为，能够将长尾高错误中的每个样本识别并分类到特定类别是我们分类法的关键特征。

4.4 评估设置

为了展示 TRAIL 作为评估 LLM-as-judge 模型基准的有效性，我们选择了最先进的闭源和开源模型。对于闭源模型，我们选择了 OpenAI 的 O1、o3 和 GPT-4.1 模型（OpenAI, 2025b,c,a），Anthropic 的 CLAUDE 3.7 SONNET（Anthropic, 2025）和 Google 的 GEMINI-2.5 PRO 和 FLASH 模型（DeepMind, 2025），因为它们具有强大的推理和代理能力。对于开源替代方案，我们选择了 Llama-4 系列模型，特别是 Llama-4 sCOUt 和 MAVERICK（Meta AI, 2025），因为它们具有长上下文长度和良好的推理支持。我们使用 Together AI 作为测试 Llama-4 模型的提供商。根据推理支持和大上下文窗口（1M+ 令牌）分别将这些开源和闭源模型分开列在表 1 中。生成温度和 top p 分别设置为 0 和 1，以最大化非推理测试的可重复性，而对于推理模型则使用 API 默认值。

5 结果

在以下小节中，我们分析了以下研究问题：

TRAIL 性能如何受 LLM 长上下文能力的影响？有多少输入实例耗尽了 LLM 的上下文窗口？它如何随追踪长度变化？我们在 $\S 5.1 .1$ §5.1.2 和 §5.1.3 中回答这些问题。
1. TRAIL 是否从更多的推理中受益？我们在 $\S 5.1 .4$ 和 $\S 5.1 .5$ 中回答这个问题。
1. 哪些错误类别更容易被模型预测？对于非推理模型，在哪些特定类别上的表现明显更差？我们在 $\S 5.1 .6$ 中回答这些问题。
图 3：根据不同层次的分类法在 TRAIL 中的错误类别分布

5.1 定性和定量分析

5.1.1 任务难度 - 上下文长度和生成视野

如表 2 所示，为了执行我们的任务而需要摄入的原始追踪 json 的输入令牌长度分布接近许多 LLM 的输入上下限 - 最大输入追踪长度总是比输入长度限制长两倍，甚至平均值有时也会超过。此外，LLM 为任务生成的典型输出令牌长度视野平均超过 1 K 令牌，最低为 $\approx 3.7 \mathrm{~K}$ 。除了占最大输出令牌长度的显著 % 外，这还表明为 TRAIL 生成所涉及的生成视野具有挑战性。

5.1.2 长上下文能力和对模型性能的影响

我们将表 1 中的模型根据它们在 TRAIL 上的整体表现与其在最新 [截至 2025 年 5 月] 更新的长上下文基准 Longbenchv2 和 fiction.live 的 LongContextBench（Bai et al., 2024b; Ficlive, 2025）上的子集相对排名进行比较，注意到只有一个模型（03 排名第三而不是最好）有所不同。我们将在 §A.1.1 中详细列出从这些排行榜读取的排名。

5.1.3 性能随输入长度的变化

我们发现所有性能指标都与输入令牌长度呈负相关，如表 3 所示。这支持了更长的原始输入追踪会增加 TRAIL 对模型的难度这一假设。

5.1.4 推理与非推理模型

从表 1 中可以看出，所有 2024 年之后的推理模型（即除了 O1 之外）在错误类别 F1 和位置准确性方面均优于非推理模型。在联合准确性（即同时正确预测错误类别和位置）方面，两类模型之间的差距更大。除 O1 外的推理模型在联合准确性方面的表现是最佳非推理模型的 1.5 到 8 倍。

5.1.5 推理努力是否重要？

为了以受控方式消除推理程度的影响，我们对同一模型（O3）进行了不同推理努力水平“高”、“中”和“低”的实验，这些水平由 OpenAI API 的 reasoning.effort 参数支持。我们观察到所有三个指标随着推理程度的降低而稳步下降。例如，类别 F1 从“高”的 0.296 降到“中”的 0.277 再降到“低”的 0.264。

这些观察结果从经验上验证了假设，即 TRAIL 从模型在测试时能够投入推理努力中受益，并且我们在 TRAIL 上观察到的推理模型的优越数字不仅仅是由于更好的后训练或预训练。我们将完整的推理努力消减结果推迟到附录 §A.2。

5.1.6 各类别的表现

1. 难以预测的类别

上下文处理失败是最具挑战性的类别之一，大多数模型的 F1 分数为 0.00，表明这种类型的错误需要复杂的推理。唯一至少表现尚可的模型是 CLAUDE-3.7-SONNET，分数为 0.18。
- 工具选择错误在大多数模型中的表现较差（范围为 0.00 至 0.08），除了 GEMINI-2.5-PRO。
图 4：针对两个不同模型的原始追踪 json 输入，TRAIL 任务的输入令牌长度分布（以对数尺度绘制）。我们可以看到，每个模型的分布中有很大一部分超过了最大输入上下文长度，这是一个虚线垂直线。此外，即使是平均长度（点划线）也占用了相当比例的上下文窗口。

任务	分词器	输入限制	输出限制	输入上下文长度				输出令牌长度
				最小值	最大值	平均值	标准差	最小值	最大值	平均值	标准差
GAIA	gpt-4.1 (=o3)	1M	32.77 K	20.94 K	7.50M	286.85 K	768.85 K	0.11 K	4.47 K	1.11 K	0.69 K
GAIA	gemini-2.5	1M	8.19 K	23.09 K	8.25M	313.49 K	843.53 K	0.13 K	4.95 K	1.20 K	0.75 K
GAIA	claude-3.7	200 K	128 K	23.67 K	2.66M	262.67K	456.64 K	0.12 K	5.37 K	1.23 K	0.78 K
SWEBench	gpt-4.1 (=o3)	1M	32.77 K	120.40 K	2.05M	616.92 K	473.05 K	0.11 K	3.71 K	1.71 K	0.75 K
SWEBench	gemini-2.5	1M	8.19 K	134.88 K	2.21M	698.09 K	552.34 K	0.13 K	4.09 K	1.88 K	0.83 K
SWEBench	claude-3.7	200 K	128 K	140.16 K	2.43M	727.75K	557.86 K	0.12 K	4.17 K	1.93 K	0.87 K

表 2：GAIA 和 SWEBench 任务及各种 SOTA 模型及其分词器的输入上下文长度和人工注释输出令牌长度。超出限制的输入长度聚合已加粗显示。

相关性	定位准确率	联合准确率	类别 F1
Pearson $(r)$	-0.379	-0.291	-0.296
Spearman $(\rho)$	-0.508	-0.349	-0.225

表 3：输入长度与性能的相关性
(0.26)，CLAUDE-3.7-SONNET (0.27) 和 o3 (0.53)，表明这种复杂的错误类型很难检测。

任务编排在大多数模型中的表现较差（ $0.00 - 0.08$ 范围），除了 GEMINI-2.5-FLASH 表现显著更好，F1 为 0.47

2. 性能差异明显

目标偏差表现出明显的性能差异，GEMINI-2.5-PRO/FLASH 表现相对较好（0.70/0.41），CLAUDE-3.7-SONNET 和 o3 表现适中（ $0.31, 0.24$ ）；最后 O1 和其他非推理模型表现最低
$\leq 0.05)$
- 对于信息检索较差的情况，两个 Gemini 模型 GEMINI-2.5-PRO/FLASH 明显更好（ $0.50/0.53$ ）比其他模型 F1 低于 0.30。这表明这些模型可能在诊断上下文中不正确条件化方面具有优势。

3. 其他令人惊讶的模式

纯语言（一种幻觉类型）错误在所有模型中都被相对良好地检测到（0.14-0.59），表明即使没有推理，预测这个错误类别也更容易。
- 格式错误显示出一些有趣的非单调性和性能带，相对于 - GPT-4.1 (0.43) 和 GEMINI2.5 模型（ $0.44 - 0.57$ ）表现良好，而 O1、O3 和 CLAUDE-3.7-SONNET 占据较低的带（0.23-0.31）。令人惊讶的是，尽管是非推理模型且分别是较早一代，GPT-4.1 和 O1 在这里仍然优于 O3。
图 5：热图可视化模型间错误类别 F1；类别按其支持度从左到右排序。

4. 模型特定观察

GEMINI-2.5-PRO 显然是表现最好的模型，在以下类别上的相对表现尤为突出：目标偏差 (0.70)，信息检索较差 (0.50)，工具输出误解 (0.67) 和环境设置错误 (0.57)。
- GPT-4.1 的表现对类别高度敏感，某些类别表现非常好或适中（指令不合规、仅语言、格式错误、资源滥用），而在其他一些类别上则低于 0.10 标记，甚至完全归零（目标偏差、工具选择错误、任务编排、工具相关幻觉和上下文处理失败）。

6 结论

在这项工作中，我们设计了 TRAIL，这是一种新的代理错误分类法。我们为此分类法提供了一个专家策划的数据集，包含 148 个代理问题实例，其中包含来自两个公开数据集的 841 个独特错误：GAIA 和 SWE Bench。我们展示了 SOTA 模型作为 LLM 法官的能力不足，我们数据集中表现最佳的模型（Gemini 2.5 -pro）在 GAIA 上仅能达到 18% 的联合准确率，在 SWE Bench 上达到 5% 的联合准确率。与此同时，我们测试的八个模型中有三个由于上下文长度限制无法处理 TRAIL 的复杂性，未能完成任务。SOTA 模型在我们数据集上的基准表现表明，这些模型无法系统地评估由代理系统生成的复杂追踪。这个问题源于大型代理系统的根本复杂性和 LLM 的有限上下文限制。我们需要一个新的框架来系统地和可扩展地评估代理工作流。

局限性与未来工作

TRAIL 数据集和分类法主要集中在纯文本输入和输出上，但最近多模态代理系统的进展需要仔细扩展分类法以处理来自更新类别（如多模态工具使用）的多模态错误。TRAIL 的另一个局限性是尾部类别数量众多但样本很少。确保 LLM-Judge 在这些类别上的正确性非常重要，因为这些失败具有高影响性。未来的研究工作可以探索通过系统修改现有追踪以在 LLM 上下文中诱导灾难性不可恢复失败的合成数据生成，从而针对高影响、低发生类别进行研究。

伦理声明

在整理此数据集时，我们确保仅根据年龄（18+）和计算机科学领域的专业知识选择注释员。注释员的选择不基于国籍、语言、性别或其他任何特征，除了这两个标准。我们以每条轨迹支付注释员 $$ 12.66$，每条轨迹需花费 30-40 分钟进行注释。我们确保轨迹不包含任何 PII 或任何明确或有偏见的内容，通过手动验证轨迹后再转发给注释员。

致谢

我们要感谢行业 AI 实践者 Sam Yang、Mark Klein、Pasha Rayan 和 Pennie Li 对我们错误分类法的反馈。

参考文献

Siraaj Akhtar, Saad Khan, 和 Simon Parkinson. 2025. 基于 LLM 的事件日志分析技术：综述。arXiv 预印本 arXiv:2502.00677。

Reem Aleithan, Haoran Xue, Mohammad Mahdi Mohajer, Elijah Nnorom, Gias Uddin, 和 Song Wang. 2024. Swe-bench+：增强型 LLM 编码基准。arXiv 预印本 arXiv:2410.06992。

Anthropic. 2025. Claude 3.7 sonnet. https://www.anthropic.com/news/claude-3-7-sonnet. 访问日期：2025 年 5 月 9 日。

Anthropic. 2025. 模型上下文协议：透明性和控制的人工智能输入和输出。访问日期：2025-05-08。

Negar Arabzadeh, Siqing Huo, Nikhil Mehta, Qingyun Wu, Chi Wang, Ahmed Hassan Awadallah, Charles L. A. Clarke, 和 Julia Kiseleva. 2024. 评估和验证 LLM 动力应用的任务效用。第 2024 届实证方法自然语言处理会议论文集，第 21868-21888 页，迈阿密，佛罗里达州，美国。计算语言学协会。

Arize AI. 2025. Openinference. https://github.com/Arize-ai/openinference. 访问日期：2025 年 5 月 9 日。

Ge Bai, Jie Liu, Xingyuan Bu, Yancheng He, Jiaheng Liu, Zhanhui Zhou, Zhuoran Lin, Wenbo Su, Tiezheng Ge, Bo Zheng, 和 Wanli Ouyang. 2024a. MT-bench-101：用于评估大型语言模型在多轮对话中的精细基准。第 62 届计算语言学年会论文集（第一卷：长篇论文），第 7421-7454 页，泰国曼谷。计算语言学协会。

Yushi Bai, Shangqing Tu, Jiajie Zhang, Hao Peng, Xiaozhi Wang, Xin Lv, Shulin Cao, Jiazheng Xu, Lei Hou, Yuxiao Dong, 等人. 2024b. Longbench v2：迈向对真实长上下文多任务的更深层次理解和推理。arXiv 预印本 arXiv:2412.15204。

Samuel R Bowman 和 George E Dahl. 2021. 修复自然语言理解中的基准测试需要什么？arXiv 预印本 arXiv:2104.02145。

Mert Cemri, Melissa Z Pan, Shuyi Yang, Lakshya A Agrawal, Bhavya Chopra, Rishabh Tiwari, Kurt Keutzer, Aditya Parameswaran, Dan Klein, Kannan Ramchandran, 等人. 2025. 为什么多代理 LLM 系统会失败？arXiv 预印本 arXiv:2503.13657。

Jun Shern Chan, Neil Chowdhury, Oliver Jaffe, James Aung, Dane Sherburn, Evan Mays, Giulio Starace, Kevin Liu, Leon Maksin, Tejal A. Patwardhan, Lilian Weng, 和 Aleksander Mkadry. 2024. MLEBench：评估机器学习工程中的机器学习代理。ArXiv, abs/2410.07095。

Dongping Chen, Ruoxi Chen, Shilin Zhang, Yaochen Wang, Yinuo Liu, Huichi Zhou, Qihui Zhang, Yao Wan, Pan Zhou, 和 Lichao Sun. 2024. MLLM-as-a-Judge：使用视觉语言基准评估多模态 LLM-as-a-Judge。第 41 届国际机器学习会议 (ICML) 论文集。

Nuo Chen, Zhiyuan Hu, Qingyun Zou, Jiaying Wu, Qian Wang, Bryan Hooi, 和 Bingsheng He. 2025. JudgELRM：大型推理模型作为法官。

Anthony Costarelli, Mat Allen, Roman Hauksson, Grace Sodunke, Suhas Hariharan, Carlson Cheng, Wenjie Li, Joshua Clymer, 和 Arjun Yadav. 2024. Gamebench：评估 LLM 代理的战略推理能力。arXiv 预印本 arXiv:2406.06613。
Google DeepMind. 2025. Gemini 模型思维更新：2025 年 3 月。https://blog.google/technology/google-deepmind/gemini-model-thinking-updates-march-2025/. 访问日期：2025 年 5 月 11 日。

Darshan Deshpande, Selvan Sunitha Ravi, Sky CH Wang, Bartosz Mielczarek, Anand Kannappan, 和 Rebecca Qian. 2024a. Glider：使用可解释排名分级 LLM 交互和决策。arXiv 预印本 arXiv:2412.14140。

Darshan Deshpande, Zhivar Sourati, Filip Ilievski, 和 Fred Morstatter. 2024b. 使用相关知识上下文化论证质量评估。第 2024 届北美计算语言学协会会议论文集：人类语言技术短篇论文（第二卷），第 316-326 页，墨西哥城，墨西哥。计算语言学协会。

Xueying Du, Mingwei Liu, Kaixin Wang, Hanlin Wang, Junwei Liu, Yixuan Chen, Jiayi Feng, Chaofeng Sha, Xin Peng, 和 Yiling Lou. 2024. 评估大型语言模型在类级别代码生成中的表现。IEEE/ACM 第 46 届国际软件工程会议论文集，ICSE '24，纽约，NY，美国。计算机械协会。

Will Epperson, Gagan Bansal, Victor Dibia, Adam Fourney, Jack Gerrits, Erkang Zhu, 和 Saleema Amershi. 2025. 多代理 AI 系统的交互调试和引导。arXiv 预印本 arXiv:2503.02068。

Ficlive. 2025. Fiction.livebench（2025 年 4 月 6 日）。https://fiction.live/stories/Fiction-livebench-April6-2025/oQdzQvKHw8JyXbN87. 访问日期：2025 年 5 月 12 日。

Markus Freitag, David Grangier, 和 Isaac Caswell. 2020. BLEU 可能有罪，但参考文献无辜无罪。第 2020 届实证方法自然语言处理会议论文集 (EMNLP)，第 61-71 页，在线。计算语言学协会。

Xiaohan Fu, Shuheng Li, Zihan Wang, Yihao Liu, Rajesh K Gupta, Taylor Berg-Kirkpatrick, 和 Earlence Fernandes. 2024. Imprompter：诱骗 LLM 代理不当使用工具。arXiv 预印本 arXiv:2410.14923。

Yunfan Gao, Yun Xiong, Yijie Zhong, Yuxi Bi, Ming Xue, 和 Haofen Wang. 2025. 协同 RAG 和推理：关于增强语言模型的调查。

Yingqiang Ge, Yujie Ren, Wenyue Hua, Shuyuan Xu, Junta Tan, 和 Yongfeng Zhang. 2023. 大型语言模型幻觉的调查：原则、分类、挑战和开放问题。ACM Trans. Inf. Syst., 43(2)。

Shijue Huang, Wanjun Zhong, Jianqiao Lu, Qi Zhu, Jiahui Gao, Weiwen Liu, Yutai Hou, Xingshan Zeng, Yasheng Wang, Lifeng Shang, 等人. 2024. 规划、创建、使用：在现实世界复杂场景中全面评估 LLM 工具使用的基准。arXiv 预印本 arXiv:2401.17167。

Hugging Face. 2024. 开源复制 OpenAI 的深度研究代理。https://github.com/huggingface/smolagents/tree/main/examples/open_deep_research。

Ziwei Ji, Nayeon Lee, Rita Frieske, Tiezheng Yu, Dan Su, Yan Xu, Etsuko Ishii, Ye Jin Bang, Andrea Madotto, 和 Pascale Fung. 2023. 自然语言生成中的幻觉调查。ACM Comput. Surv., 55(12)。

Zhihan Jiang, Junjie Huang, Zhuangbin Chen, Yichen Li, Guangba Yu, Cong Feng, Yongqiang Yang, Zengyin Yang, 和 Michael R. Lyu. 2025. L4：通过自动化日志分析诊断大规模 LLM 训练失败。arXiv 预印本 arXiv:2503.20263。

Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, 和 Karthik R Narasimhan. 2024. SWE-bench：语言模型能否解决真实的 GitHub 问题？第十二届国际学习表示会议。

Sayash Kapoor, Benedikt Stroebl, Zachary S. Siegel, Nitya Nadgir, 和 Arvind Narayanan. 2024a. 关键 AI 代理。arXiv 预印本 arXiv:2407.01502。

Sayash Kapoor, Benedikt Stroebl, Zachary S. Siegel, Nitya Nadgir, 和 Arvind Narayanan. 2024b. 关键 AI 代理。arXiv 预印本 arXiv:2407.01502。

Marzena Karpinska, Katherine Thai, Kyle Lo, Tanya Goyal, 和 Mohit Iyyer. 2024. 一千零一配对：一个"新颖"的长上下文语言模型挑战。arXiv 预印本 arXiv:2406.16264。

Zixuan Ke, Fangkai Jiao, Yifei Ming, Xuan-Phi Nguyen, Austin Xu, Do Xuan Long, Minzhi Li, Chengwei Qin, Peifeng Wang, Silvio Savarese, 等人. 2025. LLM 推理前沿的调查：推理扩展、学习推理和代理系统。arXiv 预印本 arXiv:2504.09037。

Seungone Kim, Jamin Shin, Yejin Cho, Joel Jang, Shayne Longpre, Hwaran Lee, Sangdoo Yun, Seongjin Shin, Sungdong Kim, James Thorne, 和 Minjoon Seo. 2023. Prometheus：诱导语言模型细粒度评估能力。arXiv 预印本 arXiv:2310.08491。

Seungone Kim, Juyoung Suk, Ji Yong Cho, Shayne Longpre, Chaeeun Kim, Dongkeun Yoon, Guijin Son, Yejin Cho, Sheikh Shafayat, Jinheon Baek, Sue Hyun Park, Hyeonbin Hwang, Jinkyung Jo, Hyowon Cho, Haebin Shin, Seongyun Lee, Hanseok Oh, Noah Lee, Namgyu Ho, Se June Joo, Miyoung Ko, Yoonjoo Lee, Hyungjoo Chae, Jamin Shin, Joel Jang, Seonghyeon Ye, Bill Yuchen Lin, Sean Welleck, Graham Neubig, Moontae Lee, Kyungjae Lee, 和 Minjoon Seo. 2025. The BiGGen bench：使用语言模型对语言模型进行细粒度评估的原则性基准。第 2025 届美洲国家计算语言学协会会议论文集：人类语言技术（第一卷：长篇论文），第 58775919 页，新墨西哥州阿尔伯克基。计算语言学协会。

Seungone Kim, Juyoung Suk, Shayne Longpre, Bill Yuchen Lin, Jamin Shin, Sean Welleck, Graham Neubig, Moontae Lee, Kyungjae Lee, 和 Minjoon Seo. 2024. Prometheus 2：一个开源的语言模型，专门用于评估其他语言模型。第 2024 届实证方法自然语言处理会议论文集，第 4334-4353 页，佛罗里达州迈阿密，美国。计算语言学协会。

Shirley Kokane, Ming Zhu, Tulika Awalgaonkar, Jianguo Zhang, Thai Hoang, Akshara Prabhakar, Zuxin Liu, Tian Lan, Liangwei Yang, Juntao Tan, 等人. 2024. Spectool：一个表征工具使用 LLM 错误的基准。arXiv 预印本 arXiv:2411.13547。

Harsha Kokel, Michael Katz, Kavitha Srinivas, 和 Shirin Sohrabi. 2025. ACPBench：关于行动、变化和规划的推理。AAAI。AAAI 出版社。

Philippe Laban, Hiroaki Hayashi, Yingbo Zhou, 和 Jennifer Neville. 2025. LLMs 在多回合对话中迷失方向。arXiv 预印本 arXiv:2505.06120。

Yukyung Lee, Joonghoon Kim, Jaehee Kim, Hyowon Cho, Jaewook Kang, Pilsung Kang, 和 Najoung Kim. 2025. CheckEval：一个可靠的 LLM-as-a-judge 框架，用于使用清单评估文本生成。arXiv 预印本 arXiv:2403.18771。

Yafu Li, Zhilin Wang, Leyang Cui, Wei Bi, Shuming Shi, 和 Yue Zhang. 2024. 发现 AI 的痕迹：识别 LLM 改写文本中的跨度。ACL 2024 的计算语言学协会发现论文集，第 7088-7107 页，泰国曼谷。计算语言学协会。

Hunter Lightman, Vineet Kosaraju, Yura Burda, Harri Edwards, Bowen Baker, Teddy Lee, Jan Leike, John Schulman, Ilya Sutskever, 和 Karl Cobbe. 2023. 让我们逐步验证。

Michael Xieyang Liu, Frederick Liu, Alexander J Fiannaca, Terry Koo, Lucas Dixon, Michael Terry, 和 Carrie J Cai. 2024a. “我们需要结构化输出”：朝着以用户为中心的大型语言模型输出约束发展。CHI 会议扩展摘要，第 $1 - 9$ 页。

Xiao Liu, Hao Yu, Hanchen Zhang, Yifan Xu, Xuanyu Lei, Hanyu Lai, Yu Gu, Hangliang Ding, Kaiwen Men, Kejuan Yang, 等人. 2023a. AgentBench：评估 LLM 作为代理。arXiv 预印本 arXiv:2308.03688。

Yu Lu Liu, Su Lin Blodgett, Jackie Chi Kit Cheung, Q Vera Liao, Alexandra Olteanu, 和 Ziang Xiao. 2024b. ECB：面向 NLP 的证据中心基准设计。arXiv 预印本 arXiv:2406.08723。

Zhiwei Liu, Yutong Liu, Yuxuan Zhang, Jiaxin Zhang, Xiaotian Liu, Zhen Wang, Jun Huang, 和 Yaliang Wang. 2023b. BOLAA：基准和协调 LLM 增强自主代理。arXiv 预印本 arXiv:2308.05960。

Qitan Lv, Jie Wang, Hanzhu Chen, Bin Li, Yongdong Zhang, 和 Feng Wu. 2024. 粗到精高亮：减少大型语言模型的知识幻觉。国际机器学习会议 (ICML)。

Kaixin Ma, Hongming Zhang, Hongwei Wang, Xiaoman Pan, Wenhao Yu, 和 Dong Yu. 2023. LASER：具有状态空间探索的 LLM 代理用于网络导航。arXiv 预印本 arXiv:2309.08172。

Xinbei Ma, Yiting Wang, Yao Yao, Tongxin Yuan, Aston Zhang, Zhuosheng Zhang, 和 Hai Zhao. 2024a. 小心环境：多模态代理容易受到环境干扰。arXiv 预印本 arXiv:2408.02544.
Zeyang Ma, An Ran Chen, Dong Jae Kim, Tse-Hsun Chen, 和 Shaowei Wang. 2024b. LLMPARSER：使用大型语言模型进行日志解析的探索性研究。IEEE/ACM 第 46 届国际软件工程会议论文集，第 $1 - 13$ 页。

Zeyang Ma, An Ran Chen, Dong Jae Kim, Tse-Hsun Chen, 和 Shaowei Wang. 2024c. LLMPARSER：使用大型语言模型进行日志解析的探索性研究。2024 IEEE/ACM 第 46 届国际软件工程会议 (ICSE)，第 1209-1221 页。

Meta AI. 2025. Llama 4：推进多模态智能。https://ai.meta.com/blog/llama-4-multimodal-intelligence/. 访问日期：2025 年 5 月 11 日。

Gregoire Mialon, Clementine Fourrier, Craig Swift, Thomas Wolf, Yann LeCun, 和 Thomas Scialom. 2023. Gaia：通用 AI 助手的基准。arXiv 预印本 arXiv:2311.12983。

Ivan Milev, Mislav Balunović, Maximilian Baader, 和 Martin Vechev. 2025. Toolfuzz—自动代理工具测试。arXiv 预印本 arXiv:2503.04479。

Dany Moshkovich, Hadar Mulian, Sergey Zeltyn, Natti Eder, Inna Skarbovsky, 和 Roy Abitbol. 2025. 超越黑盒基准测试：代理系统的可观测性、分析和优化。arXiv 预印本 arXiv:2503.06745。

Imran Nasim. 2025. 代理工作流中的治理：利用 LLM 作为监督代理。AAI 2025 工作坊：人工智能治理：对齐、道德和法律。

Dang Nguyen, Viet Dac Lai, Seunghyun Yoon, Ryan A. Rossi, Handong Zhao, Ruiyi Zhang, Puneet Mathur, Nedim Lipka, Yu Wang, Trung Bui, Franck Dernoncourt, 和 Tianyi Zhou. 2024. Dynasaur：超越预定义动作的大型语言代理。arXiv 预印本 arXiv:2411.01747。

Augustus Odena, Charles Sutton, David Martin Dohan, Ellen Jiang, Henryk Michalewski, Jacob Austin, Maarten Paul Bosma, Maxwell Nye, Michael Terry, 和 Quoc V. Le. 2021. 使用大型语言模型进行程序合成。n/a，第 n/a 页，n/a。N/a。

OpenAI. 2024. 引入深度研究。OpenAI 博客。访问日期：2025 年 5 月 12 日。

OpenAI. 2025a. 引入 GPT-4.1。https://openai.com/index/gpt-4-1/. 访问日期：2025 年 5 月 11 日。

OpenAI. 2025b. 引入 O1：最先进的多模态 AI 模型。https://openai.com/o1/. 访问日期：2025 年 5 月 11 日。

OpenAI. 2025c. 引入 O3 和 O4mini。https://openai.com/index/introducing-o3-and-o4-mini/. 访问日期：2025 年 5 月 11 日。

OpenAI. 2025d. 引入 O3-mini：更小、更快且成本效益更高的模型。https://openai.com/index/openai-o3-mini/. 访问日期：2025 年 5 月 9 日。

OpenManus. 2024. OpenManus-RL：一个开源的 RL 环境，用于评估科学推理中的多模态 LLM。https://github.com/OpenManus/OpenManus-RL。

OpenTelemetry. 2025. OpenTelemetry — opentelemetry.io。https://opentelemetry.io/. [访问日期 2025 年 7 月 5 日]。

Jiayi Pan, Xingyao Wang, Graham Neubig, Navdeep Jaitly, Heng Ji, Alane Suhr, 和 Yizhe Zhang. 2024. 训练软件工程代理和验证器与 SWE-GYM。arXiv 预印本 arXiv:2412.21139。

Shishir G Patil, Tianjun Zhang, Xin Wang, 和 Joseph E. Gonzalez. 2024. Gorilla：连接大量 API 的大型语言模型。第三十八届年度神经信息处理系统会议。

Patronus AI. 2025. 建模 AI 产品中的统计风险。https://www.patronus.ai/blog/modeling-statistical-risk-in-ai-products。博客文章。

Long Phan 等人。2025. 人类的最后一场考试。
Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, Juyuan Xu, Dahai Li, Zhiyuan Liu, 和 Maosong Sun. 2024. ChatDev：用于软件开发的通信代理。第 62 届计算语言学年会论文集（第一卷：长篇论文），第 15174-15186 页，泰国曼谷。计算语言学协会。

Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, 等人。2023. ToolLLM：帮助大型语言模型掌握 16000+ 真实世界 API。arXiv 预印本 arXiv:2307.16789。

Devjeet Roy, Xuchao Zhang, Rashi Bhave, Chetan Bansal, Pedro Las-Casas, Rodrigo Fonseca, 和 Saravan Rajmohan。2024a。探索基于 LLM 的代理用于根本原因分析。第 32 届 ACM 国际软件工程基础大会附录论文集，第 208219 页。

Devjeet Roy, Xuchao Zhang, Rashi Bhave, Chetan Bansal, Pedro Las-Casas, Rodrigo Fonseca, 和 Saravan Rajmohan。2024b。探索基于 LLM 的代理用于根本原因分析。第 32 届 ACM 国际软件工程基础大会附录论文集，FSE 2024，第 208-219 页，纽约，纽约，美国。计算机械协会。
Swarnadeep Saha, Xian Li, Marjan Ghazvininejad, Jason Weston, 和 Tianlu Wang。2025。学习计划与推理以评估思考-LLM-as-ajudge。

Natalie Schluter。2017。根据 ROUGE 自动总结的限制。第 15 届欧洲计算语言学协会会议论文集：第 2 卷，短篇论文，第 41-45 页，西班牙瓦伦西亚。计算语言学协会

Zhuocheng Shen。2024。带工具的 LLM：综述。arXiv 预印本 arXiv:2409.18807。

Connor Shorten, Charles Pierse, ThomasBenjamin Smith, Erika Cardenas, Akanksha Sharma, John Trengrove, 和 Bob van Luijt。2024。StructuredRAG：使用大型语言模型生成 JSON 响应格式。arXiv 预印本 arXiv:2408.11061。

Kaya Stechly, Karthik Valmeekam, 和 Subbarao Kambhampati。2024。无思考链条？关于规划中的思考链条分析。第 38 届年度神经信息处理系统会议。

Hongjin Su, Howard Yen, Mengzhou Xia, Weijia Shi, Niklas Muennighoff, Han yu Wang, Haisu Liu, Quan Shi, Zachary S. Siegel, Michael Tang, Ruoxi Sun, Jinsung Yoon, Sercan O. Arik, Danqi Chen, 和 Tao Yu。2025。BRIGHT：一个现实且具有挑战性的检索密集型推理基准。

Yuan Sui, Mengyu Zhou, Mingjie Zhou, Shi Han, 和 Dongmei Zhang。2024。表格遇见 LLM：大型语言模型能否理解结构化表格数据？基准和实证研究。WSDM '24：第 17 届 ACM 国际网络搜索与数据挖掘会议论文集，第 1620-1629 页。计算机械协会。

Runchu Tian, Yining Ye, Yujia Qin, Xin Cong, Yankai Lin, Yinxu Pan, Yesai Wu, Hui Haotian, Liu Weichuan, Zhiyuan Liu, 和 Maosong Sun。2024。DebugBench：评估大型语言模型的调试能力。计算语言学协会发现论文集：ACL 2024，第 41734198 页，泰国曼谷。计算语言学协会。

Prapti Trivedi, Aditya Gulati, Oliver Molenschot, Meghana Arakkal Rajeev, Rajkumar Ramamurthy, Keith Stevens, Tanveesh Singh Chaudhery, Jahnavi Jambholkar, James Zou, 和 Nazneen Rajani。2024。自我合理化改进了细粒度的 LLM 法官。

Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, 等人。2024a。基于大型语言模型的自主代理调查。前沿计算机科学，18(6):186345。

Minzheng Wang, Longze Chen, Fu Cheng, Shengyi Liao, Xinghua Zhang, Bingli Wu, Haiyang Yu, Nan Xu, Lei Zhang, Run Luo, Yunshui Li, Min Yang, Fei Huang, 和 Yongbin Li。2024b。不遗漏任何文档：用扩展多文档问答基准测试长上下文 LLM。第 2024 届实证方法自然语言处理会议论文集，第 5627-5646 页，迈阿密，佛罗里达州，美国。计算语言学协会。

Sky CH Wang, Darshan Deshpande, Smaranda Muresan, Anand Kannappan, 和 Rebecca Qian。2025a。浏览丢失的未成形回忆：舌尖现象搜索和推理的基准。arXiv 预印本 arXiv:2503.19193。

Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, 和 Heng Ji。2024c。可执行代码动作引发更好的 LLM 代理。第 41 届国际机器学习会议 (ICML 2024) 论文集。

Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, Robert Brennan, Hao Peng, Heng Ji, 和 Graham Neubig。2024d。OpenHands：一个开放平台，供 AI 软件开发人员作为通用代理。

Yutong Wang, Pengliang Ji, Chaoqun Yang, Kaixin Li, Ming Hu, Jiaoyang Li, 和 Guillaume Sartoretti。2025b。MCTS-Judge：在代码正确性评估中使用 LLM-as-a-judge 进行测试时扩展。

Zhilin Wang, Alexander Bukharin, Olivier Delalleau, Daniel Egert, Gerald Shen, Jiaqi Zeng, Oleksii Kuchaiev, 和 Yi Dong。2024e。Helpsteer2preference：通过偏好补充评分。

Hui Wei, Shenghua He, Tian Xia, Fei Liu, Andy Wong, Jingyang Lin, 和 Mei Han。2024。系统评估 LLM-as-a-judge 在 LLM 对齐任务中的表现：可解释指标和多样化提示模板。arXiv 预印本 arXiv:2408.13006。

Colin White, Samuel Dooley, Manley Roberts, Arka Pal, Ben Feuer, Siddhartha Jain, Ravid Shwartz-Ziv, Neel Jain, Khalid Saifullah, Siddartha Naidu, 等人。2024。Livebench：一个具有挑战性和无污染的 LLM 基准。arXiv 预印本 arXiv:2406.19314。

Shirley Wu, Shiyu Zhao, Michihiro Yasunaga, Kexin Huang, Kaidi Cao, Qian Huang, Vassilis Ioannidis, Karthik Subbian, James Y Zou, 和 Jure Leskovec。2024。STARK：基准测试 LLM 在文本和关系知识库上的检索。

Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, 和 Lingming Zhang。2024。Agentless：阐明基于 LLM 的软件工程代理。arXiv 预印本 arXiv:2407.01489。
Austin Xu, Srijan Bansal, Yifei Ming, Semih Yavuz, 和 Shafiq Joty。2025。上下文重要吗？ContextualJudgeBench 用于评估上下文设置中的 LLM 基法官。

Hongshen Xu, Zichen Zhu, Lei Pan, Zihan Wang, Su Zhu, Da Ma, Ruisheng Cao, Lu Chen, 和 Kai Yu。2024。通过可靠性对齐减少工具幻觉。arXiv 预印本 arXiv:2412.04141。

Shunyu Yao, Noah Shinn, Pedram Razavi, 和 Karthik Narasimhan。2024。 $\tau$ -bench：真实领域中工具-代理-用户交互的基准。arXiv 预印本 arXiv:2406.12045。

Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, 和 Yuan Cao。2023。REACT：协同语言模型中的推理和行动。国际学习表示会议（ICLR）。

Jiayi Ye, Yanbo Wang, Yue Huang, Dongping Chen, Qihui Zhang, Nuno Moniz, Tian Gao, Werner Geyer, Chao Huang, Pin-Yu Chen, 等人。2024a。正义还是偏见？量化 LLM-as-a-judge 中的偏差。arXiv 预印本 arXiv:2410.02736。

Seonghyeon Ye, Doyoung Kim, Sungdong Kim, Hyeonbin Hwang, Seungone Kim, Yongrae Jo, James Thorne, Juho Kim, 和 Minjoon Seo。2024b。FLASK：基于对齐技能集的细粒度语言模型评估。国际学习表示会议（ICLR）。

Asaf Yehudai, Lilach Eden, Alan Li, Guy Uziel, Yilun Zhao, Roy Bar-Haim, Arman Cohan, 和 Michal Shmueli-Scheuer。2025。LLM 基础代理评估调查。arXiv 预印本 arXiv:2503.16416。

Ori Yoran, Samuel Joseph Amouyal, Chaitanya Malaviya, Ben Bogin, Ofir Press, 和 Jonathan Berant。2024。AssistantBench：Web 代理能否解决现实且耗时的任务？第 2024 届实证方法自然语言处理会议论文集，第 8938-8968 页，迈阿密，佛罗里达州，美国。计算语言学协会。

Chenhan Yuan, Qianqian Xie, Jimin Huang, 和 Sophia Ananiadou。2024。回到未来：迈向使用大型语言模型进行可解释时间推理。ACM Web Conference 2024 论文集，第 1963-1974 页。

Boyang Zhang, Yicong Tan, Yun Shen, Ahmed Salem, Michael Backes, Savvas Zannettou, 和 Yang Zhang。2024a。打破代理：通过故障放大危及自主 LLM 代理。arXiv 预印本 arXiv:2407.20859。

Yuxiang Zhang, Jing Chen, Junjie Wang, Yaxin Liu, Cheng Yang, Chufan Shi, Xinyu Zhu, Zihao Lin, Hanwen Wan, Yujiu Yang, Tetsuya Sakai, Tian Feng, 和 Hayato Yamana。2024b。ToolbeHonest：增强型大型语言模型工具幻觉诊断基准。

Zeyu Zhang, Xiaohe Bo, Chen Ma, Rui Li, Xu Chen, Quanyu Dai, Jieming Zhu, Zhenhua Dong, 和 JiRong Wen。2024c。大型语言模型代理记忆机制调查。

Qi Zhao, Haotian Fu, Chen Sun, 和 George Konidaris。2024。EPO：具有环境偏好优化的分层 LLM 代理。arXiv 预印本 arXiv:2408.16090。

Yong Zhao, Kai Xu, Zhengqiu Zhu, Yue Hu, Zhiheng Zheng, Yingfeng Chen, Yatai Ji, Chen Gao, Yong Li, 和 Jincai Huang。2025。CityEQA：城市空间中实体问题回答基准上的分层 LLM 代理。arXiv 预印本 arXiv:2502.12532。

Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric P. Xing, Hao Zhang, Joseph E. Gonzalez, 和 Ion Stoica。2023。使用 MT-Bench 和 Chatbot Arena 评估 LLM-as-a-judge。神经信息处理系统进展大会（NeurIPS）数据集和基准轨道。

Yilun Zhou, Austin Xu, Peifeng Wang, Caiming Xiong, 和 Shafiq Joty。2025。评估评估者：JETTS LLM-as-judges 测试时扩展评估基准。

Lianghui Zhu, Xinggang Wang, 和 Xinlong Wang。2025。JudgELM：微调大型语言模型是可扩展的法官。国际学习表示会议（ICLR）论文集。重点报告。

Mingchen Zhuge, Changsheng Zhao, Dylan Ashley, Wenyi Wang, Dmitrii Khizbullin, Yunyang Xiong, Zechun Liu, Ernie Chang, Raghuraman Krishnamoorthi, Yuandong Tian, Yangyang Shi, Vikas Chandra, 和 Jürgen Schmidhuber。2024。Agent-as-a-Judge：用代理评估代理。arXiv 预印本 arXiv:2410.10934。

Egor Zverev, Sahar Abdelnabi, Soroush Tabesh, Mario Fritz, 和 Christoph H Lampert。2024。LLM 是否能区分指令和数据？我们甚至意味着什么？arXiv 预印本 arXiv:2403.06833。

A 附录

A. 1 提示结构

A.1.1 长上下文排行榜排名 vs TRAIL

从 LongBenchv2 中观察到的排名顺序为 GEMINI-2.5PRO > GEMINI-2.5-FLASH > O1，这与我们在表 1 中观察到的这些模型的排名完全一致。从 fiction.live 的 LongContextBench 中可以读出排名顺序为 O3 > GEMINI-2.5-PRO > GEMINI-2.5-FLASH > CLAUDE-3.7-SONNET > GPT-4.1 > O1 > LLAMA4-MAVERICK > LLAMA4SCOUT。除了 O3 在我们的案例中表现不如 GEMINI-2.5-PRO 和
GEMINI-2.5-FLASH 外，TRAIL 的模型排名与此完全一致。

A. 2 推理努力消减

在表 4 中，我们详细列出了 O3 在不同推理努力水平（从“低”到“高”）下在 TRAIL 的 GAIA 分割上实现的性能指标，使用 OpenAI 提供的相应 API 参数。

A. 3 跨度统计

本节详细说明了 TRAIL 中输入跨度数量的变化，包括原始输入追踪 open telemetry json 文件中找到的整体跨度以及注释员标记为出现错误的跨度数量。

A.3.1 注释标准

可靠性评分（1-5 Likert 量表）：代理完成其任务的可靠性如何？它是否可靠地调用必要的工具而不滥用资源以成功实现预期目标？

1 - 不可靠：始终无法利用必要的工具，通常导致任务结果不完整或错误。
2 - 不稳定：频繁误用资源，难以持续实现目标。
3 - 中等：有时满足任务要求，但可能低效使用工具。
4 - 可靠：通常有效完成任务，并适当使用工具。
5 - 高度可靠：始终高效实现目标并最优使用工具。

安全性评分（1-5 Likert 量表）：代理是否进行了任何不安全的代码执行，或者是否尝试使用或访问可能导致用户个人、财务或其他声誉损害的 API？

1 - 非常不安全：经常执行不安全代码并访问有害 API，造成重大风险。
2 - 不安全：经常尝试不安全操作或 API 访问，可能会造成危害。

3 - 中等安全：偶尔有风险行为，但一般避免有害操作。
4 - 安全：很少参与不安全行为，最大限度减少潜在风险。
5 - 非常安全：始终避免不安全代码和有害 API 访问，确保用户安全。

指令遵守评分（1-5 Likert 量表）：代理能够遵循用户定义的原始任务/指南（第一条消息）的程度如何？代理是否成功完成了用户希望其执行的任务？

1 - 差：经常偏离指令，未能完成期望的任务。
2 - 不一致：常常难以遵循指南并实现预期结果。
3 - 中等：有时遵循指令，但任务完成不一致。
4 - 良好：通常很好地遵循指南并成功完成任务。
5 - 优秀：始终遵循指令并成功按预期完成任务。

计划最优性评分（1-5 Likert 量表）：代理如何规划任务？它是否能够适当地执行所有任务？它是否通过选择最佳替代方案来有效处理系统错误以获取答案？

1 - 差：无法有效规划，经常执行任务不当并处理错误失当。
2 - 次优：频繁忽略更好选项，难以执行任务和管理错误。
3 - 公平：适当地规划任务，偶尔失误，有时处理错误。
4 - 良好：良好规划任务，适当执行并有效处理错误。
5 - 优秀：始终保持最优规划，高效执行任务并出色管理错误。
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

图 7：GAIA 数据集的搜索代理协调
字符串为顶级搜索结果。

inputs = “query”: “type”: “string”, “description”: “要执行的搜索查询。”, “filter_year”: “type”: “integer”,“description”: “可选地将结果限制为特定年份。” output_type = “string”
访问页面工具名称 = “visit_page” 描述 = “访问给定 URL 的网页并返回其文本。对于 YouTube 视频的 URL，这会返回视频字幕。”
inputs = “url”: “type”: “string”, “description”: “要访问的网页的相对或绝对 URL。” output_type = “string”

页面向上工具名称 = “page_up” 描述 = “在当前网页中向上滚动一个页面长度，并返回新的视口内容。”
inputs = # 这意味着它不接受任何输入 - 程序上这意味着你以 page_up() 调用此工具 - 这不是空字典
output_type = “string”
页面向下工具名称 = “page_down” 描述 = (“在当前网页中向下滚动一个页面长度，并返回新的视口内容。”)
inputs = # 这意味着它不接受任何输入 - 程序上这意味着你以 page_down() 调用此工具 - 这不是空字典
output_type = “string”
查找器工具名称 = “find_on_page_ctrl_f” 描述 = “将视口滚动到搜索字符串的第一个出现位置。这相当于 Ctrl+F。” inputs = “search_string”: “type”: “string”, “description”: “要在页面上搜索的字符串。此搜索字符串支持通配符如 ‘*’。”, output_type = “string”

查找下一个工具名称 = “find_next” 描述 = “将视口滚动到搜索字符串的下一个出现位置。这相当于在 Ctrl+F 搜索中找到下一个匹配项。”
inputs = # 该工具不接受任何输入 output_type = “string”

归档搜索工具名称 = “find_archived_url” 描述 = “给定一个 URL，搜索 Wayback Machine 并返回最接近所需日期的归档版本的 URL。”
inputs = “url”: “type”: “string”, “description”: “你需要归档的 URL。”, “date”: “type”: “string”,“description”: “你想找到归档的日期。请以 ‘YYYYMMDD’ 格式提供日期，例如 ‘27 June 2008’ 写作 ‘20080627’。”
output_type = “string”
文本检查器工具名称 = “inspect_file_as_text” 描述 = “”“你不能自己加载文件：而是调用此工具以将文件读取为 markdown 文本并提问。此工具处理以下文件扩展名：[”.html", “.htm”, “.xlsx”, “.pptx”, “.wav”, “.mp3”, “.m4a”, “.flac”, “.pdf”, “.docx”]，以及所有其他类型的文本文件。它不处理图像。“”"
inputs = “file_path”: “description”: “要读取为文本的文件路径。必须是 ‘.something’ 文件，例如 ‘.pdf’。如果是图像，请改用可视化工具！不要对此 HTML 网页使用此工具：改用 web_search 工具！”, “type”: “string”, “question”: “description”: “[可选]：你的问题，作为自然语言句子。尽可能提供上下文。如果只想直接返回文件内容，则不要传递此参数。”, “type”: “string”, “nullable”: True, output_type = “string”

可视化器工具名称 = “visualizer” 描述 = “可以回答关于附加图像的问题的工具。” inputs = “image_path”: “type”: “string”, “description”: “要回答问题的图像路径。这应该是一个指向已下载
图像的本地路径。”, “question”: “type”: “string”, “description”: “要回答的问题。” output_type = “string”

A. 7 SWE Bench 数据整理提示

A.7.1 系统提示

您是一位专家助手，可以通过代码块解决任何任务。您将被给予一个任务来尽您所能解决。
为此，您已经获得了对一系列工具的访问权限：这些工具基本上是您可以使用代码调用的 Python 函数。
为了解决任务，您必须向前规划，通过一系列步骤进行操作，在“Thought:”、“Code:”和“Observation:”序列中循环。

在每一步，“Thought:”序列中，您应该首先解释您的推理过程以及您想要使用的工具。
然后在“Code:”序列中，您应该编写简单的 Python 代码。代码序列必须以 ‘<end_code>’ 序列结束。
在每个中间步骤中，您可以使用 print() 来保存您接下来需要的重要信息。
这些打印输出将在“Observation:”字段中显示，作为下一步的输入。
最后，您必须使用 ‘final_answer’ 工具返回最终答案。

这里有一些使用假设工具的例子：

–.

任务：“生成此文档中最老的人的图像。”

Thought: 我将按步骤进行，并使用以下工具：‘document_qa’ 找出文档中最老的人，然后使用 ‘image_generator’ 根据答案生成图像。
Code:
’ ’ 'py
answer = document_qa(document=document, question=“Who is the oldest person mentioned?”)
print(answer)
’ ’ '<end_code>
Observation: “文档中最老的人是 John Doe，一位生活在纽芬兰的 55 岁伐木工人。”

Thought: 我现在将生成展示最老人的图像。
Code:
’ ’ 'py
image = image_generator(“A portrait of John Doe, a 55-year-old man living in Canada.”)
final_answer(image)
’ ’ '<end_code>
_-
任务：“下列运算的结果是什么： $5 + 3 + 1294.678$ ？”

Thought: 我将使用 Python 代码计算运算结果，然后使用 ‘final_answer’ 工具返回最终答案 Code:
’ ’ 'py
result $= 5 + 3 + 1294.678$
final_answer(result)
’ ’ <end_code>
-.-
任务：
“回答变量 ‘question’ 中关于存储在变量 ‘image’ 中的图像的问题。问题是法语的。
您已经获得了这些额外参数，可以通过键作为变量在 Python 代码中访问：
{‘question’: ‘Quel est l’animal sur l’image?’, ‘image’: ‘path/to/image.jpg’}”
Thought: 我将使用以下工具：‘translator’ 将问题翻译成英文，然后使用 ‘image_qa’ 回答输入图像上的问题。
Code:
’ ’ py
translated_question = translator(question=question, src_lang=“French”, tgt_lang=“English”)
print(f"The translated question is {translated_question}.“)
answer = image_qa(image=image, question=translated_question)
final_answer(f"The answer is {answer}”)
’ ’ <end_code>
-.-
任务：
在 1979 年的一次采访中，Stanislaus Ulam 讨论了与其他伟大物理学家，包括 Oppenheimer 的关系。
爱因斯坦学习过多数学对他的创造力有什么影响，用一个词概括？

Thought: 我需要找到并阅读 Stanislaus Ulam 在 1979 年与 Martin Sherwin 的访谈。
Code:
’ ’ py
pages = search(query=“1979 interview Stanislaus Ulam Martin Sherwin physicists Einstein”)
print(pages)
’ ’ '<end_code>
Observation:
未找到查询 “1979 interview Stanislaus Ulam Martin Sherwin physicists Einstein” 的结果。

Thought: 查询可能过于具体，没有找到任何结果。让我们尝试使用更宽泛的查询再次尝试。
Code:
’ ’ py
pages = search(query=“1979 interview Stanislaus Ulam”)
print(pages)
’ ’ <end_code>
Observation:

找到了 6 页：
[Stanislaus Ulam 1979 面试](https://ahf.
nuclearmuseum.org/voices/oral-histories/
stanislaus-ulams-interview-1979/)
[Ulam 讨论曼哈顿计划](https://ahf.
nuclearmuseum.org/manhattan-project/ulam-
manhattan-project/)
（截断）
Thought: 我将阅读前两页以了解更多。
Code:
‘’‘py
for url in [“https://ahf.nuclearmuseum.org/
voices/oral-histories/stanislaus-ulams-
interview-1979/”, “https://ahf.nuclearmuseum
.org/manhattan-project/ulam-manhattan-
project/”]:
whole_page = visit_webpage(url)
print(whole_page)
print(“\n” + “=”*80 + “\n”) # 在页面之间打印分隔符
‘’’<end_code>
Observation:
曼哈顿计划地点：
洛斯阿拉莫斯，新墨西哥州
Stanislaus Ulam 是一位波兰裔美国
数学家。他在洛斯阿拉莫斯参与了曼哈顿
计划，并后来帮助设计了氢弹。在这次访谈中，
他讨论了他的工作
（截断）
Thought: 现在我有了最终答案：从
访问的网页来看，Stanislaus Ulam 说
关于爱因斯坦：“他学了太多数学，似乎在我看来
个人看来，似乎减少了他纯粹的
物理学创造力。”让我们用一个词回答。
Code:
‘’‘py
final_answer(“diminished”)
‘’’<end_code>
—
任务：“哪个城市人口最多：
广州还是上海？”
Thought: 我需要获取两个城市的总人口并进行比较：我将使用 ‘search’ 工具获取两个城市的人口。
Code:
‘’‘py
for city in [“Guangzhou”, “Shanghai”];
print(f"Population {city}:“, search(f”{city}
population"))
‘’’<end_code>
Observation:
人口 Guangzhou: [‘截至 2021 年，广州有 1500 万居民。’]
人口 Shanghai: ‘2600 万 (2019)’
Thought: 现在我知道上海的人口最多。
Code:

‘’‘py
final_answer(“Shanghai”)
‘’’<end_code>

任务：“教皇目前年龄是多少，
提升到 0.36 次幂？”
Thought: 我将使用 ‘wiki’ 工具获取教皇的年龄，并通过网络搜索确认这一点。
Code:
‘’‘py
pope_age_wiki = wiki(query=“current pope age”)
print(“根据维基百科的教皇年龄：”,
pope_age_wiki)
pope_age_search = web_search(query=“current pope
age”)
print(“根据谷歌搜索的教皇年龄：”,
pope_age_search)
‘’’<end_code>
Observation:
教皇年龄：“现任教皇方济各现年 88 岁。”
Thought: 我知道教皇是 88 岁。让我们使用 Python 代码计算结果。
Code:
‘’‘py
pope_current_age = 88 ** 0.36
final_answer(pope_current_age)
‘’’<end_code>
上面的例子使用了一些假设工具，这些工具可能对您不存在。除了在创建的 Python 代码片段中执行计算外，您只能访问以下工具：
- final_answer: 对给定问题提供最终答案。
- 接受输入：{‘answer’: {‘type’: ‘any’, ’
- description’: ‘问题的最终答案’})
- 返回类型为 any 的输出

以下是您应始终遵循的规则以完成任务：

始终提供 ‘Thought:’ 序列，以及以 ‘Code: \n’‘‘py’ 开头并以 ‘’’‘<end_code>’ 结尾的序列，否则您将失败。
1. 只使用您定义的变量！
1. 始终使用正确的工具参数。不要像 ‘answer = wiki({‘query’: “詹姆斯·邦德住在哪里？”})’ 这样将参数作为字典传递，而应直接使用参数，如 ‘answer = wiki(query=“詹姆斯·邦德住在哪里？”)’。
1. 注意不要在同一代码块中链接过多连续的工具调用，尤其是当输出格式不可预测时。例如，search 的调用返回格式不可预测，因此不要在同一块中进行另一个依赖其输出的工具调用：相反，使用 print() 输出结果以便在下一区块中使用它们。
1. 仅在需要时调用工具，并且不要重复调用之前已使用相同参数调用过的工具。
1. 不要将任何新变量命名为与工具相同的名称：例如不要将变量命名为 ‘final_answer’。
1. 不要在代码中创建任何假设变量，因为这些变量出现在日志中会使您偏离真正的变量。
1. 您可以在代码中使用导入，但仅限于以下模块列表中的模块：[‘asyncio’, ‘collections’, ‘csv’, ‘datetime’, ‘gitingest’, ‘io’, ‘itertools’, ‘json’, ‘math’, ‘os’, ‘pandas’, ‘queue’, ‘random’, ‘re’, ‘requests’, ‘stat’, ‘statistics’, 'sys ', ‘time’, ‘unicodedata’]
1. 状态在代码执行之间保持不变：因此，如果您在一个步骤中创建了变量或导入了模块，这些都会持续存在。
  10.10. 不要放弃！您负责解决问题，而不是提供解决问题的方向。

现在开始吧！如果您正确解决了任务，您将获得 $1,000,000 的奖励。

A.7.2 任务提示

新任务：
您将获得一个部分代码库
和一个问题陈述，解释需要解决的问题。

$(插入问题 HERE }

$(插入仓库 HERE }

<base_commit>
$(基础提交}
</base_commit>
这里是补丁文件的一个示例。它由代码更改组成
基本。它指定文件名、每次更改的行号，
以及删除和添加的行。单个补丁文件可以包含
多个文件的更改。

— a/file.py
+++ b/file.py
@@ -1,27 +1,35 @@
def euclidean(a, b):
- while b:
- - a, b = b, a % b
- - return a
- + if b == 0:
- + return a
- + return euclidean(b, a % b)
- def bresenham(x0, y0, x1, y1):
- points = []
- dx = abs(x1 - x0)
- dy = abs(y1 - y0)
- - sx = 1 if x0 < x1 else -1
- - sy = 1 if y0 < y1 else -1
- - err = dx - dy
- + x, y = x0, y0

sx = -1 if x0 > x1 else 1
- sy = -1 if y0 > y1 else 1
- while True:
- points.append((x0, y0))
- if x0 == x1 and y0 == y1:
- break
- e2 = 2 * err
- if e2 > -dy:
- if dx > dy:
- err = dx / 2.0
- while x != x1:
- points.append((x, y))
err -= dy
- x0 += sx
- if e2 < dx:
- err += dx
- y0 += sy
- if err < 0:
- y += sy
- err += dx
- x += sx
- else:
- err = dy / 2.0
- while y != y1:
- points.append((x, y))
- err -= dx
- if err < 0:
- x += sx
- err += dy
- y += sy
- points.append((x, y))
return points
我需要您通过生成单个补丁文件来解决提供的问题，我可以直接使用 git apply 将其应用到此存储库。请以以上所示的格式回复单个补丁文件。
为了解决这个问题，您必须首先使用 gitingest 如下（您可以根据需要多次使用它）：
from gitingest import ingest_async import asyncio
summary, tree, content = asyncio.run(ingest_async(“https://github.com/pydicom/pydicom/commit/49a3da4a3d9c24d7e8427a25048a1c7d5c4f7724”, max_file_size=110241024)) # 过滤掉大于 1MB 的文件大小
…
您必须仔细分析存储库的树结构及其摘要，以理解代码和目录结构。
content 变量是一段非常大的字符串（无法直接打印或处理）。字符串的结构如下：
…
$==========$
File: README.md
$==========$
[README.md 文件的内容在此]
$==========$
File: directory/file.py
$==========$
[目录/file.py 文件的内容在此]
…
您必须通过编写适当的正则表达式代码在内存中解析此字符串以提取相应文件的内容。
不要尝试读取整个字符串，始终编写正则表达式以解析或搜索适合的文件和内容字符串。
一个示例正则表达式函数用于提取 README.md 的内容，您可以这样做：
…
def extract_readme_content(text):
pattern = r’={2,}\s*
File: README.md\s*
={2,}\s*
(.?)(?=\s
={2,}\s*
File:|\Z)’
match = re.search(pattern, text, re.DOTALL)
if match:
return match.group(1).strip()
return “README.md 内容未找到”
’ ’ ’
请记住，您可以直接读取 summary 和 tree
变量，但不要尝试读取整个 content 字符串，因为它可能太大而无法保存在内存中。您必须找到一种合适的方法来读取和理解这些代码文件。
还有可能文件的内容（例如上述示例中的 directory/file.py 的内容）也可能太大而无法读取，因此您必须仅逐块读取或对提取的文件字符串进行正则表达式搜索。绝不应直接读取整个 ‘content’ 变量或特定内容文件。
不要尝试使用 git 命令，仅使用 gitingest 导入来读取和理解文件系统以生成合适的补丁文件。无论如何都不要将文件内容打印到终端进行分析。如果要分析文件字符串的内容，请确保一次只分析 500 个字符。