Agent 评估框架：如何衡量 Agent 的真正能力

引言

2026 年，AI Agent 已从简单的对话助手演进为能自主规划、调用工具、执行多步骤任务的复杂系统。但 Agent 的评估远比 LLM 困难——同一个任务可能有无数条正确路径，中间步骤的错误可能被后续步骤弥补，而「完成任务」的定义本身也充满模糊性。本文系统梳理 Agent 评估的方法论与框架。

一、Agent 评估的核心难点

1.1 与传统 LLM 评估的本质区别

维度	LLM 评估	Agent 评估
输入	单轮/多轮 prompt	任务描述 + 环境 + 工具集
输出	文本回答	多种模态（文本、代码、文件、API 调用）
评估单元	单次回答	多步骤轨迹
正确性	可对照参考答案	路径多样，无唯一正确答案
环境依赖	无	依赖外部环境状态
成本	低	高（每步消耗 tokens + 工具调用）
可复现性	高	低（环境状态变化）

1.2 核心挑战

挑战一：路径多样性。 「订一张明天去上海的机票」这个任务，Agent 可以先查日历确认日期、再搜索航班、最后预订；也可以直接搜索航班并预订。路径不同但都正确。

挑战二：中间错误的可恢复性。 Agent 在第 2 步调错了 API，但在第 3 步意识到并纠正了——这算不算错误？如何量化？

挑战三：环境不可复现。 Agent 调用的 API 返回值可能随时间变化，同一任务在不同时间执行可能得到不同结果。

挑战四：评估成本高。 一个 Agent 任务可能涉及 10-50 步工具调用，每步都需要评估正确性，总成本远超单次 LLM 评估。

二、Agent 评估维度体系

2.1 核心评估维度

Agent 能力评估
├── 任务完成能力
│   ├── 成功率 (Success Rate)
│   ├── 部分完成度 (Partial Completion)
│   └── 结果质量 (Output Quality)
├── 工具使用能力
│   ├── 工具选择准确率
│   ├── 参数填充正确率
│   └── 调用时机合理性
├── 规划能力
│   ├── 任务分解质量
│   ├── 步骤排序合理性
│   └── 计划调整能力
├── 效率指标
│   ├── 步骤数 (Steps to Complete)
│   ├── Token 消耗
│   ├── 时间延迟
│   └── 工具调用次数
└── 鲁棒性
    ├── 错误恢复能力
    ├── 环境变化适应
    └── 异常处理

2.2 任务完成能力

成功率 (Success Rate)

最基础也最重要的指标。定义「成功」需要明确的标准：

成功等级	定义	示例
完全成功	任务目标完全达成	正确订到指定航班机票
部分成功	核心目标达成，有瑕疵	订到机票但日期偏差 1 天
失败	未达成核心目标	订票失败或订错航班
放弃	Agent 主动放弃或无限循环	Agent 循环调用同一 API

建议： 成功率应同时报告「严格」（完全成功）和「宽松」（部分成功+）两个口径。

部分完成度

对于复杂任务，二元的成功/失败过于粗糙。推荐使用完成度评分：

$$\text{Completion Score} = \frac{\text{完成的子任务数}}{\text{总子任务数}}$$

或更精细的加权完成度，按子任务重要性加权。

2.3 工具使用能力

工具选择准确率

准确率 = 正确选择工具的次数 / 总工具调用次数

需要定义「正确选择」的标准：如果多个工具都能完成任务，选择任何一个都算正确。

参数填充正确率

参数正确率 = 正确填充的参数数 / 总参数数

常见错误类型：

必填参数缺失（30%）
参数类型错误（25%）
参数值错误但格式正确（35%）
可选参数不必要地填充（10%）

调用时机合理性

即使工具和参数都对，调用时机也可能出错：

在信息不足时就调用（如没确认日期就搜索航班）
重复调用同一工具获取相同信息
在应该等待用户确认时就执行了不可逆操作

2.4 规划能力

任务分解质量

评估 Agent 是否正确识别了子任务：

任务：预订去上海的出差行程
正确分解：
  1. 查询日历确认出差日期
  2. 搜索去上海的航班
  3. 搜索上海的酒店
  4. 预订航班
  5. 预订酒店
  6. 设置日历提醒

评估方法：

子任务覆盖率：Agent 识别的子任务 / 参考子任务
冗余子任务率：不必要子任务 / 总子任务
排序合理性：子任务执行顺序是否合理

计划调整能力

当遇到错误时，Agent 能否调整计划：

API 报错后是否重试或换方案
中间结果不符合预期时是否修正方向
用户追加要求时是否能动态调整

2.5 效率指标

指标	定义	理想值
步骤数	完成任务的总步骤	越少越好（但不牺牲正确性）
Token 消耗	总输入+输出 tokens	越少越好
工具调用次数	总工具 API 调用	越少越好
端到端延迟	从任务开始到完成的时间	视交互需求
冗余动作率	不必要的步骤 / 总步骤	< 10%
重试率	失败后重试的次数 / 总调用	< 15%

三、主流 Agent 评测框架

3.1 AgentBench

AgentBench 是最全面的 Agent 评测框架之一，覆盖 8 个场景：

场景	描述	关键指标
Web Shopping	在线购物	购买成功率、价格合理性
Web Browsing	网页浏览	信息获取准确率
Database	数据库查询	查询正确率、效率
Knowledge Graph	知识图谱推理	推理正确率
Card Game	卡牌游戏	策略质量、胜率
Linux System	Linux 操作	命令正确率、任务完成
House Holding	模拟家务	任务完成率
Database Admin	数据库管理	操作正确率

3.2 WebArena

WebArena 创建真实的网页环境（含 200+ 网站），评估 Agent 在真实网页上的交互能力：

