TLDR： 最好的 Agent 评测会直接衡量我们真正关心的 Agent 行为。下面介绍我们如何获取数据、定义指标，并持续运行范围清晰、目标明确的实验，从而让 Agent 更准确、更可靠。

评测会塑造 Agent 的行为

我们一直在策划评测，用来衡量并改进 Deep Agents^[1]。Deep Agents 是一个开源、与模型无关的 agent harness，为 Fleet^[2] 和 Open SWE^[3] 等产品提供能力支持。评测会定义并塑造 Agent 的行为，因此必须经过审慎设计。

每个评测都是一个会改变你的 agent 系统行为方向的向量。举例来说，如果某个用于评估高效文件读取的评测失败了，你很可能会调整系统提示词或 read_file 工具描述，逐步引导模型通过该评测。你保留下来的每一个评测，都会持续对整体系统施加压力。

在添加评测时，认真取舍至关重要。人们很容易不加筛选地增加数百个甚至上千个测试。这样会造成一种“你的 agent 正在变好”的错觉，但这个评测集合未必真实反映你在生产环境中关心的行为。

评测更多，并不等于 Agent 更好。相反，应构建能够反映生产中目标行为的定向评测。

在构建 Deep Agents 时，我们会梳理生产环境中真正重要的行为，例如跨文件系统中的多个文件检索内容，或者准确地按顺序组合 5 次以上的工具调用。我们不会把基准任务简单混在一起看，而是采用如下方式策划评测：

1. 1. 先决定我们希望 Agent 遵循哪些行为，再研究并整理能够以可验证方式衡量这些行为的定向评测。
2. 2. 为每个评测补充 docstring，说明它在衡量哪项 Agent 能力。这样每个评测本身就具备自解释性。我们还会为评测打上如 tool_use 这样的标签，便于分组运行。
3. 3. 审查输出 trace，理解失败模式，并更新评测覆盖范围。

由于我们会把每次评测运行都追踪到共享的 LangSmith^[4] 项目里，团队中的任何人都可以介入分析问题、进行修复，并重新评估某个评测的价值。这让添加和维护优质评测成为共同责任。跨大量模型运行大量评测也会很昂贵，因此定向评测既能省钱，也能提升 Agent。

这篇博客会介绍：

• • 我们如何策划数据
• • 我们如何定义指标
• • 我们如何运行评测

我们如何策划数据

我们获取评测数据主要有几种方式：

1. 1. 使用我们在日常 dogfooding 自家 agent 时得到的反馈
2. 2. 从外部基准中挑选部分评测（例如 Terminal Bench 2.0^[5] 或 BFCL^[6]），并且通常会针对特定 agent 做适配
3. 3. 针对我们认为重要的行为，手工编写自己的（artisanal）评测和单元测试

注意：我们会把 SDK 的单元测试和集成测试（系统提示词透传、interrupt 配置、subagent 路由）与模型能力评测分开。任何模型都能通过这些测试，因此把它们计入评分并没有信号价值。你当然应该编写单元测试和集成测试，但这篇博客只聚焦模型能力评测。

Dogfooding agent 并阅读 trace，是评测的重要来源

这样我们才能发现错误。Traces^[4] 为我们理解 Agent 行为提供数据。由于 trace 往往很大，我们会使用内置 agent，例如 Polly^[4] 或 Insights^[7]，来大规模分析它们。你也可以用其他 agent 来做同样的事情（例如 Claude Code 或 Deep Agents CLI^[4]），再配合一种拉取 trace 的方式，例如 LangSmith CLI^[4]。

我们的目标是理解每一种失败模式，提出修复方案，重新运行 agent，并持续追踪随时间发生的改进与回归。

例如，现在很大一部分修复 bug 的 PR 都通过 Open SWE^[8] 来驱动，它是我们的开源后台编码 agent。使用它的团队会接触到许多不同的代码库，而这些代码库又有不同的上下文、约定与目标，这自然会导致错误。Open SWE 的每一次交互都会被追踪，因此这些交互很容易转化成评测，确保同样的错误不会再次发生。

另外一些评测则来自现有基准，并经过调整，例如用于函数调用的 BFCL^[6]。对于编码任务，我们会与 Harbor^[9] 集成，在沙箱环境中运行来自 Terminal Bench 2.0^[10] 等数据集的选定任务。还有许多评测是从零编写的，作为聚焦型测试，用来观察孤立行为，例如测试 read_file 工具。

我们按“评测在测试什么”来分组

拥有一套评测分类体系会很有帮助，它能让我们在观察 Agent 表现时获得一个中间层视角，既不是单一数字，也不是一条条独立运行记录。

提示：建立这套分类体系时，要看它们在测试什么，而不是它们来自哪里。

例如，来自 FRAMES^[11] 和 BFCL^[6] 的任务都可以被标记为“外部基准”，但那样无法体现它们分别衡量的是检索和工具使用。

下面是我们定义的一些类别及其测试内容：

如今，所有评测都是让 Agent 在任务上执行端到端运行。我们有意鼓励评测结构的多样性。有些任务只需针对一个输入提示执行单步完成，而另一些任务则会让另一个模型模拟用户，进行 10 轮以上的交互。

我们如何定义指标

在为 Agent 选择模型时，我们首先看正确性。如果模型不能稳定完成我们关心的任务，其它一切都无从谈起。我们会在评测上运行多个模型，并随着时间推移不断改进 harness，以解决我们发现的问题。

