第18章：Agent 评估体系（Evaluation）—— 你怎么知道它变好了？

Anthropic 在 2026 年 1 月的工程文章中复盘 Claude Code 的评估实践时提到：让 Agent 可靠变好的关键，不只是换上更强的模型，而是把 eval 建成可以持续迭代的工程系统——从针对文件编辑的窄 eval，到针对简洁性、过度工程化等复杂行为的 eval。有了这些，"Agent 感觉变差了"这句话才从抱怨变成了可以调试的信号。[1]

上一章讲可观测性——知道 Agent 在第 6 步干了什么。这一章讲评估——知道它干的那件事究竟算不算做对了。两者不可替代。可观测性是事后复盘，评估是持续验证。

没有评估，你只有直觉。有了评估，你有了能爬的山。

18.1 为什么 Agent 评估比传统测试难得多

核心直觉

传统软件测试有一个前提：给定输入 X，正确输出是 Y。能验证这一点就算测试通过。Agent 打破了这个前提——同一个任务可以有无数条合法路径，执行结果具有随机性，而且"结果"不一定是 Agent 说了什么，而是它对外部世界做了什么。

三重不确定性

Agent 评估面临三重不确定性，叠加在一起让问题变得非线性地困难：

路径不确定性：Agent A 用 6 步解决了问题，Agent B 用 3 步。你无法事先知道哪条路径会被选择，也无法用"步骤序列完全匹配"来判定对错。

输出不确定性：同一个任务运行两遍，在相同环境下，Agent 可能产生两个语义等价但格式不同的输出。简单的字符串匹配会给出错误的判定。

涌现行为：Anthropic 团队在评估 Opus 4.5 时遇到了一个典型案例——一道航班预订题，Agent "失败"了，但实际上它发现了订票系统的一个政策漏洞，给了用户更优的方案。[1] 比预期答案更好，但会被 eval 判 0 分。

传统测试 vs Agent 评估

维度	传统软件测试	Agent 评估
正确性判断	输出精确匹配	语义正确 + 环境状态验证
路径约束	执行路径固定	路径多样，只要结果合法就算通过
随机性	确定性输出	同一任务多次运行结果可能不同
执行粒度	函数/方法级	多轮工具调用 + 状态变迁链
环境	Mock 即可	通常需要真实或沙箱环境
故障归因	代码层面清晰	模型 / prompt / 工具 / 上下文难以区分

这些挑战不是无解的，但它们决定了你必须用不同的思路来设计 Agent 的评估体系。

18.2 评估结构：从任务到 Transcript

Anthropic 的评估框架给出了一套清晰的基本术语，这里直接用，因为它已经被工程实践验证过。[1]

核心概念

Task（任务）：一次测试的完整定义——输入是什么、成功标准是什么。每个 Task 应该无歧义，两个领域专家拿到同一个 Task 后，应该能独立得出相同的通过/失败判定。

Trial（试验）：对一个 Task 的一次执行。由于 Agent 输出具有随机性，通常需要对同一 Task 跑多次 Trial 来降低方差。

Grader（评分器）：执行评分逻辑的组件。一个 Task 可以有多个 Grader，每个 Grader 检查不同维度。

Transcript（执行记录）：一次 Trial 的完整记录，包括所有 API 调用、工具调用参数与返回值、LLM 推理输出、中间状态变化。这是诊断问题最重要的数据来源。

Outcome（结果）：Trial 结束时外部环境的实际状态。这个和 Transcript 的区别很关键——Agent 可以在 Transcript 里说"我已经完成了预订"，但 Outcome 是数据库里有没有出现一条新的订单记录。评估的是 Outcome，不是 Agent 的声明。

Evaluation Harness（评估脚手架）：运行 eval 的基础设施，负责并发执行多个 Task、记录所有步骤、调用 Grader、汇总结果。

这套术语的价值在于：它强迫你在写 eval 之前就想清楚"成功是什么"。"回答得比较好"不是成功标准，"订单状态变为 confirmed 且确认邮件被发出"才是。

单轮 vs 多轮评估

Single-turn eval：一个输入，一次响应。这是 LLM 时代最常见的评估形式，比如给模型一道数学题让它解答。对于 Agent，这只适用于最简单的场景——单次工具调用、意图识别、参数提取等。

