祥哥的技术博客

主题

📅 2026年7月21日 🏷️ AI 应用 ⏱️ 13 分钟阅读 AIAgent评测基准SWE-benchGAIA

AI Agent 评测基准 ​

提出问题 ​

大语言模型本身的评测已经相对成熟——MMLU 测知识、HumanEval 测代码、GSM8K 测数学，输入输出都是确定性的。但 AI Agent 的评测远比这复杂：Agent 需要多步推理、调用外部工具、维护状态、从错误中恢复，结果不是一次输出就能判定的。

一个例子就能说明问题：Task 是"帮我查一下上海明天下午 3 点有没有从浦东到虹桥的火车票，如果有，帮我订一张一等座"。

  • Agent A：花了 10 步，1 步查时刻表、1 步查余票、8 步查各种备选方案，最后成功下单
  • Agent B：3 步搞定——查票 → 发现没票 → 报告"无票"，但漏掉了应该查相邻时段的兜底逻辑
  • Agent C：2 步，查票时 API 超时，直接报错

传统 NLP 指标（BLEU、ROUGE、准确率）完全无法回答"谁更好"——因为任务结果是开放式的，判定标准是"是否完成了用户意图"，而不是"是否输出了一串匹配的字符"。因此，评测基准成了 Agent 落地的关键基础设施：没有合理的评测，就无法衡量 Agent 的能力边界，也无法比较不同方案的优劣。

分析问题 ​

为什么 Agent 评测难 ​

传统 NLP 任务是"单轮、无状态、封闭"的：模型读一段文本，输出一段文本，用精确匹配或语义相似度就能打分。Agent 任务则是"多轮、有状态、开放"的：

维度传统 NLP 评测Agent 评测
交互轮次单轮（一问一答）多轮（自主规划→执行→反馈→纠错）
状态无状态，每次独立有状态，上下文累积、工具调用历史、中间变量
环境封闭，只有输入输出开放，可操作代码执行器、搜索引擎、数据库、API
结果判定精确匹配 / 语义相似度执行结果判定 / 行为轨迹判定 / LLM-as-Judge
失败模式回答错误路径错误、工具调用失败、死循环、成本超限

这使得传统的"给输入→判输出"范式完全失效。Agent 评测需要设计可执行的任务环境和自动化判分机制，而不仅仅是准备一个测试集。

SWE-bench：真实软件工程任务 ​

SWE-bench 是目前最受关注的 Agent 代码评测基准，由 Princeton 团队（John Yang 等人）在 2023 年发布。它的设计思路非常巧妙：从 GitHub 上收集真实 Python 仓库的 Issue 和对应的 PR 修复，让 Agent 直接面对真实世界的代码缺陷。

任务格式：给定一个 Issue 描述（含 bug 复现步骤）和整个仓库的代码快照，Agent 需要生成一个 patch 来修复该 Issue。判分方式是把生成的 patch 应用到仓库上，运行该 Issue 对应的测试用例，检查是否全部通过。

为什么 SWE-bench 比 HumanEval 难得多？

python
# HumanEval 示例：函数级代码生成
def fib(n: int) -> int:
    """返回第 n 个斐波那契数"""
    # 写一行代码就行
    ...

# SWE-bench 示例：需要理解整个仓库
# Issue: "admin change_form template raises AttributeError 
#          when using custom ModelAdmin with no fieldsets"
# Agent 需要读懂 Django admin 源码，定位到 
# django/contrib/admin/options.py 的 render_change_form 方法，
# 修复当 fieldsets 为 None 时的空指针异常。

diff --git a/django/contrib/admin/options.py b/django/contrib/admin/options.py
--- a/django/contrib/admin/options.py
+++ b/django/contrib/admin/options.py
@@ -1,3 +1,5 @@
+    def get_fieldsets(self, request, obj=None):
+        if self.fieldsets is None:
+            return [(None, {'fields': self.get_fields(request, obj)})]
+        return self.fieldsets

HumanEval 给的是单函数签名，Agent 写个函数体就行。SWE-bench 给的是10 万行代码的仓库快照 + 一个 Issue 描述，Agent 要先定位到相关文件，理解上下文，再修改。这中间涉及：

  1. 代码检索：从大量文件中找到相关代码（通常需要 grep + 阅读理解）
  2. 上下文理解：读懂修改位置的上下游逻辑，不破坏现有功能
  3. patch 生成：输出的必须是标准 git diff 格式，否则直接判 0 分
  4. 回归验证：patch 要通过该 Issue 对应的全部测试用例

