【智能体测评-04】主流Agent Benchmark全景拆解：GAIA、SWE-bench、WebArena、τ-bench、BrowseComp到底在测什么

为什么要拆 benchmark

几乎每个 Agent 产品发布都会附一张 benchmark 成绩表。GAIA 多少分、SWE-bench 百分之多少、WebArena 排第几——数字看起来很硬核，但如果你不了解每个 benchmark 的任务设计和评分机制，这些数字和“跑分”没有区别。

一个 benchmark 的分数有没有意义，取决于三个问题：

1. 它测的能力和你关心的能力是不是同一种？ SWE-bench 高分不等于客服 Agent 做得好。
2. 评分方式能不能真实反映任务质量？ 有些 benchmark 的评分方式存在明显漏洞，模型可以“应试”而非“解题”。
3. 测试集是否已经被污染？ 公开 benchmark 上线越久，训练数据泄漏和过拟合的风险越高。

这篇我们逐个拆，最后给一个横向对比表和我的判断。

GAIA：通用助理的“高考题”

它是什么

GAIA（General AI Assistants benchmark）由 Meta 和 HuggingFace 在 2023 年底发布，目标是测试通用 AI 助理的“真实任务”能力。它的题目设计哲学是：对人类来说很简单（不需要专业知识），但对 AI 来说很难（需要多步推理、工具使用、网络浏览、文件处理）。

题目分为三个难度等级（Level 1/2/3），共 466 道题。每道题都是一个真实世界的任务，比如：

• “查一下某篇论文的第三作者在哪个大学工作，然后找到该大学 CS 系最近招聘的教职岗位中，有多少个方向和这位作者的研究方向匹配”
• “根据这份 PDF 财报，计算公司 Q3 的运营利润同比变化率”
• “听这段播客音频，回答主持人在第 23 分钟提到的那本书的 ISBN”

测什么能力

GAIA 主要测的是多步推理 + 多工具协同 + 多模态理解的综合能力。具体来说：

• 网页浏览和信息检索
• 文件解析（PDF、表格、图片、音频）
• 多步推理和信息整合
• 基础计算和数据分析

它不测试长程对话、不测试代码生成、不测试有副作用的真实操作。对应我们的六维模型，GAIA 主要覆盖感知、规划和工具三个维度，对记忆和反思的考察很弱（单轮任务，没有用户交互）。

评分方式

精确匹配（exact match）。每道题有一个确定的答案（一个词、一个数字、一个名字），模型的输出经过标准化处理后和标准答案比对，完全一致就算对。

这种评分方式的优点是客观、可复现、没有 judge 偏见。缺点是：

• 答案可能有多种表述方式（“MIT”和“Massachusetts Institute of Technology”算同一个答案，但精确匹配可能判错）
• 模型可能在过程中展示了很强的推理能力但最终答案差了一个字母，得 0 分
• 模型也可能蒙对答案但过程全错，得 1 分

已知问题

数据污染是最大的问题。 GAIA 的题目和答案在网上公开，训练数据很可能已经包含了这些题目或类似题目。2024 年以来多个模型的 GAIA 分数从 20% 飙升到 60%+，这个涨幅有多少来自真实能力提升、有多少来自污染，很难厘清。

题目数量太少。 466 道题分三个难度等级，每个等级只有一百多道。统计置信区间很宽，几道题的差异就能改变排名。

不考察过程。 GAIA 只看最终答案，一个用 50 步绕路完成的 Agent 和一个用 5 步高效完成的 Agent 得分相同。这使得它在 L2 轨迹测评层面没有信号。

它在四层框架中的位置

L3 任务测评层。它是端到端的真实任务，但没有生产环境的动态性和副作用，也不考察长程一致性。

分数怎么看

• Level 1（简单）高分：说明模型有基础的多步推理和工具使用能力
• Level 2/3 高分：说明模型在复杂信息整合上有较强能力
• 但要注意：如果一个模型的 GAIA 分数在短时间内跳涨，且没有伴随其他 benchmark 的同步提升，要警惕过拟合或污染
• GAIA 高分不代表 Agent 在你的具体场景里好用——它测的是“通用助理”能力，不是垂直场景能力

SWE-bench：Coding Agent 的试金石

它是什么

