摘要
1) 一句话总结
评估（Evals）是构建可靠 AI 智能体的核心基础设施，通过在开发阶段进行系统化的自动化测试，帮助团队提前发现缺陷、防止能力退化并加速迭代。
2) 关键要点
- 评估核心结构：完整的评估包含任务（明确输入与标准）、尝试（单次执行）、评分器（打分逻辑）、记录（完整交互轨迹）和结果（最终环境状态）。
- 核心价值：评估能消除开发歧义，将新模型的测试时间从数周缩短至数天，并提供免费的基准测试与回归测试。
- 评分器类型：分为基于代码（确定性强、速度快、成本低）、基于模型（灵活、可处理开放任务）和人工评分（黄金标准、用于校准）。
- 评估分类：分为“能力评估”（针对困难任务，通过率低，提供优化目标）和“回归评估”（通过率接近 100%，用于防止能力倒退）。
- 非确定性衡量：使用
pass@k（k 次尝试中至少成功一次，适用于编程/创意）和pass^k（k 次尝试全部成功，适用于要求高一致性的场景）来量化智能体表现。 - 实施路径：建议尽早从 20-50 个真实故障用例起步，构建无歧义且正反例平衡的任务集。
- 评分原则：优先使用确定性评分器，对智能体产生的“最终结果”而非“具体路径”进行评分，以避免惩罚 AI 的创造力。
- 综合监控体系：自动化评估应与生产环境监控、A/B 测试、用户反馈及人工审查相结合，以覆盖发布前后的完整质量生命周期。
3) 风险与缺口
- 无评估的风险：缺乏评估会导致团队陷入被动调试循环（“盲飞”状态），修复单一 Bug 极易引发其他未知的系统退化。
- 错误级联风险：智能体的多轮交互特性（调用工具、修改状态）会导致错误在执行步骤中不断传播和叠加。
- 评分器局限性：基于模型的评分器存在非确定性且成本较高；人工评分器虽然准确但极其昂贵、缓慢且无法规模化。
- 环境污染风险：评估框架若缺乏严格的环境隔离（如存在残留文件或缓存等共享状态），会导致测试结果不可靠，甚至让智能体在测试中“作弊”。
- 用户反馈的局限：仅依赖用户反馈来评估智能体表现，获取的信号往往过于嘈杂，且存在偏向严重问题的幸存者偏差。
正文
优秀的评估（Evals）能帮助团队更有信心地发布 AI 智能体（Agents）。如果没有评估，团队很容易陷入被动的循环——只能在生产环境中发现问题，而修复一个故障往往会引发其他故障。评估能在问题影响用户之前，将缺陷和行为变化暴露出来，其价值会在智能体的整个生命周期中不断复利。
正如我们在构建高效智能体时所描述的，智能体在多轮交互中运行：调用工具、修改状态，并根据中间结果进行调整。这些赋予 AI 智能体自主性、智能性和灵活性的能力，也恰恰增加了评估的难度。
基于我们的内部实践以及与前沿智能体开发客户的合作，我们总结了如何为智能体设计更严谨、更实用的评估方法。以下是在真实部署的各种智能体架构和用例中行之有效的经验。
评估的结构
评估（Eval）是对 AI 系统的测试：给定 AI 一个输入，然后对其输出应用评分逻辑以衡量是否成功。本文主要关注在开发阶段无需真实用户即可运行的自动化评估。
单轮评估非常直接：提示词、回复和评分逻辑。对于早期的 LLM，单轮、非智能体评估是主要方法。随着 AI 能力的提升，多轮评估变得越来越普遍。
智能体评估则更为复杂。智能体会跨越多轮调用工具，修改环境状态并不断调整——这意味着错误可能会传播和叠加。前沿模型甚至能找到超越静态评估限制的创造性解决方案。例如，Opus 4.5 曾通过发现策略漏洞解决了一个关于预订航班的测试题。从字面上看它“未通过”评估，但实际上它为用户提供了一个更好的解决方案。
在构建智能体评估时，我们使用以下定义：
- 任务（Task / Problem / Test case）：具有明确输入和成功标准的单次测试。
- 尝试（Trial）：对任务的单次执行。由于模型输出在不同运行中存在差异，我们会运行多次尝试以产生更一致的结果。
- 评分器（Grader）：对智能体表现的某个方面进行打分的逻辑。一个任务可以有多个评分器，每个评分器包含多个断言（Assertions/Checks）。
- 记录（Transcript / Trace / Trajectory）：单次尝试的完整记录，包括输出、工具调用、推理、中间结果及任何其他交互。
- 结果（Outcome）：尝试结束时环境的最终状态。例如，订票智能体可能在记录末尾说“您的航班已预订”，但真正的结果是环境的 SQL 数据库中是否存在预订记录。
- 评估框架（Evaluation harness）：端到端运行评估的基础设施。它提供指令和工具，并发运行任务，记录所有步骤，对输出进行评分并汇总结果。
- 智能体框架（Agent harness / Scaffold）：使模型能够作为智能体行动的系统。当我们评估“一个智能体”时，我们实际上是在评估框架和模型的协同工作。
- 评估套件（Evaluation suite）：旨在衡量特定能力或行为的任务集合。套件中的任务通常有一个共同的宏大目标（例如：客户支持评估套件可能测试退款、取消和升级服务）。
为什么要构建评估？
在刚开始构建智能体时，团队往往可以通过手动测试、内部试用（Dogfooding）和直觉取得惊人的进展。更严谨的评估甚至可能看起来像是拖慢发布速度的额外负担。但是，一旦度过早期原型阶段，智能体投入生产并开始扩展，缺乏评估的开发模式就会开始崩溃。
转折点通常出现在用户反馈“修改后智能体变差了”，而团队却处于“盲飞”状态，除了猜测和检查之外无法验证。没有评估，调试是被动的：等待投诉、手动复现、修复 Bug，然后祈祷没有引发其他退化。团队无法区分真正的退化和噪音，无法在发布前针对数百个场景自动测试更改，也无法衡量改进。
编写评估在智能体生命周期的任何阶段都很有用。在早期，评估迫使产品团队明确智能体的“成功”意味着什么；在后期，它们有助于维持一致的质量标准。
- 加速开发与消除歧义：两名工程师阅读同一份初始规格说明，可能会对 AI 应如何处理边缘情况产生不同的理解。评估套件能消除这种歧义。
- 加速采用新模型：当更强大的模型发布时，没有评估的团队需要数周时间进行测试，而拥有评估的团队可以在几天内确定模型的优势、调整提示词并完成升级。
- 免费的基准与回归测试：一旦有了评估，你就可以在静态任务库上跟踪延迟、Token 使用量、单任务成本和错误率。评估还能成为产品和研究团队之间最高效的沟通渠道。
如何评估 AI 智能体
目前大规模部署的智能体主要包括：编程智能体、研究智能体、计算机操作智能体和对话智能体。虽然应用行业广泛，但可以使用类似的技术进行评估。
智能体评分器的类型
智能体评估通常结合三种类型的评分器：基于代码、基于模型和人工评分。
- 基于代码的评分器（Code-based graders）：
- 特点：确定性强、速度快、成本低。
- 适用场景：精确匹配、状态验证、单元测试。
- 基于模型的评分器（Model-based graders）：
- 特点：灵活、可扩展、能捕捉细微差别、处理开放式任务和自由格式输出。
- 局限：非确定性、比代码更贵、需要与人工评分器校准以确保准确性。
- 方法：基于量规的评分、自然语言断言、成对比较、多裁判共识等。
- 人工评分器（Human graders）：
- 特点：黄金标准质量、符合专家判断、用于校准模型评分器。
- 局限：昂贵、缓慢、难以规模化。
对于每个任务，评分可以是加权的（组合得分必须达到阈值）、二元的（所有评分器都必须通过）或混合的。
能力评估 vs. 回归评估
- 能力评估（质量评估）：问的是“这个智能体擅长做什么？”。它们应该从较低的通过率开始，针对智能体难以处理的任务，给团队一个攀登的目标。
- 回归评估：问的是“智能体还能处理它过去能处理的所有任务吗？”。它们应该具有接近 100% 的通过率，以防止能力倒退。
当能力评估的通过率变得很高时，它们就可以“毕业”成为回归套件，持续运行以捕捉任何偏差。
针对不同类型智能体的评估策略
- 编程智能体：通常依赖明确的任务、稳定的测试环境和对生成代码的全面测试。确定性评分器是首选（代码能运行吗？测试通过了吗？）。此外，还可以对记录（Transcript）进行评分，以评估代码质量或工具调用行为。
- 对话智能体：成功是多维的（例如：工单是否解决、是否在 10 轮内完成、语气是否合适）。通常需要第二个 LLM 来模拟用户，并依赖可验证的最终状态结果和捕捉交互质量的量规。
- 研究智能体：由于没有绝对的对错，研究质量只能相对于任务来判断。策略是组合评分器：基础性检查（验证声明是否有来源支持）、覆盖率检查（包含关键事实）和来源质量检查。基于 LLM 的量规应经常与专家人工判断进行校准。
- 计算机操作智能体：需要在一个真实或沙盒环境中运行，检查其是否实现了预期结果（例如：检查 URL、页面状态、后端数据库状态）。在浏览器操作中，需要在 Token 效率和延迟之间取得平衡（DOM 提取 vs. 屏幕截图）。
如何看待评估中的非确定性
智能体的行为在不同运行中会有所不同。两个指标有助于捕捉这种细微差别：
- pass@k：衡量智能体在 k 次尝试中至少获得一次正确解决方案的可能性。适用于只要有一个成功方案即可的场景（如编程或头脑风暴）。
- pass^k：衡量所有 k 次尝试全部成功的概率。适用于一致性至关重要的面向客户的智能体。
从零到一：构建优秀评估的路线图
以下是从没有评估到建立可信评估的实战指南：
第一阶段：收集初始评估数据集的任务
- 步骤 0：尽早开始。 不要等到需要数百个任务时才开始。从真实故障中提取 20-50 个简单任务就是一个很好的起点。遵循 80/20 法则。
- 步骤 1：从手动测试的内容开始。 查看你的 Bug 跟踪器和客服队列，将用户报告的故障转化为测试用例。
- 步骤 2：编写带有参考答案的无歧义任务。 一个好任务的标准是：两位领域专家能独立得出相同的通过/失败结论。智能体不应因为模糊的规格说明而失败。为每个任务创建一个已知有效的参考解决方案。
- 步骤 3：构建平衡的问题集。 既要测试行为“应该”发生的情况，也要测试“不应该”发生的情况，避免单边优化（例如：既测试需要联网搜索的查询，也测试不该搜索的常识查询）。
第二阶段：设计评估框架和评分器
- 步骤 4：构建具有稳定环境的稳健框架。 每次尝试都应从干净的环境开始，实现“隔离”。共享状态（如残留文件、缓存）会导致结果不可靠，甚至让智能体“作弊”。
- 步骤 5：精心设计评分器。 尽量使用确定性评分器，必要时使用 LLM 评分器。不要惩罚创造力：最好对智能体产生的结果进行评分，而不是对其采取的具体路径进行评分。为多组件任务设置部分得分（Partial credit）。确保评分器能抵抗漏洞或黑客攻击。
第三阶段：长期维护和使用评估
- 步骤 6：检查记录（Transcripts）。 除非你阅读了大量尝试的记录和分数，否则你无法知道评分器是否运作良好。当任务失败时，记录能告诉你这是智能体的真正错误，还是评分器拒绝了一个有效的解决方案。
- 步骤 7：监控能力评估的饱和度。 100% 的通过率意味着没有改进的空间。随着评估接近饱和，进展会显得缓慢。如果评分不公平、任务模糊或框架限制了模型，就应该修改评估。
- 步骤 8：通过开放贡献和维护保持评估套件的长期健康。 评估套件是一个活的产物。对于 AI 产品团队来说，拥有和迭代评估应该像维护单元测试一样成为常规工作。让最接近产品需求和用户的人（如产品经理、客户成功经理）来定义成功并贡献评估任务。
评估如何与其他方法结合
自动化评估只是了解智能体表现的众多方法之一。一个完整的图景包括：
- 自动化评估：迭代快、可复现、无用户影响。适用于发布前和 CI/CD。
- 生产环境监控：揭示真实用户行为，捕捉合成评估遗漏的问题。适用于发布后检测分布漂移。
- A/B 测试：衡量实际用户结果，控制混杂因素。用于验证重大变更。
- 用户反馈：带来真实案例，但信号可能嘈杂且偏向严重问题。
- 手动记录审查：建立对故障模式的直觉，捕捉自动化检查遗漏的细微质量问题。
- 系统性人工评估：处理主观任务的黄金标准，用于校准基于模型的评分器。
最有效的团队会将这些方法结合起来：用自动化评估进行快速迭代，用生产监控获取真实情况，并定期进行人工审查以进行校准。
结语
没有评估的团队会陷入被动循环；而尽早投资评估的团队则会发现开发速度加快，指标取代了猜测。评估为整个团队提供了一个清晰的攀登目标，将“感觉智能体变差了”转化为可执行的行动。
AI 智能体评估仍是一个新兴且快速发展的领域。随着智能体承担更长的任务、在多智能体系统中协作并处理越来越主观的工作，我们需要不断调整我们的技术。
(附注：目前有许多开源和商业框架可以帮助团队实施智能体评估，如 Harbor、Promptfoo、Braintrust、LangSmith 和 Langfuse。虽然框架能加速进度，但它们的价值取决于你运行的评估任务。最好的做法是快速选择一个适合工作流的框架，然后将精力投入到迭代高质量的测试用例和评分器上。)