如何构建可信赖的智能体系统｜Anthropic

Created time

Feb 19, 2026 09:48 AM

Demystifying evals for AI agents

原文链接： https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

引言

一套优秀的 评估体系（Evaluations，简称 Evals）是团队敢于上线 AI Agent 的底气。没有它，你就会陷入“拆东墙补西墙”的被动循环：在生产环境中刚修好一个 Bug，却又引发了新的故障。Evals 的价值在于，它能让问题和行为变化在触达用户之前就“显形”，这种价值会随着 Agent 的生命周期不断叠加。

正如我们在《构建高效 Agent》中所述，Agent 的运作是多轮的：调用工具、修改状态、根据中间结果进行调整。正是这些让 Agent 变得强大的特性——自主性、智能和灵活性——也让它们变得极难评估。

通过 Anthropic 内部的实践以及与前沿开发者的合作，我们总结了一套更严谨、更实用的 Agent 评估设计方案。以下是我们在各种架构和真实场景中验证有效的经验。

评估的结构

所谓评估（Eval），本质上就是给 AI 系统做的一场考试：给它一个输入，然后用一套评分逻辑来衡量输出是否成功。本文重点讨论自动化评估，即在开发阶段无需真实用户参与即可运行的测试。

*单轮评估（Single-turn evals）**非常直观：一个提示词，一个回复，一套评分逻辑。对于早期的 LLM，这是主流。但随着 AI 能力的进化，**多轮评估（Multi-turn evals）**已成为标配。

图注：简单评估中，评分器直接检查输出；复杂多轮评估中，如编码 Agent 需要在环境中执行“Agent 循环”（工具调用和推理），最后通过单元测试验证结果。

Agent 评估则更加复杂。Agent 在多轮交互中调用工具、改变环境状态，这意味着错误会产生连锁反应。此外，顶尖模型往往能找到超出预设的“创意方案”。例如，Claude 3.5 Opus 在一次订票测试中发现了一个政策漏洞，虽然它“违反”了原定的测试步骤，但实际上为用户提供了更好的方案。

在构建 Agent 评估时，我们需要明确以下定义：

任务（Task/Problem）：单个测试用例，包含输入和成功标准。

尝试（Trial）：对任务的一次执行。由于模型输出具有随机性，通常需要运行多次 Trial 以获得稳定的结果。

评分器（Grader）：负责打分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（Assertions/Checks）。

轨迹记录（Transcript/Trace）：一次 Trial 的完整记录，包括工具调用、推理过程和中间结果。

最终状态（Outcome）：环境在 Trial 结束时的状态。比如订票 Agent 说“订好了”不算赢，数据库里真的存了订单才算赢。

评估框架（Evaluation Harness）：运行评估的基础设施，负责并发运行、记录步骤、汇总结果。

Agent 框架（Agent Harness/Scaffold）：让模型能够作为 Agent 运行的系统（如处理工具调用）。我们评估的是“模型+框架”的整体表现。

评估套件（Evaluation Suite）：针对特定能力（如退款、取消订单）的一组任务集合。

图注：Agent 评估的组成部分。

为什么要构建评估体系？

很多团队在起步阶段靠手动测试和直觉也能走得很远，甚至觉得写 Eval 耽误进度。但一旦 Agent 进入生产环境并开始规模化，**“盲目飞行”**的弊端就会显现。

最典型的崩溃时刻是：用户反馈产品变难用了，但团队完全不知道是哪次改动出了问题。没有 Eval，调试就是被动响应：等投诉、手写复现、修 Bug、祈祷没引发新 Bug。你无法区分真正的退步和随机噪声，也无法在上线前自动测试数百个场景。

以 Claude Code 为例，它最初靠内部反馈迭代，后来引入了针对简洁度、文件编辑等维度的 Eval。这些 Eval 帮助我们识别了“过度工程”等复杂行为问题。Eval 是产品与研究团队之间带宽最高的沟通渠道，它定义了优化的目标。