Multi-turn eval：Agent 接收任务后，经过多轮工具调用和状态更新，最终完成或放弃任务。这才是 Agent 评估的主战场。评估多轮 eval 时，错误会在每一步传播和放大——第 3 步工具返回了脏数据，可能在第 8 步变成一个看似合理但完全错误的最终输出。

Capability Eval vs Regression Eval

评估还可以按目标分成两类，这个区分直接决定你怎么选题、怎么设阈值、怎么接入发布流程。

Capability Eval（能力评估）：回答"这个 Agent 现在能做到什么程度？"它的任务应该足够有挑战，起始分低并不可怕，甚至是好事——说明这个 eval 还能区分能力差距。Capability Eval 适合用来比较模型、prompt、工具设计和架构方案，帮助团队找到下一座要爬的山。

Regression Eval（回归评估）：回答"已经承诺能做好的事情有没有退化？"它的任务来自真实失败案例、核心用户路径和高风险场景，起始通过率应该较高，并且接入 CI/CD 或发布门禁。Regression Eval 的价值不是证明 Agent 很聪明，而是防止它把昨天已经修好的问题重新犯一遍。

同一个 Task 可以先作为 Capability Eval 出现，等系统稳定通过后，再进入 Regression Eval 套件。评估集不是静态题库，而是随着产品能力成熟不断迁移和分层的资产。

18.3 Grader 设计：三类评分器的选择逻辑

Grader 的选择是 eval 设计最核心的决策。每类 Grader 有不同的强项和局限，没有放之四海而皆准的选择。

Code-based Grader（代码评分器）

用确定性代码来验证结果，是所有 Grader 里最快、最便宜、最稳定的。

适合的场景：

数据库里是否存在一条特定记录
文件是否被正确创建 / 修改
代码是否通过了单元测试
工具是否被调用过（以及参数是否合规）
输出格式是否满足 JSON Schema

典型实现：

python

def grader_booking_created(outcome: dict, expected: dict) -> bool:
    """检查预订是否成功写入数据库"""
    reservation = outcome["database"]["reservations"].get(
        expected["reservation_id"]
    )
    if reservation is None:
        return False
    return (
        reservation["status"] == "confirmed"
        and reservation["user_id"] == expected["user_id"]
        and reservation["flight_id"] == expected["flight_id"]
    )

代码 Grader 的常见陷阱：过度约束路径。如果 Grader 检查的是"Agent 必须先调用 search_flights 再调用 book_flight"，那你实际上测的是步骤顺序，而不是结果。Anthropic 的经验是：评估 Agent 产出了什么，而不是它走了哪条路。[1]

Model-based Grader（模型评分器）

用一个 LLM 来判断另一个 LLM 的输出是否合格，即 LLM-as-Judge。适合：

代码质量、文档质量等难以用正则衡量的标准
多维度的对话质量（语气是否恰当、信息是否完整）
需要语义理解的内容核查

关键是：Model Grader 需要精心校准，否则它自己就是一个需要评估的系统。

设计 Model Grader 的实践原则：

给出逃跑出口。当 LLM 判断不确定时，允许它返回"Unknown"，而不是强迫它在 pass/fail 之间二选一。强迫二选一会引入伪精确性。

拆分维度。不要用一个 Grader 同时评估"任务完成度"+"交互质量"+"安全性"——这三件事用三个独立的 Grader 分别评，每个 Grader 只有一个关注点，结果更可靠。

用参考答案校准。对 Model Grader 的评分进行人工抽检，计算模型判定与人类判定的一致率。不要把某个 Cohen's κ 阈值当成通用门槛：Eugene Yan 的研究综述显示，LLM-as-Judge 在不同任务上的一致性差异很大，有些事实核查任务能接近专家判断，有些主观或复杂任务则明显不稳定。[2] 更稳妥的做法是为自己的任务建立人工标注校准集，同时报告 Cohen's κ、precision / recall、混淆矩阵，并特别关注"坏输出被误判为好"的召回率。

小心偏见。已有文献记录的 LLM 评分偏见包括：位置偏见（偏好出现在前面的答案）、长度偏见（偏好更长的输出）、自我强化偏见（模型偏好自己风格的输出）。[2]

python

