AI Agent 评估指南：从工具调用到任务完成

当你上线一个 AI agent 时，关键问题是它能否在真实环境中串联几十次工具调用完成一整套工作，并在某一步失败时自我恢复。只给模型的回答打分，几乎无法判断工作是否真正完成了。

正是这个差距，推动了 agent 评估从给单次函数调用打分，演进到给整个任务打分，而工具调用则是贯穿其中的基础能力。本文将梳理这条演进路径，并解释为什么如今几乎所有严肃的 agent 基准测试都建立在工具使用之上。

标准的 LLM 基准测试为什么不够用？

早期评测框架是为静态任务设计的。第一个与模型无关的开源评测框架将模型和评测协议解耦开来。

Agent 打破了这个假设。在多步任务中，agent 需要调用工具、处理错误、在多个步骤间观察结果，单一的输出字符串已经不够用了。于是 Berkeley Function-Calling Leaderboard（BFCL） 应运而生，用于评估单轮和多轮场景下的函数选择与参数准确性。但 BFCL 只评估单次调用——即使 issue_refund 调用本身合法，只要跳过了底层的校验或更新操作，任务照样失败。调用准确是必要条件，但远远不够。

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

完整的 agent 评估如今需要一个完整的执行环境：它能执行每一次工具调用、跨步骤跟踪状态，并在结束后读取环境状态，判断工作是否真正完成。

在这个环境之上，有两层打分：

• 步骤级（过程评分）：回答的是——在当时的状态下，这次调用是否有效、相关、有用？
• 端到端（E2E，即结果评分）：不关心过程路径，只看最终状态：退款到账了吗？工单路由对了吗？

步骤级评分能告诉你链条在哪里断了，这正是调试或针对性微调时所需要的；而 E2E 会把第一步的失败和第九步的失败都归为同一个“任务失败”。但 E2E 才是用户真正体验到的结果，所以大多数生产环境的评估以 E2E 作为发布门槛，同时在底层保留步骤级追踪用于调试。

这两个分数其实是在同一对象——轨迹（trace）——上的两次不同读取。所谓轨迹，是单次尝试的有序日志，包含用户消息、每个步骤以及尝试终止时的环境状态。过程评分针对的是日志中的各步骤（行），而端到端（E2E）评分关注的则是最终状态。

基准测试运行衡量什么

调用工具的基准测试按顺序衡量三个环节：决定是否使用工具、选择正确的工具，以及填充其参数。有些模型在直接回答必然失败时，会如同那些在需要工具时却跳过的模型一样，盲目地试图调用工具。成本和延迟叠加在此之上，由调用的冗余度和运行时间决定。

每次运行都遵循固定的层级结构汇总：基准测试 → 尝试（Trial）→ 任务（Task）→ 轮次（Turn）→ 步骤（Step）：

• 尝试（Trial）是在固定配置下对整套任务集进行的一次独立遍历。
• 任务（Task）是一个可独立评分的问题实例，由任务 ID 标识。
• 轮次（Turn）是单次交互的边界：用户输入消息，智能体返回回复，其间的所有行为都属于该轮次。
• 步骤（Step）是轮次内的一个原子操作——可以是工具/命令调用，也可以是非工具输出（如规划或最终回复）。

一个步骤通常就是一个工具调用，而更高层级的所有评分都是基于这些步骤汇总而来的。值得关注的指标可归结为三个维度：准确性、冗余度和成本（详见下文表 1）。

correct_calls / calls_issued

指标	公式	维度	存在原因
任务成功率	成功任务数 / 总任务数	准确性	发布门槛。环境是否达到了目标状态？
一致性	3-5 次尝试中成功率的波动范围	准确性	90% 和 74% 的结果不能简单平均为 84%。应报告 82–88% 的范围，而非单点估计值。
工具调用精确度	Accuracy	在此处暴露出虚构的工具名和多余调用，而非成功率。
参数准确率	correct_args / calls_with_right_tool	Accuracy	区分“调错 API”与“API 正确但参数填错”。
单次成功平均步数	steps / successful_tasks	Verbosity	任务实际完成时轨迹的长度。
单次成功平均成本	spend / successful_tasks	Cost	经济计量单位。Token 消耗和 GPU 秒数只有折算到单次成功任务才有意义。

