Agent 评测：从测模型到测系统的范式跃迁
当大模型从对话工具进化为自主智能体，评测对象也悄然改变——从单次问答准确率，到多步推理、工具调用、环境交互的系统能力。
当大模型从”对话工具”进化为”自主智能体”，我们评测的对象也悄然改变——不再是单次问答的准确率，而是多步推理、工具调用、环境交互、错误恢复的系统能力。
1. 为什么 Agent 评测是新瓶颈
1.1 Agent 与传统 LLM 评测的本质差异
传统 LLM 评测（MMLU、GSM8K、HumanEval）的默认契约很简洁：一个样本 = 一次 model.generate() → 一个 Score。模型给出一个答案，评分器比对标准答案，输出准确率。这条链路在 Agent 时代彻底失效。
Agent 的行为特征完全不同：
| 维度 | 传统 LLM 评测 | Agent 评测 |
|---|---|---|
| 交互轮次 | 单轮 | 多轮 |
| 输出形态 | 文本 | 文本 + 工具调用 + 环境修改 |
| 失败模式 | 答错 | 答错 + 中途崩溃 + 死循环 + 上下文溢出 |
| 评测对象 | 模型本身 | 模型 + Harness（编排层） |
| 成本透明度 | 单次调用 | 累计 token / API 调用 / 延迟 |
| 可靠性要求 | 一次性正确 | 多次一致性（pass^k） |
一个直观的例子：GPT-4 在 τ-bench 上的 pass@1 是 60%，但 pass^8（同一任务跑 8 次全部成功）只有 25%。这意味着同一任务跑 8 次，只有四分之一的概率每次都对——这对生产部署是致命的，因为一个 70% 单次成功的客服 Agent，每 1000 次请求会失败 300 次。
1.2 Agent 评测的三重挑战
挑战一：评测对象从”模型”扩展到”模型 + Harness”
Agent 的实际表现不只取决于底层 LLM，还取决于包裹它的”基础设施层”——上下文管理、工具接口、生命周期编排、错误恢复。这套基础设施被称为 Agent Harness。研究表明，同一模型在不同 Harness 下，完成率/成本/效率差异可达 4-10 倍。这意味着只报”模型准确率”会严重误导对 Agent 系统的理解。
挑战二：过程数据采集易、聚合难
Agent 一次任务会产出大量过程数据：每一步的推理、工具调用、token 消耗、延迟、错误。但主流评测框架普遍存在”采了用不上”的断层——过程数据落到了 trace 缓存里，却进不了评测报告。以 EvalScope 为例，其 AgentTrace 事件流已采集 step_count、token、latency、tool_call、error、nudge 等事件，但报告层只产出准确率（acc/resolved），过程数据完全不聚合。
挑战三：成本与可靠性长期缺位
学术评测长期聚焦准确率，把成本和可靠性视为”工程问题”。但工业部署的现实是：复杂架构（如 Reflexion，单任务可调 2000 次 API）在准确率上只比 ReAct 好一点点，成本却贵 50 倍。CLEAR 框架的实证显示，只优化准确率的 Agent 比成本感知的替代方案贵 4.4-10.8 倍，且准确率相当。
2. 当前主流 Agent 评测数据集
通过对 τ-bench、SWE-bench、BFCL、GAIA 等主流评测体系的调研，当前 Agent 评测数据集可分为 3 大类。它们分别对应不同的能力维度与评测范式。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────────────┐
│ Agent 评测数据集分类 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 类别1：通用 Agent 推理能力评测 │
│ 代表：GAIA、AgentBench、WebArena │
│ 特征：测多步推理 + 工具使用 + 环境交互的综合能力 │
│ │
│ 类别2：函数调用专项评测 │
│ 代表：BFCL-v3/v4、τ-bench/τ²-bench/τ³-bench │
│ 特征：测工具调用准确性、参数填充、多轮函数调用 │
│ │
│ 类别3：代码 Agent 评测 │
│ 代表：SWE-bench、Terminal-Bench、HumanEval │
│ 特征：测代码修改、测试通过、真实工程问题解决 │
│ │
└─────────────────────────────────────────────────────────────┘
2.1 通用 Agent 推理能力评测
代表数据集：GAIA
GAIA（General AI Assistants Benchmark）由 Meta 等机构提出，包含需要多步推理、工具使用、环境交互的真实世界问题。问题涵盖文件处理、Web 搜索、代码执行、数学计算等。
评测方式：
GAIA 采用 框架驱动的标准 Agent 编排 范式。以 EvalScope 的实现为例，评测流程如下：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
┌──────────────────────────────────────────────────────────────┐
│ GAIA 评测流程（AgentLoopAdapter 范式） │
├──────────────────────────────────────────────────────────────┤
│ │
│ 数据样本 │
│ ┌──────────────────────────────────────────┐ │
│ │ question: "下载附件中的Excel,求和" │ │
│ │ file: task.xlsx │ │
│ │ answer: "12345" │ │
│ └─────────────────┬────────────────────────┘ │
│ ↓ │
│ Adapter 预处理（_post_process_samples） │
│ ┌──────────────────────────────────────────┐ │
│ │ 1. 下载附件到本地 │ │
│ │ 2. 绑定 bash 工具（可执行 Python） │ │
│ └─────────────────┬────────────────────────┘ │
│ ↓ │
│ AgentLoop 核心循环（generate → parse → tool → observe） │
│ ┌──────────────────────────────────────────┐ │
│ │ Step1: model.generate() → "我要读取Excel" │ │
│ │ Step2: parse → tool_call(bash, "python...")│ │
│ │ Step3: tool 执行 → "12345" │ │
│ │ Step4: model.generate() → submit("12345") │ │
│ └─────────────────┬────────────────────────┘ │
│ ↓ │
│ 评分（question_scorer） │
│ ┌──────────────────────────────────────────┐ │
│ │ final_answer="12345" vs ground_truth="12345"│ │
│ │ 支持数值/列表/字符串三种匹配 │ │
│ │ → acc = 1.0 │ │
│ └──────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
评测指标：仅准确率（acc = 0/1）
局限性：
- 只测结果，不测过程：Agent 走 3 步答对和走 30 步答对，acc 都是 1.0，但成本和延迟差异巨大
- 无可靠性维度：单次跑对就给分，不衡量多次一致性
- 沙箱与真实环境差距：Docker 沙箱的网络/文件系统限制可能让 Agent 无法施展真实能力
- 评分器脆弱：字符串匹配对格式敏感，”12345” 和 “12,345” 可能被判错
2.2 函数调用专项评测
代表数据集：BFCL-v3 与 τ-bench
BFCL（Berkeley Function Calling Leaderboard） 是函数调用的事实标准，v3 覆盖 16 个 subset，横跨 4 大类别：单轮/多轮/中文/相关性检测。
τ-bench 则聚焦客服场景的多轮工具-用户-Agent 三方交互，首次引入 pass^k 可靠性指标。
BFCL 评测方式：两层嵌套循环
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
┌──────────────────────────────────────────────────────────────┐
│ BFCL-v3 评测流程（两层嵌套循环） │
├──────────────────────────────────────────────────────────────┤
│ │
│ 外层循环：按 turn（用户驱动） │
│ ┌──────────────────────────────────────────┐ │
│ │ for turn in multi_turn_dialogue: │ │
│ │ user_msg = turn.user │ │
│ │ ┌──────────────────────────────────┐ │ │
│ │ │ 内层循环：按 step（模型驱动） │ │ │
│ │ │ while not should_stop: │ │ │
│ │ │ resp = model.generate(msgs) │ │ │
│ │ │ if resp.has_tool_calls: │ │ │
│ │ │ if should_execute: │ │ │
│ │ │ results = execute_tools() │ │ │
│ │ │ msgs.append(results) │ │ │
│ │ │ else: │ │ │
│ │ │ break # 等待下一轮用户输入 │ │ │
│ │ │ else: │ │ │
│ │ │ break # 模型不再调用工具 │ │ │
│ │ └──────────────────────────────────┘ │ │
│ └──────────────────────────────────────────┘ │
│ │
│ 评分（3 条路径） │
│ ┌──────────────────────────────────────────┐ │
│ │ 1. AST 匹配：参数语法树对比（单轮） │ │
│ │ 2. 相关性检测：拒绝无关函数调用 │ │
│ │ 3. 多轮检查：工具调用序列正确性 │ │
│ │ → acc = float(valid) │ │
│ └──────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
τ-bench 评测方式：可靠性曲面
τ-bench 的核心创新是把”可靠性”从单次成功率升级为多次一致性：
| 指标 | 定义 | 含义 |
|---|---|---|
| pass@1 | 单次成功率 | 模型的”能力上限” |
| pass^k | k 次全部成功的概率 = p^k | 模型的”可靠性” |
| pass^k_ε | 扰动下的 pass^k | 模型的”鲁棒性” |
评测指标：准确率（AST 匹配 / 多轮检查）+ pass^k（仅 τ-bench）
局限性：
- 工具集封闭：BFCL/τ-bench 的工具集是预定义的，无法测 Agent 对未知工具的泛化
- 无成本核算：τ-bench 上游库会算成本，但适配层主动清零，导致无法做成本-准确率 Pareto
- 多轮深度有限：BFCL 多轮通常 3-5 turn，真实客服可能 20+ turn
- 用户模拟器偏差：LLM 模拟的用户行为分布与真实用户有差距
2.3 代码 Agent 评测
代表数据集：SWE-bench
SWE-bench 是代码 Agent 评测的事实标准，从真实 GitHub PR 构造任务，要求 Agent 修复 bug 或实现 feature，通过单元测试验证。
评测方式：双容器沙箱 + patch 验证
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
┌──────────────────────────────────────────────────────────────┐
│ SWE-bench 评测流程（双容器架构） │
├──────────────────────────────────────────────────────────────┤
│ │
│ 阶段1：推理容器（Agent 工作） │
│ ┌──────────────────────────────────────────┐ │
│ │ problem_statement: "TypeError in..." │ │
│ │ base_commit: abc123 │ │
│ │ FAIL_TO_PASS: [test_foo, test_bar] │ │
│ │ PASS_TO_PASS: [test_baz] │ │
│ │ ↓ │ │
│ │ Agent 在 /testbed 工作，修改代码 │ │
│ │ ↓ │ │
│ │ post_run_hook: git diff HEAD → patch │ │
│ └─────────────────┬────────────────────────┘ │
│ ↓ │
│ 阶段2：评测容器（patch 验证） │
│ ┌──────────────────────────────────────────┐ │
│ │ 1. git reset --hard base_commit │ │
│ │ 2. 尝试应用 patch（3种方式） │ │
│ │ - git apply │ │
│ │ - git apply --reject │ │
│ │ - patch --fuzz=5 │ │
│ │ 3. 运行 eval_script │ │
│ │ 4. get_eval_report → resolved: bool │ │
│ └──────────────────────────────────────────┘ │
│ │
│ 评分 │
│ ┌──────────────────────────────────────────┐ │
│ │ resolved = FAIL_TO_PASS 全过 & PASS_TO_PASS 不破 │ │
│ │ → acc = float(resolved) │ │
│ └──────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
评测指标：resolved 率（准确率）
局限性：
- 只看测试通过，不看代码质量：Agent 可能写出能过测试但不可维护的烂代码
- patch 提取有损：新建文件不被
git diff HEAD捕获，导致部分正确解答被判错 - 测试集本身有噪声：部分 PR 的测试不完整或 flaky
- 上下文溢出无感知：长 problem_statement 容易触发
model_length，但当前评测不报告溢出率 - 成本巨大：单实例评测需启动 2 个 Docker 容器，跑测试脚本，耗时可达 30 分钟
3. 总结与展望
当前 Agent 评测的局限性
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
┌─────────────────────────────────────────────────────────────┐
│ 当前 Agent 评测的四大局限 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 局限一：准确性单一维度 │
│ ───────────────────── │
│ 所有 benchmark 报告层只产出 acc/resolved │
│ 过程数据（step/token/latency/tool/error）采了但不聚合 │
│ 成本核算完全缺失（τ-bench 主动清零 cost 字段） │
│ │
│ 局限二：可靠性维度缺位 │
│ ───────────────────── │
│ 仅 τ-bench 有 pass^k，其他 benchmark 都报单次成功率 │
│ pass@1 = 60% 的 Agent，pass^8 可能只有 25% │
│ 生产部署要求 pass^k > 95%，当前评测无法回答 │
│ │
│ 局限三：Harness 与模型混淆 │
│ ───────────────────── │
│ 同一模型 + 不同 Harness，成本/准确率差异 4-10 倍 │
│ 但 benchmark 把"模型能力"和"Harness 质量"混在一起报 │
│ 导致归因错误：明明是 Harness 差，却怪模型不行 │
│ │
│ 局限四：错误恢复与鲁棒性盲区 │
│ ───────────────────── │
│ Agent 中途出错怎么办？当前评测不测 │
│ 工具调用失败能否重试？当前评测不测 │
│ 上下文溢出如何处理？当前评测不测 │
│ 扰动下（同义改写、API 抖动）表现如何？当前评测不测 │
│ │
└─────────────────────────────────────────────────────────────┘
Agent 评测正在经历从”测模型能力”到”测系统能力”的范式跃迁。这个跃迁的核心驱动力是 Agent 从 demo 走向生产——生产部署关心的不只是”能不能做到”，更关心”每次都能做到吗”、”花多少钱做到”、”出错怎么办”。
当前的主流 benchmark 完成了”能不能做到”的评测基建，但离生产级评测还差三个维度：可靠性、成本、Harness 质量。
对于 Agent 评测的实践者而言，现在的关键在于： 谁先把 “准确性 + 过程数据 + 成本 + 可靠性 + Harness 质量” 五维评测闭环跑通，谁就能在生产部署上占据先机。
这不仅是评测问题，更是 Agent 工程化的核心竞争力的来源。