NVIDIA 提出以工具调用为骨架的智能体评测框架，并用 SWE-bench 轨迹展示端到端与步骤级评分如何分工

文章主张智能体评测必须从单次调用评分升级为整任务评分，因为 BFCL 这类只评函数选择与参数准确性的榜单无法反映底层检查或更新是否被跳过。 相对以往以单次函数调用为单位的评测，文章把工具调用定位为贯穿评测的“连接组织”，并指出“调用准确是必要但不充分”。 属于框架性论述，以 BFCL 的覆盖范围与 issue_refund 的举例作为说明，未提供对照实验数据。

文章提出完整智能体评测需要执行环境加两层评分：步骤级（过程）判断某次调用在当时状态下是否有效、相关、有用；端到端（结果）只看最终状态，如退款是否入账、工单是否正确路由。 把过程分与结果分统一到同一个对象“trace”（一次尝试的有序日志）上，并说明生产评测通常以端到端作为发布门槛、以步骤级追踪用于调试。 以概念定义与生产实践描述为主，未给出跨模型统计对比。

文章给出可操作的指标集合与层级：Benchmark→Trial→Task→Turn→Step，以及任务成功率、一致性（3–5 次试验的成功率区间）、工具调用精确率、参数准确率、每次成功的步数、每次成功的成本，并强调指标需成对解读。 把“成功率缺一致性只是随机系统上的点估计”“工具调用精确率缺参数准确率会掩盖填槽失败”等配对关系明确化，并指出并行工具调用降低步数与延迟但不降低调用数。 以公式与解释性表格呈现，属于方法论建议，未附独立验证实验。

文章用 SWE-bench Verified 上 pytest-dev__pytest-5262 的公开轨迹演示评分：端到端检查通过、端到端得分 1，步骤级 3/4、工具调用精确率 3/4、参数准确率 4/4，其中第 2 步整文件查看被判为冗余、第 3 步用 grep 定位被视为纠正。 把抽象指标落到一条可读的真实轨迹上，展示结果分与过程分如何在同一 trace 上给出不同信息。 单条公开轨迹示例，使用 OpenHands 框架、关闭并行工具调用、真实文件系统与 git 状态持久化，属于示例性证据而非统计结论。

文章面向需要为智能体发布做决策的工程与评测团队，适用于具备可执行验证环境（数据库状态、测试通过、工单关闭）的场景；它给出的是一套评测组织方式与指标口径，而非某个模型的定论。文中还提示，公开分数适合作为信号与下限，真正的发布门槛应建立在用自有工单、轨迹与 API 构建的领域评测之上，并以环境状态而非对最终消息的评审意见作为判据。

文章提到污染已从训练数据泄漏扩展到实时变体，例如联网搜索的智能体在评测中检索到答案、Hugging Face 上的数据集被迅速重新抓取进预训练语料，并称私有领域评测因无法被抓取而规避此问题，但未给出量化影响。文中关于 Nemotron 3.5 Lightning 在 PinchBench 上 86% 准确率、比 Qwen3.6 35B 快 30% 完成 10,000 个任务的说法来自厂商发布，读者仍需关注其可复现配置与独立验证。此外，文章指出哪个指标轴在不同模型间变化最大取决于基准（如 Terminal-Bench 2.0 上每轮步数也在变化），因此不存在通用的“最重要指标”。