SWE-bench 由 Princeton NLP 在 2023 年底发布，任务是：给模型一个真实的 GitHub issue 和对应的代码仓库，让模型生成一个 patch 来解决这个 issue。然后用仓库里的测试用例验证 patch 是否正确。

它的数据来自 12 个流行 Python 开源项目（Django、scikit-learn、sympy、requests 等），共 2294 个任务实例。每个实例包含：

• 一个 GitHub issue 描述（bug 报告或功能请求）
• 代码仓库在 issue 提出时的快照
• 对应的“正确 patch”（开发者实际合入的修复）
• 一组测试用例（能验证修复是否正确的 FAIL_TO_PASS 和 PASS_TO_PASS 测试）

测什么能力

SWE-bench 测的是在真实代码库中理解问题、定位代码、生成修复、验证正确性的端到端能力。这和“写一道算法题”完全不同——它要求模型：

• 理解 issue 的自然语言描述
• 在大型代码库中导航和定位相关文件
• 理解代码的上下文和依赖关系
• 生成最小化的、不会破坏其他功能的 patch
• 通过测试验证

对应六维模型：感知（读代码、读 issue）、规划（定位和修复策略）、工具（代码搜索、文件编辑、测试运行）、执行（生成正确的 patch）都有覆盖。反思维度较弱——大部分 Agent 框架在 patch 生成后不会自我迭代修复。

评分方式

测试用例判定。 模型生成的 patch 被应用到代码仓库后，运行预先标记的测试用例：

• FAIL_TO_PASS：修复前失败、修复后应该通过的测试（验证 bug 确实修了）
• PASS_TO_PASS：修复前通过、修复后也应该通过的测试（验证没破坏其他功能）

两组测试全部通过才算解决（resolved）。最终指标是 resolved rate（解决率）。

这种评分方式是所有 Agent benchmark 中最可靠的之一——测试通过就是通过，没有主观判断空间。但也有一些细节问题：

• 测试可能有 flaky（不稳定、随机失败）
• 有些 issue 的修复可能涉及多个 PR，单一 patch 无法通过所有测试
• 测试覆盖率本身可能不完整，patch 可能“通过了测试但修错了方向”

已知问题

SWE-bench Verified 和 SWE-bench Lite 的分化。 原始 SWE-bench 中有一部分任务被人类标注者认为“描述不清、测试有问题或无法验证”，OpenAI 出资请人筛选出了 500 个高质量任务，称为 SWE-bench Verified。现在厂商宣传的基本都是 Verified 上的成绩。这个子集和全集的难度分布不同，分数不能直接对比。

容器环境和真实开发环境的差距。 SWE-bench 在 Docker 容器中运行，网络隔离、依赖固定、测试预设。真实开发中的 issue 可能涉及跨仓库依赖、环境配置、需求讨论、code review——这些在 SWE-bench 中完全不存在。一个 SWE-bench 80% 的 Agent，在真实开发场景中可能远达不到 80% 的“一次通过率”。

测试导向的过拟合风险。 Agent 可以“刷测试”——反复运行测试、根据测试报错调整 patch，直到通过。这确实是一种能力（调试能力），但也可能导致 patch“为了通过测试而通过测试”，而非真正理解问题本质。

框架差异巨大。 同一个模型，用不同的 Agent 框架（如 SWE-agent、OpenHands、Aider、Devin）跑 SWE-bench，分数差距可以达到 20-30 个百分点。这说明 SWE-bench 测的不只是模型能力，而是“模型 + 框架 + prompt”的系统能力。看分数时必须看用的是什么框架、允许多少步、是否允许 agent 自主运行测试。

它在四层框架中的位置

L2-L3 之间。任务是端到端的（L3），但评分基于测试用例的自动验证，且过程数据（agent 的代码导航轨迹、编辑次数、测试运行次数）也可用于 L2 分析。

分数怎么看

• SWE-bench Verified 50%+：在特定类型的 bug 修复上已经有实用价值
• 70%+：非常强的代码修复能力，但要注意框架和步数限制
• 看分数时必须问：用的什么模型、什么框架、多少步、是否允许自主测试？这些变量对结果影响极大
• SWE-bench 高分基本不反映代码设计能力、架构能力、跨仓库重构能力——它只测“修 bug”

