当你交付一个 AI 智能体（Agent（智能体））时，关键问题是它能否在真实环境中执行跨越数十次顺序工具调用的工作链，并在某一步失败时恢复。评估模型听起来是否正确，几乎无法告诉你工作是否完成。

这一差距正是智能体评估必须从对单次函数调用打分，演进为对整个任务打分的原因，而工具调用是贯穿其中的连接组织。本文追溯这一演进脉络，并解释为什么如今几乎所有严肃的智能体基准测试都建立在工具使用之上。

为什么标准 LLM（大语言模型） 基准测试不够？

最初的测试框架是为静态任务构建的。第一个与模型无关的开源测试框架将模型与评估协议解耦。

智能体打破了这一假设。智能体在多步任务中运行，调用工具、处理错误，并在许多步骤中观察结果，这使得单一输出字符串不足以评估。Berkeley Function-Calling Leaderboard（BFCL）应运而生，用于评估单轮和多轮场景下的函数选择和参数准确性。然而，BFCL 只评估单次调用——如果底层的检查或更新被跳过，一次有效的 issue_refund 调用仍然会失败。调用准确性是必要的，但并不充分。

从对调用打分到对环境打分

完整的智能体评估现在需要一个完整的执行环境：一个能够执行每次工具调用、跨步骤跟踪状态，并在之后读取世界状态以判断工作是否完成的环境。

在此之上有两个评分层：

• 步骤级（过程评分）询问：鉴于当时的状态，这次调用是否有效、相关且有用？

• 端到端（E2E，即结果评分）忽略路径，只检查最终状态：退款是否入账，工单是否正确路由？

步骤级告诉你链条在哪里断裂，这正是调试或针对性微调时所需要的；E2E 将第一步的失败和第九步的失败都归结为同样的“任务失败”。E2E 才是用户实际体验到的，这就是为什么大多数生产评估将其作为发布门槛，并在底层保留步骤级追踪用于调试。

这两个分数是对同一对象的两种解读：追踪（trace）。追踪是一次尝试的有序日志：用户消息、每一步，以及尝试停止时的环境状态。过程评分对各行打分。E2E 评分对最终状态打分。

一次基准测试运行测量什么

工具调用基准按顺序评估三件事：决定使用工具、选择正确的工具、填充其参数。一个在直接回答会失败时伸手去拿工具的模型，与一个跳过了所需工具的模型一样糟糕。成本和延迟叠加其上，由调用的冗长程度和运行时间决定。

每次运行都通过一个固定的层级结构汇总：Benchmark → Trial → Task → Turn → Step：

• 一次 trial 是在固定配置下对整个任务集的一次独立遍历。

• 一个 task 是一个可独立评分的问题实例，由 task ID 标识。

• 一个 turn 是一个交换边界：一条消息进入，智能体的回复输出，其间的一切都属于该 turn。

• 一个 step 是 turn 内部的一个原子动作——一次工具/命令调用，或一次非工具输出，如计划或最终消息。

一个 step 通常是一次工具调用，其上方的每一项得分都从这些 step 汇总而来。值得跟踪的指标归结为三个轴：准确性、冗长程度、成本（见下方表 1）。

| 指标 | 公式 | 轴 | 存在原因 |
| --- | --- | --- | --- |
| 任务成功率 | successful_tasks / tasks | 准确性 | 发布门槛。环境是否达到目标状态？ |
| 一致性 | 3–5 次 trial 间成功率的范围 | 准确性 | 90% / 74% 的分裂不是 84%。报告 82–88%，而非点估计。 |
| 工具调用精确率 | correct_calls / calls_issued | 准确性 | 幻觉名称和多余调用在此浮现，而非在成功率中。 |
| 参数准确率 | correct_args / calls_with_right_tool | 准确性 | 区分“错误的 API（应用程序编程接口）”与“正确的 API，填充错误”。 |
| 每次成功的步数 | steps / successful_tasks | 冗长程度 | 任务实际完成时轨迹运行多长。 |
| 每次成功的成本 | spend / successful_tasks | 成本 | 经济单位。Token 和 GPU（图形处理器） 秒数只有在每次成功任务的基础上才有意义。 |

