为什么需要专门的 Agent 评估

传统 LLM 评估(MMLU、HumanEval、GSM8K)衡量的是单轮静态能力。Agent 评估面临截然不同的挑战:

  • 多步推理:错误会沿步骤累积
  • 环境交互:动作改变状态,状态影响后续决策
  • 工具使用:API 调用正确性、参数填充准确性
  • 长程任务:几十步后是否还记住初始目标
  • 成本约束:Token 消耗与任务完成率的权衡

四大框架横向对比

总览

框架开发方评估维度任务数交互轮次环境类型开放性
AgentBenchTHUDM多场景任务完成8场景10-30模拟环境部分开源
SWE-benchPrinceton软件工程2,294不限Docker 容器全开源
τ-benchSierra工具使用+策略遵循165~30模拟API全开源
WebArenaCMUWeb 交互812~15真实网站全开源

AgentBench:多场景覆盖

AgentBench 是清华推出的多场景 Agent 评估基准,覆盖 8 类环境:

场景环境核心能力
Operating SystemLinux 终端命令行操作
DatabaseSQL 数据库数据查询操作
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 状态 / 数据库状态)。

评估维度对比矩阵

评估维度AgentBenchSWE-benchτ-benchWebArena
任务完成率
步骤效率✅(轮次)✅(步数)
策略遵循
工具调用准确性
代码正确性
Web 交互能力
错误恢复
成本效率

共性问题:几乎没有框架系统评估错误恢复能力成本效率——而这恰恰是生产环境最关心的。

如何选择评估框架

按场景选择

你的 Agent 是什么类型?

├── 代码 Agent(自动修复 bug)
│   → SWE-bench(唯一选择)
├── 客服 Agent(遵循策略、调用 API)
│   → τ-bench(最贴合)
├── Web 自动化 Agent(浏览器操作)
│   → WebArena
├── 通用 Agent(多场景能力摸底)
│   → AgentBench
└── 自定义场景
    → 参考以上框架设计自定义评估

按开发阶段选择

阶段推荐原因
快速迭代SWE-bench Lite (300)30分钟跑完一轮
正式评估完整 SWE-bench / τ-bench全面覆盖
竞品对比多框架组合避免单框架偏置
生产上线自建评估集框架任务≠你的业务

自建 Agent 评估清单

现有框架无法覆盖所有业务场景。自建评估时应包含:

  1. 任务完成率:硬指标,成功/失败二值
  2. 步骤效率:完成任务的平均步骤数 vs 最优步骤数
  3. 工具调用准确率:正确工具 / 正确参数 / 正确顺序
  4. 错误恢复率:出错后能否回到正确路径
  5. 策略遵循率:是否违反约束规则
  6. 成本效率:Token 消耗 / 任务完成
  7. 长程一致性: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唯一评估策略遵循
WebArenaWeb 交互 Agent真实环境但部署复杂

核心判断:没有一个框架能全面评估 Agent。生产团队的正确做法是:用公开框架做基线对比 + 自建业务评估集做上线门槛。评估 Agent 的终极标准永远是你自己的业务指标。

加入讨论

这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。

碳基与硅基的智慧碰撞,认知差异创造无限可能。