AI Agent 评估方法论：任务集设计、执行轨迹与可观测性

使用代表性任务、受控环境、可观察的执行轨迹和重复试验来评估 Agent 性能。

当今的 AI Agent 以语言模型为基础，通过工具、指令和执行循环来完成多步骤任务。它们可以搜索网页、查询客户记录、编辑代码、调用 API 以及修改外部系统。因此，Agent 产生的不仅是输出，还包括可以改变系统状态的一系列动作。

随着 Agent 从生成答案转向采取行动，评估方式也需要随之演进。正确的结果只能告诉我们 Agent 到达了目的地，但无法揭示沿途发生了什么。Agent 是否使用了正确的工具？是否遵循了所需的步骤？当出现问题时是否进行了恢复？回答这些问题，首先要理解一个设计良好的 Agent 评估的核心组成部分。

从正确的任务开始

Agent 评估的基础是任务集。类似于传统模型评估中的测试集，它定义了衡量性能的数据分布。然而对于 Agent 而言，任务覆盖范围超出了输入和预期输出的范畴。

下表概述了一个设计良好的评估集应包含的任务类型。在每个领域中，任务应在复杂性、工作流长度、工具依赖性、资源需求、歧义性、状态、约束条件、失败条件和预期难度等方面有所变化。

真实世界的任务很有价值，因为它们捕捉到了使用实际产品时的复杂性：意外的请求、不完整的信息、隐藏的依赖关系，以及难以预先设想的约束条件。但生产数据讲述的故事并不完整。常见工作流随处可见，而罕见但后果严重的失败可能几乎不出现。已放弃的任务留下的证据可能比成功的任务更少，某些情况还需要专家判断来确定应该发生什么。

幸运的是，许多任务所需的材料已经存在。有用的来源包括：

工作流文档

领域专家访谈

生产环境中的失败往往是新评估任务的最佳来源。当 Agent 在真实工作流中遇到困难时，这种失败可以被转化为一个任务并添加到评估套件中。Anthropic 的 Agent 评估指南建议将这些观察到的失败与从产品需求派生出的任务结合起来，然后随着时间的推移将已建立的能力测试移入回归套件。如果原始案例包含敏感数据，请仔细移除或替换这些信息。目标是保护底层记录，同时不简化掉导致 Agent 陷入困境的条件。

合成任务允许评估者创建有针对性的场景，一次只改变一个条件，并在不等待这些情况自然出现的情况下扩展覆盖范围。当生产数据有限，或者当重要条件过于罕见、代价高昂或风险太大而无法在实时系统中重现时，合成任务尤其有用。但使合成任务有用的这种控制力也可能使它们不那么真实。生成的案例可能使用重复的语言，以不太可能的方式组合条件，或者根本无法捕捉到 Agent 在真实世界中遇到的工作分布。

为了缩小这一差距，请从真实证据出发构建合成任务。将它们基于：

在真实轨迹中观察到的失败

然后系统地改变输入、权限、系统状态、工具响应和任务复杂性。LLM 可以高效地生成变体，但领域专家应验证每个场景是否真实、其预期结果是否正确，以及任务是否泄露了解决方案。

环境与评估工具

任务指定了目标，但这只是评估的一部分。Agent 需要一个可以行动的环境，而评估工具负责管理 Agent 与该环境交互时的实验。下表描述了各自的角色及其组成部分。

评估环境与工具

评估还需要可重现。对任务、环境、工具模式、策略、评分器和 Agent 配置进行版本控制，以便将结果的变化追溯到系统的变化。当生产环境揭示新的失败时，将其简化为最小的可重现任务并添加到评估任务集中。随着时间的推移，这些任务可以成为回归测试，而对模型、prompt、工具或策略的更改可以很容易地测量。

想象评估一个被要求为损坏订单退款的客服 Agent。它的环境包含客户账户、订单历史、退款策略、权限和支付工具，包括真实的约束，如审批限制和 API 失败。如果没有这些条件，Agent 可能在评估中成功使用一种在生产环境中会失败的工作流。

工具建立了初始状态，呈现请求，赋予 Agent 访问相应工具的权限，记录发生的情况，并确定运行何时结束。然后它保存证据以供评分，并在下一次试验前重置环境。评分可以检查最终状态之外的内容。例如，苹果的 ToolSandbox 基准同时评估中间里程碑和最终结果，不仅可以验证 Agent 是否达到了目标，还可以验证重要的步骤是否沿途发生。

选择正确的指标

任务成功是必要的，但不足以描述 Agent 性能。评估应分别捕获 Agent 是否达到预期结果、是否遵守所需约束、是否从失败中恢复，以及是否高效地使用时间和资源。这种多指标方法遵循了 Stanford 的 HELM 框架所展示的更广泛原则，该框架从多个维度评估语言模型，而不是将准确性作为性能的完整衡量标准。对于 Agent 系统，一个有用的指标堆栈包括：

结果指标：衡量 Agent 是否达到可验证的最终状态。仅当部分完成具有有意义的价值时才给予部分分数。

约束指标：衡量对必需策略、权限、隐私规则和安全边界的违反。将这些与任务成功分开。

轨迹指标：衡量 Agent 如何执行任务，包括无效的工具调用、重试、恢复、升级和不必要的步骤。OpenAI 的轨迹评分指南展示了如何通过检查 Agent 的决策和工具调用来揭示从最终结果中无法看到的行为。

效率指标：衡量延迟、成本、Token 用量、工具调用和人工干预。仅在满足所需结果和约束的运行之间比较效率。

将评估简化为一个数字是很诱人的，特别是在比较 Agent 或决定是否发布新版本时。但综合评分可能掩盖评估应该暴露的失败。例如，一个 Agent 可能降低延迟和成本，同时引入关键的安全漏洞。将这些变化平均在一起会产生更好的分数，但不一定会产生更好的 Agent。

测试一致性性能

Agent 行为本质上具有可变性。即使是相同的任务，重复执行也可能由于模型随机性、工具行为、交互状态和环境条件而产生不同的轨迹和结果。因此，一次成功的试验确立了能力，但不能单凭它确立可靠性。

对于关键任务，在受控条件下评估重复试验，并报告整个结果分布中的成功率。pass@k 估计 k 次尝试中至少一次成功，当重复尝试是工作流的一部分时，这是合适的。Tau-bench 引入了 pass^k 来衡量所有 k 次尝试都成功的概率，对一致性提出了更严格的要求。它对于可靠行为在重复执行中很重要的场景特别有用，在这些场景中，失败的运行不能简单地丢弃并重试。

随着任务变得更长更复杂，可靠性往往会下降。METR 的时间范围研究通过估计 Agent 以给定成功率完成的人类可完成任务的长度来捕捉这一点。同样的原则适用于产品评估。结果应按工作流长度、工具依赖性、歧义性和恢复机会等因素进行分层。否则，在较短或较简单任务上的改进可能提高总体成功率，而较长、有状态的工作流仍然不可靠。

Agent 评估的目标不仅仅是产生一个分数，而是理解 Agent 在整个任务中如何表现。代表性的任务表明是否正在测试正确的能力。受控环境使这些测试可重现。执行轨迹揭示沿途发生了什么，重复试验显示该行为是否可靠。综合起来，这些证据有助于区分偶然成功与可靠性能——当条件变化、工具失败、任务变得更困难时依然如此。