Agent 与 Tool Use Benchmark

开篇：模型能调 API、操作浏览器、完成多步骤任务——这些能力怎么系统化评估？

当 OpenAI 宣布 GPT-4 支持 function calling 时，LLM 从”对话助手”跃升为”工具使用者”。当 Anthropic 让 Claude 操控计算机、Google 让 Gemini 调用搜索和代码执行器时，模型进一步成为”自主 Agent”。

但随之而来的问题是：模型说自己能用工具，怎么客观验证？ 它调对 API 的概率是多少？面对多步骤任务，它会不会在第三步就走偏？遇到工具返回错误时，能不能自主恢复？

在上一篇文章中，我们深入了代码评估——从 HumanEval 到 SWE-bench 的演进。现在进入 Agent 与 Tool Use 评估——LLM 评估中最接近”真实应用场景”的维度。本文将回答：

Agent 能力可以分成哪几个层级？每个层级对应什么评估方式？
BFCL（Berkeley Function Calling Leaderboard）如何系统化评估 function calling？
GAIA 为什么被设计成”对人简单、对 AI 难”？
从 WebArena 到 τ-bench，Web Agent 评估是如何工作的？

Agent 能力的层级

Agent 能力不是一个单一维度，而是一个层级递进的体系。理解这个层级结构对选择合适的 benchmark 至关重要：

Level 1: 单次 Function Calling

最基础的能力——模型接收一组函数定义（JSON Schema），根据用户请求选择正确的函数并填充参数。

核心要求：参数类型正确、值合理、能处理 enum 约束
代表 benchmark：BFCL（Simple、Multiple 类别）
已基本解决：主流闭源模型在此层级准确率普遍超过 85%

Level 2: 多轮 Tool Use

模型需要在多个回合中使用工具，处理工具返回结果，并根据结果决定下一步操作。

核心要求：状态跟踪、结果解析、条件分支决策
代表 benchmark：BFCL Multi-Turn、τ-bench
差距明显：即使是 GPT-4o，多轮任务成功率也显著低于单次调用

Level 3: 自主规划 + 执行 + 纠错

最高层级——模型需要自主分解复杂任务、制定执行计划、调用多种工具、处理异常并调整策略。

核心要求：任务分解、长期规划、错误恢复、效率优化
代表 benchmark：GAIA、WebArena、AgentBench、SWE-bench（Agent 模式）
远未解决：GAIA 上人类成功率 92%，初始 GPT-4 插件模式仅 15%；WebArena 上最佳 GPT-4 Agent 仅 14.41%（人类 78.24%）

评估维度

无论哪个层级，Agent 评估都围绕四个核心维度展开：

维度	衡量什么	典型指标
调用准确率	选择正确函数、填充正确参数	AST 匹配率、执行通过率
任务完成率	端到端完成用户意图	成功率、部分完成率
效率	用最少步骤/token 完成任务	平均步骤数、token 消耗
鲁棒性	面对异常能否恢复	错误恢复率、幻觉调用率

主要 Benchmark 一览

Agent 评估生态已相当丰富，按评估侧重可分为三大类：

Function Calling 类

BFCL（Berkeley Function Calling Leaderboard）：最权威的 function calling 评估，覆盖单次调用、多函数选择、并行调用、相关性判断和多轮交互。V3 版包含 4,441 条测试数据。下文深潜详述。
Gorilla：BFCL 的前身，重点测试 API 调用生成能力。

Web Agent 类

WebArena：在电商、论坛、代码协作、内容管理 4 类真实网站环境中测试自主 Agent。GPT-4 最佳表现仅 14.41%（人类 78.24%），揭示了当前模型与人类在真实网页操作中的巨大差距。
VisualWebArena：WebArena 的多模态扩展，加入视觉理解需求。

通用 Agent 类

GAIA（General AI Assistants）：466 个问题，设计哲学是”对人简单、对 AI 难”。人类成功率 92%，GPT-4 插件模式初始仅 15%。下文深潜详述。
τ-bench：测试 Agent 在模拟客服场景中的多轮工具使用能力，注重状态追踪和错误恢复。
AgentBench：跨 8 种环境的综合评估，包括操作系统、数据库、知识图谱、Web 等。
SWE-bench（Agent 模式）：虽然主要是代码 benchmark，但其 Agent 框架模式（如 SWE-Agent）本质上在评估 Agent 的代码仓库导航和修复能力——参见代码 Benchmark 一文。