指标组合至关重要：仅看成功率而忽略一致性，得到的是随机系统上的单点估计（一个波动于 90% 和 74% 之间的模型，比稳定在 84% 的模型风险更高）；仅看工具调用精度而忽略参数准确率，会掩盖槽位填充失败的问题。

步数往往是同一任务在不同模型间差异最显著的维度——4 步与 15 步——但在 Terminal-Bench 2.0 等测试集中，每轮步数也会有波动，因此哪个维度波动最大取决于具体的基准测试。并行工具调用能减少步数和延迟，但不会减少调用次数：单轮执行中同时触发四个工具，依然发出了四次调用。指标应按序累加，不要简单平均步数就当作基准测试得分。

如何解读评估结果

两个基准测试都可以声称在测试工具调用，但产出的数据可能无法对比。三个维度解释了大部分差异：

• 任务复杂度 — 是单轮调用单个工具，还是多轮涉及规划、错误恢复和状态管理？仅测试单次调用的基准无法告诉你模型在 15 步中的第 8 步是否会崩溃。
• 状态保持性 — 环境是否随每个动作更新？有状态的基准测试能暴露漂移、上下文丢失和状态损坏，而静态基准测试会漏掉这些问题。
• 评估方法 — 可执行验证（数据库是否更新、测试是否通过）是金标准。基于参考答案的评估需要维护一个标注好的答案集。LLM-as-a-Judge 填补了没有可执行检查时的空白，但其评分应视为临时性的，直到在样本上通过与人类评分的对比验证。

污染已不再局限于训练数据泄露，还包括实时变体：会联网搜索的 Agent 可能在评测过程中检索到答案，而 Hugging Face 上的数据集也很快会被重新抓取进预训练语料库。私有领域的评测之所以能解决这个问题，是因为它根本无法被抓取。

下面的表 2 是一次真实基准测试的公开轨迹，使用了步骤级和 E2E 双重评分。工具、用户和完成标准都由测试套件提供，而非人为构造的工单。

• 套件：SWE-bench Verified（真实的 GitHub issue，可通过可执行测试验证）
• 任务 ID：pytest-dev__pytest-5262（第 .2 次试验，第 0–4 轮）
• 用户 / 用户模拟器的开场白："对仓库（/testbed）进行必要的修改，以满足 issue 中提出的要求"——该 issue 的内容是：_pytest.capture.EncodedFile 会从底层 buffer 继承并报告 rb+（二进制）模式，但它的 write() 只接受 str，因此检查 .mode 的外部代码（如 youtube-dl）在写入 bytes 时会崩溃。
• 测试框架说明（暴露的工具、最大步数、并行调用开关）：OpenHands agent harness；暴露的工具：terminal、file_editor、task_tracker、finish；并行工具调用关闭（每轮一次工具调用）；仓库状态跨轮持久（真实文件系统 + git，非模拟环境）。

步骤	轮次	调用	环境观察结果	判定	原因（有效 / 有用 / 冗余 / 补救 / 策略）
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 之后修复的对象

• 端到端检查（数据库状态 / 测试 / 票据）：通过
• 端到端得分（0 或 1）：1
• 步骤级得分（通过数 / 总步骤数）：3/4
• 工具调用精确度：3/4
• 参数准确性：4/4

查看输出结果时，重点关注最后五个要点：端到端检查、端到端得分、步骤级得分、工具调用精确度以及参数准确性。端到端检查表明旨在修复的相关 Bug 测试已通过，这意味着本例中的端到端得分为 1（is_resolved: true）。下一个指标是步骤级得分，它反映模型采取的步骤中有多少是实际必需的。参照上表的得分，步骤级得分为 3/4，因为其中一个步骤存在冗余，特别是步骤 2。这一冗余直接影响了工具调用精确度参数准确性显示所有参数均填写正确，未出现格式错误。

