让智能体具备实用价值的能力，同时也让它们难以评估。适用于多场景部署的评估策略，需结合多种技术，以匹配所测系统的复杂程度。
原文：Demystifying evals for AI agents \ Anthropic
翻译：领测老贺机翻
文章摘要
本文由 Anthropic 工程团队发布，系统拆解了 AI Agent（智能体）评估的核心难点与实践方法。文章解释了为何评估对智能体研发至关重要，介绍了代码型、模型型、人工三类评分器，以及针对编码、对话、研究、计算机操作等不同智能体的评估方案。同时给出了从零搭建评估体系的完整路线图，强调通过 pass@k、pass^k 等指标衡量智能体稳定性，并建议将自动化评估与生产监控、A/B 测试、人工审核结合，形成多层质量保障体系，帮助团队实现评估驱动的智能体开发，避免功能退化、提升发布可靠性。
引言
优质的评估能帮助团队更有信心地发布 AI 智能体。没有评估，团队很容易陷入被动应对的循环 —— 仅在生产环境中发现问题，而修复一个故障又会引发其他问题。评估能在问题影响用户前将其暴露，其价值会在智能体的全生命周期中持续累积。
正如我们在《打造高效智能体》中所述，智能体通过多轮交互运行：调用工具、修改状态、根据中间结果自适应调整。正是自主性、智能性和灵活性这些让 AI 智能体实用的能力，也让它们更难被评估。
通过内部研发以及与前沿智能体开发客户的合作，我们摸索出了设计更严谨、更实用的智能体评估方法。这些方法已在多种智能体架构和实际部署场景中得到验证。
评估的结构
评估（eval） 是针对 AI 系统的测试：向 AI 输入内容，再通过评分逻辑判断输出，衡量其表现。本文重点介绍自动化评估—— 无需真实用户参与，可在开发阶段运行。
单轮评估 简单直接：提示词、输出结果、评分逻辑。早期大语言模型主要采用单轮、非智能体式评估。随着 AI 能力升级，多轮评估 愈发普遍。
简单评估中，智能体处理提示词后，评分器检查输出是否符合预期。复杂的多轮评估里，编码智能体获取工具、任务（如搭建 MCP 服务器）和运行环境，执行 “智能体循环”（工具调用与推理），并通过实现更新环境状态，最终用单元测试验证 MCP 服务器是否可用。
智能体评估 更为复杂。智能体通过多轮调用工具、修改环境状态并持续自适应，错误会不断传导、放大。前沿模型还能找到突破静态评估限制的创新解法 —— 例如，Opus 4.5 在 τ2-Bench 的机票预订测试中，发现了规则漏洞，虽未按评估设定 “通关”，却给出了对用户更优的方案。
构建智能体评估时，我们采用以下定义：
- 任务（也称问题 / 测试用例）：带明确输入和成功标准的单个测试。
- 试测：对单个任务的一次尝试。因模型输出存在随机性，需多次试测以保证结果稳定。
- 评分器：为智能体某方面表现打分的逻辑。一个任务可搭配多个评分器，每个评分器包含多条判定规则（也称检查项）。
- 交互记录（也称轨迹 / 执行链路）：单次试测的完整日志，包含输出、工具调用、推理过程、中间结果及所有交互信息。Anthropic API 中，评估结束后的完整消息数组即为交互记录，涵盖所有 API 调用与返回结果。
- 最终状态：试测结束后环境中的最终状态。例如机票预订智能体的交互记录显示 “机票已预订”，但最终状态是环境 SQL 数据库中是否存在预订记录。
- 评估框架：端到端运行评估的基础设施，提供指令与工具、并发执行任务、记录全流程、评分输出并汇总结果。
- 智能体框架（也称支撑系统）：让模型成为智能体的系统，负责处理输入、调度工具调用、返回结果。我们评估 “一个智能体”，实际是评估框架与模型的协同效果。例如 Claude Code 是灵活的智能体框架，我们通过 Agent SDK 使用其核心能力搭建了长时运行智能体框架。
- 评估套件：用于衡量特定能力或行为的任务集合，套件内任务通常目标一致。例如客服评估套件会测试退款、取消订单、转接人工等能力。
为什么要做评估
团队刚开始搭建智能体时，仅凭手动测试、内部试用和直觉就能推进不少工作，严谨评估甚至会被视为拖慢发布的额外成本。但进入早期原型阶段后，一旦智能体上线并规模化，不做评估的问题就会暴露。
问题爆发点通常是：用户反馈更新后智能体表现变差，团队却 “盲目摸索”，只能靠猜测验证问题。没有评估，调试完全被动：等待用户投诉、手动复现、修复故障、祈祷不引发其他问题。团队无法区分真实退化与噪声，无法在发布前自动测试数百种场景，也无法量化优化效果。
这种情况我们见过多次。例如 Claude Code 初期依靠员工与外部用户反馈快速迭代，后续逐步加入评估 —— 先针对简洁性、文件编辑等细分场景，再扩展到过度设计等复杂行为。这些评估帮助定位问题、指导优化、衔接研发与产品协作。结合生产监控、A/B 测试、用户研究等手段，评估为 Claude Code 的规模化迭代提供了关键依据。
在智能体全生命周期的任何阶段，编写评估都有价值。早期，评估能倒逼产品团队明确智能体的成功标准；后期，可维持稳定的质量底线。
Descript 的视频编辑智能体，围绕编辑流程的三个核心维度搭建评估：不破坏原有内容、完成用户指令、完成质量达标。团队从人工评分过渡到基于产品标准的大模型评分，并定期人工校准，如今常态化运行两套套件，分别用于质量基准测试和退化检测。
Bolt AI 团队则是在智能体广泛使用后才搭建评估，3 个月内建成一套系统：通过静态分析评分、用浏览器智能体测试应用、用大模型评判指令遵循等行为。
有些团队在开发初期就搭建评估，有些则在规模化后、评估成为优化瓶颈时补充。开发初期搭建评估尤其有用，能明确编码预期行为 —— 两名工程师解读同一份初始需求，对边缘情况的处理可能理解不同，评估套件能消除这种歧义。无论何时搭建，评估都能加速开发。
评估还能加快新模型的落地速度。更强模型发布时，无评估的团队需数周测试，而有评估的团队能快速判断模型优势、优化提示词，数天内完成升级。
评估建成后，可自动获得基准线和退化测试指标：延迟、令牌消耗、单任务成本、错误率等，都能在固定任务集上持续追踪。评估还能成为产品与研发团队最高效的沟通渠道，明确研发可优化的指标。显然，评估的价值远不止追踪退化与优化，其前期成本直观，后期价值持续累积，很容易被忽视。
如何评估 AI 智能体
目前规模化部署的智能体主要包括编码智能体、研究智能体、计算机操作智能体、对话智能体等。尽管应用行业广泛，但可采用通用评估技术，无需从零独创评估方法。下文介绍经实践验证的各类智能体评估方法，可作为基础再结合领域扩展。
智能体的三类评分器
智能体评估通常结合代码型、模型型、人工三类评分器，分别针对交互记录或最终状态的部分维度打分。高效评估设计的核心，是为任务匹配合适的评分器。
代码型评分器
表格
| 方法 | 优势 | 劣势 |
|---|---|---|
| 字符串匹配（精确、正则、模糊等） | ||
| 二元测试（失败转通过、通过转通过） | ||
| 静态分析（语法检查、类型、安全） | ||
| 最终状态验证 | ||
| 工具调用验证（使用工具、参数） | ||
| 交互记录分析（交互轮次、令牌消耗） | ||
| 速度快 | ||
| 成本低 | ||
| 客观公正 | ||
| 可复现 | ||
| 易调试 | ||
| 精准验证特定条件 | ||
| 对合理但不符合预设格式的变化敏感 | ||
| 缺乏细腻度 | ||
| 难以评估主观类任务 | ||
模型型评分器
表格
| 方法 | 优势 | 劣势 |
|---|---|---|
| 基于评分细则打分 | ||
| 自然语言判定 | ||
| 成对比较 | ||
| 参考式评估 | ||
| 多评判员共识 | ||
| 灵活可扩展 | ||
| 能捕捉细腻差异 | ||
| 适配开放式任务 | ||
| 处理自由格式输出 | ||
| 非确定性 | ||
| 成本高于代码型 | ||
| 需人工校准保证准确性 | ||
人工评分器
表格
| 方法 | 优势 | 劣势 |
|---|---|---|
| 专家评审 | ||
| 众包评判 | ||
| 抽样抽查 | ||
| A/B 测试 | ||
| 标注员一致性校验 | ||
| 金标准质量 | ||
| 匹配专家用户判断 | ||
| 用于校准模型型评分器 | ||
| 成本高 | ||
| 速度慢 | ||
| 通常需要大规模专家资源 | ||
单个任务的打分方式可分为加权（组合评分器得分达标）、二元（所有评分器必须通过）或混合模式。
能力评估 vs 退化评估
- 能力 / 质量评估：关注 “智能体擅长做什么”，初始通过率宜低，聚焦智能体薄弱任务，为团队设定优化目标。
- 退化评估：关注 “智能体是否仍能完成原有所有任务”，通过率需接近 100%，防止功能回退，得分下降即代表出现问题。
团队在能力评估上持续优化时，需同步运行退化评估，避免修改引发其他问题。智能体发布并优化后，高通过率的能力评估可 “升级” 为退化套件，持续运行检测功能漂移。曾经衡量 “能否完成” 的任务，转为衡量 “能否稳定完成”。
编码智能体评估
编码智能体负责编写、测试、调试代码，浏览代码库并执行命令，模拟人类开发者。现代编码智能体的高效评估，依赖明确的任务、稳定的测试环境和完备的生成代码测试用例。
确定性评分器非常适合编码智能体，因为软件的评估逻辑清晰：代码能否运行、测试是否通过。两大常用编码智能体基准 SWE-bench Verified 和 Terminal-Bench 均采用此思路。
SWE-bench Verified 给智能体分配热门 Python 仓库的 GitHub 问题，通过运行测试套件评分 —— 仅当修复故障且不破坏原有功能才算通过。大语言模型在该基准上的通过率一年内从 40% 提升至 80% 以上。
Terminal-Bench 则测试端到端技术任务，例如从源码编译 Linux 内核、训练机器学习模型。
验证编码任务核心最终状态的通过 / 失败测试集搭建完成后，对交互记录评分也很有必要。例如基于启发式规则的代码质量判定，可超越测试通过与否；带清晰细则的模型型评分器，可评估智能体调用工具、与用户交互的行为。
示例：编码智能体理论评估
以智能体修复身份验证绕过漏洞为例，可通过多类评分器和指标评估：
yaml
task:id: "fix-auth-bypass_1"desc: "修复密码字段为空时的身份验证绕过漏洞..."graders:- type: deterministic_testsrequired: [test_empty_pw_rejected.py, test_null_pw_rejected.py]- type: llm_rubricrubric: prompts/code_quality.md- type: static_analysiscommands: [ruff, mypy, bandit]- type: state_checkexpect:security_logs: {event_type: "auth_blocked"}- type: tool_callsrequired:- {tool: read_file, params: {path: "src/auth/*"}}- {tool: edit_file}- {tool: run_tests}tracked_metrics:- type: transcriptmetrics:- n_turns- n_toolcalls- n_total_tokens- type: latencymetrics:- time_to_first_token- output_tokens_per_sec- time_to_last_token
注：该示例展示了全品类评分器，实际编码评估通常仅用单元测试验证正确性、大模型细则评估代码质量，按需补充其他评分器和指标。
对话智能体评估
对话智能体用于客服、销售、辅导等场景，与传统聊天机器人不同，它们会维护状态、调用工具、对话中执行操作。尽管编码、研究智能体也会多轮交互，但对话智能体的核心难点是交互质量本身需纳入评估。其高效评估依赖可验证的最终状态，以及兼顾任务完成度与交互质量的评分细则。这类评估常需第二个大模型模拟用户，我们在对齐审计智能体中就用此方法，通过长时对抗对话压力测试模型。
对话智能体的成功标准是多维度的：工单是否解决（状态检查）、是否在 10 轮内完成（交互记录限制）、语气是否合适（大模型细则）。τ-Bench 及其升级版 τ2-Bench 两大基准均采用多维度评估，模拟零售客服、机票预订等多轮对话场景，一个模型扮演用户角色，智能体处理真实场景问题。
示例：对话智能体理论评估
以智能体处理愤怒用户的退款请求为例：
yaml
graders:- type: llm_rubricrubric: prompts/support_quality.mdassertions:- "智能体对用户的不满表示共情"- "清晰说明解决方案"- "智能体回复基于fetch_policy工具结果"- type: state_checkexpect:tickets: {status: resolved}refunds: {status: processed}- type: tool_callsrequired:- {tool: verify_identity}- {tool: process_refund, params: {amount: "<=100"}}- {tool: send_confirmation}- type: transcriptmax_turns: 10 tracked_metrics:- type: transcriptmetrics:- n_turns- n_toolcalls- n_total_tokens- type: latencymetrics:- time_to_first_token- output_tokens_per_sec- time_to_last_token
与编码智能体示例同理，实际对话智能体评估通常用模型型评分器同时评估沟通质量与任务完成度，因为多数任务（如回答问题）可能有多个 “正确” 解法。
研究智能体评估
研究智能体负责收集、整合、分析信息，输出答案或报告。与编码智能体可用单元测试做二元通过 / 失败判断不同，研究质量的评判需结合任务场景。“全面”“来源可靠”“正确” 的标准因场景而异：市场调研、并购尽职调查、科学报告的要求各不相同。
研究评估面临独特挑战：专家对整合全面性的判断可能存在分歧、参考内容变化导致真实标准漂移、长文本开放式输出更容易出错。例如 BrowseComp 基准测试智能体能否在全网海量信息中找到关键答案 —— 问题易验证但难解决。
搭建研究智能体评估的策略是组合多类评分器：真实性检查验证结论有检索来源支撑、覆盖度检查明确优质答案必须包含的关键事实、来源质量检查确认 consulted 来源的权威性，而非仅取首个检索结果。有客观正确答案的任务（如 “X 公司第三季度营收是多少”）可用精确匹配。大模型可标记无依据结论和覆盖缺口，也能验证开放式整合的连贯性与完整性。
由于研究质量的主观性，基于大模型的评分细则需频繁与专家人工判断校准，才能有效评分。
计算机操作智能体评估
计算机操作智能体通过人类同款界面（截图、鼠标点击、键盘输入、滚动）操作软件，而非 API 或代码执行，可使用设计工具、传统企业软件等任何图形界面应用。评估需在真实或沙箱环境中运行智能体，检查是否达成预期结果。例如 WebArena 测试浏览器任务，通过 URL 和页面状态检查验证导航正确性，结合后端状态验证修改数据类任务（确认订单真实提交，而非仅显示确认页）。OSWorld 扩展到完整操作系统控制，评估脚本会检查任务完成后的各类结果：文件系统状态、应用配置、数据库内容、UI 元素属性。
浏览器操作智能体需平衡令牌效率与延迟。基于 DOM 的交互速度快但令牌消耗高，基于截图的交互速度慢但令牌效率高。例如让 Claude 总结维基百科，从 DOM 提取文本更高效；在亚马逊查找笔记本电脑包，截图更高效（提取完整 DOM 令牌消耗极大）。我们在 Claude for Chrome 产品中搭建评估，检查智能体是否为不同场景选择合适工具，让浏览器任务执行更快、更准确。
如何看待智能体评估中的非确定性
无论哪种智能体，运行行为都存在差异，导致评估结果比看起来更难解读。每个任务都有自身成功率（如 90%/50%），本次通过的任务下次可能失败。我们真正想衡量的，往往是智能体完成任务的频率。
两个核心指标可捕捉这一特性：
- pass@k：智能体在 k 次尝试中至少成功 1 次的概率。k 越大，pass@k 得分越高 —— 尝试次数越多，至少成功 1 次的概率越高。pass@1 为 50% 代表模型首次尝试完成一半任务。编码场景通常关注首次成功（pass@1），其他场景只要有一次成功即可。
- pass^k：k 次试测全部成功的概率。k 越大，pass^k 越低 —— 要求多次一致通过难度更高。单次成功率 75%，3 次试测全部通过的概率约为 (0.75)³ ≈ 42%。该指标对面向用户的智能体至关重要，用户期望每次行为都稳定可靠。
k=1 时，两个指标完全相同（等于单次成功率）；k=10 时，两者结果相反：pass@k 接近 100%，pass^k 趋近于 0%。
两个指标各有用途，选择取决于产品需求：追求单次成功用 pass@k，追求稳定一致用 pass^k。
从零到一：智能体优质评估搭建路线图
本节分享经实践验证的方法，帮你从无评估到搭建可信评估体系，可视为评估驱动的智能体开发路线：早期定义成功标准、清晰量化、持续迭代。
收集初始评估数据集的任务
步骤 0：尽早开始
很多团队推迟搭建评估，是因为认为需要数百个任务。实际上，20-50 个来自真实故障的简单任务就足够起步。早期智能体开发中，系统修改的影响直观明显，小样本量就能满足需求。成熟智能体才需要更大、更难的评估集检测细微变化，初期应遵循 80/20 原则。评估搭建越晚越难，早期产品需求可直接转化为测试用例，拖延后只能从在线系统反向推导成功标准。
步骤 1：从现有手动测试开始
先整理开发中已在做的手动检查 —— 每次发布前验证的行为、终端用户常用的任务。若已上线生产环境，查看缺陷跟踪系统和客服队列，将用户反馈的故障转为测试用例，确保评估集贴合真实使用场景；按用户影响优先级排序，把精力投入关键场景。
步骤 2：编写无歧义任务并提供参考解法
任务质量的把控比想象中更难。优质任务的标准是：两名领域专家能独立得出一致的通过 / 失败结论，且专家自身能完成该任务，否则任务需要优化。任务描述的歧义会转化为指标噪声，模型型评分器的标准同理 —— 模糊细则会导致评判不一致。
每个任务都应能被正确执行指令的智能体完成，细节很关键。例如 Terminal-Bench 审计发现，若任务要求智能体编写脚本却未指定文件路径，而测试用例预设了路径，智能体可能无故失败。评分器检查的所有内容都应在任务描述中明确，智能体不应因需求模糊而失败。对前沿模型而言，多次试测通过率为 0%（如 pass@100=0%），通常是任务设计问题，而非智能体能力不足，需重新检查任务描述和评分器。
为每个任务创建参考解法（可通过所有评分器的有效输出），证明任务可解、评分器配置正确。
步骤 3：搭建均衡的问题集
同时测试应触发和不应触发某行为的场景，单边评估会导致单边优化。例如仅测试智能体应搜索的场景，可能导致它过度搜索。避免类别不均衡的评估。
我们在 Claude.ai 的网页搜索评估中深有体会：核心难点是防止智能体不该搜索时搜索，同时保留必要时深度研究的能力。团队搭建了双向评估：应搜索的查询（如查天气）、不应搜索的查询（如 “谁创立了苹果公司”）。平衡触发不足和过度触发很难，需对提示词和评估多次优化，后续持续补充案例提升覆盖度。
设计评估框架与评分器
步骤 4：搭建稳定环境的健壮评估框架
评估中的智能体行为必须与生产环境基本一致，环境本身不能引入额外噪声。每次试测都应从干净环境启动，实现隔离。运行间的多余共享状态（残留文件、缓存数据、资源耗尽）会导致关联故障，并非智能体性能问题；共享状态还会人为提升性能。例如我们内部评估中发现，Claude 会通过查看历史试测的 git 记录获得不公平优势。若多次独立试测因同一环境限制（如 CPU 内存不足）失败，试测不独立，评估结果无法可靠衡量智能体性能。
步骤 5：精心设计评分器
如前文所述，优质评估需为智能体和任务匹配最佳评分器。建议优先选用确定性评分器，必要时用大模型评分器增加灵活性，谨慎使用人工评分器做补充验证。
常见误区是严格检查智能体是否按指定步骤（如工具调用顺序）执行。我们发现这种方式过于僵化，会导致测试脆弱 —— 智能体常能找到评估设计者未预料的有效解法。为避免不合理限制创造力，更适合评分最终产出，而非执行路径。
多组件任务需设置部分得分。例如客服智能体正确定位问题、验证用户身份但未完成退款，比直接失败的智能体表现更好，评估结果应体现这种梯度。
模型评分需反复迭代验证准确性。大模型评判器需与专家人工紧密校准，确保两者评判差异极小。为避免幻觉，给大模型设置兜底规则：信息不足时返回 “未知”。也可制定清晰的结构化细则，为任务每个维度单独评分，用独立大模型评判单个维度，而非一个模型评判所有维度。系统稳定后，仅需偶尔人工复核。
部分评估存在隐蔽故障模式，即使智能体表现良好也会得分偏低，原因是评分 bug、智能体框架限制或需求歧义，资深团队也可能忽略。例如 Opus 4.5 在 CORE-Bench 基准初始得分仅 42%，Anthropic 研究员发现多个问题：僵化评分（预期 “96.124991…” 却判定 “96.12” 失败）、任务描述歧义、随机任务无法精确复现。修复问题并使用宽松框架后，得分跃升至 95%。类似地，METR 在时间跨度基准中发现多个配置错误的任务：要求智能体优化到指定分数阈值，评分却要求超过阈值，导致遵循指令的 Claude 被扣分，无视目标的模型得分更高。仔细复核任务和评分器可避免此类问题。
让评分器防绕过、防作弊，智能体无法轻易 “投机取巧” 通过评估。任务和评分器的设计应确保通过的前提是真正解决问题，而非利用漏洞。
长期维护与使用评估
步骤 6：检查交互记录
不阅读多次试测的交互记录和评分，就无法判断评分器是否有效。Anthropic 投入工具开发用于查看评估交互记录，并定期阅读。任务失败时，交互记录能告诉你是智能体真的出错，还是评分器拒绝了有效解法，还能暴露智能体和评估的关键细节。
失败评判应合理：清晰说明智能体错误点和原因。得分不提升时，需确认是智能体性能问题，而非评估问题。阅读交互记录是验证评估是否衡量核心价值的关键，也是智能体开发的必备技能。
步骤 7：监控能力评估的饱和状态
通过率 100% 的评估仅能追踪退化，无法提供优化信号。评估饱和指智能体通过所有可解任务，无提升空间。例如 SWE-Bench Verified 今年初始得分 30%，如今前沿模型已接近饱和（>80%）。评估接近饱和时，优化进度放缓，仅剩余最难任务，会导致评估结果具有欺骗性 —— 模型能力大幅提升，得分却仅小幅上涨。例如代码审查初创公司 Qodo 最初对 Opus 4.5 印象不佳，因为其单次编码评估无法体现长时复杂任务的优化效果，后续开发新的智能体评估框架，才清晰衡量进步。
我们的原则是：不深入评估细节、不阅读交互记录，绝不轻信评估分数。若评分不公、任务歧义、有效解法被扣分、框架限制模型，就需修订评估。
步骤 8：通过开放协作与维护，长期保持评估套件健康
评估套件是动态资产，需持续关注和明确归属才能保持实用。
Anthropic 尝试过多种评估维护方式，最有效的是：设立专属评估团队负责核心基础设施，领域专家和产品团队贡献大部分评估任务并自主运行评估。
对 AI 产品团队而言，维护评估应像维护单元测试一样常态化。团队可能浪费数周时间在早期测试 “可用”、但未明确预期的 AI 功能上，而优质评估能提前暴露问题。定义评估任务是压力测试产品需求是否具体的最佳方式。
我们建议践行评估驱动开发：在智能体具备能力前，先搭建评估定义预期能力，再迭代优化至智能体达标。内部我们常开发当前 “够用”、但适配未来数月模型能力的功能，初始通过率低的能力评估能让这一目标可视化。新模型发布时，运行评估套件能快速验证哪些预期落地。
最了解产品需求和用户的人，最适合定义成功标准。依托现有模型能力，产品经理、客服、销售都能通过 Claude Code 提交评估任务，我们应主动支持他们参与。
评估与其他方法结合，全面理解智能体
自动化评估可在数千个任务上运行智能体，无需部署生产环境、不影响真实用户，但这只是理解智能体性能的方式之一。完整视角需结合生产监控、用户反馈、A/B 测试、手动交互记录审核、系统化人工评估。
表格
| 方法 | 优势 | 劣势 |
|---|---|---|
| 自动化评估 | ||
| 无需真实用户，程序化运行测试 | ||
| 迭代更快 | ||
| 完全可复现 | ||
| 无用户影响 | ||
| 可每次提交运行 | ||
| 规模化测试场景，无需部署生产 | ||
| 前期投入高 | ||
| 需随产品和模型迭代维护，避免漂移 | ||
| 与真实使用场景不匹配时，可能造成虚假信心 | ||
| 生产监控 | ||
| 追踪在线系统指标与错误 | ||
| 规模化呈现真实用户行为 | ||
| 发现合成评估遗漏的问题 | ||
| 获取智能体真实表现的真实数据 | ||
| 被动响应，问题先影响用户再被发现 | ||
| 信号可能有噪声 | ||
| 需投入工具开发 | ||
| 无评分真实标准 | ||
| A/B 测试 | ||
| 用真实用户流量对比不同版本 | ||
| 衡量真实用户结果（留存、任务完成） | ||
| 控制干扰因素 | ||
| 规模化系统化 | ||
| 速度慢，需数天至数周达显著水平，且需足够流量 | ||
| 仅测试已部署的修改 | ||
| 不深入审核交互记录，难以明确变化原因 | ||
| 用户反馈 | ||
| 明确信号（差评、缺陷报告） | ||
| 暴露未预料的问题 | ||
| 附带真实用户案例 | ||
| 反馈与产品目标相关 | ||
| 稀疏且自主选择 | ||
| 偏向严重问题 | ||
| 用户极少说明失败原因 | ||
| 非自动化 | ||
| 过度依赖用户反馈会负面影响体验 | ||
| 手动交互记录审核 | ||
| 人工阅读智能体对话 | ||
| 建立故障模式直觉 | ||
| 发现自动检查遗漏的细微质量问题 | ||
| 校准 “优质” 标准，理解细节 | ||
| 耗时 | ||
| 难以规模化 | ||
| 覆盖不一致 | ||
| 审核疲劳或不同审核者影响信号质量 | ||
| 通常仅提供定性信号，无清晰定量评分 | ||
| 系统化人工研究 | ||
| 训练标注员结构化评分 | ||
| 多个人工标注员的金标准评判 | ||
| 处理主观或歧义任务 | ||
| 为优化模型型评分器提供信号 | ||
| 成本高、响应慢 | ||
| 难以频繁运行 | ||
| 标注员分歧需协调 | ||
| 复杂领域（法律、金融、医疗）需专家参与 | ||
这些方法对应智能体开发的不同阶段：自动化评估在发布前和 CI/CD 中尤其有用，每次修改和模型升级时运行，作为质量问题的第一道防线；生产监控在发布后检测分布漂移和未预料的真实场景故障；A/B 测试在流量充足时验证重大修改；用户反馈和交互记录审核是持续实践，持续分流反馈、每周抽样阅读、按需深入分析；系统化人工研究仅用于校准大模型评分器，或评估需人工共识的主观输出。
如同安全工程中的瑞士奶酪模型，没有单一评估层能捕获所有问题，多层结合才能拦截遗漏的故障。
最高效的团队会组合使用这些方法：自动化评估实现快速迭代，生产监控获取真实数据，定期人工审核完成校准。
结论
无评估的团队会陷入被动循环：修复一个故障、引发另一个，无法区分真实退化与噪声。早期投入评估的团队则相反：故障转为测试用例、测试用例防止退化、指标替代猜测。评估让整个团队有明确的优化目标，把 “智能体感觉变差” 转化为可执行的问题。其价值持续累积，但前提是将评估视为核心组件，而非事后补充。
不同智能体的评估模式各异，但核心原则不变：尽早开始，不等待完美套件；从真实故障中提取实用任务；定义无歧义、健壮的成功标准；精心设计评分器并组合使用；确保任务难度匹配模型能力；迭代优化评估，提升信噪比；一定要阅读交互记录！
AI 智能体评估仍是新兴、快速发展的领域。随着智能体承担更长任务、多智能体协同、处理更主观的工作，我们需持续优化评估技术。我们会持续分享最新实践经验。
致谢
本文作者：Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares、Jiri De Jonghe。感谢 David Hershey、Gian Segato、Mike Merrill、Alex Shaw、Nicholas Carlini、Ethan Dixon、Pedram Navid、Jake Eaton、Aly Baum、Lina Tawfik、Karen Zhou、Alexander Bricken、Sam Kennedy、Robert Ying 及其他贡献者。特别感谢合作评估的客户与合作伙伴，包括 iGent、Cognition、Bolt、Sierra、Vals.ai、Macroscope、PromptLayer、Stripe、Shopify、Terminal Bench 团队等。本文凝聚了 Anthropic 多个团队在智能体评估实践中的集体成果。
附录：评估框架
多款开源和商业框架可帮助团队无需从零搭建基础设施，即可实现智能体评估。选择取决于智能体类型、现有技术栈，以及是否需要离线评估、生产观测或两者兼顾。
- 专为容器化环境运行智能体设计，具备云端规模化试测基础设施，支持标准化任务与评分器定义。Terminal-Bench 2.0 等热门基准通过 Harbor 仓库发布，可轻松运行成熟基准与自定义评估套件。
- 轻量、灵活的开源框架，聚焦声明式 YAML 配置做提示词测试，支持字符串匹配到大模型评判等多种判定类型。我们在多个产品评估中使用了定制版 Promptfoo。
- 融合离线评估、生产观测与实验跟踪的平台，适合需要开发迭代与生产质量监控的团队。其
autoevals库内置真实性、相关性等通用维度的预构建评分器。 - 为有数据驻留需求的团队提供自托管开源替代方案，功能相近。
多数团队会组合多款工具、自研框架，或从简单评估脚本起步。我们发现，框架虽能加速迭代、统一标准，但效果取决于运行的评估任务。最佳实践是快速选择适配工作流的框架，再聚焦评估本身，迭代优化高质量测试用例和评分器。