你测什么
就得什么

1.1 古德哈特定律在 Agent 评测里的表现

古德哈特定律：当一个指标变成了目标，它就不再是一个好指标。

在 Agent 评测里的具体表现：

1. SWE-bench 分数最高的团队花了最多钱——不是他们的 Agent 架构最聪明，而是他们愿意用高价模型 + 高 effort + 多次重试。SWE-bench 不控制成本，所以"最好的 Agent"约等于"最贵的 Agent"
2. HumanEval 饱和之后，区分度消失了——当 5 个模型都在 90%+，你不知道哪个更好。就像用小学算术去考博士生——全是满分，测不出任何东西
3. 评测数据污染之后，高分可能是背答案——SWE-bench 超过 94% 的题目日期早于模型训练截止日期。模型可能在做题时"回忆"而非"推理"

1.2 评测的四层体系

越往上，越不像考试，越像真实的活。人类得分也逐层下降。 这不是因为题变难了，是因为"真实"天然包含了模糊性、多解性、环境噪声——这些是做题不涉及的。

HumanEval

怎么造的：OpenAI 2021 年手写了 164 道 Python 编程题。每道题给一个函数签名（def has_close_elements(numbers, threshold):）和 docstring（"""Check if any two numbers in the list are closer than threshold."""），让模型补充函数体。用单元测试判对错——跑 10 个左右的 assert，全过算对。

为什么 2026 年还在用：数字简单、可比。大家都知道它的局限性，但正因为用了 5 年，前几年的分数能当基线对比。

为什么光看它不够： - 单函数、单文件、Python only——真实开发是跨几十个文件改代码 - 题目见过 N 遍了——模型训练数据里大概率有这些题 - pass@1 在给足了采样预算的情况下不可靠——模型可以每次猜不同的，猜 100 次总有一次对

"AI Agents That Matter"这篇论文的核心批评（Kapoor et al., 2025, TMLR）： 他们做了一个实验：不用复杂的 Agent 架构，就是一个简单的"失败就换参数重试"策略，在 HumanEval 上击败了当时很多"SOTA Agent"。因为 HumanEval 有公开的测试用例——Agent 可以跑代码看对不对，不对就换种写法再来——这不是"更聪明"，这是"更有耐心（和更多 token）"。

所以怎么看 HumanEval 分数：把它当冒烟测试——如果新模型在 HumanEval 上只有 30%，基础能力不够，不用浪费时间在 SWE-bench 上。但如果两个模型都是 90%+，HumanEval 区分不了它们。

其他 L1 基准

和 L1 的本质区别

L1（HumanEval）是"给你一张白纸，写个函数"。 L2（Aider Polyglot）是"给你一个项目，里面有一堆文件，你需要改某几个文件的某几行，改完之后项目还能跑"。

前者测的是"你能不能写代码"。后者测的是"你能不能当程序员"——读懂已有代码、定位要改的地方、改对格式、不改坏别的东西。

Polyglot 怎么测的

题目来源：225 道 Exercism 题目，覆盖 C++ / Go / Java / JavaScript / Python / Rust 六种语言。筛选方法很讲究——先让 7 个顶级模型各跑一遍全部 697 道候选题目，只保留"7 个模型里 ≤3 个能做对的"225 道。这样保证了题库有区分度——如果一道题 7 个模型全会，加进题库毫无意义。

评测过程： 1. 模型收到任务描述 → 修改代码文件 2. 跑语言特定的单元测试（pytest、cargo test 等） 3. 第一次没过 → 模型被展示测试错误 → 再给一次修改机会（最多 2 次） 4. 全程在 Docker 容器里跑——LLM 生成的代码不能在你的真实机器上直接执行

三个关键指标（它们测的东西不一样）：

编辑格式合规率为什么被单独拎出来：编程 Agent 不是只把代码写对了就行——它产出的 diff 必须能被机器自动应用。如果 Agent 输出的格式是"在第 37 行和第 38 行之间插入……"这种自然语言，你必须人工去改——这就不是 Agent，是"建议器"。