下面的雷达图将这些 benchmark 的评估维度综合可视化，展示不同模型在 Agent 能力各维度上的相对表现：

Agent 能力雷达图

GPT-4oClaude 3.5 SonnetGemini 1.5 ProLlama 3.1 70BQwen 2.5 72B(最多选 3 个)

数据来源：BFCL v3、GAIA、τ-bench、AgentBench 等排行榜，经归一化至 0-100 分。仅供定性比较，不同 benchmark 量纲不同。

交互说明：勾选模型对比其 Agent 能力轮廓（最多 3 个）。悬停在顶点上查看具体分数和数据来源。注意闭源模型在 function calling 和规划能力上的优势，以及开源模型在效率上的竞争力。数据经归一化处理，仅供定性比较。

趋势：从”能不能调对一个 API”到”能不能自主完成复杂任务”

Agent 评估的演进与代码评估类似——评估粒度不断提升：

2023 年：Gorilla 建立了 API 调用生成评估范式。问题很”干净”——给定函数定义，填对参数就行。GAIA 和 WebArena 同年发布，将评估推向真实任务场景。
2024 年：BFCL v1（2024 年 2 月）正式上线并快速迭代至 v3，加入多轮交互、缺失参数、幻觉检测。τ-bench 也在同年发布，聚焦于长程状态管理和错误恢复。
2025 年：Agent 评估进一步走向实际应用场景——这是当前模型最薄弱的环节。

核心趋势是：单次调用已近饱和，差距在多步骤、长时间、需要纠错的场景中。这也解释了为什么 GAIA 和 WebArena 的绝对分数远低于 BFCL——它们测试的是更高层级的能力。

深潜 1: BFCL — 系统化的 Function Calling 评估

为什么选择 BFCL 深入？

BFCL（Berkeley Function Calling Leaderboard）是目前最系统、更新最频繁的 function calling 评估。它的优势在于：

覆盖全面：从单次调用到多轮交互，从简单参数到复杂嵌套
评估严格：AST 匹配 + 可执行验证双重检查
持续更新：从 v1 到 v4 不断演进，反映真实需求变化
社区标准：几乎所有新模型发布都会报告 BFCL 分数

评估框架

BFCL 的核心设计是将 function calling 分解为四个递进类别：

Simple（单函数调用）：给定一个函数，正确填充参数。最基础的测试。
Multiple（多函数选择）：提供多个候选函数，模型需要选择正确的那个。测试”理解意图→匹配函数”的能力。
Parallel（并行调用）：用户请求需要同时调用多个函数。测试”识别并行需求”的能力。
Relevance（相关性检测）：提供函数定义但用户请求与其无关。模型应拒绝调用，直接回复。测试”不该调时别乱调”的能力。

BFCL 评测流程示例

给定一个函数，正确填充参数

1输入

可用函数

{
  "name": "get_weather",
  "parameters": {
    "location": { "type": "string" },
    "unit": { "type": "string",
              "enum": ["celsius", "fahrenheit"] }
  }
}

用户请求

"北京今天天气怎么样？用摄氏度"

2输出 & 验证

模型输出

get_weather(
  location="Beijing",
  unit="celsius"
)

评估结果

✅ AST 匹配: 函数名正确，参数类型和值正确

BFCL 使用 AST（抽象语法树）匹配和可执行验证两种方式评估函数调用正确性。

交互说明：点击上方标签切换 4 种测试类别。左侧是模型接收的输入（函数定义 + 用户请求），右侧是期望的输出和验证方式。注意 Relevance 类别——这是很多模型的薄弱环节，容易出现”过度调用”（hallucinated function calls）。

评分方式

BFCL 使用两种互补的评估方法：

AST 匹配：将模型输出解析为抽象语法树，与标准答案比较。函数名、参数名、参数值、参数类型都必须完全匹配。这是最严格的方式。
可执行验证：实际执行模型生成的函数调用，检查返回结果是否正确。这允许不同的参数格式（例如 "Beijing" vs "beijing"），只要最终执行结果一致即可。

V3 版本还引入了多轮评估的专用指标：

基于状态的评估：对比函数调用后的系统状态是否与预期一致（特别重要的是写入/删除操作）
子集匹配：允许模型通过不同路径达到正确结果，只要最终结果包含所有必要信息

数据规模与结构

BFCL V3 包含 4,441 条测试数据：

