如何评估AI智能体：从工具调用到任务完成-模型-至顶网

当你上线一个AI智能体，关键问题在于它能否在真实环境中执行跨数十次连续工具调用的工作链，并在某一步出错时恢复。仅仅评判模型"听起来是否正确"，几乎无法告诉你工作是否真正完成。

正是这个差距，促使智能体评估必须从对单次函数调用打分，演变为对整个任务打分，而工具调用则是贯穿其中的连接组织。本文将梳理这一发展脉络，并解释为何如今几乎所有严肃的智能体基准测试都建立在工具使用之上。

为什么标准大语言模型基准测试还不够

最初的测试框架是为静态任务而构建的。第一个与模型无关的开源测试框架，将模型与评估协议解耦。

智能体打破了这一假设。智能体在多步骤任务中运行，需要调用工具、处理错误、并在多个步骤中观察结果，因此单一的输出字符串已不足以说明问题。伯克利函数调用排行榜（BFCL）应运而生，用于评估单轮和多轮场景下的函数选择与参数准确性。然而，BFCL仅评估单次调用——即便底层检查或更新步骤被跳过，一个有效的issue_refund调用仍可能失败。调用准确性是必要条件，但并非充分条件。

从评判调用到评判环境

真正完整的智能体评估如今需要一个完整的执行环境：该环境能执行每次工具调用、跟踪各步骤的状态，并在事后读取世界状态以判断工作是否完成。

在此之上有两个评分层级：

步骤级（过程评分）关注的问题是：在当时的状态下，这次调用是否有效、相关且有用？

端到端（E2E，或结果评分）忽略路径，只检查最终状态：退款是否到账，工单是否正确路由？

步骤级评分能告诉你链条在哪里断裂，这在调试或针对性微调时非常有用；而端到端评分则会把第一步的失败和第九步的失败，都归结为同样的"任务失败"。端到端评分才是用户实际感受到的结果，这也是为什么大多数生产环境的评估都以此作为发布门槛，同时保留步骤级追踪用于调试。

这两种评分实际上是对同一个对象的两种解读：轨迹（trace）。轨迹是单次尝试的有序日志：用户消息、每个步骤，以及尝试终止时的环境状态。过程评分对每一行打分，端到端评分对最终状态打分。

基准测试运行衡量什么

工具调用基准测试按顺序对三件事打分：是否决定使用工具、是否选择了正确的工具、是否正确填充了参数。一个在直接回答就能奏效时仍去调用工具的模型，和一个跳过了必要工具调用的模型，同样是失败的。成本和延迟则叠加在这三者之上，由调用的冗长程度和运行时间决定。

每次运行都通过一个固定的层级结构汇总：基准测试 → 试验 → 任务 → 轮次 → 步骤：

试验是在固定配置下，对整个任务集进行的一次独立遍历。

任务是一个可独立评分的问题实例，由任务ID标识。

轮次是一个交互边界：一条用户消息进入，智能体的回复输出，二者之间的一切都属于该轮次。

步骤是轮次内的一个原子动作——一次工具/命令调用，或者一个非工具输出，如计划或最终消息。

步骤通常是一次工具调用，其上的每一项评分都是由这些步骤汇总而来。值得追踪的指标可归结为三个维度：准确性、冗余度、成本（见下方表1）。

这些指标的配对关系很重要：没有一致性的成功率只是对一个随机系统的单点估计（一个模型这次命中90%、下次命中74%，比一个稳定保持84%的模型风险更大）；没有参数准确性的工具调用精确度则会掩盖填槽失败的问题。

步骤数量通常是同一任务在不同模型间差异最大的维度——四步与十五步之间的差异——尽管在Terminal-Bench 2.0这类测试套件中，每轮的步骤数也存在差异，所以哪个维度变化最大取决于具体的基准测试。并行工具调用能减少步骤数和延迟，但不会减少调用次数：一轮触发四个工具的单步操作，仍然算作四次调用。汇总时要按顺序进行，不要把步骤简单平均后就称之为基准分数。

如何解读一次评估

两个基准测试都声称在测试工具调用，但得出的数字可能并不可比。三个维度可以解释大部分差异：

任务复杂度——是单轮单工具，还是需要规划、错误恢复和状态管理的多轮任务？单次调用的基准测试无法告诉你一个模型是否会在第十五步中的第八步崩溃。

状态性——环境是否在每次操作后更新？有状态的基准测试能够暴露静态基准测试无法捕捉到的漂移、上下文丢失和状态损坏问题。

方法论——可执行验证（数据库是否更新、测试是否通过）是黄金标准。基于参考答案的评估需要有人维护一份标注好的答案集。"大语言模型作为评判者"的方法可以填补没有可执行检查手段时的空白，但其评分应被视为初步结果，直到在样本上与人工评分进行验证。