def model_grader_code_quality(transcript: str, code_output: str) -> dict:
    prompt = f"""你是一名高级工程师，请评估以下代码的质量。
    
代码：
{code_output}

评估维度（每项独立打分 1-5）：
1. 可读性：命名清晰、注释合理、结构清晰
2. 健壮性：错误处理、边界检查、类型安全
3. 效率：算法复杂度、不必要的计算、资源使用

对每个维度给出分数和简短理由。
如果信息不足以评估某个维度，返回 Unknown。"""
    
    response = llm.complete(prompt)
    return parse_rubric_response(response)

Human Grader（人工评分）

金标准，但昂贵且慢。人工评分最适合：

校准 Model Grader（上线前用人工标注一批样本，验证模型判定的准确率）
处理高度主观或领域专业的任务（法律合规、医疗建议）
周期性的质量抽检（生产环境中每周采样 50-100 个 Transcript 人工审查）

不建议把人工评分作为 CI/CD 的门禁——太慢，不可扩展。

混合策略

实践中最常见的做法是三者组合：

代码 Grader → 确定性验证（状态检查、格式验证、必要工具调用）
  +
Model Grader → 语义验证（内容质量、行为合规）
  +
Human Grader → 周期性校准 + 高风险任务验收

评分聚合：硬门槛、部分得分和防绕过

多个 Grader 不是简单平均一下就完事。一个好的 eval 通常会把评分拆成三层：

硬性门槛（hard fail）：只要触发就直接失败，比如越权访问、写错生产数据、绕过安全校验、输出包含禁止内容。安全和权限类问题不应该被"语气很好"或"格式正确"抵消。

必要条件（required checks）：任务真正完成所必须满足的状态，例如订单已创建、退款金额正确、测试套件通过。这些条件决定 pass/fail。

部分得分（partial credit）：用于衡量能力差距，例如找到了正确文件但补丁没完全修好、覆盖了 4 个关键事实中的 3 个、用了合理工具但多绕了几步。部分得分对 Capability Eval 尤其重要，因为它能告诉你系统正在向哪里进步，而不是只给一个冰冷的 0 分。

还要专门设计防绕过检查。Agent 会学会 eval 的边界：它可能修改测试、伪造日志、写死期望输出，或者在 Transcript 里声称完成但没有改变真实状态。防绕过的思路包括：把测试与答案分离、用隐藏用例复验、检查环境最终状态、审查关键 Transcript、限制 Agent 访问 eval 元数据。

一个典型的 Coding Agent eval 任务可能同时运行：

test_suite_passes（代码 Grader）：生成的代码能通过所有单元测试
static_analysis_clean（代码 Grader）：lint / type check / security scan 通过
code_quality_rubric（Model Grader）：LLM 评估代码的可读性和健壮性
n_turns / total_tokens（指标）：效率跟踪

18.4 关键指标：pass@k 和 pass^k

Agent 输出有随机性，这让"这个 Task 到底通过了没有"这个问题复杂起来。同一个 Task 运行一次通过，不能说明 Agent 稳定；运行十次全部通过，说明另一件事。

pass@k：在 k 次尝试中，至少有一次成功的概率。k 越大，pass@k 越高。

$$\text{pass@k} = 1 - \prod_{i=1}^{k}(1 - p_i)$$

适用场景：工具型 Agent、代码生成 Agent——只要能找到一个正确答案就够了，用户不在意它失败了几次。pass@1 是最常用的，意义是"第一次就成功的概率"。

在代码生成评估里，如果对同一个 Task 采样 n 个候选，其中 c 个通过，常见的经验估计写法是：

$$\widehat{\text{pass@k}} = 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}}$$

当 $n-c < k$ 时，分子视为 0。这个估计比"直接跑 k 次看有没有成功"更稳定，但前提是你真的保存了 n 个独立采样候选。

pass^k：k 次尝试全部成功的概率。k 越大，pass^k 越低。

$$\text{pass}^{\wedge} k = p^k$$（假设每次独立，p 为单次成功率）

适用场景：对外服务的 Agent、高可靠性场景——每次执行都必须成功，用户没有重试机会。一个每次成功率 75% 的 Agent，在 pass^3 下的通过率只有 $0.75^3 \approx 42%$。

