大模型与 AI Agent Benchmark 全景指南：它们究竟在评估什么

看模型发布报告时，我们经常会遇到一长串名字：ARC-E、ARC-C、MMLU、GPQA、GSM8K、HumanEval、SWE-bench、GAIA、WebArena、OSWorld……它们的分数不能直接横向比较，因为每个 benchmark 测量的能力、输入形式、可用工具和评分方式都不同。

本文整理一张从“大模型答题”到“Agent 完成真实任务”的评测地图，并解释每个常见 benchmark 究竟是什么、适合测什么，以及不能从分数中推出什么结论。

先澄清两个常见误区

1. SWE-bench 是 benchmark，SWE-agent 不是。SWE-bench 提供 GitHub issue、代码仓库和测试；SWE-agent 是让语言模型操作仓库、修改代码并解决 issue 的 Agent 系统。
2. ARC-E / ARC-C 与 ARC-AGI 不是同一个 ARC。前者来自 AI2 Reasoning Challenge，是科学选择题；后者使用彩色网格测试抽象规则归纳。

1. Benchmark 测的到底是模型，还是系统

评测对象可以分为三层：

因此，Agent benchmark 的分数不是“底层模型智商”。同一个模型放入不同的搜索策略、工具接口、上下文压缩和错误恢复框架，结果可能差很多。更准确的表示是：

1
2
3
4
5

Agent 结果 = 模型能力
           + Agent scaffold
           + 工具与环境
           + 推理预算
           + 评测协议

2. 一张快速索引表

下面按能力类型展开。

3. 知识、常识与文本推理

3.1 ARC-E 与 ARC-C：小学科学选择题

AI2 Reasoning Challenge（ARC） 收集三至九年级的科学考试题，并分成两个子集：

• ARC-Easy（ARC-E）：相对容易，很多题可通过基础事实或直接推理回答；
• ARC-Challenge（ARC-C）：由检索和词共现基线都较难回答的问题组成，更强调知识组合与推理。

示意题：

1
2

哪一种变化属于物理变化？
A. 木头燃烧  B. 铁生锈  C. 冰融化  D. 牛奶变酸

主要测量：科学知识、阅读理解、选项比较和短链推理。常用指标是 accuracy。

局限：选择题允许排除法和猜测；题目难度较低时容易饱和，也不能证明模型会做开放式科学研究。

3.2 HellaSwag：哪个后续事件最合理

HellaSwag 给出一个场景或动作描述，要求从四个候选结尾中选择最符合常识的后续。它更关注日常事件的顺序、动作可行性和语境一致性，而不是专业知识。

主要测量：常识推理、事件预测、语言连贯性。指标通常是 normalized accuracy。

局限：仍然是候选排序任务；模型可能利用数据风格或选项统计线索，而不是真的构造世界模型。

3.3 WinoGrande：常识驱动的指代消解

WinoGrande 延续 Winograd Schema 的思路，要求模型判断代词或空缺指向哪个实体。

1
2

奖杯放不进棕色手提箱，因为它太大了。
“它”更可能指奖杯还是手提箱？

主要测量：语法理解、实体关系和常识。局限在于二选一任务容易受模板与数据偏差影响。

3.4 MMLU 与 MMLU-Pro：多学科知识地图

MMLU 用来自 57 个学科的选择题评估多任务知识与问题求解，覆盖数学、历史、计算机、法律、医学、哲学等领域。

它回答的是：模型的知识覆盖是否广，以及能否在不同学科格式间切换。它不直接测量检索、工具使用或长周期任务执行。

MMLU-Pro 将选项从 4 个扩展到 10 个，加入更多需要推理的问题，并降低简单猜测和模板记忆带来的收益。比较报告时必须确认写的是 MMLU 还是 MMLU-Pro，两者分数不能直接等价。

3.5 GPQA：研究生级“Google-Proof”科学问题

