AI Agent 的评测（Evals）祛魅
真正有效的评测策略，从来不是单一方法，而是用组合拳去匹配被测系统本身的复杂度。
01为什么 Agent 比模型更难评
让 Agent 强大的那些特性，恰好就是让它难以被测量的原因。
Eval（评测）的价值很朴素：在问题进入线上之前先发现它。没有 eval 的团队会陷入一种被动循环——用户报障 → 紧急修复 → 引入新问题 → 再报障，而且始终分不清「这次是真的退步了」还是「只是模型的随机波动」。
但把单轮 LLM 的测试经验直接搬到 Agent 上会失效。原因在于 Agent 的三个核心特性同时也是三个测量难题：
自主性
你无法预设它会走哪条路。同一个任务，它可能用三步解决，也可能用十五步。
灵活性
它会根据中间结果调整策略，这意味着「标准答案路径」这个概念本身就不成立。
有状态
它调用工具、修改环境。要判断成败，光看它说了什么不够，还得看世界被改成了什么样。
在 τ²-bench 的航班改签任务里，Claude 4.5 发现了航司政策中的一个「漏洞」，用一种测试设计者没预料到的方式给用户解决了问题——结果在静态 eval 里被判为失败。这暴露了 Agent 评测的核心张力：模型比你的评分器更聪明时，分数就不再等于能力。
02一套 Eval 的结构与术语
先把词统一了，团队讨论才不会各说各话。
三种评测形态
| 形态 | 流程 | 复杂度来源 |
|---|---|---|
| 单轮 eval | prompt → response → 打分 | 只需判断输出文本 |
| 多轮 eval | 跨多步推进，可调工具、改状态 | 路径不唯一，中间状态需追踪 |
| Agent eval | 工具使用 + 状态变更 + 跨轮自适应推理 | 三者叠加，最复杂 |
核心术语表
- 任务 Task / Test case
- 一个有明确输入和成功标准的测试单元。
- 试次 Trial
- 对同一个任务的一次尝试。因为模型输出有方差，必须跑多次才有意义。
- 评分器 Grader
- 判定表现的打分逻辑。一个任务可以挂多个 grader，每个 grader 里可以有多条断言。
- 轨迹 Transcript / Trace
- 完整过程记录：输出、工具调用、推理、中间结果——调试时最有价值的东西。
- 结果状态 Outcome
- 试次结束后环境的最终状态。和「说了什么」是两回事，必须分开评。
- 评测框架 Eval harness
- 端到端基础设施：并发跑任务、记录每一步、执行打分、聚合结果。
- Agent 脚手架 Agent harness / Scaffold
- 让模型能以 Agent 身份行动的那层系统：编排工具调用并把结果喂回去。
- 评测套件 Eval suite
- 一组任务的集合，用来衡量某项特定能力或行为。
Eval harness ≠ Agent harness。前者是「考场」，后者是「考生的手脚」。评测中的 Agent harness 必须尽可能贴近生产环境的那一套，否则你测的是另一个 Agent。
03为什么值得投入建 Eval
早期靠直觉够用，问题在于「够用」什么时候会突然不够用。
产品早期，人工试用（dogfooding）加直觉迭代得最快，这没问题。但规模一上来，被动排障就撑不住了——团队开始「盲飞」：改了一版，不知道整体是变好还是变坏。
Eval 在整个生命周期里的六种价值
- 逼团队提前把「成功」讲清楚。写不出评分标准，往往说明产品需求本身还是模糊的。
- 规模化过程中守住质量线，而不是靠个别人的手感。
- 大幅加速换模型。原文的观察是：有 eval 的团队迁移到新模型只要几天，没有的要几周。
- 提供性能基线：延迟、token 消耗、成本、错误率，都可以在固定任务集上横向对比。
- 成为产品团队和研究团队之间带宽最高的沟通渠道——一个失败任务比十页需求文档更能说明问题。
- 让「产品押注」变得可见：很多功能是赌几个月后模型能力会跟上，低通过率的能力 eval 正好把这个赌注量化了。
三个演进路径的样本
Claude Code
从纯人工反馈起步 → 加窄口径 eval（简洁度、文件编辑正确性）→ 扩展到复杂行为（是否过度设计）→ 叠加生产监控与 A/B 测试。
Descript
人工打分 → 用产品定义的标准做 LLM grader → 拆成两套：质量基准测试 + 回归测试。
Bolt
大规模上线后用三个月补齐 eval 体系，融合静态分析、浏览器 Agent、LLM 裁判三种手段。
04三类 Grader：各自的甜区与坑
没有一种评分器能通吃，成熟方案都是混合的。
代码型 Grader
手段：字符串匹配（精确 / 正则 / 模糊）、二元断言、静态分析、结果状态校验、工具调用校验、轨迹分析。
✓ 强在
快、便宜、客观、可复现、好调试，能精准校验特定条件。
✗ 弱在
对合法的表达变体很脆弱，抓不住细微差别，主观任务上基本没用。
模型型 Grader（LLM-as-judge）
手段：评分量表（rubric）、自然语言断言、成对比较、参考答案对照、多裁判共识。
✓ 强在
灵活、可规模化，能捕捉细微差别，适合开放式任务和自由格式输出。
✗ 弱在
非确定性、成本高，必须用人类打分做校准，否则你只是在测量另一个模型的偏好。
人工 Grader
手段：领域专家评审、众包判断、抽样抽查、A/B 测试、标注者一致性测量。
✓ 强在
质量金标准，是校准 LLM grader 的唯一可靠锚点。
✗ 弱在
贵、慢，且规模化时很难持续拿到专家时间。
组合打分的三种方式
05能力 Eval 与回归 Eval
两种 eval 的目标通过率是相反的，混在一起会让信号失真。
能力 Eval（Capability）
回答「Agent 现在能做好什么？」
- 起步通过率就该很低
- 专门挑有挑战性的任务
- 给团队一座明确的「待爬之山」
回归 Eval（Regression）
回答「以前能做的，现在还能做吗？」
- 目标通过率接近 100%
- 分数一降就是坏掉了
- 像单元测试一样进 CI
能力 eval 一旦被稳定攻克，就应该「毕业」转入回归套件。任务的问法从「我们能不能做到？」变成「我们还能不能做到？」——这是一条单向的传送带。
06四类 Agent 分别怎么评
不同形态的 Agent，成功的定义在哪一层，评测手段就落在哪一层。
① 编程 Agent
它们写代码、跑测试、调 bug、在代码库里穿梭、执行命令——行为方式接近人类开发者。好在它的成果天然可验证：跑测试就行。
基准：SWE-bench Verified（取自 Python 仓库的真实 GitHub issue，判据是「修好失败的测试，且不破坏原有测试」）；Terminal-Bench（端到端技术任务，如编译 Linux 内核、训练 ML 模型）。
任务定义示例（YAML）
task:
id: "fix-auth-bypass_1"
graders:
- type: deterministic_tests # 硬结果
required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]
- 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: # 不判定成败，但要记
- n_turns, n_toolcalls, n_total_tokens
- time_to_first_token, output_tokens_per_sec② 对话 Agent
客服、销售、教练类场景，跨多轮交互、维持状态、中途调工具。难点在于交互过程本身就是被评对象：需要另一个 LLM 扮演用户，而且成功是多维的——问题解决了吗？用了几轮？语气对吗？
基准：τ-Bench / τ²-Bench，让一个模型扮演用户人设，Agent 在零售客服、航司订票等真实场景中周旋。
graders:
- type: llm_rubric
rubric: prompts/support_quality.md
assertions:
- "对客户的挫败情绪表达了共情"
- "清晰解释了解决方案"
- "回复内容确实基于 fetch_policy 的返回结果"
- type: state_check # 事真的办了吗
expect:
tickets: {status: resolved}
refunds: {status: processed}
- type: tool_calls
required:
- {tool: verify_identity}
- {tool: process_refund, params: {amount: "<=100"}}
- {tool: send_confirmation}
- type: transcript
max_turns: 10 # 效率也是质量③ 研究 Agent
负责搜集、综合、分析信息，产出答案或报告。三个特有难点：
- 专家之间对「全面」的定义都不一致；
- ground truth 会漂移——被引用的网页内容本身在变；
- 输出越长，出错面越大。
基准：BrowseComp——在开放网络的大海里捞针，问题「难解但易验」。
推荐的组合打法：
务必定期用专家判断校准 LLM rubric。研究类任务的评分标准最容易悄悄漂移——模型裁判会逐渐奖励「读起来像好报告」而不是「事实上正确的报告」。
④ Computer Use Agent
通过和人一样的 GUI 界面操作：截图、点击、键盘、滚动。好处是能驱动任何图形界面应用——包括设计工具和没有 API 的老旧企业软件。
评法：把 Agent 放进真实或沙箱环境，直接检查预期结果有没有达成。
WebArena
浏览器任务。用 URL 和页面状态验证导航，更关键的是后端状态校验——确认订单真的进了系统，而不只是停在一个确认页上。
OSWorld
完整操作系统控制。用检查脚本验证各类产物：文件系统状态、应用配置、数据库内容、UI 元素属性。
DOM 交互快但费 token，截图交互慢但省 token。Claude for Chrome 的 eval 专门测了一件事：Agent 能不能在每个具体情境下选对工具。这类「效率决策能力」值得单列成评测项。
07非确定性：pass@k 还是 pass^k
同一个任务这次过下次挂，是常态而非 bug。指标选错，产品结论就会反。
pass@k
k 次尝试中至少成功一次的概率。k 越大越高——「射门次数多了总能进」。
适用于「给多个方案、有一个能用就行」的场景。pass@1 是编程领域最常关注的口径。
pass^k
k 次试次全部成功的概率。k 越大越低——这是一条一致性的高门槛。
单次成功率 75%，连过 3 次只有 0.75³ ≈ 42%。
一次成功就够 → 看 pass@k；每次都必须对 → 看 pass^k。面向 C 端用户的客服、支付、下单类 Agent，必须用 pass^k 口径，因为用户不会给你三次机会。反过来，代码补全这类「生成几个候选让人挑」的场景，pass@k 才是对的。
08从 0 到 1：落地路线图
九个步骤，从「什么都没有」到「一套能长期活下去的 eval 套件」。
-
第 0 步：尽早开始，别等完美
20–50 个来自真实失败的简单任务，就是一个很好的开始——不需要几百个。开发早期改动的效应量大，小样本就足以看出差异；只有 Agent 成熟之后，才需要更大更难的 eval 去分辨微小提升。
拖延的代价是复利式的：早期，产品需求可以自然翻译成测试用例；等系统上线很久再补，你就得从一个活系统里反向逆推当初的期望是什么。先做 80/20。
-
第 1 步：把现有的人工检查转成 eval
你其实已经在做 eval 了，只是没有沉淀。把每次发版前手动点的那几个场景写下来。已上线的系统还有两个金矿：bug 追踪系统和客服工单队列。按用户影响面排优先级。
-
第 2 步：写无歧义的任务，并配参考解
质量标准：两位领域专家独立评判，能得出相同的通过/失败结论。而且专家自己得能做出这道题。
- 需求里的歧义会原封不动变成评测噪声；
- rubric 写得含糊，判分就会前后不一；
- grader 要检查的每一项，都必须能从任务描述里读出来——不能考「没教过的隐藏要求」；
- 「0% pass@100」通常说明任务坏了，而不是 Agent 不行。
写一份参考解，同时证明两件事：任务可解，且 grader 配置正确。用前沿模型跑一遍很有用——它们特别擅长暴露你没想到的漏洞。
-
第 3 步：构造平衡的问题集
既要测「应该发生」的情况，也要测「不应该发生」的情况。单边的 eval 会导致单边的优化，同时注意避免类别失衡。
案例：Claude.ai 的联网搜索 eval 同时覆盖两侧——该搜不搜（欠触发）和不该搜乱搜（过触发）。原文提到，这套集合经过了很多轮打磨才平衡。
-
第 4 步：搭稳固的 harness 和干净的环境
两条铁律：评测里的 Agent 必须和生产的 Agent 行为一致；环境本身不能引入噪声。
每个试次都要从干净环境隔离启动，消除一切不必要的共享状态（残留文件、缓存数据、资源耗尽）。共享状态有两种危害：
- 相关性失败——失败源于基础设施抖动而非 Agent 能力，试次之间不再独立，统计结果不可信；
- 虚高——原文的真实案例：Claude 读到了上一个试次留下的 git 历史，等于开卷考试。
-
第 5 步：认真设计 Grader
总原则：能用确定性 grader 就用；需要灵活性时才上 LLM grader；人工 grader 谨慎使用、用于校准。几条具体的经验：
- 别做僵硬的步骤检查。不要强制某个固定的工具调用序列——Agent 经常找到设计者没预料到的有效路径，卡死步骤等于惩罚创造力。
- 设置部分得分。「正确识别了问题、验证了客户身份，但退款没走通」明显好于「一上来就失败」，评分应该体现这条连续谱。
- 给 LLM 裁判一个逃生舱。明确允许它在信息不足时返回「Unknown」，而不是硬猜。
- 拆结构化 rubric。每个维度用独立的 LLM-as-judge 分别评，而不是一个 grader 包打所有维度。
- 抗绕过。任务和 grader 要设计成「必须真解决问题才能通过」，而不是能靠钻空子拿分。
两个反面教材CORE-Bench：Opus 4.5 初测只有 42%。排查后发现是评测本身的问题——评分过于僵硬（答
96.12却期望96.124991…）、任务描述有歧义、部分任务本身就是随机不可复现的。修好之后分数跳到 95%。METR 时间跨度基准：任务让 Agent「优化到某个阈值」，但评分要求「超过该阈值」。结果听话的模型被扣分，无视指令的模型反而得分。
-
第 6 步：读轨迹（Read the transcripts!）
这是原文反复强调、也最容易被跳过的一步。值得专门投入做轨迹查看工具，并且要定期、大量地读。
任务失败时，只有轨迹能告诉你：这是 Agent 真的犯错了，还是 grader 拒绝了一个合法的解。判断标准很简单——每一次失败看起来都应该是「公平」的：清楚地知道它错在哪、为什么错。做不到，说明该改的是 eval。
-
第 7 步：警惕能力 Eval 饱和
饱和指的是 Agent 已经通过了所有可解任务，没有提升空间了。SWE-bench Verified 今年从 30% 起步，前沿模型已逼近 80%+ 的饱和区。
饱和的危险不在于「没进步」，而在于结果会骗人：真实的巨大能力提升，在分数上只表现为几个百分点。
案例：代码审查公司 Qodo 起初对 Opus 4.5 印象平平——因为他们的单次（one-shot）eval 根本捕捉不到模型在长链路复杂任务上的提升。他们重建了一套agentic eval 框架后，进步才清晰显现。
一条硬规则：在有人真正读过 eval 细节和轨迹之前，不要按面值相信分数。红旗包括：评分不公、任务歧义、合法方案被判错、harness 限制过强——出现这些就该改 eval，而不是改模型。
-
第 8 步：让 Eval 套件长期健康
Eval 套件是活的资产，需要持续维护和明确的归属人，像单元测试一样做例行维护。
Anthropic 内部验证过的分工模型：专门的 evals 团队负责核心基础设施；领域专家和产品团队贡献绝大部分任务、并负责跑评测。
Eval 驱动开发：在 Agent 还做不到之前，就先写出定义目标能力的 eval，然后迭代到通过为止。这样也让「押注未来模型能力」的产品决策变得可度量——新模型一发布，跑一遍套件就知道哪些赌注兑现了。
最后一条，很关键：离产品需求和用户最近的人，最有资格定义什么叫成功。以现在的模型能力，产品经理、客户成功、销售都可以通过 Claude Code 以 PR 的形式提交 eval——应该主动去打通这条路径。
09Eval 只是一层：与其他手段的配合
没有任何单一方法能抓住所有问题——这是瑞士奶酪模型。
完整的质量体系应该是六种手段的叠加：自动化 eval + 生产监控 + 用户反馈 + A/B 测试 + 人工轨迹review + 系统性人类评估。
| 方法 | 优势 | 局限 |
|---|---|---|
| 自动化 Eval | 迭代快；完全可复现；不影响用户；无需上线即可大规模测试各种场景 | 前期投入大；需持续维护防漂移；若与真实用法脱节会带来虚假信心 |
| 生产监控 | 大规模呈现真实用户行为；抓得住合成 eval 漏掉的问题；是真实表现的 ground truth | 被动——问题先到用户那；信号嘈杂；需埋点投入；缺少判分的标准答案 |
| A/B 测试 | 直接测量真实用户结果（留存、完成率）；能控制混杂因素；可规模化、系统化 | 慢（几天到几周才显著）；需足够流量；只能测已上线的变更；不读轨迹就说不清「为什么」 |
| 用户反馈 | 暴露你完全没预料到的问题；自带真实案例；与产品目标高度相关 | 稀疏且自选择；偏向严重问题；用户很少说清原因；不自动化；主要靠它意味着已经伤害了用户 |
| 人工轨迹 Review | 建立对失败模式的直觉；抓住自动检查漏掉的细微质量问题；校准团队对「好」的共同理解 | 耗时；不可规模化；覆盖不均；评审疲劳；不同人口径不同；通常是定性而非定量 |
| 系统性人类评估 | 多评分者给出金标准判断；能处理主观、模糊任务；是改进模型 grader 的信号来源 | 贵且慢，难以高频；评分者分歧需要协调；复杂领域必须请专家 |
按时间线怎么排布
- 发版前 / CI-CD：自动化 eval 是第一道防线。
- 上线后：生产监控负责发现分布漂移和没预料到的失败。
- 流量足够时：A/B 测试用来验证重大改动。
- 日常：反馈持续分诊；每周抽样读轨迹，发现苗头再深挖。
- 主观场景：把系统性人类评估留给「校准 LLM grader」和「人类共识本身就是参考标准」的任务。
就像安全工程里那样，每一层都有孔洞，但把多层叠起来，穿过一层的失败会被下一层拦住。最有效的团队都是组合用：自动 eval 保迭代速度、生产监控给真实基准、周期性人工评审做校准。
10可用的 Eval 框架
工具选型远没有任务质量重要。
Harbor
容器化 Agent 环境，支持跨云厂商的大规模试次运行，提供标准化的任务/grader 格式。Terminal-Bench 2.0 等主流基准通过其 registry 分发，也可接入自建套件。
Braintrust
离线评测 + 生产可观测性 + 实验追踪三合一。自带 autoevals 库，内置事实性、相关性等评分器。
LangSmith
链路追踪、离线/在线评测、数据集管理，与 LangChain 生态深度集成。
Langfuse
能力与 LangSmith 类似，开源可自托管——有数据驻留要求的团队的选择。
Arize
Phoenix（开源，追踪 / 调试 / 离线在线评测）+ AX（SaaS，面向规模化、优化与监控）。
选型建议
很多团队是混用、自研，或者一开始就用简单脚本。框架远没有任务本身的质量重要——挑一个契合你工作流的，然后把精力全部投到高质量的测试用例和 grader 上。
11要点回顾
如果只记七条。
- 尽早开始，不要等一套完美的套件。20–50 个任务就能起步。
- 任务从真实失败里来：bug 库、工单队列、你自己每次发版前手动点的那几下。
- 成功标准必须无歧义：两个专家独立判断能得出同一结论，否则歧义会变成噪声。
- Grader 要混合设计：确定性优先，LLM 补灵活性，人工做校准；留部分得分，别卡死步骤。
- 题目要够难，并持续留意饱和——分数不动不代表能力没进步。
- 持续提升信噪比：干净隔离的环境、平衡的正反例、校准过的裁判。
- 读轨迹。这是原文唯一用感叹号强调的建议。
没有 eval，你会陷入被动循环：修好一个坏掉一个，还分不清真退步和噪声。有了 eval，失败会变成测试用例，测试用例会防住回归，度量取代猜测——而且价值是复利的：成本在前期一次性可见，收益持续累积。
Agent 评测仍然是一个非常年轻、演进极快的领域。随着 Agent 承担更长的任务、在多 Agent 系统中协作、处理越来越主观的工作，评测方法本身也必须继续进化。