WebArena：浏览器里的“真实任务”

它是什么

WebArena 由 CMU 在 2023 年底发布，提供了一个自托管的、可复现的 Web 环境，包含四个真实开源 Web 应用（电商平台、论坛、CMS 内容管理、GitLab 代码托管），Agent 需要在这些网站上完成真实任务，比如：

• “在论坛上找到标记为 ‘resolved’ 的帖子中，回复最多的那篇，把它的标题改成 ‘Solved: …’”
• “在 GitLab 上找到我最近的一个 merge request，如果它有 CI 失败的 comment，就关闭它”
• “在商城买一件价格低于 50 美元、评分 4 星以上的无线耳机，用默认地址下单”

测什么能力

WebArena 测的是浏览器操作能力——理解网页、点击、输入、导航、处理表单。对应六维模型，它主要覆盖感知（理解 DOM/页面）、工具（浏览器操作）、执行（精确的 UI 交互）。

它对规划和记忆有一定考察（多步任务需要记住目标和中间状态），但对反思的考察很弱——Agent 通常不会回头检查自己是否做对了。

评分方式

基于最终状态的规则校验。 每个任务有一个程序化的验证函数，检查 Agent 操作后网站的最终状态是否符合预期。比如“购物车里是否有正确的商品”“帖子标题是否被修改”“merge request 是否已关闭”。

这种评分方式的优点是客观、自动化。缺点是：

• 只看最终状态，不看过程（可能用了 100 步，但最终对了就给分）
• 有些任务的验证逻辑比较粗糙，可能被“欺骗”
• 不评估操作的安全性（Agent 可能在操作过程中误删了其他数据，但最终状态验证通过）

已知问题

环境维护困难。 WebArena 需要自托管四个 Web 应用，配置复杂、依赖多、容易出环境问题。不同实验室的环境配置可能有细微差异，影响分数可比性。

任务难度和真实世界有差距。 WebArena 的网站是固定的、数据是预设的，不会像真实网站那样改版、出现反爬、有动态加载。而且它的任务大多是“操作型”的，不涉及开放域信息检索或复杂判断。

分数长期在低位徘徊。 WebArena 发布一年多，最好的系统也只在 20-30% 左右（远低于 GAIA 和 SWE-bench 的快速攀升）。这说明浏览器操作是 Agent 的一个真实瓶颈——DOM 理解、元素定位、动态页面处理比想象中难。但也有人质疑：是这些任务对当前模型确实太难，还是 benchmark 本身的交互设计不够好？

和 VisualWebArena 的区别。 WebArena 主要基于 DOM 文本操作，VisualWebArena 增加了截图理解（给 Agent 看网页截图而非纯 DOM）。两者考察的能力不同，分数不能直接比较。

它在四层框架中的位置

L3 任务测评层，但比 GAIA 更接近“操作型”而非“推理型”任务。它在工具使用和执行维度有较好的区分度。

分数怎么看

• WebArena 20%+：说明 Agent 具备基础的浏览器导航和表单操作能力
• 不要把 WebArena 分数和 GAIA/SWE-bench 分数横向比较——它们测的是完全不同的能力
• WebArena 的主要价值不是排名，而是诊断：看 Agent 在哪类网站操作上失败最多（电商 vs 论坛 vs GitLab），可以针对性改进

τ-bench：客服 Agent 的“政策遵从”考试

它是什么

τ-bench（tau-bench）由 Sierra 在 2024 年中发布，是一个面向工具调用型 Agent 的测评 benchmark，重点测的是客服场景下的政策遵从（policy compliance）和多轮一致性。

它的设计很有特色：模拟一个零售客服场景（如航空公司、零售商），Agent 需要：

1. 和一个“用户模拟器”进行多轮对话
2. 在对话中调用工具（查询订单、修改预订、处理退款）
3. 遵守一套详细的政策规则（如“退款只能在购票后 24 小时内”“经济舱改签费 200 美元”“VIP 用户免改签费”）
4. 在多轮对话中保持一致，不“前后矛盾”

测什么能力

τ-bench 的核心考察点和其他 benchmark 不同——它不测“能不能完成任务”，而是测：