GPQA 包含由领域专家编写的生物、物理和化学选择题。原始数据集有 448 题；常见的 GPQA Diamond 是其中质量和难度更高的子集。

主要测量：高难科学知识、多步定量或概念推理，以及模型在陌生专业问题上的可靠性。

局限：题量小，置信区间较大；选择题 accuracy 也无法告诉我们推理过程是否可靠。报告分数时应说明是 GPQA 全集还是 Diamond、是否使用工具以及推理预算。

4. 数学推理

4.1 GSM8K：多步小学数学文字题

GSM8K 包含约 8,500 道高质量小学数学文字题，每题通常需要 2–8 个基本算术步骤。

1
2

一家商店上午卖出 18 个苹果，下午卖出上午的 2 倍，
还剩 14 个。原来有多少个苹果？

主要测量：从自然语言抽取数量关系、安排计算顺序并得到正确结果。常见指标是最终答案 exact match。

局限：它主要是小学算术，不等于高级数学；只比较最终答案时，正确过程和碰巧猜对可能得到相同分数。数据公开时间较久，也需要考虑训练数据污染。

4.2 MATH / MATH-500：竞赛级数学

MATH 涵盖代数、几何、数论、概率等竞赛数学题，通常需要更长的符号推理。MATH-500 是常用于快速评估的 500 题子集。

主要测量：复杂数学推理、公式操作和解题策略。评分常提取最终答案做 exact match，但不同 harness 的答案规范化规则可能不同。

4.3 AIME：更高难度、答案易验证

AIME 题目来自美国数学邀请赛，答案是 000–999 的整数。它难度高，但最终答案容易自动验证，因此经常用于推理模型评测。

需要注意年份、题目集合、采样次数和推理 token budget。pass@1 与允许生成 64 次后取最好结果的分数，代表完全不同的计算预算。

5. 函数级代码生成

5.1 HumanEval

HumanEval 包含 164 个手写 Python 函数任务。模型根据函数签名和 docstring 补全实现，隐藏单元测试判断是否正确。

1
2

def has_close_elements(numbers, threshold):
    """判断列表中是否存在距离小于 threshold 的两个数。"""

常用指标是 pass@k：生成 k 个候选时，至少一个通过测试的概率。它测的是小型函数合成，而不是阅读大型仓库、调试、Git 操作或需求澄清。

5.2 MBPP

MBPP（Mostly Basic Python Problems）包含较基础的 Python 编程题、参考实现和测试用例。它与 HumanEval 都适合测基础代码生成，但题目风格、数据规模和拆分方式不同。

5.3 LiveCodeBench

LiveCodeBench 持续从 LeetCode、AtCoder 和 Codeforces 等平台收集新题，并按时间切分，目标是降低污染和过拟合。除了代码生成，还覆盖 self-repair、代码执行和测试输出预测。

它比 HumanEval 更能反映新题上的算法能力，但仍以相对独立的竞赛问题为主，不等于真实仓库维护。

6. 仓库级软件工程：SWE-bench 与 SWE-agent

6.1 SWE-bench 是什么

SWE-bench 从真实 Python 项目的 GitHub issue 和对应修复中构造任务。系统获得：

1
2
3
4
5

代码仓库 + issue 描述 + 可执行环境
                     ↓
             生成代码 patch
                     ↓
        fail-to-pass / pass-to-pass tests

只有补丁修复目标问题，同时没有破坏原有测试，任务才算 resolved。常见指标是 % Resolved。

常见版本：

• SWE-bench Full：原始完整集合；
• SWE-bench Lite：较小、运行成本更低的子集；
• SWE-bench Verified：500 个经软件工程师确认可解决、描述较清晰的任务；
• SWE-bench Multimodal：issue 中可能包含截图等视觉信息；
• SWE-bench Multilingual：扩展到不同编程语言。