这些配对很重要：没有一致性的成功率是对随机系统的点估计（一个先达到 90% 再达到 74% 的模型，比一个保持 84% 的模型更差）；没有参数准确率的工具调用精确率会掩盖槽位填充失败。

步数通常是同一任务上不同模型间差异最大的轴——四步对十五步——不过在 Terminal-Bench 2.0 等套件上，每 turn 步数也会变化，因此哪个轴变化最大取决于基准。并行工具调用减少了步数和延迟，但不减少调用次数：一个一步的 turn 触发四个工具，仍然发出了四次调用。按顺序汇总；不要对步数取平均就称之为基准分数。

如何解读评估

两个基准都可以声称测试工具调用，并产生不可比较的数字。三个维度解释了大部分差距：

• 任务复杂度——单 turn 单工具，还是需要规划、错误恢复和状态管理的多 turn？单次调用基准不会告诉你模型是否在十五步中的第八步崩溃。

• 状态性——环境是否在每次动作后更新？有状态基准会暴露静态基准遗漏的漂移、上下文丢失和状态损坏。

• 方法论——可执行验证（数据库是否更新，测试是否通过）是黄金标准。基于参考的评估需要有人维护的标注答案集。LLM-as-a-Judge 填补了没有可执行检查的空白，但在样本上对照人工评分验证之前，其分数应视为暂定。

污染现在已超出训练数据泄露，延伸到实时变体：网络搜索智能体在评估期间检索答案密钥，以及 Hugging Face 上的数据集被迅速重新抓取进预训练语料库。私有领域评估通过无法被抓取来解决这个问题。

下方表 2 是来自真实基准运行的公开轨迹，使用 step 级和 E2E 评分，其中由套件而非人工工单提供工具、用户和完成标准。

• 套件：SWE-bench Verified（真实 GitHub 问题，可执行测试验证）

• 任务 ID：pytest-dev__pytest-5262（试验 .2，轮次 0–4）

• 用户 / 用户模拟器开场白：“对仓库（ /testbed ）实施必要的更改，以满足问题中指定的要求”——该问题：_pytest.capture.EncodedFile 从其底层缓冲区报告模式 rb+（二进制），但其 write() 仅接受 str ，因此检查 .mode 的外部代码（例如 youtube-dl ）在写入 bytes 时会崩溃。

• 测试框架说明（暴露的工具、最大步数、并行调用开/关）：OpenHands 智能体测试框架；暴露的工具：terminal 、file_editor 、task_tracker 、finish ；并行工具调用关闭（每轮一次工具调用）；仓库状态逐轮持续（真实文件系统 + git，而非模拟）。

| 步骤 | 轮次 | 调用 | 环境观察 | 判定 | 原因（有效 / 有用 / 冗余 / 恢复 / 策略） |
| --- | --- | --- | --- | --- | --- |
| 1 | 0 | terminal(find /testbed -name "capture.py") | 返回 /testbed/src/_pytest/capture.py | 有效 | 在编辑任何内容之前定位问题中提到的文件 |
| 2 | 1 | file_editor(view, capture.py) | 转储整个文件（400+ 行） | 冗余 | 文件很大；先 grep 查找该类会更有针对性 |
| 3 | 2 | terminal(grep -n "EncodedFile" capture.py) | 返回 422: return EncodedFile(...) / 425: class EncodedFile(object): | 恢复 | 通过直接缩小到相关行，纠正了步骤 2 的低效 |
| 4 | 3–4 | file_editor(view, view_range=[420,450]/[450,470]) | 显示 EncodedFile.__init__ / __getattr__ ，揭示它直接从二进制模式缓冲区委托 .mode | 有效 | 精确定位步骤 5+ 修复的确切根本原因（未过滤的 __getattr__ 委托） |

• E2E 检查（数据库状态 / 测试 / 工单）：通过

• E2E 分数（0 或 1）：1

• 步骤级分数（通过 / 步骤）：3/4

• 工具调用精确度：3/4

• 参数准确度：4/4