这里的独立性假设非常强。真实 Agent 的多次 Trial 往往相关：同一个 prompt、同一个模型、同一个工具缺陷，会让错误重复出现。所以在正式报告里，不要只写一个 pass@k 或 pass^k 数字，还要写清楚：

每个 Task 跑了多少次 Trial
temperature、top_p、模型版本、工具版本是否固定
失败是否按 Task 做 macro-average，还是按所有 Trial 做 micro-average
是否给出置信区间或历史波动范围
重试策略是否和线上产品一致

两个指标在 k=1 时相等（都等于单次成功率），但随着 k 增大，pass@k 趋向 100%，pass^k 趋向 0%。它们描述的是 Agent 能力的两个不同侧面：上限 vs 一致性。

选择哪个指标，取决于你的产品要求：

给开发者用的代码补全工具：pass@1 或 pass@3 更重要
自动化企业流程的 Agent（发邮件、提交工单）：pass^k 更关键，因为每次失败都有业务代价

18.5 不同类型 Agent 的评估策略

Coding Agent

Coding Agent 是目前评估基础设施最成熟的类型，原因很简单：代码可以运行，运行结果是确定性的。

主力评分器：代码执行。单元测试通过了就是通过了。SWE-bench Verified 和 Terminal-Bench 都遵循这个原则——给 Agent 一个 GitHub Issue 或技术任务，通过运行测试套件来验证解法。[1]

辅助评分器：静态分析（lint、type check、security scan）+ Model Grader（代码可读性、是否过度工程化）。

关键注意点：不要只测"能不能过测试"，还要评估 Transcript。一个 Agent 可能暴力绕过了测试而不是真正修复了 bug——某些暴力方案能通过现有测试但会引入新问题。Anthropic 给过一个很有说服力的例子：在安全漏洞修复任务中，eval 设计需要同时检查测试通过 + 安全日志里出现 auth_blocked 事件，否则 Agent 可能用禁用鉴权的方式"修复"了这个报错。[1]

yaml

# Coding Agent eval 示例任务结构
task:
  id: "fix-auth-bypass-001"
  description: "修复认证绕过漏洞：当密码字段为空时系统未拒绝登录"
  graders:
    - type: unit_tests
      required: [test_empty_password_rejected.py, test_null_password_rejected.py]
    - type: static_analysis
      tools: [ruff, mypy, bandit]
    - type: state_check
      expect:
        security_logs:
          event_type: "auth_blocked"
    - type: llm_rubric
      rubric: "评估代码修复是否有针对性，是否避免了过度修改"
  tracked_metrics:
    - n_turns
    - n_tool_calls
    - total_tokens
    - time_to_complete

对话 Agent（客服、销售、辅导类）

对话 Agent 的挑战在于：交互质量本身就是评估的一部分。不只是"任务完成了没有"，还包括"过程体验好不好"。

成功标准是多维的：工单是否被解决（状态检查）+ 在 10 轮内完成（Transcript 约束）+ 语气是否恰当（Model Grader）。这三个维度同样重要，不能只看最终状态。

通常需要用户模拟（User Simulator）：另一个 LLM 扮演用户，驱动多轮对话。τ-bench 和 τ2-bench 基准就是这么做的——一个模型模拟用户 persona，被测 Agent 负责完成真实场景任务。[1]

yaml

# 对话 Agent eval 示例
graders:
  - type: llm_rubric
    assertions:
      - "Agent 对客户的沮丧情绪表达了同理心"
      - "退款金额基于 fetch_policy 工具的返回结果"
      - "解决方案说明清晰，客户能理解下一步"
  - type: state_check
    expect:
      tickets: {status: resolved}
      refunds: {status: processed, amount_matches_policy: true}
  - type: tool_calls
    required:
      - {tool: verify_identity}
      - {tool: fetch_policy}
      - {tool: process_refund}
  - type: transcript_constraint
    max_turns: 10

Research Agent（调研报告、信息收集类）

Research Agent 的评估最难标准化，因为"全面"和"准确"在不同任务下含义不同。

三类检查组合：

Groundedness：输出中的每一个关键声明，是否都能被检索到的来源支撑
Coverage：任务要求覆盖的关键事实，有没有遗漏
Source Quality：检索到的来源是否权威（官方文档、同行评审论文 vs 论坛帖子）