比较分数时，必须同时写明数据集版本、Agent scaffold、模型版本、最大步数、是否使用 test-time scaling，以及评测 harness 版本。

6.2 SWE-agent 是什么

SWE-agent 是一个 Agent-Computer Interface：让模型查看文件、搜索代码、编辑、执行测试并迭代修复。它可以在 SWE-bench 上运行，但它本身不是 benchmark。

可以这样理解：

1
2
3

SWE-bench = 试卷 + 仓库环境 + 判分程序
SWE-agent = 参加考试的解题框架
LLM       = 解题框架内部使用的模型

因此“某模型 SWE-bench 得分”严格来说通常是“某模型 + 某 Agent 实现 + 某推理预算”的系统成绩。

7. Function Calling 与工具使用

7.1 BFCL：函数名和参数能否调用正确

Berkeley Function-Calling Leaderboard（BFCL） 评估模型是否能根据用户请求选择正确函数，并生成结构、参数名、类型和值都正确的调用。

它覆盖单函数、多函数候选、并行调用、多轮状态和“没有合适工具时拒绝调用”等情况。常见评分包括：

• AST evaluation：比较函数调用的抽象语法树；
• Executable evaluation：实际执行调用，检查结果是否正确；
• multi-turn / agentic success：检查多轮工具轨迹是否完成目标。

BFCL 很适合评估 function calling 接口，但单轮高分不代表 Agent 会做长期规划或从工具错误中恢复。

7.2 ToolBench：在大量 API 中选择和组合工具

ToolBench / ToolLLM 围绕大量真实 API 构建工具学习数据与评测，关注工具检索、参数生成和多步调用。

它比简单 function calling 更强调“面对很多候选 API 时找到正确工具”，但自动生成数据、API 可用性和基于模型的评审都会影响可重复性。

7.3 τ-bench：工具、用户和业务政策同时存在

τ-bench 模拟客服等真实场景：Agent 一边与模拟用户多轮对话，一边调用领域 API，还必须遵守业务政策。

它测试的不只是“API 参数有没有写对”，还包括：

• 是否从用户处收集必要信息；
• 是否保持多轮状态；
• 是否遵守退款、改签等规则；
• 是否真正改变了环境状态并满足用户目标。

这类评测常报告 success rate，以及更严格的 pass^k：连续运行 k 次都成功，才能体现稳定性。

8. 通用 Agent、网页和电脑操作

8.1 GAIA：通用 AI 助手

GAIA 包含 466 个现实问题，需要组合推理、网页搜索、多模态文件处理和工具调用，并按三档难度划分。

GAIA 的问题往往对人类并不需要博士知识，但对 Agent 的难点在于找到信息、组合证据、处理文件并输出严格格式的最终答案。它适合测“通用研究助手”，不适合单独归因到底层模型的哪一个能力。

8.2 AgentBench：横跨多种交互环境

AgentBench 将 Agent 放入操作系统、数据库、知识图谱、数字卡牌、网页购物、网页浏览等多个环境，评估其多轮决策和执行能力。

优点是覆盖面广；缺点是不同环境的动作空间和评分尺度不同，聚合总分会隐藏具体短板。

8.3 WebArena：在可复现网站中完成任务

WebArena 提供自托管的电商、论坛、代码托管、内容管理等网站。任务要求 Agent 把自然语言目标转成点击、输入、导航和信息检索动作。

主要测量：网页 grounding、长程规划、表单操作、跨页面状态管理。评分通常检查网站最终状态，而不是只判断最后一段文字。

8.4 OSWorld：真实桌面与跨应用操作

OSWorld 在真实操作系统与应用中评估多模态电脑使用 Agent，包含浏览器、文件系统、Office 类软件、媒体工具和跨应用工作流。

它同时要求视觉理解、GUI 定位、键鼠操作、应用知识和错误恢复。分数受到截图分辨率、动作接口、最大步数和环境稳定性的显著影响。

8.5 PaperBench：复现一篇研究论文