• 政策遵从：Agent 是否严格遵守了给定的业务规则，没有越权操作
• 多轮一致性：Agent 在对话的不同轮次中是否保持一致，不会“前面说不能改，后面又给改了”
• 工具调用准确性：在多轮交互中是否选对工具、传对参数
• 用户意图理解：面对用户的模糊表达甚至“诱导”（用户试图让 Agent 违反政策），能不能坚持原则

对应六维模型：工具（核心）、记忆（多轮一致性）、规划（任务流程）、反思（检测到自己前后矛盾时纠正）。

评分方式

τ-bench 有两个核心指标：

1. 任务成功率：Agent 是否正确处理了用户的请求（和其他 benchmark 类似）
2. 政策遵从率：Agent 在整个对话中是否违反了任何政策规则。这是 τ-bench 最有特色的指标——一个“成功完成了任务但违反了政策”的 Agent，在 τ-bench 里是不合格的。

评分由“用户模拟器”自动完成——模拟器在对话结束后检查最终状态是否符合预期，同时检查整个对话历史中是否有违规操作。

已知问题

用户模拟器的局限。 τ-bench 的用户模拟器是基于规则的，它的对话模式比较固定，不能模拟真实用户的所有表达方式和情绪。一个在 τ-bench 上表现很好的 Agent，面对真实用户的“胡搅蛮缠”可能完全不同。

领域较窄。 τ-bench 目前只有零售/航空客服等少数几个领域，政策规则也是人工设计的。它能不能泛化到金融、医疗、法律等合规要求更高的领域，还有待验证。

政策本身可能有歧义。 人工编写的政策规则有时是模糊的（“在特殊情况下经理可以批准例外”），不同 Agent 对“特殊情况”的理解不同，评分时可能产生争议。

它在四层框架中的位置

L2-L3 之间。它有多轮对话和工具调用的轨迹（L2），也有端到端任务完成（L3），但最有价值的信号在 L2——政策遵从和多轮一致性是轨迹级的属性。

τ-bench 是目前所有主流 benchmark 中唯一一个系统考察“政策遵从”和“多轮一致性”的，这两个能力在客服、金融、医疗等高风险场景中至关重要，但在其他 benchmark 中几乎完全被忽视。

分数怎么看

• τ-bench 的政策遵从率比任务成功率更值得关注。一个 90% 成功率但 70% 政策遵从率的 Agent，在生产中是危险的
• 它特别适合对比“纯模型”和“加了 guardrail 的模型”的差异——加了政策约束后成功率可能略降，但遵从率应该显著提升
• τ-bench 高分说明 Agent 在“有规则可依”的多轮工具调用场景中比较可靠，但不代表开放域能力

BrowseComp：OpenAI 的“信息检索”难题

它是什么

BrowseComp 由 OpenAI 在 2025 年初发布，专门测试 Agent 的深度网页浏览和信息检索能力。它的题目特点是：答案在网上存在，但非常难找——需要多次搜索、跨多个网站、深入网页深层内容才能找到。

一个典型的 BrowseComp 题目可能像：

• “某本书的作者在 2019 年的一次播客中提到他最喜欢的一款机械键盘型号是什么？”
• “某个 GitHub 项目在 star 数达到 1000 那天，它的 README 第二行写的是什么？”

这些问题不是“搜一下就有”的——你需要找到正确的播客集数、定位到正确的时间点、或者用 Wayback Machine 查看历史页面。

测什么能力

BrowseComp 聚焦在一个非常具体的能力上：在开放互联网上，通过多步浏览找到难以定位的信息。

对应六维模型：感知（阅读理解网页）、规划（设计搜索策略、决定下一步点哪里）、工具（搜索引擎、浏览器）、执行（精确导航）、反思（搜索方向不对时调整策略）。它不测试代码生成、文件处理、有副作用的操作。

评分方式

精确匹配。每道题有一个确定答案，Agent 的输出和答案匹配就算对。题目数量大约 1000+，分为不同难度。

已知问题

“难”和“有用”不是一回事。 BrowseComp 的很多题目给人一种“数字时代的寻宝游戏”的感觉——找到答案需要很强的浏览能力，但这种能力在多少真实场景中是核心瓶颈？大部分用户的 Agent 使用场景是“帮我订机票”“帮我分析这份报告”，而不是“找到某个网页三年前的某个版本里的一句话”。BrowseComp 可能在测一种“偏科”的能力。

