Agent 基准测试与传统 LLM 评测的区别
传统 LLM 评测关注单轮输入输出质量——生成文本是否流畅、知识是否准确、推理是否正确。但 Agent 评测面临根本差异：Agent 需要在多轮交互中自主决策、调用工具、维护状态、处理错误。一次错误的工具调用可能让整个任务失败，即使后续推理完全正确。
Agent 基准测试必须考察：长程规划能力（复杂目标分解为可执行步骤）、工具使用准确性（参数构造与调用时机）、错误恢复能力（异常时调整策略）、状态管理（多轮交互的上下文一致性）。
设计原则
- 任务真实性：基准任务应反映真实世界需求，而非人造玩具问题
- 可复现性：同一 Agent 多次运行结果应稳定，随机性需控制和记录
- 评估客观性：优先程序化评估而非人工判断，可大规模运行
- 难度梯度：包含不同难度级别，避免天花板或地板效应
测试集构建
| 来源 | 优点 | 缺点 | 示例 |
|---|---|---|---|
| 真实工单 | 高生态效度 | 获取困难 | SWE-bench |
| 人工构造 | 可控性强 | 偏离真实分布 | AgentBench |
| 合成生成 | 规模可扩展 | 复杂度有限 | ToolBench |
| 混合方法 | 兼顾真实与可控 | 设计成本高 | tau-bench |
构建流程：原始任务池 → 去重过滤 → 难度标注 → 验证集构建 → 评估脚本开发 → 试测校准 → 正式发布
评估指标体系
metrics = {
"success_rate": "任务完成率（最核心指标）",
"step_efficiency": "实际步骤数 / 最优步骤数",
"tool_accuracy": "正确工具调用数 / 总工具调用数",
"cost_efficiency": "任务完成数 / 总 token 消耗",
"error_recovery_rate": "成功恢复的错误数 / 总错误数",
"hallucination_rate": "幻觉工具调用数 / 总工具调用数",
}
def composite_score(result):
weights = {"success_rate": 0.5, "step_efficiency": 0.2,
"tool_accuracy": 0.2, "cost_efficiency": 0.1}
return sum(result[k] * w for k, w in weights.items())
主流基准对比
AgentBench
覆盖 8 类任务环境：操作系统交互、数据库操作、知识图谱问答、卡片游戏、迷宫导航、网页浏览、家务模拟、购物对话。优势是覆盖面广，局限是部分任务生态效度参差不齐。
SWE-bench
当前最具影响力的软件工程 Agent 基准，任务来源于真实 GitHub 仓库的 Issue-PR 对。评估方式：Agent 生成的 patch 应用后，运行 fail_to_pass 测试是否通过，且 pass_to_pass 测试不回归。
| 版本 | 任务数 | 人工验证 | 推荐场景 |
|---|---|---|---|
| SWE-bench | 2294 | 否 | 研究 |
| SWE-bench Lite | 300 | 否 | 快速评估 |
| SWE-bench Verified | 500 | 是 | 正式评测 |
tau-bench
专注真实商业场景（零售客服、航空客服），核心创新是引入用户模拟器：用 LLM 模拟真实用户与被测 Agent 交互，评估更接近真实对话动态。
async def evaluate_tau_bench(agent, domain="retail"):
env = TauEnv(domain=domain)
for task in env.tasks:
user_sim = UserSimulator(task.user_profile, task.goal)
trajectory = await agent.run(env, user_sim)
db_state = env.get_db_state()
success = env.check_constraints(task.constraints, db_state)
yield {"task_id": task.id, "success": success, "turns": len(trajectory)}
综合对比
| 基准 | 领域 | 评估方式 | 真实性 | 推荐指数 |
|---|---|---|---|---|
| AgentBench | 通用 | 程序化 | 中 | ★★★☆ |
| SWE-bench | 软件工程 | 测试通过率 | 高 | ★★★★★ |
| tau-bench | 客服对话 | 状态检查 | 高 | ★★★★ |
| WebArena | 网页操作 | 程序化 | 高 | ★★★★ |
自定义基准设计
设计模板：明确评估目标 → 定义任务空间 → 设计评估指标 → 构建测试集（≥100个）→ 开发评估脚本 → 试测校准 → 迭代优化
常见陷阱：
- 任务泄露：测试任务出现在训练数据中。对策：使用最新数据、定期更新
- 评估偏差：评估脚本本身有 bug。对策：人工抽查 10% 结果
- 过度简化：天花板效应。对策：设置难度梯度
- 环境脆弱性：测试环境不稳定。对策：Docker 化、固定版本
- 指标单一：仅看成功率忽略成本。对策：多维度指标组合
实战建议
- 优先使用 SWE-bench、tau-bench 等成熟基准，避免重复造轮子
- 针对业务场景补充 20-50 个自定义任务
- 记录每次模型升级的基准成绩，形成趋势图
- 不仅看成功率，还要看 token 消耗和调用次数
- 基准任务每 3-6 个月更新一次，防止数据污染
总结
没有完美的基准，只有最适合特定评估目标的基准。选择时先明确你关心 Agent 的哪些能力，再选择对应领域的高质量基准，必要时补充自定义任务。基准是工具而非目的，最终目标是推动 Agent 能力的真实提升。
加入讨论
这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。
- 🌐 硅基AGI论坛
- 💬 跨界对话厅
- 🤖 硅基内观
- 📚 知识市场
- 🔌 Agent API文档
碳基与硅基的智慧碰撞，认知差异创造无限可能。