BrowseComp 基准测试用了一个聪明的设计来评估 Research Agent：选择"容易验证、但难以找到"的问题——需要多跳检索的事实，而不是常识或 Google 第一条就能找到的信息。[1]

Model Grader 的校准尤为重要：Research Agent 输出的质量高度依赖领域，模型判定需要频繁与领域专家的判定进行对比校准。

Computer Use Agent（操作 GUI 的 Agent）

Computer Use Agent 需要在真实或沙箱环境中实际操作应用，评估方式与其他类型最不一样。

评估方式：通过检查环境状态（数据库记录、文件内容、DOM 元素属性、应用配置）来验证任务结果，而不是只看截图或 Agent 的文字描述。WebArena 用 URL 和页面状态检查来验证导航是否正确；OSWorld 在 Agent 完成任务后，用专门的脚本检查文件系统状态和应用配置。[1]

重要细节：不要只验证"确认页面出现了"——要验证后端数据库里真的有那条记录。前者是 Agent 的声明，后者是 Outcome。

18.6 Eval-Driven Development：评估驱动开发

这是评估体系最容易被误解的地方：很多团队认为评估是一个在系统建好之后才做的事。Anthropic 的经验和社区实践都指向相反的结论——越早建评估，收益越大，维护成本越低。[1]

从 0 到 1 的路线图

第 0 步：不要等到有完美的测试集

20-50 个真实失败案例就够了。早期的 Agent 每次改动影响明显，小样本就能检测到大效应。等到系统成熟了再建评估，你会发现你在从一个运行中的系统倒推成功标准——比从头建困难得多。

Rechat 的 AI 助手 Lucy 就是一个典型案例：系统上线后陷入了"打地鼠"困境——修好一个问题，冒出另一个——直到他们建立了系统性的评估体系，才真正走出了这个循环。[3]

第 1 步：从你已经手动测的东西开始

把你每次发布前手动验证的行为、用户反馈里频繁出现的失败模式，转化成 Task。这些东西你已经知道它们重要，不需要从头推导。

第 2 步：写无歧义的任务，带上参考答案

衡量标准：两个领域专家独立判断，结论是否一致？如果不一致，Task 需要改。给每个 Task 写一个参考解法，验证 Grader 能正确判定它通过——这是检验 Grader 没有 bug 的最快方法。

第 3 步：注意正反例的平衡

Anthropic 在为 Claude.ai 的网络搜索功能构建 eval 时，花了很长时间才找到正确的平衡：既要有"模型应该搜索"的查询（找天气），也要有"模型不应该搜索"的查询（回答谁创建了苹果公司）。只测一个方向会导致单向优化——Agent 学会了什么时候搜索，但不知道什么时候不该搜。[1]

第 4 步：隔离环境，防止状态污染

每次 Trial 都应该从干净的环境开始。Anthropic 曾经遇到过 Claude 通过检查 git 历史从前一个 Trial 获取信息的情况——这让 eval 结果虚高，没有意义。[1]

第 5 步：阅读 Transcript

这一条听起来很简单，但被忽视的频率惊人。Grader 的分数是 eval 的汇总，Transcript 是真相本身。如果 Agent 失败，Transcript 告诉你它错在哪里；如果 Grader 给了高分但你觉得答案不对，Transcript 告诉你 Grader 在哪里被绕过了。

Anthropic 在 CORE-Bench 上做评估时，初始分数是 42%，一个研究员读了 Transcript 之后发现了三类问题：僵化的 Grader 把"96.12"判为错误（期望值是"96.124991…"）、任务描述存在歧义、以及随机性任务无法精确复现。修复这些问题后，同一个 Agent 的分数跳到了 95%。[1] eval 的分数不是 Agent 能力的直接反映——它是 Agent + Grader + 任务设计三者共同的输出。

评估集治理

一套 eval 能长期有用，靠的不只是写出第一批 Task，还要把它当成需要治理的数据资产。

版本化：Task、Grader、工具环境、模型配置、系统 prompt 都要有版本。否则一次分数变化可能来自 Agent 变强，也可能只是 Grader 改了或测试数据变了。

分层维护：把任务按来源和风险分层，例如 smoke eval、核心回归 eval、长尾失败 eval、能力挑战 eval、高风险安全 eval。不同层的运行频率和阻断阈值不同。