非实时单轮：1,390 条
实时单轮：2,251 条
多轮：800 条增强场景（4 类 × 200 条，基础 200 条单独计算）
幻觉检测：240 条

增强多轮场景特别值得关注——它们模拟真实使用中的困难情况：缺失参数（用户没说完整）、缺失函数（需要的工具不可用）、长上下文（大量无关信息干扰）、复合场景（以上三种同时出现）。

已知局限

BFCL 尽管优秀，仍有明确的局限：

函数定义预设：真实场景中 Agent 可能需要自己发现可用工具，而非从预定义列表中选择
评估粒度：AST 匹配过于严格——有时参数值在语义上等价但格式不同（如日期格式 2025-01-16 vs Jan 16, 2025）
不测试工具结果处理：评估止步于”调对了没有”，不涉及”拿到结果后怎么用”
静态评估：缺乏动态环境中的适应性测试——真实 Agent 需要根据工具返回调整策略

深潜 2: GAIA — “对人简单、对 AI 难”的哲学

为什么选择 GAIA 深入？

GAIA 代表了 Agent 评估的另一个极端——不是测试模型能否调对一个函数，而是测试模型能否像人类一样综合使用多种能力完成实际任务。它的设计哲学直接挑战了”刷分即进步”的惯性思维。

数据集设计

GAIA 包含 466 个问题，每个问题都有一个明确的、可验证的答案（通常是一个数字、名字或事实）。问题按难度分三个层级：

Level 1（基础，约 31% 的问题）——通常需要 1-2 步操作：

“2023 年诺贝尔物理学奖得主的出生城市的人口是多少？”

需要：搜索 → 找到人名 → 搜索出生地 → 查人口数据

Level 2（中等，约 53%）——需要 3-5 步，涉及多种工具：

“下载这个 Excel 文件，计算第三列的平均值，然后找到最接近该值的质数”

需要：文件下载 → 数据处理 → 数学计算 → 质数判断

Level 3（困难，约 16%）——需要复杂推理 + 多种工具 + 长程规划：

需要跨多个网站交叉验证信息、处理多模态内容、进行多步逻辑推理

”对人简单、对 AI 难”的设计哲学

这是 GAIA 最具洞察力的设计决策。它的论文明确指出：

“GAIA’s philosophy departs from the current trend in AI benchmarks suggesting to target tasks that are ever more difficult for humans.”

传统 benchmark（如 MMLU、MATH）追求”越难越好”——问题对人类也很难，需要专业知识。GAIA 反其道而行之：设计普通人能在几分钟内用搜索引擎解决的问题。

人类成功率 92%。但最初的 GPT-4 插件模式仅获得 15%。

这个巨大的差距揭示了一个重要事实：当前 AI 的瓶颈不是知识储备，而是”把简单步骤串起来”的执行能力。人类觉得理所当然的操作——打开网页、看一眼表格、记住中间结果、调整搜索关键词——对 AI Agent 来说仍然是巨大的挑战。

评估方式

GAIA 的评估极其简洁：答案通常是一个短字符串，精确匹配即可。没有部分得分——要么完全正确，要么错误。这种”非此即彼”的评估方式确保了结果不可刷分：模型要么真正完成了任务，要么没有。

466 个问题中，166 个用于公开开发集（答案公开），300 个用于隐藏测试集（防止过拟合）。

对评估体系的启发

GAIA 的思路对整个 LLM 评估领域有深远影响：

难度不等于价值：测试”正常人能做的事”可能比测试”专家才能做的事”更有诊断价值
端到端比分步重要：GAIA 不检查中间步骤，只看最终答案——这更接近用户关心的事情
组合能力比单一能力重要：每个子步骤都简单，但组合起来就成了 AI 的盲区

从 Agent 评估到模型选型

本文覆盖了 Agent 与 Tool Use 评估的核心维度。回顾关键要点：

层级递进：从单次 function calling 到自主规划执行，评估难度指数级上升
BFCL 的系统化：四类测试 × 两种评分方式，是 function calling 能力最细粒度的度量
GAIA 的哲学：用”简单问题”暴露 AI 的”执行能力”短板，人类 92% vs AI 15% 的差距极具启发性
真实差距：单次调用已近饱和，但多步骤 Agent 场景仍远未解决

在下一篇文章中，我们将进入模型发布标配解析——当一个模型发布技术报告时，它通常会报告哪些 benchmark？这些”标配”指标反映了什么？