我们如何为Deep Agents构建评估体系

我们如何为Deep Agents构建评估体系我们如何为Deep Agents构建评估体系 Modified March 29 以下是我们定义的部分类别及其测试内容：如今，所有评估均为智能体在任务上的端到端运行过程。我们刻意鼓励评估结构呈现多样性。部分任务仅需依据输入提示单步完成，而另一些任务则需要与另一款模拟用户的模型进行十余轮交互才能结束。我们如何定义评估指标在为智能体挑选模型时，我们首先考量的是准确性。如果一个模型无法可靠完成我们所关注的任务，其他方面便都无从谈起。我们会在评估测试中运行多款模型，并持续优化评估框架，以解决发现的各类问题。准确性的衡量标准取决于具体的测试内容。多数内部评估会采用自定义判定条件，例如“智能体是否实现了工具调用并行化？”。而像BFCL这类外部基准测试，则会与数据集中的标准答案进行严格精准匹配。对于需从语义层面判断准确性的评估场景，比如智能体是否在内存中正确存储了相应内容，我们会采用大模型作为评判依据。当多款模型满足准确性要求后，我们便会进一步考量效率。在实际应用中，即便两个模型能完成同一任务，表现也可能差异显著。其中一个可能会产生多余交互步骤、发起不必要的工具调用，或是因模型体量较大导致任务执行速度更慢。在生产环境中，这些差异会体现为更高的延迟、更多的成本消耗，以及更差的整体用户体验。综上，我们在每次评估运行中所测算的指标包括：解决速率衡量智能体完成任务的速度，并按预期步骤数进行标准化处理。与延迟率类似，它反映完成任务的端到端耗时，涵盖模型往返交互、服务提供商延迟、错误尝试以及工具执行时间等环节。对于可定义理想执行路径的简单任务，使用解决速率比延迟率更简便，因为它仅需测量对应智能体完成任务的耗时。这为我们通过目标评估集筛选模型提供了简便方法： 1. 首先核查准确性：哪些模型在你实际关注的任务上具备足够精度？ 2. 随后对比效率：在表现达标的模型中，哪一个能在准确性、延迟与成本之间实现最优平衡？评估相关实用指标示例为了让模型对比具备实际指导意义，我们需要分析模型表现优劣的具体原因。这就需要在准确率之外，为“良好执行”确立一个具体的参照标准。我们采用的一个基础方法是设定理想执行路径，即一系列能够生成正确结果、且不包含任何“多余”操作的步骤序列。对于边界清晰、任务简单的场景，相关变量定义足够明确，最优执行路径通常显而易见。而对于开放性更强的任务，我们会先以目前表现最优的模型为参照，近似拟合出一条执行路径，后续随着模型与测试框架的迭代优化，再重新调整这一基准。通过这种方式，观察智能体的行为能够帮助我们优化对理想执行路径的预设认知。以一个简单请求为例： “我所在地区的当前时间和天气情况是什么？” 智能体的理想执行路径可能如下：仅进行最少必要的工具调用（例如：识别用户→确定位置→获取时间与天气信息）在可行时对相互独立的工具调用进行并行处理直接生成最终答案，不产生多余的中间交互轮次理想轨迹：4步，4次工具调用，约8秒现在将其与一条在技术上仍然正确，但效率较低的轨迹进行比较。低效轨迹：6步，5次工具调用，约14秒。正确但低效的轨迹：6个智能体步骤，5次工具调用，包含一次不必要的工具调用，且未并行化工具调用。上述示例具有说明性：REPL甚至可以更快地解决此任务，但工具调用版本使这个想法更容易解释。两次运行都是正确的，但第二次运行会增加延迟和成本，并增加失败的可能性。这种框架使我们能够在评估中同时评估正确性和效率。我们维护和更新指标，将运行结果提炼为可用于比较实验的可衡量数字。从上面的例子来看，低效但正确的运行得分如下：我们如何进行评估我们在 CI 中使用 pytest 和 GitHub Actions 来运行评估，以便在干净、可重现的环境中执行变更。每次评估都会使用给定的模型创建一个 Deep Agent 实例，为其提供一个任务，并计算正确性和效率指标。我们还可以使用标签运行评估的一个子集，以节省成本并衡量有针对性的实验。例如，如果构建一个需要大量本地文件处理和合成的智能体，我们可以专注于标记为 file operations 和 tool use 的子集。 Code block Bash Copy export LANGSMITH API KEY="lsv2 ..." uv run pytest tests/evals eval category file operations eval category tool use model baseten:nvidia/zai org/GLM 5 我们的评估架构和实现已在Deep Agents仓库中开源。下一步是什么我们正在扩展评估套件，并围绕开源大语言模型开展更多工作！我们很快就会分享一些内容： • 开放模型在各评估类别中与封闭前沿模型的对比情况 • 评估作为一种实时自动改进代理以执行任务的机制 • 公开分享我们如何随时间维护、减少和扩展每个代理的评估感谢帮助审核和共同撰写此博客的优秀团队@masondrxy @veryboldbagel、@hwchase17。 Deep Agents完全开源。试用一下，告诉我们你的想法！我们很乐意帮助团队打造出色的智能体和评估系统。以下是我们定义的部分类别及其测试内容：如今，所有评估均为智能体在任务上的端到端运行过程。我们刻意鼓励评估结构呈现多样性。部分任务仅需依据输入提示单步完成，而另一些任务则需要与另一款模拟用户的模型进行十余轮交互才能结束。我们如何定义评估指标在为智能体挑选模型时，我们首先考量的是准确性。如果一个模型无法可靠完成我们所关注的任务，其他方面便都无从谈起。我们会在评估测试中运行多款模型，并持续优化评估框架，以解决发现的各类问题。准确性的衡量标准取决于具体的测试内容。多数内部评估会采用自定义判定条件，例如“智能体是否实现了工具调用并行化？”。而像BFCL这类外部基准测试，则会与数据集中的标准答案进行严格精准匹配。对于需从语义层面判断准确性的评估场景，比如智能体是否在内存中正确存储了相应内容，我们会采用大模型作为评判依据。当多款模型满足准确性要求后，我们便会进一步考量效率。在实际应用中，即便两个模型能完成同一任务，表现也可能差异显著。其中一个可能会产生多余交互步骤、发起不必要的工具调用，或是因模型体量较大导致任务执行速度更慢。在生产环境中，这些差异会体现为更高的延迟、更多的成本消耗，以及更差的整体用户体验。综上，我们在每次评估运行中所测算的指标包括：解决速率衡量智能体完成任务的速度，并按预期步骤数进行标准化处理。与延迟率类似，它反映完成任务的端到端耗时，涵盖模型往返交互、服务提供商延迟、错误尝试以及工具执行时间等环节。对于可定义理想执行路径的简单任务，使用解决速率比延迟率更简便，因为它仅需测量对应智能体完成任务的耗时。这为我们通过目标评估集筛选模型提供了简便方法： 1. 首先核查准确性：哪些模型在你实际关注的任务上具备足够精度？ 2. 随后对比效率：在表现达标的模型中，哪一个能在准确性、延迟与成本之间实现最优平衡？评估相关实用指标示例为了让模型对比具备实际指导意义，我们需要分析模型表现优劣的具体原因。这就需要在准确率之外，为“良好执行”确立一个具体的参照标准。我们采用的一个基础方法是设定理想执行路径，即一系列能够生成正确结果、且不包含任何“多余”操作的步骤序列。对于边界清晰、任务简单的场景，相关变量定义足够明确，最优执行路径通常显而易见。而对于开放性更强的任务，我们会先以目前表现最优的模型为参照，近似拟合出一条执行路径，后续随着模型与测试框架的迭代优化，再重新调整这一基准。通过这种方式，观察智能体的行为能够帮助我们优化对理想执行路径的预设认知。以一个简单请求为例： “我所在地区的当前时间和天气情况是什么？” “我所在地区的当前时间和天气情况是什么？” 智能体的理想执行路径可能如下：仅进行最少必要的工具调用（例如：识别用户→确定位置→获取时间与天气信息）在可行时对相互独立的工具调用进行并行处理直接生成最终答案，不产生多余的中间交互轮次理想轨迹：4步，4次工具调用，约8秒现在将其与一条在技术上仍然正确，但效率较低的轨迹进行比较。低效轨迹：6步，5次工具调用，约14秒。正确但低效的轨迹：6个智能体步骤，5次工具调用，包含一次不必要的工具调用，且未并行化工具调用。上述示例具有说明性：REPL甚至可以更快地解决此任务，但工具调用版本使这个想法更容易解释。两次运行都是正确的，但第二次运行会增加延迟和成本，并增加失败的可能性。这种框架使我们能够在评估中同时评估正确性和效率。我们维护和更新指标，将运行结果提炼为可用于比较实验的可衡量数字。从上面的例子来看，低效但正确的运行得分如下：我们如何进行评估我们在 CI 中使用 pytest 和 GitHub Actions 来运行评估，以便在干净、可重现的环境中执行变更。每次评估都会使用给定的模型创建一个 Deep Agent 实例，为其提供一个任务，并计算正确性和效率指标。我们还可以使用标签运行评估的一个子集，以节省成本并衡量有针对性的实验。例如，如果构建一个需要大量本地文件处理和合成的智能体，我们可以专注于标记为 file operations 和 tool use 的子集。我们的评估架构和实现已在Deep Agents仓库中开源。下一步是什么我们正在扩展评估套件，并围绕开源大语言模型开展更多工作！我们很快就会分享一些内容： • 开放模型在各评估类别中与封闭前沿模型的对比情况 • 评估作为一种实时自动改进代理以执行任务的机制 • 公开分享我们如何随时间维护、减少和扩展每个代理的评估感谢帮助审核和共同撰写此博客的优秀团队@masondrxy @veryboldbagel、@hwchase17。 Deep Agents完全开源。试用一下，告诉我们你的想法！我们很乐意帮助团队打造出色的智能体和评估系统。 🔗 原文链接： https://x.com/Vtrivedy10/status/203... https://x.com/Vtrivedy10/status/203... 简而言之：最优质的智能体评估方法会直接衡量我们所关注的智能体行为。本文将介绍我们如何采集数据、构建评估指标，并持续开展范围明确、目标精准的实验，从而让智能体更加精准可靠。评估指标塑造智能体行为我们一直在精心设计评估体系，用以衡量并优化Deep Agents。Deep Agents是一款开源、不依赖特定模型的智能体框架，为Fleet和Open SWE等产品提供底层支撑。评估体系定义并塑造着智能体的行为表现，因此精心设计评估方案至关重要。每一项评估都是一个导向向量，会改变智能体系统的运行行为。举例而言，如果针对高效文件读取的评估未通过，你通常会调整系统提示词或read file工具的描述，逐步引导智能体行为优化直至评估达标。长期来看，你保留的每一项评估都会对整个系统产生持续影响。新增评估项时必须审慎考量。人们很容易盲目添加成百上千项测试，这会造成一种“智能体性能提升”的假象——即便在这套评估体系中取得高分，也未必能真实反映其在实际生产环境中所需的行为表现。评估项数量更多≠智能体性能更优。反之，应构建针对性评估，精准匹配生产环境中期望智能体具备的行为能力。在开发Deep Agents时，我们会梳理出生产环境中关键的智能体行为，例如跨文件系统检索内容、精准连续完成5次及以上工具调用等。我们并未采用综合基准测试任务，而是通过以下方式开展评估设计工作： • 确定我们希望智能体遵循的行为模式。随后调研并筛选出针对性评估方法，以可验证的方式衡量这些行为。 • 为每一项评估添加文档字符串，说明其如何衡量智能体的某项能力，确保每项评估均可自我说明。同时为各项评估打上工具使用等类别标签，以便分组运行。 • 复盘输出轨迹，梳理故障模式，并完善评估覆盖范围。由于我们将每一次评估运行都追踪至一个共享的LangSmith</b 项目，团队中的任何人都能随时介入分析问题、进行修复，并重新评估某项评估的价值。这就形成了共同负责添加和维护优质评估的机制。在多项评估中运行大量模型也可能产生高昂成本，因此针对性评估既能节约成本，又能优化你的智能体。本文将介绍： • 我们如何筛选数据 • 我们如何定义指标 • 我们如何开展评估我们如何筛选整理数据我们获取评估数据主要有以下几种方式：借助对智能体进行内部试用所获得的反馈从外部基准测试（如Terminal Bench 2.0或BFCL）中选取部分评估内容，并常针对特定智能体进行适配调整针对我们认为重要的行为，手动编写专属评估案例与单元测试我们每天都会对智能体进行内部实测。每一次出现的错误，都是我们编写评估用例、更新智能体定义以及上下文工程实践方法的契机。注：我们将SDK单元测试与集成测试（系统提示透传、中断配置、子智能体路由）和模型能力评估区分开来。所有模型都能通过这类测试，因此将其纳入评分体系并不会产生有效参考价值。你务必编写单元测试与集成测试，但本篇博客仅聚焦于模型能力评估。注：我们将SDK单元测试与集成测试（系统提示透传、中断配置、子智能体路由）和模型能力评估区分开来。所有模型都能通过这类测试，因此将其纳入评分体系并不会产生有效参考价值。你务必编写单元测试与集成测试，但本篇博客仅聚焦于模型能力评估。对智能体进行自用测试与查阅运行轨迹，是构建评估用例的绝佳途径这使得发现错误成为可能。追踪日志为我们提供了理解智能体行为的数据。由于追踪日志通常体量庞大，我们会使用Polly或Insights这类内置智能体对其进行大规模分析。你也可以借助其他智能体（如Claude Code或Deep Agents CLI），搭配LangSmith CLI这类工具来拉取追踪日志，实现同样的效果。我们的目标是厘清每一种故障模式，提出修复方案，重新运行智能体，并持续跟踪进展与功能回退情况。例如，目前很大一部分修复漏洞的拉取请求，都是通过我们的开源后台编码智能体Open SWE完成的。使用该工具的团队会接触到诸多不同的代码库，这些代码库有着各异的上下文、开发规范和目标，自然容易产生错误。Open SWE的每一次交互都会被记录追踪，因此这些记录可轻松转化为评估用例，确保同类错误不再重现。其他评估用例则参考并调整自现有基准测试，比如用于函数调用的BFCL</b 。针对编码任务，我们集成了Harbor，在沙箱环境中运行来自Terminal Bench 2.0等数据集的选定任务。还有许多评估用例为从零编写而成，作为专项测试来观察独立的行为表现，比如对文件读取工具进行测试。我们会根据评估所测试的内容对其进行分组建立评估指标分类体系有助于从整体层面了解智能体的表现（既非单一数值，也非单次运行结果）。提示：构建该分类体系时应依据其测试内容，而非来源。例如，来自FRAMES和BFCL的任务可标注为“外部基准测试”，但这样无法体现二者分别用于衡量检索能力与工具使用能力。提示：构建该分类体系时应依据其测试内容，而非来源。例如，来自FRAMES和BFCL的任务可标注为“外部基准测试”，但这样无法体现二者分别用于衡量检索能力与工具使用能力。