解密 AI 智能体评估体系：从零构建工程化自动化评测全流程指南

Demystifying Evals for AI Agents

文章背景与核心概要

在当今基于大语言模型 (Large Language Model, LLM) 构建复杂自主系统的浪潮中，AI 智能体 (AI Agent) 具备跨多轮交互调用工具、改变外部环境状态并动态调整决策的强大能力，但这也使其行为的不确定性与评估难度呈指数级上升。如果没有科学系统的工程化评测 (Evals) 机制，开发者往往会陷入“修复一个线上 Bug 却引入三个新问题”的被动泥潭。Anthropic 结合其内部研发实践以及与前沿客户的落地合作，系统性地梳理了 AI 智能体评测的体系结构、关键指标与工程范式。本文详细剖析了从单轮到多轮交互、从代码型到计算机操作型智能体的评测差异，并提供了一套从零到一构建高可靠自动化评测基准套件 (Eval Suites) 的全流程实战指南。

核心概要

Executive Summary

构建行之有效的评测体系 (Evals) 是工程团队能够底气十足地上线交付 AI 智能体 (AI Agent) 的核心生命线。如果缺乏系统化的评测，开发者很容易陷入“头痛医头、脚痛医脚”的被动恶性循环——往往等代码部署到生产环境后才发现线上故障，而仓促修复一个问题又常常引发连带崩溃。评测机制能够在异常行为波及真实用户之前将其尽早暴露，并且随着智能体的持续迭代，评测体系所沉淀的工程复利价值将愈发显著。

Building effective evaluations (evals) is critical for teams shipping AI agents with confidence. Without them, developers are stuck in reactive loops—catching issues only in production where fixing one failure often creates another. Evals make problems and behavioral changes visible before they affect users, and their value compounds over an agent's lifecycle.

本指南将全方位拆解 AI 智能体评测的内在机理，深入探讨为什么自动化评测不可或缺，如何针对不同场景下的智能体 (涵盖代码编写、多轮对话、深度调研以及计算机图形界面操作等) 制定评测方案，并为读者提供一套从零到一搭建高可靠评测套件的实用工程路线图。

This guide explores the anatomy of agent evaluations, why they are essential, how to evaluate different types of agents (coding, conversational, research, and computer use), and a practical zero-to-one roadmap for building reliable eval suites.

引言

Introduction

正如我们在构建高效智能体一文中所阐述的，智能体通常需要跨越多个轮次展开工作：它们不断调用外部工具、修改系统状态，并根据中间执行结果动态调整下一步动作。然而，正是自主性、智能推理与动态灵活性这些让 AI 智能体大显身手的核心特质，也使其在评测方面面临着前所未有的工程挑战。

As described in Building effective agents, agents operate over many turns: calling tools, modifying state, and adapting based on intermediate results. The very capabilities that make AI agents useful—autonomy, intelligence, and flexibility—also make them uniquely challenging to evaluate.

通过 Anthropic 内部的大量技术探索以及与前沿企业客户的深度协同，我们总结出了一套行之有效的方法论，能够在各种真实的业务架构与实际用例中，为智能体设计出更加严密、更具参考价值的评测体系。

Through internal work and collaboration with frontier customers, we have learned how to design more rigorous and useful evals for agents across various real-world architectures and use cases.

评测体系的结构组成

The Structure of an Evaluation

广义上的评估 (Evaluation，简称 "eval") 本质上就是针对 AI 系统设计的一套测试用例：它向模型输入指定内容，随后通过一套打分评判逻辑 (Grading Logic) 来检验输出结果，以此衡量任务完成度。在本文中，我们重点关注可以在软件研发阶段脱离真实用户独立运行的自动化评测 (Automated Evals)。

An evaluation (“eval”) is a test for an AI system: it supplies an input, then applies grading logic to the output to measure success. Here, we focus on automated evals that can be run during development without real users.