基准测试为何趋向聚焦于工具使用

“调用工具”与“完成任务”之间的界限不再清晰：如今大多数衡量通用能力的基准测试同时也衡量工具使用能力，因为在任何可行的部署场景中，模型都不会在没有工具的情况下运行。一个不提供工具访问权限的基准测试，评估的是没有任何人会实际交付的能力。

并非所有基准测试都能说清问题所在。HumanEval 将生成的 Python 代码与单元测试对照运行，提供可执行验证，但不涉及工具调用，也没有可交互的环境。SWE-bench 则让这一转变清晰可见：解决真实的 GitHub issue 意味着需要在代码库中导航、编写补丁并让测试套件通过——这一过程涉及按顺序发起文件读取、搜索和编辑等工具调用。分数衡量的是结果，但其下的轨迹完全由工具调用构成。因此在很多情况下，你为评估通用能力而运行的基准测试，实际上已在考察工具使用能力。这重新定义了关键问题：

学术基准测试衡量模型在抽象层面的能力上限。企业基准测试回答的是更窄但更有用的问题：它能否胜任我的工作——针对你的任务、你的 API、你的策略？基准测试离生产环境越近，其分数在你的决策中权重就应越高。

透过这一视角分析 Nemotron 3.5 Lightning

应将 NVIDIA Nemotron 3.5 Lightning 发布的测试套件视为任务完成度和完成时长，而非孤立的调用准确率。Banking 评分关注多轮银行对话中的完成情况——是大规模下的退款流程追踪，而非单次调用。GDPval-AA v2 对来自真实工作产出的智能体任务进行评分，由 LLM 评审团进行两两比较，并以 1,000 位人类专家基线校准 Elo 分数——这种人类验证机制确保了评审分数的可信度。在 PinchBench 上，Nemotron 3.5 Lightning 达到 86% 准确率，同时在完成 10,000 个任务时比准确率相当的 Qwen3.6 35B 快 30%——一个高效完成任务的模型，胜过一个孤立准确率更高但消耗更多步骤和 tokens 的模型。

公开榜单的分数是很好的参考信号，但不应该作为发布的门槛。针对自己的任务和用例对模型进行适配调整，依然同样重要。

为自己的工作负载做基准测试

• 设定公开基准线。跑一遍已发布的 agentic 测试套件，记录成功率以及 3–5 次试验中的波动范围。
• 用真实的工单、调用记录和 API 构建领域评测。以环境状态作为判定标准——数据库里的某行记录、合并的 PR、关闭的工单——而不是评判模型对最终回复的“意见”。
• 让模型和评测框架适配自己的数据分布。
• 重新测量成功率、一致性、每次成功所需的步数和成本，并保留每一步的调用记录以便调试。

在环境中验证实际结果，用评判模型处理语言层面的评估，再借助工具调用的精准度和参数准确率来定位链条在哪里出了问题。

如果想复现已发布的分数，Nemotron 提供了 复现文档，其中涵盖了 模型卡 中各分数背后的配置。你可以在 build.nvidia.com 上试用，从 Hugging Face 获取模型权重，或参考 NIM 指南。

在 LLM 基准测试领域，工具调用是当今各种评测的基础。能够构建、阅读并理解这些评测，才能为你的用例做出明智决策。

延伸阅读

关注 NVIDIA Nemotron 的最新动态：订阅 NVIDIA 新闻，并在 LinkedIn、X、YouTube 上关注 NVIDIA AI，以及加入 Discord 上的 Nemotron 频道。

在 Hugging Face 上获取开源的 Nemotron 模型，在 build.nvidia.com 上浏览 NIM 微服务 合集及开发者示例。