搜索引擎依赖。 BrowseComp 的成绩高度依赖 Agent 用的是哪个搜索引擎、搜索关键词构造得好不好。同一个 Agent 用 Google 和用 Bing，分数可能差很多。这使得“模型能力”和“搜索能力”混在一起。

时效性。 题目答案可能随时间变化（网页被删除、内容被更新），导致原本正确的答案后来无法验证。

它在四层框架中的位置

L3 任务测评层，但能力覆盖面很窄——只测信息检索这一项。

分数怎么看

• BrowseComp 高分说明 Agent 的深度搜索和网页导航能力很强
• 但它不反映 Agent 的规划、工具组合、代码、多轮交互等能力
• 适合作为“信息检索能力”的单项测试，不适合作为 Agent 整体能力的代表
• 如果你的场景大量依赖网络信息检索（如 Deep Research），BrowseComp 的信号比 GAIA 更有参考价值

横向对比

一个共同的盲区

拆完这五个 benchmark，你会发现一个共同的问题：它们几乎都不考察 L4 生产环境中的关键属性。

没有一个 benchmark 系统地测试：

• 长程可靠性：同一个任务跑 100 次，成功率方差有多大
• 安全边界：Agent 在什么情况下会执行危险操作或泄露敏感信息
• 成本效率：完成任务需要多少 token、多少次模型调用、多少钱
• 用户体验：响应速度、交互自然度、错误恢复时的沟通质量
• 跨会话一致性：同一个用户在不同时间使用，Agent 能否保持偏好和上下文一致

这些属性在 benchmark 里不考，但在生产中每一个都可能成为 Agent 能否落地的决定性因素。

公开 benchmark 的信号正在衰减

最后说一个不太乐观但很重要的判断：公开 benchmark 的分数正在逐渐失去信号意义。

原因有三个：

第一，数据污染。 所有公开 benchmark 的题目和答案都在互联网上，模型的训练数据不可避免地包含了这些内容。即使做了去重，模型也可能在预训练阶段“见过”类似题目。一个 benchmark 发布 6 个月后，分数的可比性就开始下降。

第二，过拟合。 厂商有强烈的动机在公开 benchmark 上刷高分——这是最廉价的营销。他们会专门针对 benchmark 的题型做优化、调整 prompt、甚至在训练集中加入类似数据。这不是作弊，但确实让 benchmark 分数和真实能力之间的相关性在降低。

第三，评分漏洞被利用。 随着对 benchmark 的理解加深，研究者和工程师会发现评分机制的漏洞——比如 GAIA 的答案标准化方式可以被“猜”、SWE-bench 可以通过反复跑测试来“刷”、WebArena 的最终状态验证可能被中间操作“欺骗”。这些漏洞被利用后，分数的含义就变了。

这不是说公开 benchmark 没用——它们仍然是衡量模型基础能力进步的重要参照系，SWE-bench 尤其在代码修复场景有很高的参考价值。但你不应该把它们当成 Agent 能力的唯一衡量标准。

真正有区分度的测评，是你基于自己的场景、自己的用户、自己的数据建立的私有测评集。 公开 benchmark 帮你了解“行业大概在什么水平”，私有测评帮你判断“这个 Agent 在我的场景里到底好不好用”。两者不可替代。

小结

这篇拆了五个主流 Agent benchmark：

• GAIA：通用助理的综合题，多步推理+工具，但只看最终答案，污染风险高
• SWE-bench：代码修复最靠谱的 benchmark，测试用例评分客观，但环境和真实开发有差距
• WebArena：浏览器操作能力的标杆，分数长期偏低，说明 UI 操作是真瓶颈
• τ-bench：唯一系统考察政策遵从和多轮一致性的 benchmark，客服/金融场景必看
• BrowseComp：深度信息检索的单项测试，“难”但不一定“有用”

它们都集中在 L2-L3，对 L1 组件级能力和 L4 生产级属性的覆盖都很弱。理解它们的设计和局限，才能在看到一张成绩表时判断：这个分数到底值多少。

下一篇《LLM-as-Judge 的可靠性问题》，我们讨论测评中最常用也最容易被误用的评分方式——让模型当裁判到底靠不靠谱，以及怎么设计才能减少偏见。