• 单轮评测 (Single-turn evaluations)：通常由一个提示词 (Prompt)、一段模型回复以及相应的打分逻辑组成。
• 多轮评测 (Multi-turn evaluations)：用于处理多轮迭代交互场景，随着先进 AI 交互能力的提升，这类评测正变得越来越普遍。
• 智能体评测 (Agent evaluations)：这是最为复杂的一类形态。智能体需要在多个轮次中频繁调用工具、不断修改运行环境的状态并实时自适应决策。这意味着前序步骤中的微小失误可能会在后续执行中不断蔓延和连锁放大。

• Single-turn evaluations consist of a prompt, a response, and grading logic.
• Multi-turn evaluations handle iterative interactions, increasingly common with advanced AI capabilities.
• Agent evaluations are the most complex. Agents use tools across many turns, modifying state in the environment and adapting as they go, meaning mistakes can propagate and compound.

评测核心术语解析

Core Evaluation Terminology

• 任务 (Task，又称 问题/Problem 或 测试用例/Test Case)：具备明确输入与成功判定标准的独立测试单元。
• 尝试轮次 (Trial)：对某个任务进行的单次独立执行尝试。通过多次尝试 (Multiple Trials) 可以有效平抑大模型输出固有的随机波动与方差。
• 打分器 (Grader)：用于对智能体某一特定维度表现进行打分判定的逻辑程序。一个任务可以配置多个打分器，每个打分器可包含多条断言规则 (checks)。
• 运行轨迹日志 (Transcript，又称 链路追踪/Trace 或 轨迹/Trajectory)：一次尝试过程中的全量上下文记录，包括模型输出、工具调用参数、思维链推理过程以及各项中间结果。
• 最终结果状态 (Outcome)：单次尝试执行完毕后外部环境的最终状态 (例如某项预订数据是否真正持久化到了数据库中)。
• 评测底座 (Evaluation Harness)：负责端到端运行评测的基础设施 (负责提供初始指令与工具、并发调度任务、记录各步操作并对最终输出打分)。
• 智能体框架底座 (Agent Harness，又称 脚手架/Scaffold)：驱动底层模型作为智能体协同运行的系统软件 (负责解析输入、编排并分发工具调用)。
• 评测套件 (Evaluation Suite)：为了衡量某种特定技术能力或行为模式而整合的一组任务集合。

• Task (a.k.a. problem or test case): A single test with defined inputs and success criteria.
• Trial: Each individual attempt at a task. Running multiple trials accounts for model output variance.
• Grader: Logic that scores an aspect of the agent's performance. Tasks can have multiple graders with multiple assertions (checks).
• Transcript (or trace / trajectory): The complete record of a trial, including outputs, tool calls, reasoning, and intermediate results.
• Outcome: The final state in the environment at the end of a trial (e.g., whether a reservation actually exists in a database).
• Evaluation harness: The infrastructure running evals end-to-end (providing instructions/tools, running tasks concurrently, recording steps, and grading outputs).
• Agent harness (or scaffold): The system enabling a model to act as an agent (processing inputs, orchestrating tool calls).
• Evaluation suite: A collection of tasks designed to measure specific capabilities or behaviors.

为什么必须构建评测体系？

Why Build Evaluations?

在项目初期，初创团队或许还能凭借人工手动测试和直觉进行开发；但一旦走出原型阶段走向规模化，缺乏评测体系就会带来严重的工程盲区。团队将无法分清系统性能的真实劣化与随机噪声，无法在发版前对数百个真实业务场景执行回归验证，更无法客观量化任何架构改造带来的性能提升。

While early-stage teams can rely on manual testing and intuition, scaling past the prototyping phase without evals leads to blind spots. Teams lose the ability to distinguish real regressions from noise, test changes against hundreds of scenarios prior to shipping, or objectively measure improvements.

评测的核心价值：

Key Benefits of Evals:

• 固化预期行为规范：在产品团队与工程团队之间尽早明确系统成功的判定基准。
• 沉淀基准与捕获性能回退：无缝追踪系统的响应延迟、Token 消耗量、调用成本以及错误率变化。
• 加速新模型适配换代：迅速摸清最新大模型的长板优势，针对性微调提示词，将模型迁移升级周期从数周压缩至数天。
• 构建高带宽沟通纽带：为算法研究与工程优化团队提供具象化、可落地的客观量化指标。

• Encode Expected Behavior: Clarify success criteria early between product and engineering teams.
• Baselines & Regressions: Track latency, token usage, cost, and error rates seamlessly.
• Faster Model Adoption: Quickly determine new models' strengths, tune prompts, and upgrade in days instead of weeks.
• High-Bandwidth Communication: Provide concrete metrics for research teams to optimize against.

如何对 AI 智能体进行评测

How to Evaluate AI Agents

智能体打分器的三种形态

Types of Graders for Agents

在智能体评测体系中，通常会将以下三类打分器组合使用：

Agent evaluations typically combine three types of graders:

Code-based Graders	Model-based Graders	Human Graders
Methods: String matches, binary tests, static analysis, tool call verification. Pros: Fast, cheap, objective, reproducible. Cons: Brittle, lack nuance.	Methods: Rubric-based scoring, natural language assertions, pairwise comparison. Pros: Flexible, scalable, handles open-ended tasks. Cons: Non-deterministic, more expensive, requires calibration.	Methods: SME review, crowdsourcing, spot-checks, A/B testing. Pros: Gold-standard quality, matches expert judgment. Cons: Expensive, slow, doesn't scale easily.

能力评测与回归评测的差异

Capability vs. Regression Evals

• 能力评测 (Capability Evals，关注系统“质量上限”)：用于探测智能体“能够”把哪些高难度任务处理得足够好。初期通常设定较低的通过率基线，以此主动向系统施压、摸清能力边界。
• 回归评测 (Regression Evals，关注系统“稳定性下限”)：确保智能体在迭代中“依然能够”稳定可靠地胜任历史任务。其目标是通过率必须无限逼近 100%，坚决防止技术倒退。

• Capability Evals ("Quality"): Test what the agent can do well, targeting low initial pass rates to challenge the system.
• Regression Evals: Ensure the agent still handles past tasks reliably, targeting near-100% pass rates to prevent backsliding.

针对不同类型智能体的专属评测策略

Evaluating Specific Agent Types

1. 代码型智能体 (Coding Agents)：依赖定义清晰完备的任务说明、高度稳定的隔离沙箱环境以及严格的自动化测试用例 (例如 SWE-bench Verified, Terminal-Bench)。评测时通常将“二元通过/失败”的状态判定，与静态代码分析以及轨迹日志评分细则紧密结合。
2. 对话型智能体 (Conversational Agents)：需要经历多轮复杂交互的严苛评测，工程上通常引入第二个大语言模型来充当“模拟用户” (例如 \(\tau\)-Bench)。成功判据涵盖了任务最终解决率、平均交互轮次以及话术语气评分量表。
3. 调研型智能体 (Research Agents)：重点考核面向动态知识领域时的长文信息综合能力、事实依据准确性 (Groundedness)、内容覆盖度以及引用信源的权威性与可信度。
4. 计算机操作型智能体 (Computer Use Agents)：测试智能体在虚拟隔离操作系统或浏览器中，通过图形用户界面 (GUI) 进行交互的能力 (如截图解析、鼠标点击、键盘输入，代表基准包括 WebArena, OSWorld)。

1. Coding Agents: Rely on well-specified tasks, stable environments, and thorough tests (e.g., SWE-bench Verified, Terminal-Bench). Combine pass/fail outcome checks with static analysis and transcript rubrics.
2. Conversational Agents: Require multi-turn interaction evaluations, often using a second LLM to simulate user personas (e.g., \(\tau\)-Bench). Success spans task resolution, turn counts, and tone rubrics.
3. Research Agents: Evaluate information synthesis, groundedness, coverage, and source quality against dynamic knowledge domains.
4. Computer Use Agents: Test interactions via GUI interfaces (screenshots, clicks) in sandboxed operating systems or browsers (e.g., WebArena, OSWorld).

