如何评估 AI 智能体：从工具调用到任务完成 | NVIDIA 技术博客

当你发布一个 AI 智能体时，关键问题在于它是否能在实时环境中跨越数十个连续工具调用执行一系列工作，并在某一步失败时恢复。评估模型的听起来是否正确，几乎无法告诉你工作是否完成。

这种差距就是为什么智能体评估必须从对单个函数调用评分演变为对整个任务评分，而工具调用则是底层的连接纽带。这篇文章追踪了这一发展历程，并解释了为什么几乎所有严肃的智能体基准测试现在都建立在工具调用的基础上。

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

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

智能体打破了这一假设。在跨越多个步骤的任务中，智能体会在许多步骤中调用工具、处理错误并观察结果，这使得单个输出字符串显得不足。伯克利函数调用排行榜 (BFCL) 应运而生，用于评估单轮和多轮场景中的函数选择和参数准确性。然而，BFCL 仅评估单个调用——如果跳过了底层的检查或更新，即使是一个有效的 issue_refund 调用仍然会失败。调用准确性是必要的，但不是充分的。

从对调用评分到对环境评分

完整的智能体评估现在需要一个完整的执行环境：一个能够执行每个工具调用、跟踪跨步骤状态并在事后读取世界状态以决定工作是否完成的环境。

其上有两个评分层：

• 步骤级（过程评分）询问在当时的状态下，此调用是否有效、相关且有用？
• 端到端（E2E，或称结果评分）忽略路径，仅检查最终状态：退款是否入账，工单路由是否正确？

步骤级评分可以告诉你链条在哪里断裂，这是你在调试或针对性进行微调时想要的；E2E 评分则将第一步的失败和第九步的失败都归为同一个“任务失败”。E2E 是你的用户实际体验到的，这就是为什么大多数生产环境评估将其作为发布的门槛，并在底层保留步骤级追踪以供调试。

这两个分数是对同一个对象的两种解读：轨迹 (trace)。轨迹是单次尝试的有序日志：用户消息、每个步骤以及尝试停止时的环境状态。过程评分对每一行进行分级。E2E 评分对最终状态进行分级。

基准测试运行测量什么

工具调用基准测试按顺序对三件事进行评分：决定使用工具、选择正确的工具以及填充其参数。一个在需要直接回答时却去调用工具的模型，与一个跳过所需工具的模型一样，都会失败。成本和延迟则在此之上，由调用的冗余度和运行时间决定。

每次运行都通过一个固定的层级进行汇总：基准测试 (Benchmark) → 试验 (Trial) → 任务 (Task) → 轮次 (Turn) → 步骤 (Step)：

• 试验是在固定配置下对整个任务集进行的一次独立遍历。
• 任务是一个可独立评分的问题实例，由任务 ID 标识。
• 轮次是一个交互边界：消息输入，智能体回复输出，中间的一切都属于该轮次。
• 步骤是轮次内的一个原子动作——工具/命令调用，或非工具输出（如计划或最终消息）。

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