如何衡量正确性，取决于具体在测什么。大多数内部评测使用自定义断言，例如“Agent 是否并行化了工具调用？”。像 BFCL 这样的外部基准则使用与数据集标准答案做精确匹配。对于那些正确性更偏语义层面的评测，例如 Agent 是否把正确的信息写入了记忆，我们会采用 LLM-as-a-judge。

一旦有多个模型跨过正确性这条门槛，我们就转向效率。两个能完成同一任务的模型，在实际行为上可能大不相同。一个模型可能会多走几轮、多发起不必要的工具调用，或者因为模型规模而推进更慢。在生产环境里，这些差异会体现为更高的延迟、更高的成本，以及更差的整体用户体验。

综合来看，我们会为每次 evaluator 运行记录以下指标：

Solve rate 用来衡量 Agent 解决任务的速度，并按预期步数做归一化。和 latency ratio 一样，它反映的是完成任务的端到端时间，其中包括模型往返、服务商延迟、走错路以及工具执行时间。对于我们能够定义理想轨迹的简单任务而言，solve rate 往往比 latency ratio 更容易使用，因为它只要求测量当前 agent 完成任务所花的时间。

这给了我们一种简单方式，用定向评测集来选择模型：

1. 1. 先检查正确性：哪些模型在你真正关心的任务上已经足够准确？
2. 2. 再比较效率：在“已经够好”的模型中，哪一个在正确性、延迟和成本之间给出了最佳权衡？

评测周边有用指标的示例

为了让模型比较真正具备可操作性，我们会研究模型成功和失败的方式。这要求我们除了准确率之外，还要有一个关于“好执行”应当是什么样子的具体参照点。我们使用的一种基础概念是理想轨迹（ideal trajectory）。它是一串能够得到正确结果、且没有“不必要”动作的步骤序列。

对于简单、边界清晰的任务，变量定义得足够紧，因此最优路径通常很明显。对于更开放式的任务，我们会先使用目前见过表现最好的模型来近似一条轨迹，然后随着模型和 harness 的改进不断回访这个基线。通过这种方式，观察 Agent 行为也能帮助我们修正自己对理想轨迹的先验判断。

考虑一个简单请求：

“我住的地方现在几点，天气怎么样？”

一个 Agent 的理想轨迹可能是这样的：

• • 它只做必要的最少工具调用（例如，解析用户 → 解析位置 → 获取时间和天气）
• • 在可能的地方并行执行彼此独立的工具调用
• • 在没有不必要中间轮次的情况下直接生成最终答案

理想轨迹：4 步，4 次工具调用，约 8 秒

现在再看一条虽然技术上仍然正确，但效率更低的轨迹。

低效轨迹：6 步，5 次工具调用，约 14 秒。

正确但低效的轨迹：6 个 agent 步骤、5 次工具调用，包含一次不必要的工具调用，而且没有对工具调用进行并行化。

上面的例子主要用于说明问题：用 REPL 也许能更快解决这个特定任务，但这里使用更简单的工具调用版本，更便于解释这个概念。

两次运行都得到了正确结果，但第二次运行增加了延迟和成本，也创造了更多失败机会。

这种框架使我们能够在评测中同时评估正确性和效率。我们会维护并更新这些指标，把运行结果提炼成可量化的数值，用来比较不同实验。

基于上面的例子，那次“低效但正确”的运行会得到如下分数：

我们如何运行评测

我们使用 pytest 配合 GitHub Actions 在 CI 中运行评测，这样每次变更都会在干净、可复现的环境中执行。每个评测都会创建一个带有特定模型的 Deep Agent 实例，向其输入任务，并计算正确性和效率指标。

我们也可以通过标签运行评测子集，以节省成本并衡量定向实验。例如，如果你正在构建一个需要大量本地文件处理与综合的 Agent，那么我们可能会重点关注带有 file_operations 和 tool_use 标签的子集。

   
   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 仓库^[1] 中开源。

接下来呢

我们正在扩展评测套件，并围绕开源 LLM 做更多工作。下面是一些我们很期待尽快分享的内容：

• • 开放模型在各类评测中与封闭前沿模型相比表现如何
• • 把评测作为一种机制，让 Agent 能够针对任务实时自我改进
• • 公开分享我们如何随着时间推移维护、缩减并扩展每个 Agent 的评测集合

Deep Agents^[1] 已经完全开源。欢迎试用并告诉我们你的看法！我们很期待帮助团队构建出色的 Agent 和评测。

引用链接

[1] Deep Agents: https://github.com/langchain-ai/deepagents?ref=blog.langchain.com
[2] Fleet: https://www.langchain.com/
[3] Open SWE: https://github.com/langchain-ai/open-swe?ref=blog.langchain.com
[4] LangSmith: https://docs.langchain.com/
[5] Terminal Bench 2.0: https://www.tbench.ai/?ref=blog.langchain.com
[6] BFCL: https://gorilla.cs.berkeley.edu/leaderboard.html?ref=blog.langchain.com
[7] Insights: https://docs.langchain.com/langsmith/insights?ref=blog.langchain.com
[8] Open SWE: https://blog.langchain.com/open-swe-an-open-source-framework-for-internal-coding-agents/
[9] Harbor: https://github.com/
[10] Terminal Bench 2.0: https://www.tbench.ai/leaderboard/terminal-bench/2.0?ref=blog.langchain.com
[11] FRAMES: https://huggingface.co/

https://blog.langchain.com/how-we-build-evals-for-deep-agents/