应对模型输出的非确定性

Handling Non-Determinism

由于智能体在执行任务时往往表现出行为波动性，评测结果的衡量高度仰赖统计学指标：

Because agent behavior varies, results rely heavily on statistical metrics:

• pass@k：衡量在进行 \(k\) 次独立尝试中，获得至少一次成功解的概率 (适用于只要单次成功即可解决问题的探索型任务)。
• pass\^k：衡量在连续 \(k\) 次尝试中，全部轮次均宣告成功的概率 (对于直接面向真实客户、严苛要求稳定一致性的生产级系统至关重要)。

• pass@k: Measures the likelihood of getting at least one correct solution in \(k\) attempts (useful for tasks where a single success matters).
• pass\^k: Measures the probability that all \(k\) trials succeed (essential for customer-facing consistency).

从零到一：构建卓越评测套件的工程路线图

Going from Zero to One: A Roadmap to Great Evals

1. 采集并构建初始评测任务集

1. Collect Tasks for Initial Eval Datasets

• 尽早起步，切莫等待：不要指望一步到位凑齐几百个任务。从真实生产故障中提炼出 20 到 50 个典型的精简任务，就足以启动第一代评测基准。
• 充分盘活现有工程资产：将过去的人工排查清单、Bug 缺陷追踪记录以及客服支持工单，直接重构转化为标准测试用例。
• 编写毫无歧义的任务说明：务必为每个任务附带标准参考答案 (Reference Solutions)，确保不同领域专家在人工审阅时能够达成毫无分歧的一致结论。
• 构建分布均衡的问题集：既要设计“系统应该做出某种行为”的正向测试，也要覆盖“系统绝对不应做出某种行为”的负向边界用例，避免正负样本失衡。

• Start Early: Don't wait for hundreds of tasks. 20–50 simple tasks drawn from real failures are enough to start.
• Leverage Existing Tests: Convert manual checks, bug trackers, and support queues into test cases.
• Write Unambiguous Tasks: Ensure tasks include reference solutions so that domain experts reach identical conclusions.
• Build Balanced Problem Sets: Test scenarios where behaviors should and shouldn't occur to avoid class imbalances.

2. 架构设计：评测底座与打分器

2. Design the Harness and Graders

• 严格保证环境彻底隔离：每一次执行尝试都必须从干净纯洁的初始沙箱环境启动，彻底杜绝状态残留污染或本地缓存污染带来的噪声。
• 明智遴选打分机制：在可行范围内优先采用确定性的代码打分器；在需要灵活性的复杂场景下引入大模型打分；同时切忌陷入“死抠具体执行路径”的僵化检查 (重点评判最终环境状态是否达成目标，而非限定唯一执行路线)。
• 严密防范“投机作弊”：精心设计任务逻辑，防止智能体利用评测环境的漏洞或取巧捷径钻空子，确保高分真正源自扎实的问题解决能力。

• Ensure Isolation: Start each trial from a clean environment to avoid shared-state noise or cached data corruption.
• Choose Graders Wisely: Prefer deterministic graders where possible, use LLM graders for flexibility, and avoid overly rigid path-checking (grade outcomes, not just the exact path taken).
• Guard Against Cheating: Ensure tasks require genuine problem-solving rather than loopholes.

3. 评测套件的长效维护与深度运营

3. Maintain and Use Evals Long-Term

