上周，Anthropic 发布了一篇重磅技术博客《Demystifying evals for AI Agents》，系统性地阐述了如何为 AI Agent 构建评估体系。
做过 Agent 开发的同学应该深有体会：传统软件测试的那套方法论，在 Agent 面前彻底失效了。写几个单测、跑个回归的老套路行不通，因为 Agent 天生带着两个"反骨"属性：
• 非确定性：同一个输入，在不同时间、不同上下文、不同随机性采样下，可能给出完全不同的路径和结果 • 多轮交互的复杂性：Agent 不是"问一句答一句"的函数调用，而是一段会滚雪球的对话链路，前面某一步小小偏航，后面就可能变成灾难级连锁反应
这篇文章信息量巨大，是目前业界关于 Agent 评估最完整的方法论指南。我花了一整天时间研读，把核心内容掰开揉碎分享给大家。
太长不看版
• 评估的核心区分：Transcript（过程记录）vs Outcome（最终结果），Agent 说"订好了"不算数，数据库里有记录才算 • 三类评分器组合拳：代码评分器（快速、确定性）+ 模型评分器（灵活、主观任务）+ 人工评分器（校准、金标准） • 两个关键指标：pass@k（k次中至少成功1次）适合辅助工具，pass^k（k次全部成功）适合自动化系统 • 8步实施路线图：从20-50个真实失败案例起步，不要等"完美套件" • 评估驱动开发：先写评估定义能力，再迭代直到 Agent 达标
1. 为什么 Agent 评估这么难？
Anthropic 在测试最新的 Opus 4.5 模型时遇到了一个非常有意思的真实案例：
他们用 τ2-bench 基准测试，任务是"订机票"。按照预设的评估逻辑，模型必须严格遵循某条退改签政策。
但聪明的 Opus 4.5 竟然发现了政策本身的一个漏洞，它绕过了原本的限制，成功帮用户订到了票，而且方案甚至比标准答案更好！
结果 Eval 系统判它"失败"。
这个案例给了我们一个重要启示：
Agent 的能力越强，静态的评估标准就越容易失效。评估系统必须从"批改作业"进化为"观察实验"。
2. 评估的核心组件：重新定义评估体系
为了不被聪明的模型"骗"过去，也不冤枉有创造力的模型，Anthropic 重新定义了评估的核心组件。
2.1 单轮评估 vs 多轮评估 vs Agent评估
原文第一张图清晰地展示了三种评估的复杂度递进：
左侧是简单的单轮评估：Agent 处理一个 Prompt，Grader 检查输出是否符合预期。这是早期 LLM 的主流评估方式。
右侧是复杂的多轮评估：以编程 Agent 为例，它接收工具集、任务（图中是"构建一个 MCP 服务器"）和运行环境，然后执行"Agent 循环"（工具调用 + 推理），最终将代码实现更新到环境中。评分环节通过运行单元测试来验证 MCP 服务器是否正常工作。
关键区别在于：Agent 评估不仅要看最终输出，还要看整个执行过程和环境状态的变化。
2.2 评估组件的完整定义
原文第二张图展示了 Agent 评估的完整组件架构：
让我逐一拆解这些组件：
Task（任务）
不再只是一句 Prompt。在 Agent 语境下，它是一个完整的测试用例，包含：
• 明确的输入环境（比如一个虚拟的文件系统、数据库初始状态） • 严格的成功标准（不是"看起来对"，而是可验证的条件）
Trial（试验）
Agent 的输出是概率性的，一次成功可能是运气，一次失败可能是偶然。所以 Anthropic 引入了多次试验的概念——只有在大数定律下，Agent 的真实稳定性才会显露原形。
Grader（评分器）
负责打分的逻辑实体。一个任务可以有多个 Grader，每个 Grader 内部又可以包含多条断言（Assertions/Checks）。这是实现"组合拳"评估的关键。
Transcript vs Outcome —— 这是全文最核心的区分
这是大多数开发者容易混淆的地方，我必须重点强调：
• Transcript（实录/轨迹）：Agent 的完整心路历程，包含所有的思考链（CoT）、工具调用（Tool Calls）、API 返回值、中间推理结果。对于 Anthropic API，这就是评估运行结束时完整的 messages 数组。这部分用来 Debug，告诉你 Agent "想"做什么、"怎么"做的。 • Outcome（结果）：环境的最终状态。这才是真正的"交付物"。
举个例子：你的订票 Agent 可能在对话框里信誓旦旦地说"亲亲，机票订好了！"（这只是 Transcript）。但只有当你去查询后台 SQL 数据库，发现真的多了一条预订记录时，那才叫 Outcome。
Harness（框架）
• Evaluation Harness（评估框架）：端到端运行评估的基础设施。它负责提供指令和工具、并发运行任务、记录所有步骤、对输出评分、汇总结果。 • Agent Harness（智能体框架/脚手架）：把模型包装成 Agent 的系统，负责处理输入、编排工具调用、返回结果。比如 Claude Code 就是一个灵活的 Agent Harness。
关键洞察：当我们评估一个 Agent 时，评估的其实是 Model + Harness 的结合体。一个强大的模型如果配上了一个烂透了的 Scaffold（比如工具解析逻辑写得很差），它的表现依然会很拉垮。
Evaluation Suite（评估套件）
一组旨在衡量特定能力或行为的任务集合。套件中的任务通常共享一个宏大目标。比如，一个客户支持评估套件可能包含针对退款、取消订单和问题升级处理的测试。
3. 为什么要构建评估体系？
很多团队在 Agent 开发初期，凭借手动测试、内部试用（Dogfooding）和直觉，就能取得出人意料的进展。此时，更严谨的评估甚至可能被视作拖累交付速度的额外负担。
但 Anthropic 的经验是：一旦跨越了早期原型阶段，当 Agent 投入生产环境并开始规模化应用时，缺乏评估机制的开发模式便会开始分崩离析。
临界点往往出现在：用户反馈更新后体验反而下滑，而此时团队却如同盲人摸象般处于"盲飞"状态，除了猜测与试错外，别无验证之法。
在缺失评估的情况下，调试完全是被动式的：
1. 坐等用户投诉 2. 手动复现问题 3. 修复漏洞 4. 祈祷没有引发其它的性能回退
团队既无法从随机噪点中甄别出真正的性能倒退，也无法在发布前针对数百种场景自动验证变更，更无从量化改进的效果。
3.1 Claude Code 的评估演进之路
Anthropic 以自家的 Claude Code 为例，分享了评估体系的演进过程：
Claude Code 起步于基于 Anthropic 员工及外部用户反馈的快速迭代。随后，我们引入了评估机制——起初仅针对简洁度（concision）和文件编辑（file edits）等特定领域，继而扩展至针对过度设计（over-engineering）等更复杂行为的评估。
这些评估不仅协助我们识别问题、指引改进方向，更让研究与产品部门的协作有的放矢。结合生产环境监控、A/B 测试、用户研究等手段，评估体系为 Claude Code 在规模化进程中的持续精进提供了关键信号。
3.2 业界案例：Descript 和 Bolt
Descript 的 Agent 帮助用户剪辑视频，他们围绕成功剪辑流程的三个维度构建了评估：
1. 不破坏现有内容（don't break things） 2. 精准执行指令（do what I asked） 3. 高质量完成任务（do it well）
他们经历了从人工评分到 LLM 评分的进化，由产品团队制定标准并定期进行人工校准。如今，他们定期运行两套独立的测试套件，分别用于质量基准测试和回归测试。
Bolt AI 团队则是在其 Agent 已被广泛使用后，才开始构建评估体系。短短三个月内，他们便建成了一套评估系统：
• 运行 Agent 并通过静态分析对输出评分 • 利用浏览器 Agent 测试应用程序 • 启用 LLM 裁判来评估指令遵循等行为
3.3 评估的复利价值
评估体系还决定了你采纳新模型的速度：
当更强大的模型问世时，缺乏评估的团队面临的是数周的人工测试，而拥有评估体系的竞争对手则能迅速判定模型优劣，微调提示词，并在数日内完成升级。
一旦评估体系建立，你还能免费获得：
• 基线测试：延迟、Token 用量、单任务成本、错误率等指标 • 回归测试：在固定的任务库中追踪记录 • 研产协作桥梁：评估可以成为产品团队与研究团队之间最高效的沟通渠道，确立研究人员可针对性优化的具体指标
4. 三类评分器的组合拳
Agent 评估通常综合运用三种类型的评分器：基于代码的评分器、基于模型的评分器以及人工评分。每种评分器分别针对 Transcript 或 Outcome 的特定部分进行评估。
构建高效评估体系的一大要务，便是因地制宜地选择合适的评分器。
4.1 代码评分器（Code-based Graders）
适用场景：有明确对错标准的任务，如代码是否通过测试、数据库状态是否正确。
4.2 模型评分器（Model-based Graders）
适用场景：主观性强、答案不唯一的任务，如对话质量、代码风格、研究报告的完整性。
4.3 人工评分器（Human Graders）
适用场景：校准 LLM 评分器、评估高度主观的输出、建立评估的"金标准"。
4.4 评分机制的组合方式
针对每一个具体任务，评分机制的设定可以灵活多样：
• 加权制（Weighted）：各评分器得分总和需达到特定阈值 • 一票否决制（Binary）：要求所有评分器均判定通过 • 混合模式（Hybrid）：两者结合
5. 能力评估 vs 回归评估
很多团队容易混淆这两个概念，导致开发节奏一团糟。Anthropic 给出了清晰的定义：
5.1 能力评估（Capability Evals）—— 进攻战
核心问题："这个 Agent 能做到什么？"
• 挑那些 Agent 目前觉得很难、经常翻车的 Task 来考 • 初始通过率应该较低，即使只有 10%-30% 也没关系 • 这是给团队设定的"登山目标"（hill to climb）
5.2 回归评估（Regression Evals）—— 保卫战
核心问题："这个 Agent 还能做它以前做过的事吗？"
• 挑之前已经能稳定完成的任务来考 • 通过率必须接近 100% • 如果掉分了，说明新版本引入了 Bug，需要立即修复
5.3 评估的"毕业"机制
当团队致力于提升能力评估的指标时，同步运行回归评估至关重要，以确保新的变更不会引发连带问题。
待 Agent 上线并经过优化后，那些已达到高通过率的能力评估任务便可"毕业"成为回归测试集的一部分，通过持续运行来监测任何潜在的性能偏移。
原本用来衡量"我们到底能不能做？"的任务，此刻转变为衡量"我们能否持续可靠地做？"
6. 不同类型 Agent 的评估策略
Anthropic 观察到目前规模化部署的几种常见 Agent 类型：编程 Agent、研究 Agent、计算机操作 Agent 和对话式 Agent。尽管它们广泛应用于各行各业，但评估技术却大同小异。
6.1 编程 Agent 的评估
编程 Agent 能够像人类开发者一样编写、测试、调试代码，在代码库中穿梭，并执行各类命令。
确定性评分器与编程 Agent 有着天然的契合度，因为软件评估的逻辑通常非常直接：代码能否运行？测试能否通过？
业界广泛使用的两大编程 Agent 基准测试：
• SWE-bench Verified：将热门 Python 代码库中的 GitHub Issue 派发给 Agent，通过运行测试套件来评分。只有当方案既修复了原本报错的测试点，又未破坏现有功能时，才会被判定为通过。仅仅一年时间，LLM 在此项评估中的通过率已从 40% 飙升至 80% 以上。 • Terminal-Bench：侧重于测试端到端的技术任务，例如从源码构建 Linux 内核或训练机器学习模型。
关键洞察：对于代码，Outcome（结果）只是及格线，Transcript（过程）才是分水岭。
我们在 Code Review 时，不会只看代码能不能跑，还要看它写得烂不烂。需要引入"混合双打"：
• 用确定性评分器卡死功能正确性 • 用启发式代码质量规则评估代码质量 • 用 LLM 裁判评估 Agent 如何调用工具、如何与用户交互
示例：编程 Agent 的评估配置
考虑一个编程任务：Agent 需要修复一个认证绕过漏洞。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
task:
id: "fix-auth-bypass_1"
desc: "Fix authentication bypass when password field is empty..."
graders:
# 确定性测试：必须通过这两个安全测试
- type: deterministic_tests
required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]
# LLM评分细则：评估代码质量
- type: llm_rubric
rubric: prompts/code_quality.md
# 静态分析：代码规范、类型检查、安全扫描
- type: static_analysis
commands: [ruff, mypy, bandit]
# 状态检查：安全日志中必须有拦截记录
- type: state_check
expect:
security_logs: {event_type: "auth_blocked"}
# 工具调用验证：必须真的读了源码、编辑了文件、运行了测试
- type: tool_calls
required:
- {tool: read_file, params: {path: "src/auth/*"}}
- {tool: edit_file}
- {tool: run_tests}
# 追踪的指标
tracked_metrics:
- type: transcript
metrics: [n_turns, n_toolcalls, n_total_tokens]
- type: latency
metrics: [time_to_first_token, output_tokens_per_sec, time_to_last_token]
注意：上述示例旨在全面展示各类可用的评分器以作演示。在实际应用中，编程评估通常化繁为简，核心依赖于单元测试（验证正确性）和 LLM 评分细则（评估代码质量），仅在必要时才辅以其它评分器和指标。
6.2 对话式 Agent 的评估
对话式 Agent 通常活跃于客户支持、销售或辅导等领域。与传统聊天机器人不同，它们具备状态保持、工具调用以及在对话过程中执行具体操作的能力。
对话式 Agent 面临着独特的挑战：交互过程本身的质量，正是评估体系中的重要一环。
与其它大多数评估不同，此类评估往往需要引入第二个 LLM 来模拟用户。Anthropic 在对齐审计 Agent（Alignment Auditing Agents）中便采用了这一方法，通过开展长程、对抗性的对话来对模型进行压力测试。
衡量对话式 Agent 的成功是多维度的：
τ-Bench 和 τ2-Bench 是两个融合了这种多维度评估理念的基准测试，它们模拟了零售客服、机票预订等跨领域的多轮交互场景——由一个模型扮演特定用户画像（User Persona），而 Agent 则负责在这些逼真的场景中进行应对和处理。
示例：对话式 Agent 的评估配置
考虑一个客服任务：Agent 需要为一位情绪沮丧的客户处理退款事宜。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
graders:
# LLM评分细则：评估沟通质量
- type: llm_rubric
rubric: prompts/support_quality.md
assertions:
- "Agent showed empathy for customer's frustration" # 是否表达同理心
- "Resolution was clearly explained" # 解决方案是否解释清楚
- "Agent's response grounded in fetch_policy tool results" # 回复是否基于政策查询结果
# 状态检查：验证最终结果
- type: state_check
expect:
tickets: {status: resolved} # 工单已解决
refunds: {status: processed} # 退款已处理
# 工具调用验证
- type: tool_calls
required:
- {tool: verify_identity} # 必须验证身份
- {tool: process_refund, params: {amount: "<=100"}} # 退款金额不超过100
- {tool: send_confirmation} # 必须发送确认
# 实录约束
- type: transcript
max_turns: 10 # 最多10轮对话
注意：在实战中，对话式 Agent 的评估通常倚重模型级评分器，以此兼顾沟通质量与目标达成度的双重考量。这是因为许多任务（例如回答开放式问题）往往存在殊途同归的特性，即可能存在多种皆可被认定为正确的解决方案。
6.3 研究型 Agent 的评估
研究型 Agent 负责搜集、整合并分析信息，进而产出诸如答案或报告之类的成果。
研究评估面临着独特的挑战：
• 专家们对于一份综述是否详尽可能见仁见智 • 随着参考内容的不断更迭，基准事实（Ground Truth）也在动态游移 • 篇幅较长、开放性的输出内容为错误的滋生留下了更多空间
与编程 Agent 可通过单元测试获得非此即彼的二元判定信号不同，研究质量的评判具有极强的相对性。"全面"、"有据可查"甚至"正确"的定义，完全视具体任务情境而定：市场扫描、收购尽职调查与科学报告，其所需的标准大相径庭。
构建研究型 Agent 评估的策略是组合运用多种评分器：
对于拥有客观标准答案的任务（如"X公司第三季度的营收是多少？"），精确匹配最为适用。而 LLM 不仅能标记出缺乏支撑的论点和覆盖盲区，还能对开放式综述的连贯性与完整性进行校验。
关键建议：鉴于研究质量的主观属性，基于 LLM 的评分细则应当经常与人类专家的判断进行校准，以确保评估的有效性。
6.4 计算机操作 Agent 的评估
计算机操作 Agent 通过与人类相同的界面与软件交互——屏幕截图、鼠标点击、键盘输入和滚动操作——而非依赖 API 或代码执行。它们能够驾驭任何带有图形用户界面的应用程序，从设计工具到传统的企业级软件。
此类评估要求在真实或沙箱环境中运行 Agent，使其操作软件应用，并核查是否达成预期结果。
业界基准测试：
• WebArena：专注于浏览器任务测试，利用 URL 和页面状态检查来验证导航的正确性，并辅以后端状态验证来处理涉及数据修改的任务（例如确认订单已实际生成，而非仅仅显示了确认页面） • OSWorld：将这一概念扩展至全操作系统控制，其评估脚本会在任务完成后检查各类数字产物：文件系统状态、应用配置、数据库内容以及 UI 元素属性
Token 效率 vs 延迟的权衡
浏览器操作 Agent 需要在 Token 利用率与延迟之间寻求平衡：
实战经验：在 Chrome 版 Claude 的开发中，Anthropic 设计了专门的评估机制，检查 Agent 是否"选对了工具"。聪明的 Agent 应该学会"看菜下碟"：这时候该读代码省钱？还是该看截图省心？这一机制使他们能够更准、更快地完成基于浏览器的任务。
7. 如何量化 Agent 的非确定性？
无论何种类型的 Agent，其行为在不同次运行中均存在变异性，这使得评估结果的解读远比表面看起来复杂。
每个任务都有其自身的成功率——或许在某个任务上是 90%，在另一个上则是 50%——且在一次评估中通过的任务，可能在下一次中铩羽而归。
有时，我们真正想要衡量的是 Agent 在某项任务上成功的频率（即试验成功的比例）。
为了量化这种不稳定性，Anthropic 引入了两个关键指标：
7.1 pass@k —— 至少成功一次
定义：在 k 次尝试中，至少有一次成功就算赢。
随着 k 值增加，pass@k 分数也会随之上升——更多的"射门次数"带来了更高的成功几率。
50% 的 pass@1 意味着模型在首次尝试时能通过评估中一半的任务。
适用场景：
• 编程领域，我们通常最关注 Agent 能否一击即中（即 pass@1） • 在其他情境下，只要最终能奏效，提出多个方案也是可接受的 • 比如 Copilot 给你生成代码时，可能会给出 5 个方案（k=5），只要其中有 1 个是对的，你就会觉得"这工具真好用！"
7.2 pass^k —— 全部成功
定义：在 k 次尝试中，每一次都必须成功才算赢。
随着 k 值增加，pass^k 会显著下降，因为要求在更多次试验中保持一致性是一道更高的门槛。
数学示例：如果 Agent 的单次成功率为 75%，运行 3 次试验，则全部通过的概率为：
1
(0.75)³ ≈ 42%
适用场景：
• 对于那些用户期望每次行为都稳定可靠的面向客户型 Agent，这一指标尤为关键 • 比如银行客服 Agent，用户不会给你 5 次机会让你"蒙"一个对的答案。用户要求的是：周一问你是对的，周五问你还得是对的。任何一次"发疯"都会导致信任崩塌
7.3 两个指标的分化趋势
原文中有一张非常直观的图展示了这两个指标随试验次数变化的趋势：
从图中可以清晰看到：
• k=1 时：两个指标完全相同，都等于单次试验的成功率 • k=10 时：两者彻底决裂 • pass@k 可能已经爬升到接近 100%（只要试的次数多，总能对） • pass^k 可能已经跌到接近 0%（想连续 10 次不犯错？太难了）
7.4 如何选择指标？
选哪个指标，取决于 Agent 的产品形态：
8. 从零到一：8步实施路线图
这一节是 Anthropic 经过实战检验的实用建议，旨在帮助你从零开始构建值得信赖的评估体系。可以将其视为评估驱动型 Agent 开发的战略蓝图：尽早定义成功，清晰度量结果，并持续迭代优化。
Step 0：尽早开始
很多团队拖着不做 eval 的理由都一样："题不够多，做了也不准。"
但 Anthropic 说得很直白：
早期 20-50 个真实失败案例就够了。
因为早期你每改一行 prompt，效果变化都很大（effect size 大），小样本就能看出差异。越成熟的 Agent 可能越需要更大规模、更具难度的评估来检测细微的变化，但在初期，采用 80/20 法则是最佳策略。
评估体系拖得越久，构建起来就越困难。在早期，产品需求可以自然地转化为测试用例。若等待太久，你将不得不从现有系统中逆向工程出成功的标准。
Step 1：从现有的手动测试入手
不需要上来就发明题库宇宙。
• 你现在每次发版前怎么手动测的？ • 用户最常点的功能是什么？ • 线上工单里用户最常骂的是什么？
这些就是你最该先写进 eval 的任务。
如果已经上线了——更简单：去翻 bug tracker 和 support queue。把"用户报错"直接转成测试用例。按用户影响进行优先级排序，有助于将精力投入到最关键的地方。
Step 2：任务必须"无歧义"，还要配"参考答案"
确立高质量的任务比看起来要难。
一个好任务的标准不是"我觉得描述清楚了"，而是：
两个领域专家各自看一遍，能独立得出相同的通过/失败判定。
他们自己能通过这个任务吗？如果不能，任务就需要返工。
任务规范中的模糊性会转化为指标中的噪声。这一点同样适用于模型级评分器的标准：模糊的评分细则会导致不一致的判断。
Anthropic 在审计 Terminal-Bench 时发现了一个翻车点：
任务说"写个脚本"，但没说脚本存哪，grader 却默认脚本必须在某个固定路径。结果 Agent 明明写对了，也被判失败。
这类 eval 最恶心：你以为模型不行，实际上是题坏了。
强制加一条工程规矩：每个 task 都要做一个人类/脚本能跑通的参考解（Reference Solution）。它的作用不是"喂模型"，而是证明：
• 这题确实可解 • graders 确实配对了 • harness 没在暗算你
关键洞察：对于前沿模型而言，多次试验中 0% 的通过率（即 pass@100 为 0%）通常是任务本身存在缺陷的信号，而非 Agent 能力不足，这提示你需要反复核查任务规范和评分器。
Step 3：题集要平衡
很多团队的 eval 都有一种"单边性"：只测该做的，不测不该做的。
后果就是：你把 Agent 优化成一个偏执狂。
Anthropic 在 Claude 的 web search 上就吃过亏：
如果你只测"该搜的时候会不会搜"，你很快会得到一个"啥都搜"的模型——成本爆炸、延迟爆炸、还更容易引垃圾信源。
所以他们把题集做成两边都覆盖：
• "查天气"—— 该搜 • "苹果公司谁创立的"—— 别搜，直接答
目标就是卡住两种失败：
• Undertriggering（触发不足）：该搜不搜 • Overtriggering（过度触发）：不该搜乱搜
在这两者之间取得适当的平衡十分困难，需要对提示词和评估本身进行多轮优化。随着更多示例问题的出现，持续扩充评估集以提高覆盖率。
尽量避免**类别不平衡（Class-imbalanced）**的评估。
Step 4：评估环境必须稳定
环境脏一次，你的指标就全是幻觉。
评估中的 Agent 必须与生产环境中的 Agent 功能大致相同，且环境本身不应引入额外的噪声。
每次试验都应从一个干净的环境开始，以实现隔离。 运行之间不必要的共享状态可能会导致因基础设施不稳定性而非 Agent 性能引起的关联性故障：
• 遗留文件 • 缓存数据 • 资源耗尽导致的 flaky
共享状态还可能人为地夸大性能。
Anthropic 遇到过的真实案例：
在一些内部评估中，我们观察到 Claude 在某些任务上分数高得离谱，最后发现它翻了上一次试验的 git history，相当于提前看答案。
如果多个不同的试验因环境中的同一限制（如 CPU 内存受限）而失败，这些试验就不再是独立的，因为它们受同一因素影响，导致评估结果无法可靠地衡量 Agent 性能。
Step 5：评分器要"想清楚"
很多人第一反应是："我检查它是不是按顺序调用了 A→B→C 工具就行。"
Anthropic 的结论是：太死板，测试会非常脆。
因为强模型总能找到你没想到但完全合法的路径。为了不必要地惩罚创造力，通常最好是对 Agent 的产出评分，而不是对其路径评分。
设计评分器的建议：
1. 能用确定性 grader 就用确定性 2. LLM grader 用在"必须主观"的地方，或为了增加灵活性 3. 人工评分器只做校准，审慎使用 4. 给多组件任务做部分得分（Partial Credit）
比如客服 Agent 能定位问题 + 验证身份，但退款没点成功。这也比一上来就发疯强多了。你得让指标能表达这种"差一点点就成了"的连续性。
让 LLM 裁判不胡判的技巧：
• 用人类专家去校准分歧，确保人类评分与模型评分之间的偏差极小 • 设定"逃生门"，指示 LLM 在信息不足时返回 Unknown，避免幻觉 • 创建清晰的、结构化的评分细则，按维度拆开单独判，而不是用一个 LLM 把所有维度一锅端 • 一旦系统变得稳健，只需偶尔进行人工审查即可
警惕隐蔽的故障模式：
有些评估存在隐蔽的故障模式，即使 Agent 表现良好，得分却很低，这是因为 Agent 因评分漏洞、框架限制或模糊性而未能完成任务。即便是成熟的团队也会忽略这些问题。
Anthropic 的真实案例：
Opus 4.5 最初在 CORE-Bench 上的得分仅为 42%，直到一位 Anthropic 的研究员发现了多个问题：
• 僵化的评分惩罚了"96.12"而期望的是"96.124991..."（浮点数精度问题） • 模糊的任务规范 • 无法精确复现的随机性任务 在修复漏洞并使用限制较少的框架后，Opus 4.5 的得分跃升至 95%。
类似地，METR 发现在其时间跨度基准测试中有几个配置错误的任务，要求 Agent 优化到规定的分数阈值，但评分却要求超过该阈值。这惩罚了像 Claude 这样遵循指令的模型，而忽略既定目标的其他模型却获得了更高的分数。
最后，让你的评分器能够抵御绕过或黑客攻击。 Agent 不应轻易作弊通过评估。任务和评分器的设计应确保通过测试真正需要解决问题，而不是利用意外的漏洞。
Step 6：一定要读 Transcripts
你不读 transcripts，你就会陷入一种很蠢的循环：
• 这版分低了，是不是模型退化？ • 这版分高了，是不是我们优化成功？
结果真相可能是：grader bug 了、题目歧义了、harness 卡死了模型，或者它给了一个有效解被你误判失败。
在 Anthropic，我们投资开发了查看评估记录的工具，并定期花时间阅读它们。
当任务失败时，记录会告诉你这是 Agent 真正的错误，还是评分器拒绝了一个有效的解决方案。它还经常揭示有关 Agent 和评估行为的关键细节。
失败应当显得公平：清楚 Agent 哪里做错了以及原因。当分数没有上升时，我们需要确信这是由于 Agent 性能而非评估本身的问题。
阅读 transcripts 是你验证评估是否在衡量真正重要事项的手段，也是 Agent 开发的一项关键技能。
Step 7：监控能力评估的饱和度
当你的 eval 到了 100%，它确实还能抓回归，但已经没法衡量进步了。
评估饱和（Eval Saturation） 发生在一个 Agent 通过了所有可解任务，不再有改进空间的时候。
例如，SWE-Bench Verified 的分数今年开始时为 30%，而前沿模型现在已接近饱和，超过 80%。随着评估接近饱和，进展也会放缓，因为只剩下最困难的任务。
这可能使结果具有欺骗性：巨大的能力提升在分数上仅表现为微小的增长。
业界案例：
代码审查初创公司 Qodo 最初对 Opus 4.5 印象不深，因为他们的单次编码评估（one-shot coding eval）未能捕捉到其在更长、更复杂任务上的收益。作为回应，他们开发了一个新的 agentic 评估框架，提供了更清晰的进展图景。
作为一项规则：在有人深入研究评估细节并阅读部分 transcripts 之前，我们不会按字面意思接受评估分数。如果评分不公、任务模糊、有效方案被惩罚，或框架限制了模型，则应修改评估。
Step 8：评估套件要有人维护
评估套件是一个活物（Living Artifact），需要持续的关注和明确的所有权才能保持即用性。
Anthropic 试下来最有效的组织方式是：
• 专门的 eval 团队负责核心基础设施（harness/工具链/跑分平台） • 领域专家 + 产品团队贡献大部分评估任务，并自己运行评估
对于 AI 产品团队而言，拥有并迭代评估应像维护单元测试一样成为常规。团队可能会在 AI 功能上浪费数周时间，这些功能在早期测试中看似有效，但未能满足那些设计良好的评估本可以尽早揭示的潜在期望。
定义评估任务是对产品需求是否具体到可以开始构建的最佳压力测试之一。
Anthropic 推荐实践"评估驱动开发"：
在 Agent 具备能力之前构建评估来定义计划中的能力，然后迭代直到 Agent 表现良好。
在内部，我们经常构建目前"足够好"的功能，但这些功能是对模型在几个月后能力的押注。以低通过率开始的能力评估使这一点变得可见。当新模型发布时，运行套件可以迅速揭示哪些押注获得了回报。
最接近用户的人最会定义成功。 产品经理、客服、销售……反而能写出最贴近真实需求的 task。凭借目前的模型能力，他们甚至可以使用 Claude Code 作为 PR 贡献评估任务——让他们参与进来！或者更好的是，积极赋能他们。
原文中有一张图展示了创建有效评估的完整流程：
9. 评估如何与其他方法配合？构建全景认知
自动化评估可以在不触及生产环境或干扰真实用户的前提下，针对 Agent 执行数千项任务测试。然而，这仅是洞察 Agent 性能的众多维度之一。
若要拼凑出一幅完整的全景图，还需囊括：生产监控、用户反馈、A/B 测试、人工对话记录审查以及系统化的人类评估。
9.1 各种方法的优劣对比
| 自动化评估 | ||
| 生产监控 | ||
| A/B 测试 | ||
| 用户反馈 | ||
| 人工记录审查 | ||
| 系统性人工研究 |
9.2 不同方法对应的开发阶段
这些方法精准对应着 Agent 开发生命周期的不同阶段：
| 发布前 / CI/CD | ||
| 上线后 | ||
| 流量充足时 | ||
| 持续进行 | ||
| 校准时 |
9.3 瑞士奶酪模型
原文中引用了安全工程领域经典的瑞士奶酪模型（Swiss Cheese Model）：
这张图的核心洞察是：没有任何单一的评估层级能够拦截所有隐患。
就像瑞士奶酪的每一片都有孔洞，但当多片奶酪叠加在一起时，一片的孔洞会被另一片覆盖。同样，通过多种评估方法的有机结合，那些侥幸穿透某一防御层的故障，终将被后续层级所捕获。
最高效的团队往往能将这些方法融会贯通：
• 利用自动化评估实现快速迭代 • 借助生产监控确立事实基准 • 依靠周期性人工审查进行校准
10. 附录：评估框架概览
市面上已有若干开源与商业框架，能助力团队落地 Agent 评估，使其免于从零构建基础设施的繁重工作。至于选择何种工具，则取决于 Agent 的类型、现有技术栈，以及团队是对离线评估、生产环境可观测性还是两者兼有需求。
| Harbor | ||
| Promptfoo | ||
| Braintrust | ||
| LangSmith | ||
| Langfuse |
Anthropic 的建议：
许多团队会采取组合拳策略，混合使用多种工具，或者自研评估框架，亦或是仅以简单的评估脚本作为起步。
我们发现，尽管框架在加速研发与推行标准化方面价值不菲，但其成效最终仍取决于你在其中运行的评估任务的质量。
通常最佳的策略是：迅速选定一个契合现有工作流的框架，随后将主要精力倾注于评估本身，持续打磨并迭代高质量的测试用例与评分器。
大白话总结
用一个比喻来说：
传统软件测试像是考试批改作业——有标准答案，对就是对，错就是错。
Agent 评估更像是观察一个实习生的工作表现——你不能只看他最后交的报告（Outcome），还要看他的工作过程（Transcript）、思考方式、遇到问题怎么解决。而且同一个任务，他今天做得好，明天可能就翻车了（非确定性）。更麻烦的是，有时候他用了一个你没想到的方法把事情办成了，你还得判断这算不算"对"。
所以 Anthropic 的核心建议是：
1. 别等完美：20-50 个真实失败案例就够起步 2. 看过程也看结果：Transcript 和 Outcome 都要评估 3. 组合拳：代码评分器 + 模型评分器 + 人工校准 4. 读日志：不读 transcripts 就是盲飞 5. 平衡题集：既测该做的，也测不该做的 6. 持续迭代：评估套件是活物，需要持续维护 7. 多层防护：像瑞士奶酪一样，多种方法叠加才能堵住所有漏洞