数据污染现在已从训练数据泄露扩展到实时变体：能联网搜索的智能体在评估过程中检索到答案，Hugging Face上的数据集很快被重新抓取进预训练语料库。私有领域评估通过无法被抓取来解决这一问题。

下方表2是一次真实基准测试运行的公开轨迹，使用步骤级和端到端评分，其中工具、用户和完成标准由测试套件而非人为设置的工单提供。

测试套件：SWE-bench Verified（真实GitHub问题，可执行测试验证）

任务ID：pytest-dev__pytest-5262（试验.2，第0-4轮）

用户/用户模拟器的开场白："对仓库（/testbed）进行必要的修改，以满足问题中指定的要求"——该问题是：_pytest.capture.EncodedFile从其底层缓冲区报告的模式为rb+（二进制），但其write()方法只接受字符串，因此检查.mode的外部代码（如youtube-dl）在写入字节时会崩溃。

测试框架说明（暴露的工具、最大步骤数、并行调用开关）：OpenHands智能体框架；暴露的工具：终端、文件编辑器、任务追踪器、完成指令；并行工具调用关闭（每轮一次工具调用）；仓库状态在各轮次间持续保存（真实文件系统和git，而非模拟环境）。

端到端检查（数据库状态/测试/工单）：通过

端到端评分（0或1）：1

步骤级评分（通过数/总步骤数）：3/4

工具调用精确度：3/4

参数准确性：4/4

查看输出结果时，重要的是关注最后五项：端到端检查、端到端评分、步骤级评分、工具调用精确度和参数准确性。端到端检查告诉我们，为修复该问题而进行的相关测试已通过，因此本例中端到端评分为1（is_resolved: true）。下一个指标是步骤级评分，它告诉你模型所采取的步骤中有多少是真正必要的。从上表评分来看，步骤级为3/4，因为其中一步是冗余的——具体是第二步。这直接影响到工具调用精确度，因这一细微失误同样得分3/4。在这条轨迹中，最后一项指标——参数准确性显示，所有参数都填写正确，没有出现格式错误。

为什么基准测试正在向工具使用收敛

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

并非所有基准测试都能说明这一点。HumanEval让生成的Python代码运行单元测试，提供了可执行验证，但没有工具调用，也没有可供操作的环境。SWE-bench则清楚地展现了这一转变：解决一个真实的GitHub问题，意味着要在代码库中导航、编写补丁并通过测试套件——这是一系列文件读取、搜索和编辑调用。分数衡量的是结果，但其下的轨迹完全由工具调用构成。在许多情况下，你已经在运行的通用能力基准测试，实际上已经在检验工具使用能力了。这重新定义了真正重要的问题：

学术基准测试衡量的是模型能力的抽象上限。企业基准测试回答的是更具体、更有用的问题：它能完成我的工作吗——针对你的任务、你的API、你的策略？基准测试越贴近生产环境，其分数在你的决策中所占的权重就应该越大。

从这个视角审视Nemotron 3.5 Lightning

应将NVIDIA Nemotron 3.5 Lightning发布的测试套件视为对任务完成度和完成用时的衡量，而非孤立的调用准确性。银行业务测试衡量的是多轮银行对话中的完成度——是规模化的退款轨迹，而非单次调用。GDPval-AA v2则对真实的智能体工作成果进行评分，由一组大语言模型评判者进行两两对比打分，其Elo评分以1000名人类专家的基准为锚点——正是这种人工验证，使得评判分数值得信赖。在PinchBench测试中，Nemotron 3.5 Lightning准确率达到86%，完成1万个任务的速度比准确率相当的Qwen3.6 35B快30%——一个能高效完成任务的模型，胜过一个准确率更高但消耗更多步骤和Token的模型。

公开分数是一个很好的信号，但不应被视为发布的门槛。针对你的任务和使用场景对模型进行适配，依然同样重要。

对你自己的工作负载进行基准测试

设定一个公开基准线。运行一个已发布的智能体测试套件，记录3-5次试验中的成功率及其波动范围。

基于你真实的工单、轨迹和API构建领域评估。以环境状态作为门槛——数据库中的一行记录、一次合并的PR、一个关闭的工单——而不是评判者对最终消息的主观看法。

针对该数据分布对模型和测试框架进行适配。

重新测量成功率、一致性、每次成功所需步骤数以及每次成功的成本。保留步骤级轨迹用于调试。

在环境中验证结果的实际后果，用评判者来评估语言表达质量，用工具调用精确度和参数准确性来定位链条断裂之处。

为了复现已发布的数据，Nemotron提供了涵盖模型卡评分背后各项配置的可复现性文档。你可以在build.nvidia.com上进行体验，从Hugging Face获取模型权重，或参照NIM指南进行操作。

在大语言模型基准测试领域，工具调用是当今各项评估赖以建立的基础。能够构建、阅读并理解这些评估方法，对于针对你的使用场景做出明智决策至关重要。