当您发布 AI 智能体 时，关键问题是它能否在实时环境中跨数十次连续工具调用执行工作链，并在步骤失败时恢复。打分模型听起来是否正确几乎无法判断工作是否已完成。
正因如此，智能体评估不得不从对单个函数调用进行评分演变为对整个任务进行评分，其中工具调用即为下方的结缔组织。本文追踪了这一情况，并解释了为什么现在几乎所有重要的智能体基准测试都依赖于工具的使用。
为什么标准的 LLM 基准测试还不够？
原始线束专为静态任务而构建。首个与模型无关的开源线束将模型与评估协议解。
代理打破了这个假设。智能体在多步骤任务中运行时，会调用工具、处理错误并在多个步骤中观察结果，导致单个输出字符串无法满足需求。伯克利函数调用排行榜 (BFCL) 应运而生，旨在评估单回合和多回合场景中的函数选择和参数准确性。但是，BFCL 仅评估单个调用，如果跳过底层检查或更新，有效的 issue_refund 调用仍然会失败。通话准确性是必要的，但还不够。
从通话评分到环境评分
完整的代理式评估现在需要一个完整的执行环境：执行每个工具调用、跨步骤跟踪状态，然后读取世界以确定工作是否已完成。
上面有两个评分层：
- 步骤级 (流程评分) 询问此调用是否有效、相关且有用？
- 端到端 ( E2E，或结果评分) 会忽略路径，仅检查最终状态：退款是否过期，购票路线是否正确？
Step-level 会告诉您哪里的链断裂，这是您在调试或针对微调工作时想要的结果；E2E 会将第 1 步中的失败和第 9 步中的失败折叠为相同的“任务失败”。E2E 是您的用户实际经历的情况，这就是为什么大多数生产评估者都会在其上发布版本，并在下方保留 Step-level 追踪以进行调试。
这两个分数是一个物体的两个读数：痕迹。追踪是一次尝试的有序日志：用户消息、每个步骤以及尝试停止时的环境状态。进程评分对行进行评分。E2E 评分对最终状态进行评分。
基准测试运行的衡量标准
调用工具的基准测试按三个顺序评分：决定使用工具、选择合适的工具，以及填充其参数。当直接回答失败时，模型会延伸到工具，就像跳过所需工具一样。成本和延迟取决于调用的详细程度和运行时。
每次运行都通过一个固定的层次结构进行汇总：基准测试+ 试用+ 任务+ 转向+ 步骤：
- 一个试验是对固定配置下的整个任务集的一次独立传递。
- 一个任务是可独立评分的问题实例，由任务 ID 识别。
- 一个 回合即为一交换边界：消息进入，代理的回复发出，之间的所有内容都属于该回合。
- 一个步骤是指回合中的一个原子动作，即工具/ 命令调用，或类似于计划或最终消息的非工具释放。
步长通常是指工具调用，且其上方的每个分数都会从这些步长向上滚动。值得追踪的指标分为三个方面：准确性、详细程度、成本 (请参阅下表 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 秒对每个任务的成功都很重要。 |
配对很重要：不一致的成功率是随机系统的点估算值 (如果模型达到 90%，则 74% 的几率比保持 84% 的模型更糟糕) ；如果没有参数准确性，工具调用精度会隐藏槽填充失败。
在同一任务中，步长计数通常是不同模型变化最大的轴 4 步与 15 步 ，尽管在 Terminal-Bench 2.0 等套件中，每回合步长也各不相同，因此哪条轴移动最多取决于基准测试。并行工具调用可减少步长数量和延迟，但不会减少调用数量：启动四个工具只需一步，仍然会发出四个调用。依次汇总；不要计算步数平均值，而是将其称为基准得分。
如何阅读评估
两个基准测试既可以测试工具调用，也可以生成不具有可比性的数字。以下三个维度解释了大部分差距：
- 任务复杂性 – 单轮使用一个工具，还是多轮需要规划、错误恢复和状态管理？单次调用基准测试无法判断模型是否在 15 的第 8 步中崩溃。
- 状态 – 每个动作的环境是否更新？状态监测基准测试表面漂移、上下文损失和静态数据丢失的损坏状态。
- 方法 – 可执行文件验证 ( DB 是否更新，测试是否通过) 是黄金标准。基于参考的评估需要一个标注答案集，必须有人维护。LLM-as-a-Judge 填补了不存在可执行检查的空白，但在根据样本上的人类评分进行验证之前，LLM-as-a-Judge 将其分数视为临时分数。
污染现在已从训练数据泄露扩展到实时变体：网络搜索智能体在评估期间检索答案，Hugging Face 上的数据集快速重新捕获到预训练语料库中。私有领域通过无法搜索来解决这个问题。
下表 2 是使用 step-level 和 E2E 评分的真实基准测试运行的公开追踪，其中套件 (而非人工工单) 提供工具、用户和完成标准。
- 套件：SWE-bench 已验证 (实际 GitHub 问题、可执行测试验证)
- 任务 ID：
pytest-dev__pytest-5262(试用版.2，第 0 – 4 圈) - User/user-simulator 开头：”对存储库 (
/testbed) 实施必要的更改，以便满足问题中指定的要求” – 问题：_pytest.capture.EncodedFile从其底层缓冲区报告模式rb+(二进制) ，但其write()仅接受str，因此检查.mode的外部代码 (例如。youtube-dl) 在写入bytes时崩溃。 - 线束注释 (公开的工具、最大步长、并行调用的开启/ 关闭) ：OpenHands 智能体线束；公开的工具：
terminal、file_editor、task_tracker、finish；关闭并行工具注释 (每回合一次工具调用) ；存储库状态继续保持 Turn to Turn (真实文件系统 = git，而非模拟) 。
| 步骤 | 转向 | 通话 | 环境观测 | 判决书 | 原因 (有效/ 有用/ 冗余/ 已恢复/ 策略) |
|---|---|---|---|---|---|
| 1 | 0 | terminal(find /testbed -name "capture.py") |
返回 /testbed/src/_pytest/capture.py |
有效 | 在编辑任何内容之前找到问题中命名的文件 |
| 2 | 1 | file_editor(view, capture.py) |
转储完整文件 ( 400 多行) | 冗余 | 文件很大；优先处理课程会更具针对性 |
| 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 检查 ( DB 状态/ 测试/ 工单) ：通过
- E2E 分数 ( 0 或 1) ：1
- 阶段分数 (及/ 步) ：3/ 4
- 工具调用精度：3/ 4
- 参数准确性：4/ 4
在查看输出结果时，请务必查看最后 5 个要点：E2E 检查、E2E 分数、步骤级别分数、工具调用精度和参数准确性。E2E 检查告诉我们，与其试图修复的错误问题相关的测试已通过，这意味着在本例中，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 发布的套件，了解其任务完成和完成时间，而非孤立的通话准确性。在多轮银行服务对话中对任务完成情况进行评分。GDPval-AA v2 根据实际工作输出对实际代理式工作进行评分，由一个 LLM 评委小组根据 1000 位人类专家的基准 Elo 进行配对判断。在 PinchBench 上，Nemotron 3.5 Lightning 的准确率达到 86%，同时以同等精度完成 10000 项任务的速度比 Qwen3.6 35B 快 30%，一个高效完成的模型胜过在孤立准确性上得分更高但消耗更多步骤和 token 的模型。
公开评分是一个很好的信号，但不应将其视为发布的大门。让模型适应您的任务和用例与以往一样重要。
对您自己的工作负载进行基准测试
- 设置公共楼层。运行已发布的代理式套件；在 3 – 5 次试验中记录成功率及其范围。
- 根据您的真实工单、追踪和 API 构建域评估。基于环境状态的门控 — 数据库行、合并 PR、封闭工单，而非评委对最终消息的意见。
- 调整模型并利用该分布。
- 重新衡量成功率、一致性、每次成功的步骤和每次成功的成本。保留用于调试的 step-level 追踪。
验证环境中的结果，使用判断语言，并使用工具调用精度和参数准确性来查找链断裂的位置。
为了重现已发布的数据，Nemotron 发布了涵盖模型卡分数背后的配置的再现性文档。在build.nvidia.com上试用，从Hugging Face获取权重，或按照NIM 指南操作。
LLM 基准测试领域的工具调用是当今评估所依赖的基础。能够构建、阅读和理解这些评估对于为您的用例做出明智决策至关重要。
深入了解
通过订阅 NVIDIA 新闻 并在 LinkedIn、X、YouTube 和 Nemotron 频道 上的 Discord 关注 NVIDIA AI，及时了解 NVIDIA Nemotron 的最新动态。
在 Hugging Face 上访问开放的 Nemotron 模型，并在 build.nvidia.com 上访问一系列 NIM 微服务和开发者示例。