查看输出的结果，重要的是看最后 5 个要点：E2E 检查、E2E 分数、步骤级分数、工具调用精确度和参数准确度 。E2E 检查告诉我们，它试图修复的 bug 问题的相关测试通过了，这意味着本例中的 E2E 分数为 1（is_resolved: true）。下一个指标是步骤级分数，它告诉你模型采取的步骤中有多少是实际需要的。查看上表的分数，步骤级为 3/4，因为本例中有一个步骤是冗余的——特别是步骤 2。在本例中，这直接影响了工具调用精确度，由于这一小失误，工具调用精确度也获得了 3/4。对于此轨迹，我们的最终指标参数准确度显示所有参数都正确填写，没有格式错误的参数。

为什么基准测试正在向工具使用收敛

“调用工具”和“完成任务”之间的界限不再成立：大多数衡量通用能力的基准测试现在也衡量工具使用，因为在任何可行的部署中，模型都不会在没有工具的情况下运行。一个不提供工具访问权限的基准测试所评分的，是没有人会部署的能力。

并非每个基准测试都能说明问题。HumanEval 对生成的 Python 运行单元测试，提供可执行验证，但没有工具调用，也没有可操作的环境。SWE-bench 是这种转变变得清晰的地方：解决一个真实的 GitHub 问题意味着浏览代码库、编写补丁并通过测试套件——依次进行文件读取、搜索和编辑调用。分数衡量的是结果，但底层的轨迹完全由工具调用组成。因此，在许多情况下，你为通用能力已经运行的基准测试，实际上已经在检验工具使用。这重新定义了真正重要的问题：

学术基准测试抽象地衡量模型的能力上限。企业基准测试回答一个更狭窄、更有用的问题：它能做我的工作吗——你的任务、针对你的 API、在你的策略下？基准测试越接近生产环境，其分数在你的决策中就应该越有分量。

从这个视角分析 Nemotron 3.5 Lightning

将 NVIDIA Nemotron 3.5 Lightning 发布的套件解读为任务完成和完成时间，而不是孤立的调用准确度。Banking 对多轮银行对话中的完成情况进行评分——是规模化的退款轨迹，而不是单次调用。GDPval-AA v2 对来自实际工作产出的真实智能体工作进行评分，由一组 LLM 评委进行成对评判，其 Elo 以 1,000 名人类专家基线为锚点——这种人类验证使评委分数保持可信。在 PinchBench 上，Nemotron 3.5 Lightning 达到 86% 的准确率，同时在完成 10,000 个任务时比 Qwen3.6 35B 在相当准确率下快 30%——一个高效完成的模型胜过在孤立准确率上得分更高但消耗更多步骤和 token 的模型 。

公开分数是一个很好的信号，但不应被视为发布门槛。让模型适应你的任务和用例，比以往任何时候都更重要。

对你的工作负载进行基准测试

• 设定公开基线。运行已发布的智能体测试套件；记录成功率及其在 3–5 次试验中的范围。

• 基于你的真实工单、追踪和 API 构建领域评估。以环境状态为门控——数据库行、已合并的 PR、已关闭的工单——而非评判者对最终消息的意见。

• 将模型和测试框架适配到该分布。

• 重新测量成功率、一致性、每次成功的步骤数和每次成功的成本。保留步骤级追踪用于调试。

在环境中验证后果，使用评判者评估语言，并使用工具调用精确度和参数准确度来定位链条断裂的位置。

要复现已发布的数字，Nemotron 提供了可复现性文档，涵盖模型卡分数背后的配置。在 build.nvidia.com 上试用，从 Hugging Face 获取权重，或遵循 NIM 指南。

在大语言模型基准测试领域，工具调用是当今评估所依赖的基础。能够构建、阅读和理解这些评估，对于为你的用例做出明智决策至关重要。

进一步探索

通过订阅 NVIDIA 新闻并在 LinkedIn、X、YouTube 以及 Discord 上的 Nemotron 频道关注 NVIDIA AI，随时了解 NVIDIA Nemotron 的最新动态。

在 Hugging Face 上访问开放的 Nemotron 模型，并在 build.nvidia.com 上获取 NIM 微服务和开发者示例合集。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：NVIDIA Technical Blog

原创地址：https://developer.nvidia.com/blog/how-to-evaluate-ai-agents-from-tool-calls-to-task-completion/