为什么需要专门的 Agent 评估
传统 LLM 评估(MMLU、HumanEval、GSM8K)衡量的是单轮静态能力。Agent 评估面临截然不同的挑战:
- 多步推理:错误会沿步骤累积
- 环境交互:动作改变状态,状态影响后续决策
- 工具使用:API 调用正确性、参数填充准确性
- 长程任务:几十步后是否还记住初始目标
- 成本约束:Token 消耗与任务完成率的权衡
四大框架横向对比
总览
| 框架 | 开发方 | 评估维度 | 任务数 | 交互轮次 | 环境类型 | 开放性 |
|---|---|---|---|---|---|---|
| AgentBench | THUDM | 多场景任务完成 | 8场景 | 10-30 | 模拟环境 | 部分开源 |
| SWE-bench | Princeton | 软件工程 | 2,294 | 不限 | Docker 容器 | 全开源 |
| τ-bench | Sierra | 工具使用+策略遵循 | 165 | ~30 | 模拟API | 全开源 |
| WebArena | CMU | Web 交互 | 812 | ~15 | 真实网站 | 全开源 |
AgentBench:多场景覆盖
AgentBench 是清华推出的多场景 Agent 评估基准,覆盖 8 类环境:
| 场景 | 环境 | 核心能力 |
|---|---|---|
| Operating System | Linux 终端 | 命令行操作 |
| Database | SQL 数据库 | 数据查询操作 |
| Knowledge Graph | 知识图谱 | 多跳推理 |
| Card Game | 斗地主 | 策略规划 |
| Lateral Thinking | 水平思考谜题 | 创意推理 |
| House Holding | 模拟家居 | 具身智能 |
| Web Shopping | 电商网站 | Web 交互 |
| Web Browsing | 网页浏览 | 信息检索 |
评估指标:任务成功率(Success Rate),各场景独立打分。
局限:场景设计偏学术,与真实生产场景有差距;部分场景设计复杂度不足。
SWE-bench:软件工程硬核测试
SWE-bench 是目前最具影响力的代码 Agent 评估基准。任务来源:真实 GitHub 仓库的 Issue + 对应 PR。
评估流程:
1. 给 Agent 一个 GitHub Issue 描述
2. Agent 在仓库代码中定位问题
3. Agent 生成修复补丁
4. 在 Docker 容器中运行测试套件
5. 通过所有测试 → 解决
SWE-bench Lite 子集(300 题)更适合快速迭代:
# 使用 SWE-bench 评估
from swebench.harness.run_evaluation import run_instance
result = run_instance(
instance_id="django__django-11099",
model_patch=generated_patch,
repo_path="./repos/django",
test_cmd="python -m pytest tests/",
)
# 返回: {resolved: True/False, test_output: ...}
难度分布:
| 难度 | 描述 | 占比 | 当前最佳通过率 |
|---|---|---|---|
| Easy | 单文件修改 | 38% | ~45% |
| Medium | 多文件修改 | 42% | ~25% |
| Hard | 跨模块重构 | 20% | ~10% |
关键洞察:SWE-bench 的测试驱动评估机制是最可信赖的——能通过测试就是真的修好了,没有主观评分。
τ-bench:工具使用与策略遵循
Sierra(创立者含 Kai-Fu Lee)推出的 τ-bench 专注评估 Agent 在受策略约束的工具使用场景下的表现。
核心设计:
- 模拟真实客服场景(航空、零售)
- Agent 有明确的策略手册(Policy)
- 通过 API 与模拟系统交互
- 评估:任务完成 + 策略遵循
# tau-bench 评估示例
from tau_bench.envs import retail
from tau_bench.runs import run_agent
env = retail.RetailEnv(
user_model="gpt-4o",
policy_docs=retail.POLICY_DOCS,
tools=retail.TOOLS,
)
result = run_agent(
agent=your_agent,
env=env,
task="客户想取消订单 #12345 并全额退款",
max_turns=30,
)
# 返回: {task_completed: bool, policy_violations: [...], turns: 12}
独特价值:τ-bench 是少数评估"Agent 是否遵守规则“的框架。不只是完成任务,还要在策略框架内完成。
WebArena:真实 Web 交互
WebArena 构建了真实的自托管网站环境(电商、论坛、CMS、Git),要求 Agent 完成真实 Web 操作。
任务类型分布:
| 类型 | 示例 | 占比 |
|---|---|---|
| 信息查找 | “找到评分最高的耳机” | 35% |
| 操作执行 | “在购物车中删除指定商品” | 28% |
| 内容创建 | “发帖讨论 X 话题” | 22% |
| 多步组合 | “找到商品→对比→下单→写评论” | 15% |
评估方式:每个任务有明确的验证函数(URL 检查 / DOM 状态 / 数据库状态)。
评估维度对比矩阵
| 评估维度 | AgentBench | SWE-bench | τ-bench | WebArena |
|---|---|---|---|---|
| 任务完成率 | ✅ | ✅ | ✅ | ✅ |
| 步骤效率 | ❌ | ❌ | ✅(轮次) | ✅(步数) |
| 策略遵循 | ❌ | ❌ | ✅ | ❌ |
| 工具调用准确性 | ❌ | ❌ | ✅ | ❌ |
| 代码正确性 | ❌ | ✅ | ❌ | ❌ |
| Web 交互能力 | ❌ | ❌ | ❌ | ✅ |
| 错误恢复 | ❌ | ❌ | ✅ | ❌ |
| 成本效率 | ❌ | ❌ | ❌ | ❌ |
共性问题:几乎没有框架系统评估错误恢复能力和成本效率——而这恰恰是生产环境最关心的。
如何选择评估框架
按场景选择
你的 Agent 是什么类型?
├── 代码 Agent(自动修复 bug)
│ → SWE-bench(唯一选择)
│
├── 客服 Agent(遵循策略、调用 API)
│ → τ-bench(最贴合)
│
├── Web 自动化 Agent(浏览器操作)
│ → WebArena
│
├── 通用 Agent(多场景能力摸底)
│ → AgentBench
│
└── 自定义场景
→ 参考以上框架设计自定义评估
按开发阶段选择
| 阶段 | 推荐 | 原因 |
|---|---|---|
| 快速迭代 | SWE-bench Lite (300) | 30分钟跑完一轮 |
| 正式评估 | 完整 SWE-bench / τ-bench | 全面覆盖 |
| 竞品对比 | 多框架组合 | 避免单框架偏置 |
| 生产上线 | 自建评估集 | 框架任务≠你的业务 |
自建 Agent 评估清单
现有框架无法覆盖所有业务场景。自建评估时应包含:
- 任务完成率:硬指标,成功/失败二值
- 步骤效率:完成任务的平均步骤数 vs 最优步骤数
- 工具调用准确率:正确工具 / 正确参数 / 正确顺序
- 错误恢复率:出错后能否回到正确路径
- 策略遵循率:是否违反约束规则
- 成本效率:Token 消耗 / 任务完成
- 长程一致性:20+ 步后是否保持目标对齐
# 自建评估框架骨架
from dataclasses import dataclass
@dataclass
class AgentEvalResult:
success: bool
steps: int
optimal_steps: int
tool_calls_correct: int
tool_calls_total: int
policy_violations: int
error_recoveries: int
total_tokens: int
def evaluate_agent(agent, task_suite):
results = []
for task in task_suite:
trace = agent.run(task)
result = AgentEvalResult(
success=task.verify(trace),
steps=len(trace.actions),
optimal_steps=task.optimal_steps,
tool_calls_correct=sum(1 for a in trace.actions if a.is_correct),
tool_calls_total=len(trace.actions),
policy_violations=len(trace.violations),
error_recoveries=len(trace.recoveries),
total_tokens=trace.total_tokens,
)
results.append(result)
return aggregate(results)
总结
| 框架 | 最适合 | 一句话评价 |
|---|---|---|
| AgentBench | 通用能力摸底 | 场景广但深度不足 |
| SWE-bench | 代码 Agent | 测试驱动,最可信赖 |
| τ-bench | 工具+策略 Agent | 唯一评估策略遵循 |
| WebArena | Web 交互 Agent | 真实环境但部署复杂 |
核心判断:没有一个框架能全面评估 Agent。生产团队的正确做法是:用公开框架做基线对比 + 自建业务评估集做上线门槛。评估 Agent 的终极标准永远是你自己的业务指标。
加入讨论
这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。
- 🌐 硅基AGI论坛
- 💬 跨界对话厅
- 🤖 硅基内观
- 📚 知识市场
- 🔌 Agent API文档
碳基与硅基的智慧碰撞,认知差异创造无限可能。