PaperBench 要求 Agent 理解 AI 论文、编写实验代码、运行训练并复现结果，使用细粒度 rubric 评分。

它测试的是长时间尺度上的研究执行能力：论文理解、代码、实验管理、调试和结果验证。它非常接近真实工作，但成本高，也依赖 rubric 与 judge 的可靠性。

9. 常见指标应该怎样读

Accuracy / Exact Match

选择题 accuracy 或最终答案 exact match 最直观，但对格式敏感，也忽略了过程质量。选择题随机基线还与选项数有关：四选一是 25%，十选一是 10%。

pass@k

允许模型生成 k 个候选，只要其中一个通过测试就算成功。k 越大，计算预算越高，因此 pass@1 和 pass@100 不能直接比较。

% Resolved / Task Success Rate

用于 SWE-bench、WebArena、OSWorld 等执行型任务。它比文字相似度可靠，但依赖环境、测试覆盖率和成功判定器。

LLM-as-a-Judge / Rubric score

适用于开放式成果，例如报告、研究复现和复杂轨迹。优点是能评估没有唯一答案的任务；风险是 judge 存在偏好、位置效应、自我偏好和评分漂移。最好报告 judge 模型、rubric、校准集和人工一致性。

成本、延迟与稳定性

Agent 实际部署还应同时报告：

1
2

成功率 / 每次成功成本 / 总 token / 工具调用次数
延迟 / 平均步骤数 / 最大步骤数 / 重复运行方差

一个成功率高但每题调用模型数百次的系统，和一次尝试就完成任务的系统不是同一类能力。

10. 如何为自己的模型选择 benchmark

一个实用的评测组合通常至少包含：

1. 一个与你业务输入相似的静态能力测试；
2. 一个端到端任务成功率测试；
3. 你自己的私有、持续更新回归集；
4. 成本、延迟和多次运行稳定性。

11. 为什么 Benchmark 高分不等于产品可靠

数据污染与 benchmark 饱和

公开题目可能进入预训练或微调数据。时间切分、私有测试集和持续更新 benchmark 可以降低风险，但无法完全消除污染。

Prompt、scaffold 与预算不一致

zero-shot、few-shot、chain-of-thought、工具权限、采样次数、上下文长度和最大步骤都会改变分数。只写模型名、不写配置的数字很难复现。

测试覆盖不足

SWE-bench 补丁通过 tests，不代表代码风格、性能和隐藏需求都正确；GUI 任务的自动检查器也可能遗漏视觉或语义错误。

平均分隐藏能力结构

两个平均分相同的系统，可能一个擅长数学、另一个擅长工具使用。产品选型应看分项和失败案例，而不是只看综合排行榜。

Agent 具有随机性

工具超时、网页状态、采样和长轨迹误差都会造成波动。Agent 评测最好多次运行，并同时报告平均成功率、方差和 pass^k。

总结

可以把常见 benchmark 放在一条逐渐接近真实工作的轴上：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

选择题
  ARC / MMLU / GPQA
      ↓
结构化解题
  GSM8K / MATH / HumanEval
      ↓
工具调用
  BFCL / ToolBench / τ-bench
      ↓
环境中的端到端任务
  SWE-bench / GAIA / WebArena / OSWorld
      ↓
长期、开放式专业工作
  PaperBench / 私有业务评测

越往下，评测越接近真实工作，但也越难复现、成本越高，并且越难把成绩归因给单独的底层模型。正确的问题不是“哪个 benchmark 最权威”，而是：这个评测的任务分布、工具条件和成功标准，是否与我真正想部署的系统一致？

主要资料

• AI2 Reasoning Challenge
• MMLU · GPQA
• GSM8K · HumanEval · LiveCodeBench
• SWE-bench · SWE-agent
• BFCL · τ-bench
• GAIA · AgentBench
• WebArena · OSWorld · PaperBench