如何评估 AI Agent

虽然 Agent 类型多样，但评估技术大同小异。你不需要从零发明新方法，可以参考以下成熟方案：

1. 评分器的类型

类型	方法	优势	劣势
代码评分器	字符串匹配、单元测试、静态分析、状态检查	快、省、客观、易调试	面对灵活输出时太死板，缺乏细微观察
模型评分器 (LLM-as-judge)	评分量表、自然语言断言、两两对比	灵活、可扩展、能处理开放式任务	存在随机性、比代码贵、需要人工校准
人工评分器	专家评审、抽样检查、A/B 测试	金标准、符合专家直觉	极贵、极慢、难以规模化

2. 能力评估 vs. 回归评估

能力评估（Capability Evals）：问“Agent 能做到多好？”。这类测试应该很难，初始通过率可能很低，作为团队攀登的目标。

回归评估（Regression Evals）：问“以前能做的现在还能做吗？”。通过率应接近 100%，用来防止“倒退”。

3. 针对不同 Agent 的策略

编码 Agent：核心是确定性评分。代码跑通了吗？测试过了吗？（参考 SWE-bench）。

对话 Agent：难点在于交互质量。通常需要第二个 LLM 模拟用户进行对抗性对话，检查共情能力、任务达成度和轮次限制。

研究 Agent：评估其事实准确性和覆盖率。需要检查声称的事实是否有来源支持，以及是否遗漏了关键信息。

计算机操作 Agent：在沙盒环境中运行，检查最终的 UI 状态或后端数据。需要平衡 **DOM 树解析（耗 Token）与截图识别（耗时）**的效率。

评估中的非确定性：pass@k 与 pass^k

Agent 的行为在不同运行中会有波动。为了捕捉这种细微差别，我们使用两个关键指标：

pass@k：在 k 次尝试中，至少有一次成功的概率。这代表了 Agent 解决问题的潜力。

pass^k：在 k 次尝试中，全部成功的概率。这代表了 Agent 的稳定性，对于直接面对用户的产品至关重要。

图注：随着尝试次数 k 的增加，pass@k 趋向 100%，而 pass^k 趋向 0%。

从 0 到 1：构建评估体系的路线图

尽早开始：不要等攒够几百个任务，20-50 个来自真实失败案例的任务就是完美的起点。

消除歧义：如果两个人类专家对某个任务的胜负判定不一致，那这个任务就是不合格的。

构建平衡的题库：既要测“该做的时候做了”，也要测“不该做的时候没做”（防止过度触发工具）。

环境隔离：确保每次 Trial 都在干净的环境中开始，避免缓存或残留文件干扰结果。

设置部分得分：Agent 完成了 80% 的流程也比一开头就崩溃要强，评估体系应能体现这种进步。

必杀技：阅读轨迹记录（Read the Transcripts）：这是开发者最重要的基本功。通过阅读记录，你能发现是 Agent 真的笨，还是你的评分器写错了。

警惕“评估饱和”：当通过率接近 100% 时，这个 Eval 就失去了指导意义，只能作为回归测试。此时需要引入更难的任务。

评估体系的全局观

自动化评估不是万能的，它只是**“瑞士奶酪模型”**中的一层。一套完整的体系应包含：

自动化评估：上线前的第一道防线，快速迭代。

生产环境监控：发现真实世界的分布偏移。

A/B 测试：验证改动对业务指标（如留存）的真实影响。

人工评审：校准模型评分器，处理主观任务。

图注：没有任何一层能拦截所有问题，多层组合才能确保安全。

结语

没有评估的团队会被困在“被动修 Bug”的泥潭里。而早投入的团队会发现，开发速度反而加快了：失败变成了测试用例，指标取代了猜想。评估不是事后的补丁，而是 Agent 开发的核心。

AI Agent 评估仍是一个快速演进的领域。随着 Agent 处理的任务越来越长、协作越来越复杂，我们的技术也必须随之进化。