• 定期深度研读轨迹日志：工程团队应养成日常抽查审阅 Transcript 运行日志的习惯，核实打分器的扣分判决是否公允，确保测试集测到的始终是核心关键指标。
• 严密监控评测“饱和效应”：密切警惕测试集出现 100% 满分通过的情况；随着底层基础模型实力的持续迭代跃升，必须动态注入难度更高的挑战任务以抬高天花板。
• 激发跨部门开放共建：将评测套件视为一件持续演进的动态工程资产——由专属的基础设施团队负责底层基建维护，同时广泛吸引业务与产品专家源源不断地贡献真实业务用例。

• Check the Transcripts: Regularly read transcripts to ensure grading failures are fair and that tests measure what matters.
• Monitor for Saturation: Watch for 100% pass rates and continuously introduce harder tasks as models improve.
• Foster Open Contribution: Treat the eval suite as a living artifact owned by dedicated infrastructure teams, but contributed to by product experts.

智能体的全景可观测性认知体系

Holistic Understanding of Agents

将自动化评测与其他全方位可观测性 (Observability) 工程实践紧密结合，可以构筑起一道坚不可摧的“质量安全防护网”：

Combining automated evals with other observability practices creates a robust quality safety net:

• 自动化评测 (Automated Evals)：轻量高效，最适合敏捷迭代，可在每次代码提交 (Commit) 时自动触发 CI/CD 流水线。
• 生产环境监控 (Production Monitoring)：实时捕捉线上真实流量中的数据分布漂移 (Distribution Drift) 以及突发的活跃用户异常。
• A/B 测试 (A/B Testing)：引入小流量真实业务流量，对高影响度的核心架构改造与提示词变更进行在线灰度验证。
• 用户真实反馈与轨迹回溯 (User Feedback & Transcript Reviews)：帮助开发者跳出思维定势，意外发现未曾设想过的边缘故障模式。
• 系统化人工评估实验 (Systematic Human Studies)：作为评测金字塔顶端的黄金标准，为模型打分器提供基准校准依据。

• Automated Evals: Best for fast iteration and running on every commit.
• Production Monitoring: Catches real-world distribution drift and live user issues.
• A/B Testing: Validates high-impact changes against real traffic.
• User Feedback & Transcript Reviews: Surprises developers with unpredicted failure modes.
• Systematic Human Studies: Acts as the gold standard for model calibration.

结语

Conclusion

没有评测护航的团队，终日深陷于“出现线上 Bug 盲目修补”的被动泥潭中动弹不得；而早早在评测工程上布局投资的团队，则会惊喜地发现系统迭代与交付速度迎来了成倍跃升。只要秉持“小步快跑、尽早起步”的原则，深扎真实场景采集测试用例，合理搭配多元打分器，并坚持深入分析底层运行轨迹日志，任何技术团队都能将智能体评测体系打造成自身随时间持续产生复利的核心竞争壁垒。

Teams without evals are bogged down in reactive debugging loops, whereas teams investing early find that development accelerates. By starting small, sourcing realistic tasks, choosing balanced graders, and continuously reading transcripts, organizations can turn agent evaluation into a compounding competitive advantage.

附录：主流智能体评测框架参考

Appendix: Eval Frameworks

• Harbor：提供容器化沙箱隔离环境，支持以标准化任务格式执行大规模并发尝试与基准测试。
• Braintrust：集成了离线自动化评测、生产环境可观测性监控以及系统实验版本追踪的一站式平台。
• LangSmith / Langfuse：面向 LangChain 生态及通用智能体架构，提供链路追踪 (Tracing)、数据集管理与全流程评测分析工具。
• Phoenix (Arize)：专注于大语言模型系统的开源全链路可观测性平台，支持深度 Trace 追踪、问题调试与评测分析。

• Harbor: Containerized environment running trials at scale with standardized task formatting.
• Braintrust: Combines offline evaluation, production observability, and experiment tracking.
• LangSmith / Langfuse: Offers tracing, dataset management, and evaluation tooling for the LangChain ecosystem and beyond.
• Phoenix (Arize): Open-source platform for LLM tracing, debugging, and evaluations.