resolve rate 的演进（来自 SWE-bench 官方排行榜）：

模型/Agent时间Resolve Rate备注
GPT-4 (vanilla)2023.101.7%基本靠蒙
GPT-4 + SWE-agent2024.0412.5%加入工具调用框架
Claude 3.5 Sonnet + SWE-agent2024.0833.2%模型能力提升显著
Devin2024.1213.8%被证实有 benchmark contamination
Claude 3.7 Sonnet2025.0249.9%目前最高
Claude 3.7 Sonnet + Codex CLI2025.0553.7%加 sandbox execution 后更高

踩坑记录：2024 年 Devin 被曝出 SWE-bench 成绩注水——它的评测脚本里包含了"如果 Agent 首次尝试失败，自动重试并替换 patch"的逻辑，这等于给了多次机会。更严重的是，SWE-bench 的 2294 个问题集中，有部分被证实出现在训练数据中（GPT-4 训练截止日期后仍被收录）。所以看排行榜时，一定要看报告里是否有 contamination analysis，否则分数可能虚高 10-20%。

SWE-bench 的局限性：

  • 只覆盖 Python（3 个仓库：Django、Flask、SymPy、requests 等）
  • 只覆盖 bug 修复（不是 feature 开发、重构、代码 review）
  • 倾向于单文件修改（多文件修改的 Issue 占比不到 20%）
  • 测试用例判定有噪音（flaky test 会导致误判）

SWE-bench Verified：修正版 ​

2024 年 12 月，SWE-bench 团队发布了 SWE-bench Verified，去掉了那些有歧义、测试不充分、或环境依赖的 Issue，最终保留约 500 个高质量样本。Claude 3.5 Sonnet 在 Verified 上的 resolve rate 从 33.2% 降到了 28.5%，说明原版确实有水分。目前 Verified 是更受认可的基准版本。

GAIA：通用助手的多步推理 ​

GAIA（General AI Assistants）由 Meta 和 Hugging Face 联合发布，定位是"通用助手"的基准测试。它不要求 Agent 写代码，而是要求 Agent 完成现实世界中的信息检索和推理任务。

GAIA 的题目设计：每个问题都需要多步推理，并且每一步都需要结合不同的信息来源。题目类型包括：

  • 信息检索 + 推理：搜索多个来源，交叉验证后计算答案
  • 多模态理解：读取图片表格、PDF、网页截图
  • 时间敏感：答案依赖实时数据（如"当前汇率"）
  • 反事实推理："如果某条件不成立，会怎样？"

典型题目：

# GAIA 典型题目（L2 难度）
# Q: "2024年巴黎奥运会女子马拉松的金牌得主，在她最后一场马拉松比赛中，
#     平均配速是多少分钟每公里？"

# 解题流程（Agent 需要自主完成）：
# 1. 搜索"2024 Paris Olympics women's marathon gold medalist"
#    → 结果：Sifan Hassan（荷兰），成绩 2:22:55
# 2. 搜索"Sifan Hassan last marathon race before 2024 Olympics"
#    → 需要筛选"最后一场"——可能是 2023 伦敦马拉松
# 3. 搜索"2023 London Marathon women's results Sifan Hassan"
#    → 净成绩 2:18:33
# 4. 计算配速：2:18:33 = 8313 秒，全马 42.195km
#    → 8313 / 42.195 = 197秒/公里 ≈ 3:17 min/km
# 
# 答案需要精确到秒，否则扣分。
# 踩坑点：Sifan Hassan 2023 年跑了 3 个马拉松， 
# 哪个是"最后一场"需要判断时间顺序。

GAIA 的难度分级：

级别步数典型通过率（2024 最强 Agent）特点
L11-3 步60-70%单次搜索 + 简单计算，接近 RAG 场景
L23-6 步35-45%多步推理 + 交叉验证，容易中途偏航
L36+ 步< 15%需要 sub-agent 协作，目前几乎无人能过

GAIA 的判分方式：短文本答案用精确匹配，长文本段落用 LLM-as-Judge（GPT-4 作为判分器）。但这里也有坑——判分器的长度偏好：如果 Agent 的回答很长，判分器倾向于认为"回答更详细"而给高分，即使答案不准确。实践中的做法是同时上报"精确匹配准确率"和"LLM 判分准确率"，两者差异超过 10% 时说明判分器有偏差。

其他重要评测基准 ​