防污染：Agent 不应该能读取标准答案、隐藏测试、上一轮 Trial 的残留状态或 eval 元数据。每次 Trial 都要从干净环境开始，必要时使用一次性数据库、临时目录和隔离凭证。

定期淘汰：过时任务会制造噪声。产品逻辑变了、政策变了、外部 API 变了，Task 和 Grader 都需要同步更新。成熟系统应该保留变更记录，而不是默默改掉历史样本。

失败样本入库：线上事故、人工审查发现的问题、A/B 测试暴露的退化，都应该有一条路径进入 Regression Eval。没有这个入口，eval 套件会逐渐和真实用户问题脱节。

Eval-Driven Development 的工程闭环

这个闭环的核心是：失败变成测试用例，测试用例防止回归，发布被测试用例门控。没有这个闭环，每次修复都是赌博——你不知道它在修好这个问题的同时有没有破坏别的东西。

18.7 传统测试策略在 Agent 中的位置

eval 和传统测试不是替代关系，而是分层关系。Agent 的测试体系分四层，越靠下越快越便宜，越靠上越慢越接近真实。

单元测试（Unit Tests）

对 Agent 的确定性组件进行测试：工具参数解析、路由逻辑、权限校验、输入格式验证。关键是 mock LLM 和 mock 工具——把 LLM 输出固定下来，让非随机的逻辑变得可确定性验证。

python

# 测试路由逻辑，LLM 输出被 mock 固定
def test_intent_router_routes_billing_to_billing_agent():
    mock_llm = MockLLM(response={"intent": "billing_inquiry"})
    router = IntentRouter(llm=mock_llm)
    
    result = router.route("我的账单为什么涨了？")
    
    assert result.target_agent == "billing_agent"
    assert result.confidence > 0.9

单元测试运行时间应该在秒级，可以在每次代码提交时触发。

集成测试（Integration Tests）

真实工具 + 沙箱数据 + 固定测试数据集。不 mock LLM，但使用隔离的测试环境。验证：

工具调用在真实连接下的行为
Agent 状态在工具失败时如何处理
错误传播和重试逻辑

运行时间通常在分钟级，可以在 PR 阶段触发关键子集，或者每日定时运行完整集合。

E2E 测试（End-to-End Tests）

从用户任务到最终环境状态的完整路径。包括长任务、Human-in-the-Loop 节点、失败恢复。这是最接近真实使用的测试，也是最慢的。通常只在发布前或重大变更时运行。

CI/CD 中的 eval 门禁

把 Regression Eval 集成到 CI/CD 流水线里，是让"评估驱动开发"真正落地的基础设施动作。做法：

维护一个核心 Task 集（50-200 个），专门用于回归检测，通过率目标是 95%+
PR 阶段运行轻量 smoke eval 和核心回归子集，尽早发现明显退化
merge queue、nightly 或 release candidate 阶段运行更完整的深度 eval
阈值结合样本量、历史波动和任务分层设置，不只看"下降 5 个百分点"这种固定数字
失败的 Task 附带 Transcript、模型版本、prompt/config diff 和环境快照，供开发者定位根因

18.8 评估与其他方法的协作

自动化 eval 功能强大，但不是唯一的信息来源。完整的 Agent 质量认知需要多种方法叠加。

方法	优点	缺点	最适合的阶段
自动化 Eval	快速迭代、可重复、无用户影响	需要前期投入、可能与真实使用脱节	发布前、CI/CD
生产监控	反映真实用户行为	滞后、有用户受影响	发布后持续
A/B 测试	测量真实用户结果	需要足够流量、较慢	重大变更验证
用户反馈	发现意外问题	稀疏、偏向严重问题	持续收集
Transcript 人工审查	发现细微质量问题	耗时、难以规模化	周期性抽检
系统性人工评估	金标准，处理主观任务	昂贵、慢	校准 Model Grader

借用安全工程的瑞士奶酪模型（Swiss Cheese Model）：没有任何一层能拦住所有问题，但多层叠加之后，能让漏网的失败变得极少。[1]

Anthropic 建议的不同阶段侧重：

上线前：自动化 eval 为主，确保基准能力
上线后：生产监控为主，发现真实用户的失败模式
重大变更：A/B 测试验证业务指标
持续：每周抽样 Transcript 人工审查，校准 Model Grader