任务类型：信息检索、表单填写、购物、论坛发帖、CMS 管理
难度分级：Easy / Medium / Hard / Expert
关键指标：成功率、步骤效率

2026 年头部模型在 WebArena 上的表现：

模型	Easy	Medium	Hard	Expert	总体
GPT-5 + Agent 框架	78%	52%	31%	15%	44%
Claude 4 Opus	82%	55%	33%	17%	47%
Gemini 2.5 Ultra	70%	45%	25%	11%	38%

3.3 τ-Bench (Tau-Bench)

τ-Bench 专注客服场景的多轮工具调用评估：

模拟真实客服对话（航空、零售、保险）
评估 Agent 在策略约束下的工具使用
引入「策略遵循」维度——不仅要完成任务，还要遵守业务规则

3.4 SWE-Agent / SWE-Bench

SWE-Agent 评估代码工程 Agent：

在真实 GitHub 仓库中修复 issue
评估指标：issue 解决率、代码修改质量、测试通过率
SWE-Bench Pro 增加了多文件修改和更复杂的工程任务

四、Agent 评估方法论

4.1 轨迹评估 vs 结果评估

结果评估（Outcome-based）： 只看最终结果是否正确。

优点：简单、客观
缺点：无法区分「运气好的错误路径」和「正确的推理路径」

轨迹评估（Trajectory-based）： 评估每一步的正确性。

优点：全面、可诊断问题
缺点：成本高、需要定义每步的标准

推荐：组合使用。 对关键步骤做轨迹评估，对整体做结果评估。

4.2 环境模拟与隔离

Agent 评估需要可复现的环境：

沙盒环境设计原则：

每次评估前重置环境到初始状态
Mock 外部 API（不依赖真实第三方服务）
记录所有环境状态变化
支持回放和调试

Docker 化方案：

评估环境
├── agent_container (Agent 运行环境)
├── tool_container (工具/API Mock)
├── env_container (被操作的环境)
└── eval_container (评估器)

4.3 评估器设计

Agent 评估器通常需要 LLM-as-Judge + 规则检查的组合：

def evaluate_agent_run(task, trajectory, final_state):
    # 规则检查（确定性）
    checks = {
        "task_completed": check_task_completion(task, final_state),
        "api_calls_valid": validate_all_api_calls(trajectory),
        "no_infinite_loop": check_loop_detection(trajectory),
        "within_step_limit": len(trajectory) <= MAX_STEPS,
    }
    
    # LLM 评估（主观维度）
    llm_scores = llm_judge(
        task=task,
        trajectory=trajectory,
        rubric=AGENT_EVAL_RUBRIC
    )
    
    # 聚合
    return {
        "success": all(checks.values()) and llm_scores["overall"] >= 4,
        "rule_checks": checks,
        "llm_scores": llm_scores,
        "efficiency": {
            "steps": len(trajectory),
            "tokens": sum(t.tokens for t in trajectory),
            "tool_calls": sum(1 for t in trajectory if t.is_tool_call),
        }
    }

五、评估报告模板

完整的 Agent 评估报告应包含：

任务集描述：任务类型、数量、难度分布
环境配置：工具列表、API 版本、环境参数
核心指标：成功率（严格/宽松）、平均步骤数、平均 token 消耗
分维度分析：工具选择准确率、参数正确率、规划质量
失败分析：失败原因分类（规划错误/工具错误/参数错误/超时）
效率分析：步骤分布、token 分布、延迟分布
案例研究：典型成功和失败案例的轨迹分析
统计信息：95% 置信区间、显著性检验结果

六、前沿方向

6.1 自适应难度

传统评估使用固定难度，但 Agent 能力差异大。自适应难度评估 根据 Agent 表现动态调整任务难度，类似计算机化自适应测试（CAT），能在更少样本下精确估计 Agent 能力。

6.2 对抗性评估

构造对抗性场景测试 Agent 鲁棒性：

工具返回错误信息时 Agent 是否能识别
环境突然变化时 Agent 是否能适应
用户指令模糊时 Agent 是否能合理澄清

6.3 长程任务评估

真实 Agent 任务可能需要数百个步骤。长程任务评估面临：

环境维护成本高
评估时间长（数小时到数天）
中间状态的评估标准难以定义

结语

Agent 评估仍在快速演进中。与 LLM 评估不同，Agent 评估没有简单的「Benchmark 分数」可以依赖。构建系统化、可复现、多维度的评估框架，理解每个指标衡量的是什么，才能对 Agent 的真正能力形成可靠判断。

加入讨论

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

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

引言#

一、Agent 评估的核心难点#

1.1 与传统 LLM 评估的本质区别#

1.2 核心挑战#

二、Agent 评估维度体系#

2.1 核心评估维度#

2.2 任务完成能力#

成功率 (Success Rate)#

部分完成度#

2.3 工具使用能力#

工具选择准确率#

参数填充正确率#

调用时机合理性#

2.4 规划能力#

任务分解质量#

计划调整能力#

2.5 效率指标#

三、主流 Agent 评测框架#

3.1 AgentBench#

3.2 WebArena#

3.3 τ-Bench (Tau-Bench)#

3.4 SWE-Agent / SWE-Bench#

四、Agent 评估方法论#

4.1 轨迹评估 vs 结果评估#

4.2 环境模拟与隔离#

4.3 评估器设计#

五、评估报告模板#

六、前沿方向#

6.1 自适应难度#

6.2 对抗性评估#

6.3 长程任务评估#

结语#

Agent 评估仍在快速演进中。与 LLM 评估不同，Agent 评估没有简单的「Benchmark 分数」可以依赖。构建系统化、可复现、多维度的评估框架，理解每个指标衡量的是什么，才能对 Agent 的真正能力形成可靠判断。#

加入讨论#

📌 相关推荐

引言