当你交付一个 AI 智能体 时，关键问题是它能否在真实环境中执行一连串工作，跨越数十次顺序工具调用，并在某一步失败时恢复。评估模型听起来是否正确，几乎无法告诉你工作是否完成。
这一差距正是智能体评估不得不从对单个函数调用打分，演变为对整个任务打分的原因，而工具调用则是其底层的连接组织。本文追溯这一演变脉络，并解释为什么如今几乎所有严肃的智能体基准测试都建立在工具使用之上。
为什么标准 LLM 基准测试不够？
最初的测试框架是为静态任务构建的。第一个与模型无关的开源测试框架将模型与评估协议解耦。
智能体打破了这一假设。智能体在多步任务中运行，会调用工具、处理错误，并在许多步骤中观察结果，使得单一输出字符串不足以评估。伯克利函数调用排行榜（BFCL） 应运而生，用于评估单轮和多轮场景下的函数选择和参数准确性。然而，BFCL 只评估单个
调用——如果底层的检查或更新被跳过，一个有效的
issue_refund
调用仍然会失败。调用准确性是必要的，但并不充分。## 从对调用打分到对环境打分
完整的智能体评估现在需要一个完整的执行环境：一个能够执行每次工具调用、跨步骤跟踪状态，并在事后读取世界以判断工作是否完成的环境。
在此之上有两个评分层：
步骤级（过程评分）问的是：鉴于当时的状态，这次调用是否有效、相关且有用？端到端（E2E，即结果评分）忽略路径，只检查最终状态：退款是否入账，工单是否正确路由？
步骤级告诉你链条在哪里断裂，这正是你在调试或针对微调工作时想要的；E2E 将第一步的失败和第九步的失败都归结为同一个“任务失败”。E2E 才是你的用户实际体验到的，这就是为什么大多数生产评估将其作为发布门槛，并在底层保留步骤级追踪用于调试。
这两个分数是对同一个对象的两种解读：轨迹。轨迹是一次尝试的有序日志：用户消息、每一步，以及尝试停止时的环境状态。过程评分对各行打分。E2E 评分对最终状态打分。
一次基准测试运行衡量什么
工具调用基准测试按顺序对三件事打分：决定使用工具、选择正确的工具，以及填充其参数。当直接回答会失败时，模型去调用工具，与跳过所需工具一样会失败。成本和延迟叠加在其上，由调用的冗长程度和运行时间决定。
每次运行都通过一个固定的层级汇总：基准测试 → 试验 → 任务 → 轮次 → 步骤：
- 一次 试验是在固定配置下对整个任务集的一次独立运行。 - 一个
任务是一个可独立评分的问题实例，由任务 ID 标识。 - 一个
轮次是一个交换边界：一条消息输入，智能体的回复输出，其间的一切都属于该轮次。 - 一个
步骤是轮次内的一次原子操作——一次工具/命令调用，或一次非工具输出，如计划或最终消息。
图1. 智能体工作流中轮次与步骤的可视化
一个步骤通常是一次工具调用，其上的每一项得分都从这些步骤汇总而来。值得追踪的指标可归结为三个维度：准确性、冗长度、成本（见下方表1）。
| 指标 | 公式 | 维度 | 存在原因 |
|---|---|---|---|
| 任务成功率 | successful_tasks / tasks |
准确性 | 发布门槛。环境是否达到目标状态？ |
| 一致性 | range of success rate across 3–5 trials |
准确性 | 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秒仅在每次成功任务中才有意义。 |
表1. 按维度（准确性、冗长度、成本）分组的核心评估指标
这些配对很重要：没有一致性的成功率是对随机系统的点估计（一个先达到90%后降至74%的模型，比一个保持84%的模型更糟）；没有参数准确率的工具调用精确率会隐藏槽位填充失败。
步骤数通常是同一任务上不同模型间变化最大的维度——四步对十五步——不过在Terminal-Bench 2.0等套件中，每轮步骤数也有变化，因此哪个维度变化最大取决于基准。并行工具调用减少步骤数和延迟，但不减少调用数：一步内触发四个工具仍发出四次调用。按顺序汇总；不要平均步骤数并称之为基准分数。
如何解读评估
两个基准都可能声称测试工具调用，并产生不可比较的数字。三个维度解释了大部分差距：
任务复杂度——单轮单工具，还是需要规划、错误恢复和状态管理的多轮？单次调用基准不会告诉你模型是否在十五步中的第八步崩溃。状态性——环境是否在每次动作后更新？有状态基准能揭示静态基准遗漏的漂移、上下文丢失和状态损坏。方法论——可执行验证（数据库是否更新，测试是否通过）是黄金标准。基于参考的评估需要有人维护的标注答案集。LLM作为评判者填补了无可执行检查的空白，但在样本上对照人工评分验证之前，其分数应视为暂定。
污染现已超出训练数据泄露，扩展到实时变体：网络搜索智能体在评估期间检索答案密钥，以及Hugging Face上的数据集迅速被重新抓取进预训练语料库。私有领域评估通过无法抓取来解决此问题。
下方表2是使用步骤级和端到端评分的一次真实基准运行的公开追踪，其中套件而非人工工单提供了工具、用户和完成标准。
- 套件： 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__ 委托） |
表 2. 在 SWE-Bench 验证评估上提取的跟踪调用
- 端到端检查（数据库状态 / 测试 / 工单）：通过
- 端到端得分（0 或 1）：1
- 步骤级得分（通过 / 步骤）：3/4
- 工具调用精确度：3/4
- 参数准确性：4/4
查看输出的结果，重要的是看最后 5 个要点：端到端检查、端到端得分、步骤级得分、工具调用精确度和参数准确性。端到端检查告诉我们，它试图修复的 bug 问题的相关测试通过了，这意味着本例中的端到端得分为 1（is_resolved: true）。下一个指标是步骤级得分，它告诉你模型采取的步骤中有多少是实际需要的。查看上表的得分，步骤级为 3/4，因为本例中有一个步骤是冗余的——特别是步骤 2。在这种情况下，它直接影响了工具调用精确度，由于这个小失误，该指标也获得了 3/4。对于此跟踪，我们的最终指标参数准确性显示所有参数都正确填写，没有格式错误的参数。
为什么基准测试正趋向于工具使用
“调用工具”和“完成任务”之间的界限不再成立：大多数衡量通用能力的基准测试现在也衡量工具使用，因为在任何可行的部署中，模型都不会在没有工具的情况下运行。一个不提供工具访问的基准测试所评分的是一种没有人会部署的能力。
并非每个基准测试都能说明问题。HumanEval 让生成的 Python 代码运行单元测试，提供了可执行的验证，但没有工具调用，也没有可供操作的环境。SWE-bench 则让这一转变变得清晰：解决一个真实的 GitHub issue 意味着要浏览代码库、编写补丁并通过测试套件——依次进行文件读取、搜索和编辑调用。分数衡量的是结果，但其底层的轨迹完全由工具调用构成。因此，在许多情况下，你为评估通用能力而已经运行的基准测试，其实已经在考察工具使用能力了。这重新定义了真正重要的问题：
学术基准测试衡量的是模型在抽象层面的能力上限。企业基准测试回答的是一个更狭窄、也更有用的问题：它能否胜任我的工作——你的任务、针对你的 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%——一个高效完成任务的模型，胜过在孤立准确率上得分更高、却消耗更多步骤和
tokens 的模型。
图 2. 在 PinchBench 上，Nemotron 3.5 Lightning 达到 86% 的准确率，同时在相近准确率下完成任务比 Qwen3.6 35B 快最多 30%
公开分数是一个很好的信号，但不应被视为发布门槛。让模型适配你的任务和用例，一如既往地重要。
对自身工作负载进行基准测试
设定公开基线。运行一个已发布的智能体测试套件；记录成功率及其在 3–5 次试验中的范围。构建领域评估，基于你真实的工单、轨迹和 API。以环境状态作为门槛——数据库中的一行、一个已合并的 PR、一个已关闭的工单——而不是评委对最终消息的意见。适配模型和测试框架到该数据分布。重新测量成功率、一致性、每次成功的步骤数以及每次成功的成本。保留步骤级轨迹以便调试。
在环境中验证后果，用评委评估语言，用工具调用精确度和参数准确率来找出链条断裂之处。
为复现所公布的数值，Nemotron 提供了可复现性文档，其中涵盖了模型卡分数背后的各项配置。你可以在 build.nvidia.com 上试用，从 Hugging Face 获取权重，或参阅 NIM 指南。
在 LLM 基准测试领域，工具调用是当今各项评估所依赖的基础。能够构建、阅读并理解这些评估，对于为你的用例做出明智决策至关重要。
进一步探索
通过订阅 NVIDIA 新闻，并在 LinkedIn、X、YouTube 以及 Discord 上的 Nemotron 频道关注 NVIDIA AI，随时了解 NVIDIA Nemotron 的最新动态。
在 Hugging Face 上访问开放的 Nemotron 模型，并在 build.nvidia.com 上获取一系列 NIM 微服务和开发者示例。