引言：为什么要评估智能体？

让 AI 智能体变得有用的能力——自主性、多轮交互、状态修改——同时也让它们变得难以评估。

如果没有良好的评估体系（Evals），开发团队很容易陷入“被动循环”：只有在生产环境出现问题时才发现 bug，修复一个问题又引发另一个问题。评估能让问题在影响用户之前显现出来，其价值会在智能体的整个生命周期中产生复利效应。

本文将分享 Anthropic 在构建 Claude Code 等前沿智能体时的实战经验，教你如何设计严谨且实用的评估系统。
原文：《Demystifying evals for AI agents》

---

一、评估的基本概念

在构建评估体系前，我们需要统一定义：

• 任务 (Task)：一个具体的测试用例，包含输入和成功标准。
• 尝试 (Trial)：对一个任务的一次运行。因为模型输出有随机性，通常需要多次尝试。
• 评分器 (Grader)：对智能体表现进行打分的逻辑（如代码通过率、文本匹配度）。
• 对话记录 (Transcript/Trace)：一次尝试的完整记录，包含工具调用、思维链和中间结果。
• 最终结果 (Outcome)：试验结束时环境的最终状态（例如：数据库中是否真的插入了预订记录）。
• 评估框架 (Harness)：运行评估的基础设施，负责初始化环境、执行循环、记录日志和汇总结果。

---

二、如何评估不同类型的智能体

不同类型的智能体需要不同的评估策略，但核心逻辑是通用的。

1. 编程智能体 (Coding Agents)

• 核心目标：编写、测试和调试代码。
• 评估方法：确定性评分是首选。
  • 单元测试：代码能否运行？测试用例是否通过？（类似于 SWE-bench）。
  • 静态分析：使用 Linter 检查代码风格和安全性。
  • 混合评分：结合 LLM 评分器来评估代码的可读性或工具使用是否规范。

2. 对话智能体 (Conversational Agents)

• 核心目标：在多轮对话中解决用户问题（如客服、销售）。
• 评估方法：需要多维度的评分。
  • 状态检查：工单是否已关闭？退款是否已处理？
  • 轨迹约束：是否在10轮对话内完成？
  • LLM 评分 (Rubric)：使用另一个模型模拟用户或作为裁判，评估同理心、语气和回复质量。

3. 研究智能体 (Research Agents)

• 核心目标：搜集信息、综合分析并生成报告。
• 评估方法：质量是主观的，需结合多种检查。
  • 事实依据检查 (Groundedness)：每一句陈述是否有来源支持？
  • 覆盖率检查 (Coverage)：是否包含了关键事实？
  • 来源质量：引用的来源是否权威？

4. 计算机操作智能体 (Computer Use Agents)

• 核心目标：通过 GUI（截图、点击）操作软件。
• 评估方法：在沙盒环境中运行，检查最终状态（如文件系统、数据库变化）。需要平衡 DOM 操作（省 token 但有时不准确）和截图操作（耗 token 但更通用）。

---

三、评分器

一个成熟的评估系统通常结合使用以下三种评分器：

类型	方法举例	优点	缺点
代码评分 (Code-based)	字符串匹配、正则、单元测试、JSON 校验	快速、便宜、客观、可复现	僵化，无法处理细微差别
模型评分 (Model-based)	LLM 打分、成对比较 (Pairwise)、参考答案对比	灵活、可扩展、能处理开放性问题	非确定性、成本较高、需要人工校准
人工评分 (Human)	专家审查、众包打分	黄金标准、符合人类直觉	昂贵、缓慢、难以规模化

建议策略：优先使用代码评分；必要时使用经过校准的 LLM 评分；仅在关键节点或校准模型时使用人工评分。

---

四、关于非确定性的度量：pass@k 与 pass^k

智能体的行为具有随机性，因此单次运行的结果不足以说明问题。我们需要关注两个关键指标：

1. pass@k (尝试 k 次至少成功 1 次的概率)

   • 适用场景：你只需要一个正确的解决方案（例如编程辅助，生成 10 个代码片段只要 1 个能跑就行）。
   • 含义：随着 k 增加，分数上升。

2. pass^k (尝试 k 次全部成功的概率)

   • 适用场景：用户期望极高的可靠性和一致性（例如自动化的客户退款流程）。
   • 含义：随着 k 增加，分数下降。如果单次成功率是 75%，连续 3 次成功的概率仅为 42%。

---

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

第一阶段：起步 (Start Early)

• 不要等待：不需要几百个测试用例，从 20-50 个简单的任务开始。
• 来源：将开发过程中的手动测试和用户反馈的 bug 直接转化为测试用例。

第二阶段：设计 (Design)

• 明确任务：任务描述必须清晰无歧义。如果两个人类专家对任务的成功标准有分歧，这个任务就是不合格的。
• 隔离环境：每次测试都应在干净的环境中运行，避免共享状态（如缓存、残留文件）导致的“假成功”或“假失败”。
• 不要过度约束：评估的是结果，而不是过程。只要结果正确，不要惩罚智能体使用了意料之外的工具顺序。

第三阶段：维护 (Maintain)

• 阅读对话记录 (Read the Transcripts!)：这是最重要的建议。不要只看分数。当测试失败时，去读日志，看是智能体真的蠢，还是评估逻辑有问题。
• 警惕“饱和”：如果评估通过率达到 100%，它就失去了指导改进的意义，只能作为回归测试。需要不断加入更难的任务。
• 全员参与：让产品经理、销售和领域专家参与编写测试用例，他们最懂什么是“成功”。

---

六、全方位的质量保障：瑞士奶酪模型

自动化评估并不是万能的。高效的团队会结合多种手段：

1. 自动化 Evals：开发阶段的快速迭代，CI/CD 流水线。
2. 生产环境监控：捕捉真实世界的异常和分布漂移。
3. A/B 测试：在真实流量中验证改动的影响。
4. 人工审查：定期抽查对话记录，建立对质量的直觉。

就像安全工程中的“瑞士奶酪模型”，每一层都有漏洞，但多层叠加能有效拦截大部分质量问题。

---

结语

评估智能体并非易事，但这是从“玩具 Demo”走向“生产级应用”的必经之路。

核心建议总结：

1. 尽早开始，不要追求完美。
2. 将失败案例转化为测试用例。
3. 混合使用代码评分和 LLM 评分。
4. 一定要阅读评估的详细日志。