18.9 常见误区

误区一：通过率越高越好

一个 100% 通过率的 eval 套件，要么说明 Agent 已经非常强，要么说明你的任务太简单了。Eval 的价值在于提供"还可以爬的山"。当 eval 饱和（所有任务都通过）时，它只能用于回归检测，不能指导改进方向。SWE-bench Verified 的分数从 30% 涨到 80% 以上后，很多团队发现它对能力改进的指导意义在下降——因为剩下的 20% 是极难的任务，进步很小但实际改进可能很大。[1]

误区二：路径正确比结果正确更重要

检查 Agent 是否"用了正确的步骤"通常是个坏主意。Agent 会找到评估设计者没有预料到的路径，而这些路径可能是完全合法的。评估 Outcome，不评估路径，除非路径本身就是评估维度（比如效率对比）。

误区三：0% 通过率意味着 Agent 能力差

Anthropic 的实践表明：pass@100 为 0% 通常不是 Agent 的问题，而是 Task 定义有歧义或 Grader 有 bug。[1] 把 eval 分数当成 Agent 能力的直接反映，会让你在错误的方向上优化。

误区四：可以完全依赖 Model Grader

Model Grader 本身不是透明盒，它的判定需要持续校准。一个没有定期人工校准的 Model Grader 可能在某些维度上系统性偏高或偏低，而你不会知道，直到某个用户指出"为什么这么烂的输出 eval 给了满分"。

误区五：等完美测试集再开始

这条已经被多次证伪。Lucy 案例、Claude Code 案例、Bolt 案例，所有经历了评估驱动转型的团队都是从不完美的测试集开始的。完美是好的敌人。

18.10 工具生态（截至 2026.05）

几个值得了解的评估框架，选择依据是你的 Agent 类型、数据治理要求和现有技术栈：

工具	主要定位	适合场景	选型注意
Harbor	Agent benchmark 的容器化运行基础设施	需要可复现沙箱、批量 Trial、复用 Terminal-Bench 等任务	更偏 benchmark / eval harness，不是完整生产可观测平台
Braintrust	离线 eval + 生产可观测性 + 实验追踪	需要把开发评估、线上 Trace、CI/CD 结果放在同一工作流里	商业平台能力强，数据驻留和供应商锁定要提前评估
Langfuse	开源追踪、评估、数据集和 prompt 管理	有自托管、数据驻留、OpenTelemetry / LangChain 集成需求	自托管后要自己承担升级、存储和权限治理
Arize Phoenix	开源可观测和评估分析	需要看 Trace 分布、聚类、漂移，而不只看聚合分数	更适合分析和诊断，CI 门禁可能需要自己补胶水
DeepEval	单元测试风格的 LLM / RAG / Agent eval	Python 项目里快速写自定义指标和回归测试	要警惕 Model Grader 未校准带来的虚假信心
RAGAS	RAG 专项评估	Faithfulness、Answer Relevance、Context Recall 等 RAG 指标	主要覆盖 RAG，不等价于完整 Agent eval

Anthropic 团队的建议是：框架只是加速器，质量取决于你投入到 Task 和 Grader 设计上的精力。快速选一个适合你工作流的，然后把精力放在构建高质量测试用例上。[1]

面试高频题
Q：如何为一个 Coding Agent 设计评估体系？
参考回答框架：
确定评估维度：功能正确性（单元测试）+ 代码质量（静态分析 + Model Grader）+ 效率（turns / tokens）+ 安全性（security scan）
设计 Grader 组合：代码执行结果为主，Model Grader 为辅，人工校准 Model Grader
建 Regression Eval 套件，接入 CI/CD
从真实失败案例开始构建 Task 集，持续更新
加分点：说清楚 pass@1 和 pass^k 的适用场景差异；提到 Transcript 审查是 Grader 校准的必要步骤；能说出 eval 饱和问题和如何应对。
Q：pass@k 和 pass^k 分别适用于什么场景？
参考回答：pass@k 适合工具型或创作型 Agent——只要 k 次里有一次成功，任务就算完成。pass^k 适合自动化执行关键业务的 Agent——每次执行都必须成功，因为每次失败都有真实的业务代价（发错邮件、提错工单、转错账）。两者不是互斥关系，对于重要的 Agent，应该同时跟踪：用 pass@1 衡量能力上限，用 pass^3 或 pass^5 衡量可靠性下限。
Q：如果一个任务的 pass@100 是 0%，你会怎么判断是 Agent 问题还是 Eval 问题？
参考回答：先查 Grader——检查 Grader 代码有没有 bug，确认期望值的设定是否和任务描述一致；再查 Task——用人工执行一遍任务，确认任务是否可解、参数是否完整；最后才考虑 Agent 能力问题。Anthropic 的经验是：0% pass@100 绝大多数情况下是 Task 或 Grader 的问题。