它为什么重要

SWE-bench 是第一个把 Agent 评测从"做题"拉到"干活"的基准。它不是让人出题考模型——它把 GitHub 上真实修复过的 bug 挖出来，给 Agent 一份 issue 描述和当时的代码库快照，让它产出补丁。这个补丁要在 Docker 容器里通过全部单元测试才算"解决"。

SWE-bench = 真实发生过的事情。每一道题都是一个真人在真实项目里修过的一个真实 bug。

题目怎么构造的

以 Django 项目的一个真实 issue 为例：

1. 2022 年 6 月，有人提交了 issue #33892："当使用 GenericForeignKey 时，prefetch_related_objects 在某些情况下会抛出 AttributeError"
2. 一位 Django 开发者定位了 bug，提交了 PR #15000，修改了 django/db/models/query.py 里的 3 行代码，加了 15 行测试
3. SWE-bench 把这道题变成：
4. 给 Agent：issue #33892 的原文 + Django 在 PR 之前的代码快照
5. Agent 需要：找到 query.py 里的 bug、修改正确、并通过所有测试（含新增的 15 行）
6. 隐藏的：开发者实际提交的补丁和测试（用来判分，不给 Agent 看）

SWE-bench Verified 与原始版的区别

原始 SWE-bench 有 2294 道题。OpenAI 联合 Princeton 筛出了 Verified 子集（500 题）——筛的过程非常严谨：

• 请了 93 个专业软件开发者，不是众包、不是学生
• 每人标注 3 遍（不是 1 遍）——三份独立标注取一致性
• 筛掉的标准：issue 描述不清楚的、单元测试不能可靠区分正误的、有严重缺陷的
• 结果：68.3% 的原始题目被筛掉

也就是说，你在 Leaderboard 上看到的"SWE-bench 80%"——如果是在非 Verified 子集上的分数，有相当一部分可能是靠"题目本身有问题"拿到的。

判分机制

不是"模型产出了正确的代码"就算通过。要通过两套测试：

1. FAIL_TO_PASS 测试：修之前失败、修之后必须通过的测试。这是验证"你真的修了 bug"
2. PASS_TO_PASS 测试：修之前就通过、修之后也必须通过的测试。这是验证"你没引入新 bug"

两套全部通过 → 这道题算"解决"。

已知的局限性（2025–2026 研究发现）

这些局限性不是"SWE-bench 不好"——恰恰相反，正是因为用的人多、审的人多，才暴露了这些问题：

SWE-bench-Live（动态生成新题）上分数从 >43% 掉到 19–22%——证实了污染和答案泄露的真实影响。

参考成绩

进步速度：一年内从 ~33% 到 ~74%。这个速度说明三件事——模型能力确实在快速提升 + Agent harness 工程在大幅改进 + 部分提升可能来自对评测的"针对性优化"而非通用能力增长。

GAIA：对人类简单，对 AI 超级难

怎么造的：Meta 2023 年发布，466 道题。每道题需要多步推理——搜索、浏览网页、处理文件、做简单的数学——但不需要专业技能。

典型题目："找到 2023 年诺贝尔物理学奖得主的出生城市，把城市名的字母数作为答案。"

解法：搜索"2023 Nobel Prize Physics" → 找到名字 → 搜名字 + "born" → 找到城市 → 数字母 → 输出数字。

人类平均分 92%。2023 年底最好的 AI 在 GAIA 上只有 15%。

为什么人和 AI 差距这么大：因为 GAIA 测的不是"知不知道"，而是"知不知道怎么去查"。模型可能"知道"诺奖得主是谁，但如果它不知道（2023 年的信息在其训练截止日期之后），它需要上网查、读网页、提取信息、做简单的计算——这套"感知→搜索→阅读→推理→输出"的链条，每一个环节都可能断。

WebArena：在假网站里真操作