ToolBench：专门评测 Agent 在大量工具（超过 16000 个真实 API）中正确选择并调用工具的能力。评测维度：工具选择准确率、参数构造正确率、返回值处理正确性。2024 年排名靠前的 Agent 工具选择准确率在 75-85%，但参数构造正确率往往只有 60-70% —— 说明 Agent 看 API 文档的能力是短板。

AgentBench：一个多维度评测框架，包含 8 个不同任务环境（网页浏览、数据库操作、操作系统、游戏等）。它的亮点是跨域泛化——同一个 Agent 在不同环境下的表现一致性。实践发现，大部分 Agent 在 1-2 个任务上表现好，但跨域能力差，说明目前的 Agent 还缺乏真正的通用性。

MINT：评测 Agent 的自我纠错能力。核心设置是：Agent 首次执行大概率会失败，但允许它看到执行反馈后重新尝试。MINT 的指标是"首次成功率 vs 最终成功率"——如果两者差距大，说明 Agent 利用反馈的能力强。这个指标在实际开发中很有用：你写 Agent 的时候，工具调用报错后的 retry 逻辑是不是真的有效？MINT 就是测这个的。

评测维度与落地实践 ​

面试高频考点：怎么评测一个自己开发的 Agent？

面试官："你在项目中怎么评估 Agent 效果？"
→ 不能只说"用 SWE-bench 跑一下"，那是学术评测，不是生产评测。

正确答案框架：
1. 单元级：每个 tool 的调用准确率，参数构造正确率
2. 任务级：端到端成功率（Pass Rate），平均步数，平均耗时
3. 质量级：LLM-as-Judge 打分，人工抽检
4. 成本级：单次任务 token 消耗，API 调用次数
5. 边界测试：超时、工具异常、上下文溢出、幻觉输出

生产环境中的评测矩阵：

维度指标典型阈值面试时说
成功率End-to-End Pass Rate> 80% 可上线"我们目标 85%，低于 70% 不发布"
效率平均步数 / 平均耗时< 5 步 / < 30s"步数超过 10 的做 trace 分析"
成本单次任务 token 消耗< 10k tokens"用 4o-mini 做简单步骤，AGI 做复杂推理"
鲁棒性工具调用 retry 成功率> 90%"retry 3 次后放弃，记录失败原因"
安全性幻觉率 / 注入攻击成功率< 5%"用 prompt 注入测试集每周跑一次"

踩坑总结：

  1. 评测集泄漏：2024 年多个 benchmark 被曝出 contamination。对策：在业务数据上构建私有评测集，至少 100 条，覆盖真实用户场景
  2. 判分器偏差：LLM-as-Judge 有长度偏好。对策：同时用 rule-based 判分，双指标交叉验证
  3. flaky test：30% 的 SWE-bench 测试用例在重跑时结果不一致。对策：每个测试跑 3 次，取多数结果
  4. 成本失控：一个 Agent 评测跑完整的 SWE-bench 需要 $200+ 的 API 费用。对策：先在小样本（50 条）上调参，最终验证再跑全量

总结 ​

Agent 评测的核心挑战是从"静态判分"转向"动态执行环境评测"。当前最有影响力的基准是 SWE-bench（真实代码修复）和 GAIA（通用多步推理），但两者都只覆盖了 Agent 能力的一个子集。

实际落地时，建议：

  • 在自己的业务场景上构建定制化评测集，用真实用户任务标注，至少 100 条
  • 同时关注成功率、步数、成本、工具调用准确率四个维度，不要只看 pass rate
  • 用 LLM-as-Judge 做最终判分时，同时用 rule-based 判分做交叉验证，避免判分器偏差
  • 不追求单一指标的绝对数字，而是关注不同 Agent 方案在固定预算下的相对表现
  • 定期做 contamination 检查，防止 benchmark 分数虚高

参考 ​

参考：SWE-bench 主页（https://www.swebench.com/）、GAIA 论文（Meta + Hugging Face，2023）、ToolBench 论文（Tool Learning with Large Language Models）、AgentBench 论文（AgentBench: Evaluating LLMs as Agents）、MINT 论文（MINT: Evaluating LLMs in Multi-turn Interaction with Tools and Language Feedback）、Agent 评测综述（Are LLMs Good Agents? A Survey of Agent Benchmarks and Evaluation）

面试推荐：常考"如何评测一个 Agent 的质量"，上面的评测矩阵足够回答。面试官追问"SWE-bench 和 GAIA 的优缺点"时，强调证据——各自的局限性、已知的 contamination 问题、判分器偏差。

手撕 → 框架 → 生产化，一步步把 AI Agent 工程化搞透。

Copyright © 2026 祥哥