智能体评测基准（Agent Evaluation Benchmark）正在成为衡量 AI Agent 真实能力的事实标准。过去我们靠主观试用判断一个 Agent 好不好用，但当 Agent 开始接管写代码、操作浏览器、调用工具这类多步骤任务后，主观感受就远远不够了。你需要一套可重复、可量化、可横向对比的评测体系，才能知道模型升级、Prompt 调整、工具集改动究竟带来的是进步还是倒退。本文梳理主流 Agent 评测基准的选型逻辑，并给出可落地的自建评测方案。尤其当团队同时维护多条 Agent 流水线时，没有统一评测就等于在黑箱里迭代，任何一次看似聪明的”优化”都可能悄悄引入回归而无人察觉。
一、为什么 Agent 需要专门的评测基准
聊天机器人的评测可以用对话轮次、满意度打分解决，但 Agent 的核心特征是自主完成多步骤任务：读上下文、调工具、改代码、看反馈、再决策。这种长链路里有太多会出错的环节——工具参数写错、环境状态污染、陷入死循环、成本失控。只问”最终答对了没”会掩盖过程缺陷，因此 Agent 评测必须把任务成功率、工具调用准确率、轨迹效率、鲁棒性和成本拆开度量。它本质上是 Agent 工程化的”测试金字塔”底座，配合持续集成才能在每次改动后快速回归。一个常被忽视的点是：Agent 的输出具有随机性，单次运行通过不代表稳定，必须用小样本多次采样取均值，否则分数会随运气剧烈抖动。
二、主流 Agent 评测基准全景
下面四个基准覆盖了代码、通用环境、浏览器与商业交易四类典型场景，是当前论文和工程团队引用最多的组合。
| 基准 | 任务形态 | 核心指标 | 适用场景 |
|---|---|---|---|
| SWE-bench | 真实 GitHub Issue 修复 | 补丁通过率 resolved rate | 代码智能体 |
| AgentBench | 8 类真实环境（OS/DB/Web/KG） | 平均任务成功率 | 通用 Agent 综合能力 |
| WebArena | 自托管网站多步操作 | 任务成功率 | 浏览器智能体 |
| tau-bench | 客服交易（工具 + 用户） | 奖励率 pass^tau | 工具调用型 Agent |
三、SWE-bench：让 Agent 修真实 GitHub Issue
SWE-bench 的每条样本来自真实开源仓库的 Pull Request：给定 Issue 描述与代码基线，Agent 需要产出一个能通过仓库测试的补丁。它最大的价值是用真实工程难度替代玩具题，连 GPT-4 级别模型在 Lite 子集上也只有三成左右通过率，能拉开模型与编排策略的差距。运行官方 harness 非常直接：
pip install swesmith
python -m swesmith.harness.run --dataset princeton-nlp/SWE-bench_Lite --agent my_agent --model claude-sonnet-4Agent 产出的补丁必须是标准 git diff，评测端会把它应用到干净基线上跑测试。一个典型的修复补丁长这样：
diff --git a/src/parser.py b/src/parser.py
--- a/src/parser.py
+++ b/src/parser.py
@@ -42,7 +42,7 @@ def parse(expr):
- return eval(expr) # 危险且不可控
+ return safe_eval(expr) # 受限求值，避免任意代码执行四、AgentBench：跨环境的综合能力标尺
AgentBench 把 Agent 放进操作系统命令行、数据库、网页、知识图谱等 8 类沙箱环境，统一用任务成功率打分，适合衡量一个 Agent 框架的通用迁移能力而非单一技能。本地跑一个子集只需几行代码：
from agentbench import run_benchmark
result = run_benchmark(
agent=my_agent,
envs=["os", "db", "web", "kg"],
shots=3,
)
print(result.summary())
# => {'os': 0.41, 'db': 0.55, 'web': 0.33, 'kg': 0.62, 'avg': 0.48}五、WebArena 与 tau-bench：网页与商业交易
WebArena 在自托管的购物、论坛、Git 类网站环境里跑多步操作，衡量 Agent 能否”看懂页面再点击”。tau-bench 更进一步引入一个扮演用户的模拟器与一组工具 API（查订单、改地址、退款），用奖励率 pass^tau 衡量 Agent 在用户反复改口、工具返回异常时是否仍稳定收敛。两者共同补足了”工具调用 + 图形界面”这类贴近生产的场景，和大模型工具调用 Function Calling 实战里提到的工具编排能力形成闭环验证。
六、自建评测的五个维度
直接套用公开基准成本高、且与业务距离远。多数团队更划算的做法是围绕自己的任务抽一套轻量评测集，至少覆盖下面五个维度：
| 维度 | 定义 | 采集方式 |
|---|---|---|
| 任务成功率 | 最终是否达成目标 | 规则 / 人工判定 |
| 工具调用准确率 | 参数与时机是否正确 | 解析轨迹 |
| 轨迹效率 | 步数 / token / 耗时 | 埋点统计 |
| 鲁棒性 | 面对异常能否恢复 | 注入干扰用例 |
| 单任务成本 | 一次任务花费 | 计量账单 |
七、评测中的四个常见陷阱
1. 只看最终成功率，忽略过程
一个靠运气重试通过的 Agent 和一个一次成功的 Agent 最终成功率相同，但后者显然更可靠。务必把轨迹效率与工具调用准确率一并记录。
2. 测试集泄露与过拟合
把评测集混进训练或 Few-shot，分数会虚高。公开基准尤其要确认没有污染，自建集则要定期轮换样本。
3. 环境状态未隔离
Agent 改了数据库或文件系统却没重置，下一条用例会在脏状态上跑，结果不可复现。每条用例前必须重建干净环境。
4. 指标口径不统一
“成功率”到底算不算人工兜底、”成本”含不含缓存命中，必须在团队内先对齐定义，否则历史分数无法纵向比较。
八、把评测接进 CI：每次改动都回归
最实用的落地是把评测脚本挂到持续集成，模型或 Prompt 一改动就自动跑分并写入报告。下面是一段最小可用的 GitHub Actions 配置：
name: agent-eval
on: [push]
jobs:
eval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install -e .
- run: python eval/run_swebench.py
env:
AGENT_API_KEY: ${{ secrets.AGENT_API_KEY }}
- run: python eval/report.py >> $GITHUB_STEP_SUMMARY九、小结
智能体评测基准把”Agent 行不行”从主观感受变成可追踪的数字。公开基准（SWE-bench / AgentBench / WebArena / tau-bench）适合做横向对标，自建轻量评测集才适合做日常回归。无论哪条路，关键都是多维度、可复现、接进 CI。随着AI 编程智能体从代码补全走向自主编程，以及LangChain Agent 自主编排的普及，评测会成为 Agent 团队和代码测试一样的基础设施。成本维度也别忽视——评测时顺手统计 token 消耗，能和你本地GGUF 量化部署的推理成本直接对照。
