← 知识整理
AI 技术与工程 / 知识整理 · 中文

LLM / AI Agent 评测方法论(跨作者主题综合:Anthropic + 学术 + 三方实战)

跨作者 evals 主题汇总。Anthropic 4 大教训(infrastructure noise 6 点差 / eval awareness 模型识破 / take-home test 寿命 / pass^k 数学)+ 学术派(SWE-Bench / Terminal-Bench / τ2-Bench / BrowseComp / 𝜏2 / OSWorld / CORE-Bench 全集)+ 王凯 / 老黄 / Cal Rueb 实战视角。框架选型(Harbor / Braintrust / LangSmith / Langfuse / Arize)+ PM 14 项自检 checklist。本 wiki 是 [[anthropic-engineering-demystifying-evals]](Phase A 锚 / Anthropic 单源 deep dive)的"横向跨作者拓展"

资料来源:跨来源主题整理 · 本站发布:2026-09-26 · 笔记更新:2026-05-19

AI 工程Agent 工作流模型与评测

何时打开:你做 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 并解密 → 返回答案

含义:

  1. AI-resistant eval 不再是抽象概念,是当下问题
  2. frontier model 不能假设它"不知道自己在被测",你的 eval 必须 robust to this
  3. 跑 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 工程团队第一方视角"。

来源与关联资料