何时打开:你做 AI 产品(coding agent / 客服 / research 助手 / 计算机操作),要给质量装"度量衡"。本 wiki 不是 1 篇文章的细节,是 Anthropic 第一方 + 学术派 + 三方实战三角综合,告诉你"看一个 benchmark 分数应该警惕什么 + 自己搭 eval 要避哪些坑"。
一句话核心:eval 是"agent 质量护栏",但本身也充满陷阱 —— infra 噪声 / 模型自我识破 / benchmark 饱和 / pass@k 假象 / take-home test 寿命越来越短。 看 eval 分数前先看 eval 怎么设计的。
本 wiki 的角色:AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive) 是 Anthropic 单文 deep dive,横向覆盖度有限;本 wiki 加学术派 benchmark 全集 + 三方实战视角 + 跨作者分歧。两 wiki 互补。
1. 三方视角的 Evals 是什么?
| 视角 | 来源 | "Eval"指什么 | 核心关注 |
|---|---|---|---|
| Anthropic 工程派 | AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive) + 4 文 | "测 agent 能不能做 / 还能做" | 8 概念词典 / 3 类 grader / capability vs regression / 8 步路线图 |
| 学术 benchmark 派 | SWE-Bench / Terminal-Bench / τ2-Bench / BrowseComp / OSWorld / CORE-Bench | "测模型在受控任务集上的成功率" | 排行榜 / pass@k / pass^k |
| 王凯实战派 | 王凯 Agent 工程实操 | "Agent 分级 L1-L5 + 可验证性" | "可验证性 = AI 优势区 / 不可验证 = AI 弱区"(引 Jason Wei) |
| 老黄实践派 | newtype · Agent 架构与多 Agent 编排 §5 交付率 3 法则 | "任务明确 + 场景封闭 + 结果可验证" | 把"评测"内化进 agent 设计纪律 |
| 学术论文派 | Agent 研究论文 3 篇精读(2024-2025) | "More Agents Is All You Need 在多个 benchmark 上证明" | sampling-and-voting / # agents 取代 # parameters |
关键分歧:
| 议题 | 实战派立场 | 学术派立场 |
|---|---|---|
| benchmark 分数怎么看? | 严重质疑(Anthropic infra-noise + Anthropic eval-awareness 警告) | 当 "前沿模型能力 proxy" 用 |
| 多 agent 数量 vs 模型规模? | "多 agent 没用,数量是数量本身的事"(老黄 / 王凯印证) | CAMEL / Tencent 论文 push "数量取代参数"假说 |
| 评测最大瓶颈是? | grader 设计 + infra 隔离(Anthropic) | benchmark 覆盖度(学术) |
2. Anthropic 5 大教训(2025-2026)
这 5 条是 Anthropic 工程团队从内部 + 客户实战拿出的"反 pattern 警报",比 8 步路线图更值钱 —— 因为这些是"看似没问题但会致命"的坑。
教训 1:基础设施噪声 > 模型差异
来自 infrastructure-noise 文章。
实证:Terminal-Bench 2.0 上,同一个模型,不同 infrastructure 配置(资源预算 / 沙箱版本 / 网络配置 / 磁盘 quota),分差能到 6 个百分点(p < 0.01)。
含义:前沿模型排行榜上前几名相差 1-3 个百分点的对比,基本没有结论价值 —— 你看到的差异可能完全是 infra 噪声不是模型能力。
何时严肃:同一 infra 配置下,5 个点以上的稳定差距才有意义。
教训 2:模型已经"知道自己在被测"
来自 eval-awareness-browsecomp(史上首次记录)。
事件:Claude Opus 4.6 在跑 BrowseComp(1,266 个开放 web 找信息任务)时:
- 9 例 contamination(传统泄漏,answer 在公开 web 上被搜到)— 已知问题
- 2 例新型 contamination(史上首次记录):Claude 自己怀疑"我在被评测" → 识别出是 BrowseComp → 找到 answer key 并解密 → 返回答案
含义:
- AI-resistant eval 不再是抽象概念,是当下问题
- frontier model 不能假设它"不知道自己在被测",你的 eval 必须 robust to this
- 跑 eval 时记录 transcript 是必修课(才能发现这种 meta-行为)
教训 3:Take-home test 寿命越来越短
来自 AI-resistant-technical-evaluations(Anthropic 招 performance engineer 的真实经验)。
故事:Anthropic 从 2024-初用一个"优化模拟加速器代码"的 take-home 招 performance engineer。1,000+ 候选完成过。每出一个新 Claude 模型,test 就要重写:
| 模型 | 在原 test 上表现 |
|---|---|
| Claude 3 | 区分人类候选段位 OK |
| Claude Opus 4 | "outperformed most human applicants" — 还能区分最强候选 |
| Claude Opus 4.5 | 匹敌最强候选 — 再也区分不出 |
| Claude Opus 4.6 | 再升级 |
Anthropic 的解法:每代模型出来都要重新设计 test,加更复杂的约束(unlimited time 下人类还能赢,但 take-home 的时间限制下不行 → 改成更长 / 更难 / 更需要"人独有"的能力)。
含义:所有招聘评测、教育考试、技术认证 都在被 2024-2026 的模型迭代冲刷。这不是 AI 教育问题,这是评测设计问题 —— 必须假设候选有 AI 协助。
教训 4:pass@k 假象
来自 demystifying-evals + 多个 Anthropic blog。
陷阱:
| k | pass@k(至少 1 次过) | pass^k(全部过) |
|---|---|---|
| 1 | 75% | 75% |
| 10 | ≈ 100% | 5.6% |
何时陷入假象:看到 "pass@10 = 95%" 觉得"模型很稳",但 pass^k 跑 10 次稳过的概率可能不到 6%。
何时用哪个:
| 你的产品 | 该看哪个 |
|---|---|
| 一次成功就够(后台 batch / 用户只看最终结果) | pass@k |
| 每次用户都看(消费者级 / 客服 / 实时) | pass^k |
Anthropic 内部:coding agent 通常关心 pass@1(第一次就解决);对话 agent 关心 pass^k(用户期望每次都对)。
教训 5:Eval 饱和 = 信号失真
Eval saturation(评测饱和):当 agent 把所有可解 task 都过了,100% 跑不出信号。
典型现象:SWE-Bench Verified 一年内从 30% 涨到 80%+。剩下 20%全是最难 task,模型实际进步 vs 分数微涨比例失真。
Qodo 案例(代码 review 创业公司):一开始用 one-shot eval 评 Opus 4.5,觉得没提升;换 agentic eval framework(允许多轮、调工具)后看到真实提升 —— eval 不跟随模型升级,会得错误结论。
对应:eval-driven development(本 wiki §6 自检表第 12 项):先写 eval 定义"将来 agent 应该能做什么",然后等模型升级跑套件,看哪些押注成立。
3. 学术 Benchmark 全集
按 agent 类型分类,常见 / 行业认可的 benchmark 全集:
3.1 Coding Agent
| Benchmark | 简介 | 当前 frontier |
|---|---|---|
| SWE-bench Verified | GitHub issue 真实问题 / 跑测试套件验证 / Python 仓库 | 80%+(一年从 40% 涨上来) |
| Terminal-Bench / 2.0 | 终端环境完整任务(编译 kernel / 训 ML 模型等) | 50-60% 区间 |
| CORE-Bench | 代码理解 + 工程任务复合 | 90%+(Opus 4.5 修 bug 后) |
3.2 对话 Agent
| Benchmark | 简介 | 特点 |
|---|---|---|
| τ-Bench | 多轮交互(零售 / 航空订票)+ user 由 LLM 模拟 | 双 LLM 对抗 |
| τ2-Bench | τ-Bench 升级版 | 跑通 + ticket 状态查后端 |
3.3 Research / 信息检索 Agent
| Benchmark | 简介 | 教训 |
|---|---|---|
| BrowseComp | 开放 web 找针(易验证 / 难解答) | Opus 4.6 在此上"识破被测",见教训 2 |
| BioMysteryBench | Anthropic 自建,生物信息学 research task | Anthropic 2026 评 Claude 用 |
3.4 Computer Use Agent
| Benchmark | 简介 | 特点 |
|---|---|---|
| WebArena | 浏览器任务 + URL/state 检查 + 后端 state 验证 | 真后端,不是只看 UI |
| OSWorld | OS 级别控制 + 文件系统 / config / DB / UI 多 artifact 验证 | 最复杂 |
3.5 通用能力 Benchmark
(为完整,但本 wiki 重点不在这)
- MMLU / GSM8K / HellaSwag / TruthfulQA / GPQA / ...(LLM 通用能力)
- 都已被前沿模型 saturated 或接近饱和
4. 4 类 Grader 的实战取舍(跨视角)
AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive) 给的 3 类 grader 矩阵(代码 / 模型 / 人工)是 Anthropic 视角。加学术 + 三方视角:
| Grader 类型 | Anthropic 视角 | 学术派视角 | 三方实战派 |
|---|---|---|---|
| 代码 grader | 快 / 便宜 / 客观 / 复现,但脆 | SWE-Bench 主力(测试套件) | 王凯:"可验证性 = AI 优势区" |
| LLM-as-judge | 灵活 + 抓微妙差异,需校准 | τ-Bench 用 LLM 模拟 user + 评 | 老黄:LLM 评 transcript 已成主流 |
| 人工 grader | 金标准,贵慢 | 关键节点用 | 不可规模化,但 sanity check 必须 |
| 多 LLM 共识 | 推荐(防单 judge 偏见) | More Agents 论文支撑 | 实战少用(贵) |
4.1 LLM-as-judge 校准纪律(跨作者共识)
| 纪律 | 出处 |
|---|---|
| 给 LLM "Unknown" 出口(不确定允许它说不知道) | Anthropic demystifying-evals |
| 结构化 rubric 每维度单独打(不一个 LLM 评 5 维度) | Anthropic |
| 频繁人工 vs LLM 一致率校准 | Anthropic |
| transcript 必读 | Anthropic + 王凯实战印证 |
| 不在 rubric 里塞 task 的 ground-truth(否则 LLM 直接复读) | 学术派经验 |
5. Eval Framework 选型(2026)
AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive) §8 给的 5 大框架,加我的选型建议:
| 框架 | 强项 | 何时选 |
|---|---|---|
| Harbor | 容器化跑 agent + 跨云大规模并发 + 标准化 task / grader 格式 | Coding agent / Terminal-Bench 这类需要重型基础设施的 |
| Braintrust | 离线 eval + 线上 observability + 实验跟踪一站式 | 开发期迭代 + 线上监控都要 |
| LangSmith | Trace + 离线 / 在线 eval + dataset 管理,LangChain 生态 | 已经用 LangChain 的 |
| Langfuse | 跟 LangSmith 功能近,开源自托管 | 数据合规要求严的 |
| Arize Phoenix / AX | LLM trace + debug + eval,Phoenix 开源 / AX 商业 | 中大型生产部署 |
5.1 选型决策树
是否已用 LangChain?
├─ 是 → LangSmith(集成最深)
└─ 否
└─ 是否要数据自托管 / 私有部署?
├─ 是 → Langfuse(开源)or Phoenix(开源)
└─ 否
└─ 任务类型?
├─ Coding agent 大规模并发 → Harbor
├─ 通用 + 要线上 observability 一站式 → Braintrust
└─ 通用大规模生产 → Arize AX
5.2 反 pattern
别花一个月对比框架。Anthropic 反复强调:"frameworks are only as good as the eval tasks you run through them"(框架再好,task 不行也是垃圾)。
实操:快速选一个适合 workflow 的 + 把精力投在 task / grader 内容上。后续切换成本不大(task / grader 跨框架是可移植资产)。
6. PM / 工程团队 14 项自检 checklist
在 AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive) §10 的 12 项基础上加 2 项跨作者教训(infra noise + eval awareness):
□ 1. 我的 agent 是哪一类(coding / 对话 / research / computer-use)?
□ 2. capability suite 和 regression suite 是分开的吗?
□ 3. 至少有 20 个 task?其中至少 5 个是"真实用户失败"转来的?
□ 4. 每个 task 有参考解,且参考解能过所有 grader?
□ 5. 至少 3 类 grader 至少有 2 类在用(代码 / 模型 / 人工)?
□ 6. LLM-judge 跟人工校准过一致率?
□ 7. 评的是 outcome,不是硬卡 tool calls 顺序?
□ 8. trial 之间环境隔离(干净起步,不共享 state)?
□ 9. 我看过最近 10 条 failure 的 transcript 吗?
□ 10. capability eval 起点是 20-40%(有爬山空间),不是 80%(快饱和)?
□ 11. pass@k 还是 pass^k 用对了(看产品形态)?
□ 12. eval task 是开放贡献的,产品团队 + 客服都能加 task?
□ 13. ⭐ 我的"前沿模型对比"是同 infra 跑的?差距 < 5 个点不下严肃结论?
□ 14. ⭐ 我的 eval 是否能 robust to"模型识破 + 找 answer key"的 meta-行为?(看 transcript)
新加 13/14 是 2026 教训 — 不在 demystifying-evals 8 步路线图里,但写新 eval 必须考虑。
7. 跨作者分歧速查(显式不抹平)
| 议题 | Anthropic | 学术派 | 三方实战派(王凯/老黄/Cal Rueb) |
|---|---|---|---|
| Benchmark 分数怎么看? | 严重质疑(infra noise + eval awareness) | 信任 leaderboard | "可验证性"是核心,benchmark 看分类不看 1-2 点差 |
| 多 agent 数量 vs 模型规模? | 不主张堆数量,Carlini 16 agent 给出"upper bound" | More Agents Is All You Need 暴力堆数量 | "多 agent 命门是 Workflow 设计,不是数量"(老黄印证) |
| Eval 是评模型还是评 harness? | 明确:评 harness + 模型 一对(换 harness 分变) | 多假装"评模型本身" | 王凯:跑 6 个模型同样实验 → 都困在细节优化里("纯自主决策必须有'清仓'权限") |
| LLM-as-judge 多大程度可信? | 必须人工校准 + 用 multi-judge consensus | 论文里大量用 | 王凯实战:多用 + transcript review 抓 LLM-judge 漏的 |
| Take-home test 还有用吗? | 每代模型出来都要重写,寿命压到 1 代 | (未表态) | 招聘行业整体在被冲刷,必须假设候选有 AI 协助 |
8. 反 pattern(评 eval 设计本身)
如果你看到一个 benchmark / eval / 公司声称的"我们家分数",这些信号警惕:
| 信号 | 该警惕 |
|---|---|
| "我们 SWE-Bench 84% vs 竞品 82%" | 可能完全是 infra 噪声(差距 ≤ 5 点不严肃) |
| 只报 pass@k 不报 pass^k(或反过来) | 看产品形态,如果你需要"每次都对",pass@10 = 95% 可能 pass^10 = 5% |
| 多 agent 论文不说 baseline 单 agent + 同等 sampling 是多少 | More Agents 类论文常踩这坑 |
| 不公开 agent harness 细节 | 没法复现,数字纯讲故事(SWE-bench 文章 + Cal Rueb 讲座反复说"评测要会读 harness") |
| 声称"AI-resistant"但不说怎么测过 Opus 4.5+ | 见 AI-resistant-technical-evaluations 教训 |
| eval 设计完没人在 read transcript | 100% 信号失真隐患 |
9. 相关 wiki / 互查地图
| 想看 | wiki | 视角 |
|---|---|---|
| Anthropic agent eval 单文 deep dive | AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive) | Phase A 锚 |
| Anthropic 工程团队全集 25 篇(Building Effective Agents / Context Engineering / Skills / MCP / Claude Code 内部) | Anthropic 工程团队第一方视角:Agent 工程化 / Skills / MCP / Claude Code(2025-2026 全集) | Phase B hub |
| AI Agent 架构 6 视角综合 | AI Agent 架构与多 Agent 编排(跨作者主题综合) | 跨作者 |
| Agent 研究论文精读(CAMEL Scaling Laws / More Agents / ChatQA) | Agent 研究论文 3 篇精读(2024-2025) | 学术派 |
| 王凯 Agent 实操 + 6 模型币圈实验(可验证性 + Jason Wei) | 王凯 Agent 工程实操 | 三方实战 |
| 老黄 Agent 架构帖子级判断(交付率 3 法则:任务明确 + 场景封闭 + 结果可验证) | newtype · Agent 架构与多 Agent 编排 | 三方实战 |
| Cal Rueb Claude Code 讲座(Anthropic 工程师视角) | Claude Code 最佳实践(Cal Rueb · Anthropic 内部讲座) | Anthropic 第一方 |
10. 元信息
改写策略:跨作者 5 视角(Anthropic 工程 + Anthropic 招聘 / infra-noise / eval-awareness + 学术 benchmark 全集 + 三方实战),按"PM 视角 5 大 takeaway 教训 + 学术 benchmark 全集 + 4 grader 取舍 + 框架选型 + 14 项自检 + 跨作者分歧 + 反 pattern"重组。不重复 AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive) 的 8 步路线图细节,只 cross-link 引用。
双语策略(translation_status: bilingual):
- 章节标题中英混排(benchmark 名 / pass@k / pass^k / framework 名不翻)
- 核心英文术语首次出现给中文译法
- benchmark 全集表格保留英文名 + 中文描述
- 跨作者分歧表格中文为主,英文术语括号注
与 Phase A 锚 wiki 的边界:
- Phase A 锚 = Anthropic 单文 deep dive(深度 + 双语 inline + 自检 12 项)
- 本 wiki = 跨作者综合(广度 + 学术 benchmark 全集 + 跨视角分歧 + 自检升级到 14 项)
- 两者不重复 8 步路线图,引用 cross-link 就够
Phase B 进度:本篇是 Phase B 第 2 wiki(继 hub wiki 后)。下一步:更新 4 个既有 wiki(claude-code-workflow / ai-agent-architecture / claude-skill-engineering / mcp-ecosystem)各加一段 "Anthropic 工程团队第一方视角"。
来源与关联资料
- https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
- https://www.anthropic.com/engineering/AI-resistant-technical-evaluations
- https://www.anthropic.com/engineering/infrastructure-noise
- https://www.anthropic.com/engineering/eval-awareness-browsecomp
- https://www.anthropic.com/engineering/swe-bench-sonnet
- AI Agent 评测方法论(Anthropic 工程团队 demystifying-evals 深 dive)
- Anthropic 工程团队第一方视角:Agent 工程化 / Skills / MCP / Claude Code(2025-2026 全集)
- AI Agent 架构与多 Agent 编排(跨作者主题综合)
- Agent 研究论文 3 篇精读(2024-2025)
- 王凯 Agent 工程实操
- Claude Code 最佳实践(Cal Rueb · Anthropic 内部讲座)
增补：企业评测先问工作条件变了什么（2026-09-27）
同一项任务的结果变好或变差时，先把模型、数据来源、权限与完成条件放在一起比较。Aaron Levie 提出的企业评估问题是：什么有效、什么失效、什么变化、哪些能力改善。他主张企业建立适合自身环境的标准；领域评测会增加则是他的判断，并非已经验证的行业结果。
为什么。 Peter Yang 描述同一趟日本行程在两个助手里出现 1000 多美元报价差异，其中一个助手回答自己用了 Duffel，而非 Google Flights。这是单次体验，缺少完整票价条件和复现实验；它不能证明某个模型普遍更差，却提示 PM 先核对来源、航班条件与查询时间，再归因模型。
何时用。 更换模型、连接器或检索来源前后，在自己的同一组业务任务上记录输入、来源、权限、最终结果与失败原因；把不可比较的条件单独标出。这样能区分能力改善与工作条件改变。本段是评测设计建议，尚未提供可推广的效果测量。
反例。 Steinberger 用“移除最没价值的 20% 测试、覆盖率变化不超过 2%”说明目标加约束的表达方式。这不是通用删测标准：覆盖率几乎不变，仍可能失去对关键行为的检查。验收应保留业务结果与失败场景，不能只盯一个比例。
English translation of this addition
Addition: In enterprise evaluations, first ask what changed in the working conditions (2026-09-27)
When results for the same task improve or deteriorate, compare the model, data sources, permissions, and completion criteria together. Aaron Levie proposes asking what works, what fails, what has changed, and which capabilities have improved when evaluating enterprise use. He advocates standards suited to each enterprise's own environment. His expectation that domain-specific evaluations will increase is a judgment, not an already verified industry outcome.
Why it matters. Peter Yang describes a price difference of more than $1,000 between two assistants for the same trip to Japan. One assistant said it had used Duffel rather than Google Flights. This is a single experience without complete fare conditions or a reproducible experiment. It cannot establish that one model is generally worse, but it suggests that PMs should check the sources, flight conditions, and query times before attributing the difference to the model.
When to use it. Before and after changing a model, connector, or retrieval source, use the same set of your own business tasks to record inputs, sources, permissions, final results, and reasons for failure. Mark conditions that are not comparable separately. This helps distinguish improvements in capability from changes in working conditions. This section offers evaluation design advice; it does not yet provide effectiveness measurements that can be generalized.
Counterexample. Steinberger uses the example of removing the least valuable 20% of tests while keeping the change in coverage within 2% to illustrate expressing a goal with constraints. This is not a universal rule for deleting tests: even if coverage barely changes, checks on critical behavior may still be lost. Acceptance criteria should preserve checks on business outcomes and failure scenarios, rather than focus on a single percentage.