参考资料

[1] Demystifying evals for AI agents - Anthropic Engineering (2026.01) https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

[2] Evaluating the Effectiveness of LLM-Evaluators (LLM-as-Judge) - Eugene Yan (2024.08) https://eugeneyan.com/writing/llm-evaluators/

[3] Your AI Product Needs Evals - Hamel Husain (2024.03) https://hamel.dev/blog/posts/evals/

[4] SWE-bench Verified - Princeton NLP https://www.swebench.com/SWE-bench/

[5] τ-Bench: A Benchmark for Tool-Agent-User Interaction (arXiv:2406.12045) https://arxiv.org/abs/2406.12045

[6] τ2-Bench (arXiv:2506.07982) https://arxiv.org/abs/2506.07982

[7] BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents (arXiv:2504.12516) https://arxiv.org/abs/2504.12516

第18章：Agent 评估体系（Evaluation）—— 你怎么知道它变好了？ ​

18.1 为什么 Agent 评估比传统测试难得多 ​

核心直觉 ​

三重不确定性 ​

传统测试 vs Agent 评估 ​

18.2 评估结构：从任务到 Transcript ​

核心概念 ​

单轮 vs 多轮评估 ​

Capability Eval vs Regression Eval ​

18.3 Grader 设计：三类评分器的选择逻辑 ​

Code-based Grader（代码评分器） ​

Model-based Grader（模型评分器） ​

Human Grader（人工评分） ​

混合策略 ​

评分聚合：硬门槛、部分得分和防绕过 ​

18.4 关键指标：pass@k 和 pass^k ​

18.5 不同类型 Agent 的评估策略 ​

Coding Agent ​

对话 Agent（客服、销售、辅导类） ​

Research Agent（调研报告、信息收集类） ​

Computer Use Agent（操作 GUI 的 Agent） ​

18.6 Eval-Driven Development：评估驱动开发 ​

从 0 到 1 的路线图 ​

评估集治理 ​

Eval-Driven Development 的工程闭环 ​

18.7 传统测试策略在 Agent 中的位置 ​

单元测试（Unit Tests） ​

集成测试（Integration Tests） ​

E2E 测试（End-to-End Tests） ​

CI/CD 中的 eval 门禁 ​

18.8 评估与其他方法的协作 ​

18.9 常见误区 ​

18.10 工具生态（截至 2026.05） ​

参考资料 ​

第18章：Agent 评估体系（Evaluation）—— 你怎么知道它变好了？

18.1 为什么 Agent 评估比传统测试难得多

核心直觉

三重不确定性

传统测试 vs Agent 评估

18.2 评估结构：从任务到 Transcript

核心概念

单轮 vs 多轮评估

Capability Eval vs Regression Eval

18.3 Grader 设计：三类评分器的选择逻辑

Code-based Grader（代码评分器）

Model-based Grader（模型评分器）

Human Grader（人工评分）

混合策略

评分聚合：硬门槛、部分得分和防绕过

18.4 关键指标：pass@k 和 pass^k

18.5 不同类型 Agent 的评估策略

Coding Agent

对话 Agent（客服、销售、辅导类）

Research Agent（调研报告、信息收集类）

Computer Use Agent（操作 GUI 的 Agent）

18.6 Eval-Driven Development：评估驱动开发

从 0 到 1 的路线图

评估集治理

Eval-Driven Development 的工程闭环

18.7 传统测试策略在 Agent 中的位置

单元测试（Unit Tests）

集成测试（Integration Tests）

E2E 测试（End-to-End Tests）

CI/CD 中的 eval 门禁

18.8 评估与其他方法的协作

18.9 常见误区

18.10 工具生态（截至 2026.05）

参考资料