一句话定性：这是一份可以直接照抄的 Agent 评测工程手册，覆盖数据来源、指标定义与 CI 集成的全链路。
最值得拿走的是三个做法：一是每个评测都写 docstring 说明它度量哪种能力，并打上 tool_use、file_operations 之类的标签以支持分组运行，让评测自文档化、可按需裁剪；二是把所有评测运行都追踪到同一个 LangSmith 项目，让全团队共享分析、修复与维护评测的责任；三是用「理想轨迹」做参照物，把正确但低效的运行量化为步数比 1.5、工具调用比 1.25、延迟比 1.75 这类可比数字。最容易误用的地方：盲目堆几百上千个测试，在错误的评测集上拿高分，造成「Agent 在变好」的幻觉。
中文读者为什么要读：国内团队的 Agent 评测常停留在跑几个 demo 案例，这篇给出了把评测变成持续压力系统的完整样板，尤其是「SDK 单元测试与模型能力评测分开计分」这一点，多数团队尚未区分。国内语境要叠加的是：中文任务与国内模型的评测子集需要自建，分类法可以直接沿用。
行动建议：为你的 Agent 列出五个最在乎生产行为的能力类别，本周先给每一类写一个带 docstring 的针对性评测。
—— FDEChina编辑部 · 架构师视角
关键要点：最好的 Agent 评测直接度量我们真正在乎的 Agent 行为。下面是我们如何收集数据、定义指标，并随时间运行范围清晰、目标明确的实验，让 Agent 更准确、更可靠。
评测塑造 Agent 行为
我们一直在精心维护评测，用来度量并改进 Deep Agents。Deep Agents 是一个开源、模型无关的 Agent 执行框架（harness），支撑着 Fleet 和 Open SWE 等产品。评测定义并塑造 Agent 的行为，这正是必须审慎设计评测的原因。
每一个评测都是一个向量，会推动你的 Agent 系统的行为发生偏移。例如，如果某个关于高效文件读取的评测失败了，你很可能会去调整系统提示词或 read_file 工具的描述，反复微调直到它通过。你保留的每一个评测，都会随时间对整个系统持续施加压力。
添加评测时保持审慎至关重要。人们很容易忍不住盲目添加成百上千个测试，这会导致一种幻觉——在一个未必准确反映你生产环境中关键行为的评测套件上「提升 Agent」。
评测越多 ≠ Agent 越好。要构建的是反映生产中期望行为的、有针对性的评测。
构建 Deep Agents 时，我们先把生产中真正重要的行为编目，例如跨文件系统中的多个文件检索内容、准确地把 5 个以上的工具调用按正确顺序组合起来。我们不用基准任务的聚合跑分，而是采用下面这套评测维护方法：
- 先决定我们希望 Agent 遵循哪些行为，然后研究并筛选出能以可验证方式度量这些行为的针对性评测。
- 为每个评测添加一段 docstring，说明它度量的是哪一项 Agent 能力。这保证每个评测都是自文档化的。我们还给每个评测打上 tool_use 之类的类别标签，以支持分组运行。
- 审阅输出轨迹以理解失败模式，并更新评测覆盖面。
因为我们把每一次评测运行都追踪到同一个共享的 LangSmith 项目，团队任何人都可以随时加入，分析问题、做出修复、并重新评估某个评测的价值。这让「添加并维护好评测」成为一项共同责任。多模型乘多评测的运行成本也不低，有针对性的评测既能省钱，又能真正改进你的 Agent。
本文内容包括：
- 我们如何筛选数据
- 我们如何定义指标
- 我们如何运行评测
我们如何筛选数据
我们的评测有几种来源：
- 使用来自自用自家 Agent（dogfooding）的反馈
- 从外部基准（如 Terminal Bench 2.0 或 BFCL）中挑选评测，并常常针对特定 Agent 做改造
- 为我们认为重要的行为手工编写自己的（artisanal）评测与单元测试
我们每天都会吃自己的狗粮。每一个报错都变成编写一个评测、更新 Agent 定义与上下文工程实践的机会。
注意：我们把 SDK 的单元测试与集成测试（系统提示词透传、中断配置、子智能体路由等）与模型能力评测分开。任何模型都能通过那些测试，把它们计入评分不会带来任何信号。你当然应该写单元测试和集成测试，但本文只聚焦于模型能力评测。
吃狗粮与读轨迹是评测的富矿
这让发现错误成为可能。轨迹给了我们理解 Agent 行为的数据。由于轨迹往往很大，我们使用内置 Agent（如 Polly 或 Insights）来规模化分析它们。你也可以用其他 Agent（如 Claude Code 或 Deep Agents CLI）加上拉取轨迹的手段（如 LangSmith CLI）做同样的事。我们的目标是：理解每一种失败模式、提出修复、重新运行 Agent，并随时间追踪进展与回归。
举例来说，现在很大一部分修 bug 的 PR 是通过 Open SWE——我们的开源后台编码 Agent——驱动的。使用它的团队触及大量不同的代码库，各自有不同的上下文、约定与目标，这自然会导致错误。Open SWE 的每一次交互都有轨迹，这些轨迹可以轻松转化为评测，确保同样的错误不再发生。
另一些评测则取自现有基准并做调整，比如用于函数调用的 BFCL。对编码任务，我们与 Harbor 集成，在沙箱环境中运行 Terminal Bench 2.0 等数据集中的精选任务。还有许多评测完全从零手写，充当观察孤立行为的聚焦测试，比如测试 read_file 工具。
我们按「测什么」给评测分组
给评测建一套分类法很有用：它能让你看到 Agent 表现的中间视角——既不是单一总分，也不是逐条运行记录。
提示：分类时看它们测什么，而不是看它们来自哪里。例如，FRAMES 和 BFCL 的任务都可以被打上「外部基准」的标签，但这并不能展示它们分别度量的是检索能力还是工具使用。
以下是我们定义的一部分类别，以及它们各自测试什么：
| 类别 | 测试内容 |
|---|---|
| file_operations | 文件工具（read、write、edit、ls、grep、glob）、并行调用、分页 |
| retrieval | 跨文件查找信息、搜索策略、多跳文档综合 |
| tool_use | 选择正确的工具、串联多步调用、跨轮次追踪状态 |
| memory | 召回预置上下文、提取隐含偏好、持久化持久信息 |
| conversation | 对模糊请求提出澄清问题、在多轮对话中持续做出正确动作 |
| summarization | 处理上下文溢出、触发摘要、在压缩后恢复信息 |
| unit_tests | SDK 管道——系统提示词透传、中断配置、子智能体路由、技能路径解析等是否都正常？ |
目前，所有评测都是 Agent 在某个任务上的端到端运行。我们刻意鼓励评测结构的多样性：有些任务从一条输入提示出发、一步完成，另一些则需要 10 个以上轮次，并由另一个模型模拟用户。
我们如何定义指标
为我们的 Agent 选择模型时，我们首先看正确性。如果一个模型无法可靠完成我们在乎的任务，其他一切都免谈。我们在评测上运行多个模型，并随时间打磨 harness，解决暴露出的问题。
正确性的度量取决于被测对象。多数内部评测使用自定义断言，比如「Agent 是否并行化了工具调用？」。BFCL 这类外部基准则使用与数据集标准答案的精确匹配。对于那些正确性属于语义层面的评测——比如 Agent 是否把正确的东西存进了记忆——我们使用 LLM 作为裁判（LLM-as-a-judge）。
当若干模型跨过正确性这道门槛后，我们转向效率。两个解决同一任务的模型，实际行为可能大不相同：一个可能多花好几个轮次、做出不必要的工具调用，或因为模型体量而推进得更慢。在生产环境中，这些差异表现为更高的延迟、更高的成本和更差的整体用户体验。
综合起来，我们为每次评测运行度量的指标如下：
| 指标 | 定义 |
|---|---|
| 正确性（Correctness） | 模型是否正确完成了任务 |
| 步数比（Step ratio） | 实际 Agent 步数 / 理想 Agent 步数 |
| 工具调用比（Tool call ratio） | 实际工具调用数 / 理想工具调用数 |
| 延迟比（Latency ratio） | 实际延迟 / 理想延迟 |
| 求解率（Solve rate） | 期望步数 / 实际延迟，若任务未正确解决则为 0 分 |
求解率衡量 Agent 多快解决一个任务，并以期望步数归一化。与延迟比一样，它捕捉的是端到端的任务解决时间——包括模型往返、供应商延迟、走弯路与工具执行时间。对于那些我们能定义理想轨迹的简单任务，求解率比延迟比更好用，因为它只需要测量给定 Agent 的任务耗时。
这样一来，用一组有针对性的评测来选模型就变得简单：
- 先看正确性：哪些模型在你真正在乎的任务上足够准确？
- 再比较效率：在足够好的模型中，哪一个在正确性、延迟与成本之间给出最好的权衡？
围绕评测的实用指标示例
要让模型对比可执行，我们需要考察模型如何成功、如何失败。这要求一个超越准确率的具体参照点，来定义什么是「好的」执行。我们使用的一个基础工具是理想轨迹（ideal trajectory）：一串能产出正确结果、且没有「不必要」动作的步骤序列。
对于范围清晰的简单任务，各变量被定义得足够紧，最优路径通常显而易见。对于更开放的任务，我们用目前表现最好的模型来近似一条轨迹，并随着模型与 harness 的进步回头修订基线。观察 Agent 行为，就这样帮助我们不断校准关于理想轨迹的先验。
看一个简单的请求：「我现在所在地的当前时间和天气是什么？」
Agent 的理想轨迹可能是这样：
- 用最少的必要工具调用（例如：解析用户 → 解析位置 → 获取时间与天气）
- 在可能的地方并行化独立的工具调用
- 不经过不必要的中间轮次就给出最终答案
理想轨迹：4 步、4 次工具调用、约 8 秒。
现在对比一条技术上正确、但效率更低的轨迹：
低效轨迹：6 步、5 次工具调用、约 14 秒。
正确但低效的轨迹：6 个 Agent 步骤、5 次工具调用，包含一次不必要的工具调用，并且没有并行化工具调用。
以上例子是示意性的：一个 REPL 其实可以更快解决这个特定任务，但更简单的工具调用版本更容易把想法讲清楚。
两次运行都正确，但第二次增加了延迟和成本，并制造了更多失败机会。
这个框架让我们能在评测上同时评估正确性与效率。我们维护并更新这些指标，把运行结果蒸馏成可用于对比实验的可度量数字。
以上面的例子为准，那条低效但正确的运行会得到：
| 指标 | 定义 | 示例 | 解读 |
|---|---|---|---|
| 正确性 | 模型是否正确完成了任务 | 1 | 运行成功 |
| 步数比 | 实际 Agent 步数 / 理想 Agent 步数 | 6 / 4 = 1.5 | 比理想多 50% 的步数；越低越好 |
| 工具调用比 | 实际工具调用数 / 理想工具调用数 | 5 / 4 = 1.25 | 比理想多 25% 的工具调用；越低越好 |
| 延迟比 | 实际延迟 / 理想延迟 | 14 / 8 = 1.75 | 比理想慢 75%；越低越好 |
| 求解率 | 期望步数 / 实际延迟，若任务未正确解决则为 0 分 | 4 / 14 = 0.29 步/秒 | 沿期望轨迹推进得越快；越高越好 |
我们如何运行评测
我们用 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 仓库中开源。
下一步
我们正在扩展评测套件，并围绕开源 LLM 展开更多工作！一些我们很快会分享的东西：
- 开源模型与闭源前沿模型在各评测类别上的对比
- 评测作为实时自动改进 Agent 任务表现的机制
- 公开分享我们如何随时间维护、精简与扩充每个 Agent 的评测
Deep Agents 已完全开源。试用它并告诉我们你的想法！我们期待帮助团队构建出色的 Agent 与评测。
延伸阅读
想系统了解 Agent 评测的方法体系与工具选型，参见 评测主题页；Agent 架构与上下文管理的相关实践，参见 Agent 主题页；把评测纳入交付流程的阶段化方法，参见 FDE 项目生命周期指南；更多可上手的工程指南见 FDE 实战指南。
本文由 FDEChina 团队翻译自原文，转载已注明出处；如需引用请以原文为准。