A7.2 智能体 Benchmark：怎么给「会办事」打分
从「答得对」到「办成了」
上篇第 7 章讲过怎么给模型打分：出一道题，看它答得对不对。给智能体打分完全是另一回事——你不是在问它「北京到上海怎么订票」，而是让它真的去订，然后检查：票订上了吗？日期对吗？没超预算吧？
难点一下就冒出来了：要评一个智能体，你得先搭一个能自动判定「成功」的真实环境。这比出一道选择题难太多了。
主流智能体 Benchmark 一览
看看业界是怎么解决「判成功」这个难题的（各标提出年份）：
| Benchmark | 考什么 | 环境 | 怎么判成功 | 一句点评 |
|---|---|---|---|---|
| SWE-bench（2023） | 修真实的 GitHub bug | 真实开源仓库 | 跑官方测试套件，全绿即通过 | 判据最硬核——测试是客观的，回扣 A6 |
| GAIA（2023） | 需要多工具协作的助理任务 | 网页+文件+计算 | 对照唯一正确答案 | 逼智能体串起搜索、读文档、算数 |
| WebArena / OSWorld（2023/2024） | 在真实网页/桌面上操作 | 可复位的真实软件环境 | 检查最终状态（订单建了吗、文件改对了吗） | 环境即评测，回扣 A6.3 计算机使用 |
| τ-bench（2024） | 模拟客服（订票、退货） | 带数据库的对话环境 | 检查数据库最终状态 + pass^k 稳定性 | 把稳定性当一等公民 |
一个共同点：越靠谱的 benchmark，越是用「环境的最终状态」而不是「模型说了什么」来判成功。SWE-bench 不看智能体如何雄辩地解释自己的修复，只看测试过不过；τ-bench 不看它多会安慰用户，只看数据库里退款到底退没退。
智能体评测的三个特有难点
比起模型评测，智能体评测多了三座大山：
- 判成功难。开放任务往往没有唯一正解（「写一份调研报告」怎么算对？）。要么搭一个能自动判状态的真实环境（贵），要么请 模型当裁判（继承了上篇 7.2 讲的长度、自信、位置各种偏差）。
- 轨迹也要评。不能只看结果对不对，还要看过程：它有没有绕远路烧掉十倍 token？有没有偷偷执行了危险操作？有没有把用户数据发到不该发的地方（A8 的正题）？结果对了、过程惊悚，一样不能上线。
- 贵且慢。评一道选择题是一次模型调用；评一个智能体任务是一整轮多步交互，可能几十次调用、跑几分钟。跑一遍完整评测集的成本，是模型评测的几个数量级以上。
老坑一个没少，还多了新的
上篇 7.2 讲的评测陷阱，在智能体时代全部继承：
- 数据污染：SWE-bench 里的知名 issue 和它的修复，早就在训练数据里躺着了——模型可能是「背过这道题」而不是「会修 bug」。
- 刷榜：针对某个 benchmark 的特定环境、特定脚手架过拟合，分数好看，换个场景就废。
而且还多了一个新坑：智能体的分数高度依赖脚手架（工具集、提示词、上下文管理策略）。同一个模型，配一套好工具和配一套烂工具，SWE-bench 分数能差出一大截——所以「某模型 SWE-bench 多少分」这个说法本身就不完整，得问「用的什么智能体框架」。
榜单分数 ≠ 你的场景表现（这次更严重）
模型评测里「榜单分不代表实际体验」已经够坑了，智能体这里更甚：智能体的表现是模型 × 工具 × 提示词 × 上下文策略的乘积，换任何一个因子结果都可能天翻地覆。「SWE-bench 排第一」离「能修好你公司代码库的 bug」差着十万八千里——你的代码、你的工具、你的任务分布，都不在那个榜单里。唯一靠谱的评测，是在你自己的任务上评测。这直接引出下一节。
小结
本节要点
- 给智能体打分 = 搭一个能自动判定「事办成没」的真实环境，判据要基于状态不是基于输出文本。
- 主流 benchmark：SWE-bench（跑测试）、GAIA（多工具助理）、WebArena/OSWorld（真实软件操作）、τ-bench（客服+稳定性）。
- 智能体评测三难：判成功难、轨迹也要评、贵且慢；污染和刷榜的老坑一个没少。
- 分数高度依赖脚手架，榜单第一 ≠ 你的场景能 用——一定要在自己的任务上评测。
📝 动手自测0/3
1. SWE-bench 是怎么判定智能体成功修复了一个 bug 的？
2. 设计智能体评测的成功判据时，最不该采用的方式是？
3. 为什么说「某模型 SWE-bench 得了多少分」这个说法不完整？
延伸阅读
- SWE-bench（2023）——真实 GitHub issue 上的代码修复基准，「用测试判成功」的代表作。
- GAIA（2023）——通用 AI 助理基准，任务对人简单、对智能体很难。
- 下一节 A7.3 评测驱动开发：有了评测，怎么用它像做实验一样迭代智能体。