怎么造的：搭建了 4 个假的但功能完整的网站（电商、论坛、地图、CMS），让 Agent 在浏览器里完成 812 道任务。

典型题目："在 OneStopMarket（电商网站）上搜索 'wireless keyboard'，把最便宜的那款加入购物车。"

人类水平：~78%。最好 AI（OpenAI Operator）：58.0%。最好开源：48.0%。

OSWorld：在真实电脑上操作真实软件

怎么造的：369 道任务，跨 Windows/macOS/Ubuntu，操作 Excel、图片编辑器、终端、浏览器。

典型题目："打开 Excel，读取 sales.xlsx，创建一个柱状图显示各区域季度销售额，导出为 PNG。"

人类水平：>72%。最好 AI：Agent S3 w/ bBoN 63.5%。但这个 63.5% 是 2025 年底的分数，比年初的 38% 涨了一大截——说明这个领域的进展极其快。

人类和 AI 的差距分布（为什么 63.5% 不等于"快赶上了"）：AI 擅长的是"在浏览器里填表单、搜商品"这类结构化操作，人类擅长的是"理解模糊的指令、处理意外情况"——OSWorld 里后者的比例高，所以总分看起来接近不等于能力等同。AI 在可编程任务（填表）上已经 80%+，在需要常识推理的任务上不足 30%。

问题一：成本不控制 = 分数靠钱堆

"AI Agents That Matter"（Kapoor et al., 2025）做了最有力的论证：简单的 retry-with-temperature 策略在 HumanEval 上击败了复杂的 Agent 架构。因为 HumanEval 提供了测试用例，Agent 只管采样——花 10 倍的 token，pass@1 自然上去了。如果你在排行榜上看到"Agent X 85%，Agent Y 82%"，但 X 每次请求花了 Y 的 10 倍 token——X 不一定更好，X 只是更贵。

要做的事：所有 Agent 评测必须报告总 token 花费。分数的分母不是"题目数"，是"题目数 × 花费"。

问题二：不可复现

OAgents（EMNLP 2025）检查了多个声称"开源 SOTA"的 Agent 系统——大量无法用公开代码复现论文里的成绩。同一份代码跑两次的分数波动不可忽略。这不是作弊——Agent 本身是非确定性的，但如果评测协议不要求控制随机种子和多次运行取均值，排名就不可靠。

问题三：评测本身也在老化

HumanEval 用了 5 年，饱和了。SWE-bench 用了 2 年，局限性被逐条发现。任何一个"固定的"评测集都在走向过期——因为模型被针对性优化、因为数据污染、因为题目本身的问题被暴露。评测需要和模型一起进化。

四层评测策略

第一层：冒烟测试（每次改动都该跑） - 用 HumanEval 只做冒烟——分数暴跌说明改坏了。分数不变是正常的 - 控制：固定温度=0、固定 run=1 次、记录 token 花费

第二层：编辑能力（每个版本该跑） - Aider Polyglot——测的不是"会不会写代码"，是"产出的 diff 能不能被机器自动应用" - 特别关注编辑格式合规率——你的 Agent 改的代码再对，如果格式乱七八遭需要人工整理，就不是 Agent

第三层：真实任务（里程碑节点跑） - SWE-bench Lite（300 题，比 Verified 便宜）或你自己构造的一个"内部 bug 集" - 必须记录花费：总 token 数 / 解决题数。两个 Agent 比较时看"每解决一题花了多少钱"而非"解决了多少题"

第四层：你自己的真实任务（最重要） - 收集你实际遇到的、需要 Agent 解决的问题，做成可重复运行的测试 - CodeWhale 的错题本做法直接搬：每次 Agent 搞砸了 → 记下来 → 写一个测试 → 下次跑这个测试验证修好了

一个务实建议

不要为了刷榜而优化。 你刷榜刷出来的 Agent，大概率只在榜上好用。把时间花在让你的 Agent 在你的场景里更好用——跑分是别人的事，好用是你的事。