当你上线一个 AI 智能体时，关键问题是它能否针对真实环境执行由几十次连续工具调用组成的一整条工作链，并在某一步失败时恢复。给模型听起来是否正确打分，几乎无法告诉你工作是否真的完成了。
这一差距正是智能体评估不得不从给单次函数调用打分，演进为给整个任务打分的原因，而工具调用则是其底层的连接纽带。本文梳理这一演变脉络，并解释为什么如今几乎每一个严肃的智能体基准测试都建立在工具使用之上。
为什么标准的 LLM 基准测试不够用？
最初的评测框架是为静态任务构建的。首个与模型无关的开源评测框架，把模型与评估协议解耦。
智能体打破了这一假设。在多步骤任务中，智能体要调用工具、处理错误，并在多个步骤中观察结果，单个输出字符串已不足以评估。Berkeley Function-Calling Leaderboard（BFCL）应运而生，用于评估单轮和多轮场景下的函数选择与参数准确性。然而，BFCL 只评估单个调用——如果底层的检查或更新被跳过，一次有效的 issue_refund 调用仍然会失败。调用准确性是必要的，但并不充分。
从给调用打分到给环境打分
完整的智能体评估现在需要一个完整的执行环境：它能执行每一次工具调用，跟踪跨步骤的状态，并在事后读取环境，判断工作是否完成。
在此之上有两个评分层：
- 步骤级（过程评分）关注的是：鉴于当时的状态，这次调用是否有效、相关且有用？
- 端到端（E2E，即结果评分）忽略过程，只检查最终状态：退款是否入账，工单是否被正确路由？
步骤级评分告诉你链条在哪里断裂，这在调试或确定微调重点时正是你需要的；E2E 则会把第一步的失败和第九步的失败都归为同样的“任务失败”。E2E 才是用户真正感受到的，这也是大多数生产环境评测以它作为发布门槛、同时在底层保留步骤级追踪用于调试的原因。
这两种评分是对同一个对象的两种解读，这个对象就是轨迹（trace）。轨迹是单次尝试的有序日志：用户消息、每一步，以及尝试结束时的环境状态。过程评分对每一行打分，E2E 评分则对最终状态打分。
一次基准测试运行衡量什么
工具调用基准测试依次对三件事打分：决定是否使用工具、选择正确的工具，以及填充其参数。在直接回答即可时去调用工具的模型，与跳过必需工具的模型一样会失败。成本和延迟则叠加在此之上，由调用的冗长程度和运行时间决定。
每次运行都按固定的层级向上汇总：基准测试 → 试验 → 任务 → 轮次 → 步骤：
- 一次试验（trial）是在固定配置下对整个任务集的一次独立完整遍历。
- 一个任务（task）是一个可独立评分的问题实例，由任务 ID 标识。
- 一个轮次（turn）是一个交互边界：一条消息输入，智能体的回复输出，两者之间的一切都属于该轮次。
- 一个步骤（step）是轮次内的一个原子动作——一次工具/命令调用，或者是计划、最终消息之类的非工具输出。
步骤通常就是一次工具调用，其上的每一个分数都是由这些步骤汇总而来。值得跟踪的指标可归为三个维度：准确性、冗长度、成本（见下方表 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 |
成本 | 经济学上的基本单位。词元和 GPU 秒数只有按每个成功任务来算才有意义。 |
指标的搭配很重要：没有一致性的成功率，只是对一个随机系统的点估计（先达到 90% 再降到 74% 的模型，比稳定在 84% 的模型更不可靠）；没有参数准确率的工具调用精确率，则会掩盖槽位填充（slot-filling）方面的失败。
在同一任务上，步数往往是不同模型之间差异最大的维度——四步对十五步——不过在 Terminal-Bench 2.0 这类测试集上，每轮步数同样会变化，因此哪个维度变化最大取决于具体的基准测试。并行工具调用能减少步数和延迟，但不会减少调用次数：一个单步轮次同时触发四个工具，仍然发出了四次调用。要按顺序逐层汇总；不要把步数求平均就当作基准测试分数。
如何解读一次评估
两个基准测试都可能声称在测试工具调用，却给出无法相互比较的数字。三个维度解释了大部分差距：
- 任务复杂度——是只用一个工具的单轮任务，还是需要规划、错误恢复和状态管理的多轮任务？单次调用的基准测试无法告诉你，模型是否会在十五步中的第八步崩溃。
- 状态性——环境是否会随每个动作更新？有状态的基准测试能暴露漂移、上下文丢失和状态损坏，而静态的基准测试则会漏掉这些问题。
- 方法论——可执行验证（数据库是否更新、测试是否通过）是黄金标准。基于参考答案的评估需要一套有人维护的标注答案集。LLM-as-a-Judge 填补了没有可执行检查的空白，但其分数应视为暂定，直到在样本上与人工评分验证过为止。
污染现在已不止于训练数据泄露，还延伸到了在线变体：具备网络搜索能力的智能体在评估期间检索到答案，以及 Hugging Face 上的数据集很快被重新抓取进预训练语料。私有领域评测因无法被抓取而解决了这个问题。
下方的表 2 是来自一次真实基准测试运行的公开轨迹，采用步骤级和 E2E 评分，其中的工具、用户和完成标准由测试集提供，而非人为编造的工单。
- 测试集：SWE-bench Verified（真实的 GitHub issue，可执行的测试验证）
- 任务 ID：
pytest-dev__pytest-5262（试验 .2，轮次 0–4） - 用户 / 用户模拟器的开场白：“对仓库（
/testbed）实施必要的修改，使 issue 中指定的要求得到满足”——该 issue：_pytest.capture.EncodedFile从其底层缓冲区报告模式rb+（二进制），但其write()只接受str，因此检查.mode的外部代码（例如youtube-dl）在写入bytes时会崩溃。 - 评测框架说明（暴露的工具、最大步数、并行调用开/关）：OpenHands 智能体框架；暴露的工具：
terminal、file_editor、task_tracker、finish；并行工具调用关闭（每轮一次工具调用）；仓库状态在轮次之间保持（真实的文件系统 + git，而非模拟）。
表 2. 在 SWE-Bench Verified 评估上提取的轨迹调用
| 步骤 | 轮次 | 调用 | 环境观察 | 判定 | 原因（有效 / 有用 / 冗余 / 已恢复 / 策略） |
|---|---|---|---|---|---|
| 1 | 0 | terminal(find /testbed -name "capture.py") |
返回 /testbed/src/_pytest/capture.py |
有效 | 在编辑任何内容之前，先定位 issue 中提到的文件 |
| 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 |
有效 | 精确定位了根本原因（未过滤的 __getattr__ 委托），第 5 步及之后的修复正是针对它 |
- E2E 检查（数据库状态 / 测试 / 工单）：通过
- E2E 分数（0 或 1）：1
- 步骤级分数（通过数 / 步数）：3/4
- 工具调用精确率：3/4
- 参数准确率：4/4
查看输出的结果时，重点要看最后 5 项：E2E 检查、E2E 分数、步骤级分数、工具调用精确率和参数准确率。E2E 检查告诉我们，它试图修复的 bug issue 的相关测试已通过，因此本例中的 E2E 分数为 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 以 1000 分的人类专家基线为锚点——这种人工验证让评委分数值得信赖。在 PinchBench 上，Nemotron 3.5 Lightning 达到 86% 的准确率，同时完成 10,000 个任务的速度比 Qwen3.6 35B 快 30%，而二者准确率相当——高效完成任务的模型，胜过在孤立准确率上得分更高、却消耗更多步骤和词元的模型。
公开分数是很好的信号，但不应被当作发布门槛。让模型适配你的任务和用例，依然和以往一样重要。
为你自己的工作负载做基准测试
- 设定公开基线。运行一个已发布的智能体测试集；记录成功率及其在 3–5 次试验中的波动范围。
- 基于真实的工单、轨迹和 API 构建领域评测。以环境状态作为判定依据——一条数据库记录、一个已合并的 PR、一张已关闭的工单——而不是评委对最终消息的看法。
- 让模型和评测框架适配该分布。
- 重新测量成功率、一致性、每次成功所需步数和每次成功的成本。保留步骤级轨迹用于调试。
在环境中验证后果，用评委来评判语言，并用工具调用精确率和参数准确率找出链条在哪里断裂。
为复现已发布的数字，Nemotron 提供了可复现性文档，涵盖模型卡分数背后的配置。可以在 build.nvidia.com 上试用，从 Hugging Face 获取权重，或参照 NIM 指南。
在 LLM 基准测试领域，工具调用是当今各类评估所依托的基础。能够构建、阅读并理解这些评估，对于为你的用例做出明智决策至关重要。
进一步了解
订阅 NVIDIA 新闻，并在 LinkedIn、X、YouTube 上关注 NVIDIA AI，以及加入 Discord 上的 Nemotron 频道，随时了解 NVIDIA Nemotron 的最新动态。
可在 Hugging Face 上获取开放的 Nemotron 模型，并在 build.nvidia.com 上获取一系列 NIM 微服务和开发者示例。