Agent 评估基准实战：从 AgentBench 到 DeepEval 的性能测试指南

上周我在测试一个客服 Agent，跑了 100 个测试用例，成功率 78%。看起来还行对吧？然后我又跑了一遍同样的测试，成功率变成了 65%。我当时坐在电脑前，盯着这两行结果，大概愣了五分钟。

Agent 评估这事儿，跟我之前做的普通问答评估完全不是一个物种。问答模型你问它”法国首都”，它答”巴黎”就是对了，答”马赛”就是错了，黑白分明。Agent 不一样——它会思考、会规划、会调用工具、会在半路改主意。同样一个任务，它今天走 A 路线成功，明天走 B 路线失败，后天走 C 路线又成功了。

说实话，刚开始搞 Agent 评估的时候，我整个人是懵的。翻了一堆论文，看了 AgentBench、WebArena 这些基准的文档，越看越迷糊。后来在项目里踩了几个坑，才慢慢搞明白：Agent 评估不能只盯着终点，得看轨迹。

一、为什么 Agent 评估比普通问答难？

Agent 的核心问题在于：它有自主性。每次运行，它可能选择不同的路径。

举个具体的例子。我之前测试过一个旅行预订 Agent，任务是”预订明天从北京到上海最便宜的航班”。第一次跑，它先查了携程，比了三趟航班，选了最便宜的，然后帮我下单——完美。第二次跑同样的任务，它查了携程之后，又去查了飞猪，然后死循环了五分钟，最后超时失败。

同样的输入，不同的执行轨迹。Agent 评估的核心难点就在这里：你需要的不是一个简单的”对/错”标签，而是一套能分析整个执行过程的框架。

三层评估框架

用 Anthropic 官方的说法，Agent 评估应该分三层来看：

推理层（Reasoning Layer）：Agent 的规划对不对？它有没有正确理解任务？有没有制定合理的执行计划？

行动层（Action Layer）：Agent 选的工具对不对？参数传得对不对？工具调用的顺序合理吗？

整体执行（Overall Execution）：任务最终完成了吗？花了多少步骤？效率如何？

DeepEval 文档里有个数据让我印象很深：工具调用失败是最常见的 Agent 问题。差不多 40% 的 Agent 失败，都是因为选错工具或者参数传错。这说明什么？大部分 Agent 问题出在行动层，而不是推理层。

传统指标的局限

传统问答评估用准确率、F1 分数这些指标就够了。Agent 不行。

假设你的 Agent 任务成功率是 78%。这个数字能告诉你什么？几乎什么都没有。

为什么？因为 78% 可能意味着：

• 它规划正确但工具调用失败了（行动层问题）
• 它规划就错了，后面白忙活（推理层问题）
• 它规划对了，工具也调对了，但最后一步出了岔子（整体执行问题）

不同的失败原因，优化方向完全不同。规划错了要改 Prompt 或者换模型；工具调用错了要改工具定义或者加校验；最后一步出错可能是边界条件处理不好。

所以 Agent 评估的核心不是”它成功了吗”，而是”它在哪里失败了”。

二、5 大主流评估基准对比

市面上 Agent 评估基准挺多的，我挑了 5 个主流的来说说。都是我实际调研过或者跑过的。

AgentBench：综合能力基准

AgentBench 是清华在 ICLR’24 发的，算是第一个专门针对 LLM-as-Agent 的综合基准。它覆盖了 8 个环境：数据库查询、网页浏览、API 调用、代码执行等等。

跑下来的感受：覆盖面确实广，适合做通用 Agent 的选型评估。但环境搭建挺折腾的，需要 Docker 环境，而且 Dev 集就要调用 4000 多次 LLM，成本不低。

适合场景：你要从几个模型里选一个做 Agent backbone，AgentBench 能给你一个综合评分。

WebArena：Web 导航专用

WebArena 专注于 Web 环境。它搭了一套真实的网站环境（电商、论坛、地图这些），让 Agent 在里面完成导航任务。

比如”在 Reddit 上找到一个帖子并评论”这种任务。它测试的是 Agent 在真实 Web 环境中的操作能力。

适合场景：你在做浏览器 Agent 或者 Web 自动化，WebArena 是最对口的基准。

τ-Bench：多轮对话测试

τ-Bench（读作 tau-bench）是 Anthropic 参与开发的，专注于多轮交互场景。它模拟了零售客服、航空预订这些真实的服务场景，而且会模拟用户角色跟 Agent 对话。

这个基准有个特点：它测试的是 Agent 在多轮对话中的表现，而不只是单轮任务完成。

适合场景：你在做客服 Agent、预订 Agent 这类对话式服务 Agent。

SWE-Bench：代码能力基准

SWE-Bench 专门测编程能力。它从 GitHub 上找真实的 issue 和 PR，让 Agent 去修复代码。

这个基准很硬核。Agent 不仅要有代码能力，还要能理解项目结构、定位问题、写出能通过测试的代码。

适合场景：你在做编程助手 Agent 或者代码修复 Agent。

Claw-Eval / ACE-Bench：2026 新基准

Claw-Eval（后来改名 ACE-Bench）是 2026 年新出的基准，特点是可配置难度。你可以根据自己 Agent 的水平调整任务难度。

这个思路挺好的：评估不是一次性的，而是持续的过程。Agent 能力提升了，任务难度也跟着提升。

适合场景：企业内部定制评估，或者你想建立一套可持续迭代的评估体系。

基准选型决策

怎么说呢，选基准这事儿没有标准答案，得看你的场景：

基准	环境数	任务类型	适用场景	资源需求
AgentBench	8	综合能力	通用 Agent 选型	Docker 环境，高成本
WebArena	1	Web 导航	Web Agent 评估	浏览器环境
τ-Bench	多领域	多轮对话	客服/预订 Agent	API 模拟
SWE-Bench	软件项目	代码修复	编程 Agent	GitHub仓库
Claw-Eval	可配置	自定义	企业定制评估	轻量环境

我的建议：先用 AgentBench 建个基准线，看看你的 Agent 在综合能力上的表现。然后根据具体场景，再用专用基准深入测试。

三、Agent 评估指标体系

说完基准，来说说具体用什么指标来衡量 Agent 表现。我总结了一套 6 类核心指标，基本覆盖了 Agent 评估的各个层面。

1. 任务成功率（Success Rate）

这是最直接的指标：任务完成了吗？

但这个指标有个坑：什么叫”完成”？是 Agent 自己说完成就算完成，还是得有客观标准？

我现在的做法是定义明确的验收条件。比如”预订航班”任务，验收条件是：

• 订单号存在
• 航班信息正确
• 价格在预期范围内

验收条件越明确，成功率指标越有意义。

2. 工具调用准确率

这个指标分两部分：选对工具、传对参数。

选对工具是指 Agent 在需要调用工具的时候，选择了正确的工具。传对参数是指工具的参数格式和内容都正确。

我在实际项目里发现，这个指标特别能暴露 Agent 的短板。有个 Agent 我测出来任务成功率 82%，但工具调用准确率只有 68%。深入一看，它经常在”查询”和”预订”这两个操作上选错工具。

3. 进度率（Progress Rate）

对于多步骤任务，进度率能反映 Agent 走到哪一步了。

假设一个任务有 5 个步骤，Agent 走到第 4 步失败了。成功率是 0%，但进度率是 80%。这两个数字放在一起看，你就能知道：这个 Agent 离成功不远了，可能就差最后一步的优化。

4. 推理质量指标

这类指标评估 Agent 的规划能力：

PlanQuality（规划合理性）：Agent 制定的计划合理吗？步骤之间的逻辑关系对吗？

PlanAdherence（规划一致性）：Agent 实际执行的时候，有没有偏离原计划？

这两个指标需要用 LLM 来评估。DeepEval 里的 PlanQualityMetric 就是这么干的：用另一个 LLM 来判断 Agent 的规划质量。

5. 效率指标

StepEfficiency（步骤效率）：Agent 完成任务用了多少步？理论上最少需要几步？

如果一个任务最少 3 步能完成，Agent 用了 10 步，那 StepEfficiency 就是 30%。

还有 Token 消耗，这个直接关系到成本。同样完成一个任务，一个 Agent 用 1000 token，另一个用 5000 token，成本差 5 倍。

6. 稳定性指标

Agent 的表现稳定吗？同一个任务跑 10 次，成功率的标准差有多大？

这个指标我之前没太重视，直到有一次上线后发现：测试环境跑得好好的 Agent，生产环境成功率波动特别大。后来才发现是生产环境的请求超时设置比测试环境短，导致部分任务被截断。

指标与三层框架的对应

把这些指标跟前面说的三层评估框架对应起来：

评估层	对应指标
推理层	PlanQuality, PlanAdherence
行动层	ToolCorrectness, ArgumentCorrectness
整体执行	SuccessRate, ProgressRate, StepEfficiency

这样你看到某个指标低，就知道问题出在哪一层，优化方向也就明确了。

四、开源评估工具对比：DeepEval vs LangSmith vs Arize Phoenix

指标定义好了，用什么工具来测？我对比了三个主流的开源评估工具。

DeepEval：组件级评估首选

DeepEval 是 Confident AI 开发的开源 Python 框架，专门做 LLM 和 Agent 评估。

它的核心特点是：组件级评估。你可以在 Agent 的任何一个节点插入评估，而不是只看最终结果。

内置了 6 大指标：

• TaskCompletionMetric（任务完成）
• StepEfficiencyMetric（步骤效率）
• ToolCorrectnessMetric（工具正确性）
• ArgumentCorrectnessMetric（参数正确性）
• PlanQualityMetric（规划质量）
• PlanAdherenceMetric（规划一致性）

我在一个旅行预订 Agent 项目里用 DeepEval 做评估，效果挺好。它有个 @observe 装饰器，能在 Agent 执行过程中自动追踪推理、工具调用这些组件，然后逐层评估。

DeepEval 还有配套的 Confident AI 云平台，可以把评估结果可视化、做数据集管理。不过开源部分已经够用了。

LangSmith：LangChain 官方出品

如果你用的是 LangChain 开发 Agent，LangSmith 是最顺手的选择。它跟 LangChain 无缝集成，能自动追踪整个执行链路。

LangSmith 的强项是全链路追踪。你能看到 Agent 的每一次 LLM 调用、每一次工具执行，完整的执行轨迹都在。

但它是商业产品，有定价限制。小规模测试还行，大规模评估成本会上来。

Arize Phoenix：可观测性优先

Arize Phoenix 是基于 OpenTelemetry 架构的，专注于可观测性。

它的思路是：把 Agent 的执行过程当作一个分布式系统来监控。LLM 调用、工具调用都是 Span，整个执行轨迹是 Trace。

Phoenix 对生产环境监控特别友好。它有异常检测、性能分析这些功能，适合部署后的持续监控。

选型决策

选工具这事儿，得看你的具体情况：

是否使用 LangChain？
  → 是：优先 LangSmith（无缝集成）
  → 否：是否需要生产监控？
       → 是：Arize Phoenix + DeepEval
       → 否：纯开发评估 → DeepEval

我的实际组合是：DeepEval 做开发阶段的评估，Arize Phoenix 做生产环境的监控。两个工具互补，效果挺好。

五、代码实战：用 DeepEval 评估旅行预订 Agent

说了这么多理论，来点实际的。下面是一个完整的 DeepEval 评估代码示例，我在一个旅行预订 Agent 项目里实际用过的。

Agent 实现

先定义一个简单的旅行预订 Agent，用 @observe 装饰器追踪各个组件：

from deepeval.tracing import observe
from deepeval.metrics import (
    PlanQualityMetric,
    PlanAdherenceMetric,
    ToolCorrectnessMetric,
    ArgumentCorrectnessMetric,
    TaskCompletionMetric,
    StepEfficiencyMetric
)

# 定义工具
@observe(type="tool")
def search_flights(origin: str, destination: str, date: str):
    """搜索航班"""
    # 实际项目中这里会调用真实的 API
    # 示例返回模拟数据
    return [
        {"flight": "CA1234", "price": 500, "time": "08:00"},
        {"flight": "MU5678", "price": 450, "time": "10:30"},
        {"flight": "CZ9012", "price": 520, "time": "14:00"}
    ]

@observe(type="tool")
def book_flight(flight_number: str, passenger_info: dict):
    """预订航班"""
    # 实际项目中这里会调用真实的预订 API
    return {"order_id": "ORD123456", "status": "confirmed"}

# Agent 主体
@observe(type="agent")
def travel_agent(user_input: str):
    """
    旅行预订 Agent
    输入：用户的预订请求
    输出：预订结果或失败信息
    """
    # 推理层：解析任务并制定计划
    @observe(type="reasoning")
    def parse_and_plan(input_text):
        # 这里应该调用 LLM 来解析和规划
        # 示例使用简单的规则解析
        plan = {
            "task": "book_flight",
            "origin": "北京",
            "destination": "上海",
            "date": "明天",
            "steps": ["search", "compare", "book"]
        }
        return plan

    plan = parse_and_plan(user_input)

    # 行动层：执行工具调用
    # 步骤1：搜索航班
    flights = search_flights(
        plan["origin"],
        plan["destination"],
        plan["date"]
    )

    # 步骤2：选择最便宜的航班
    cheapest = min(flights, key=lambda x: x["price"])

    # 步骤3：预订
    result = book_flight(
        cheapest["flight"],
        {"name": "测试用户"}
    )

    return result

配置评估指标

from deepeval import evaluate
from deepeval.test_case import LLMTestCase

# 定义测试数据
test_cases = [
    LLMTestCase(
        input="预订明天从北京到上海最便宜的航班",
        expected_output={"order_id": "ORD123456", "status": "confirmed"}
    ),
    LLMTestCase(
        input="帮我查一下下周三从广州到深圳的航班",
        expected_output={"flights": [...]}
    )
]

# 配置评估指标
metrics = [
    TaskCompletionMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    ),
    StepEfficiencyMetric(
        threshold=0.5,  # 期望至少 50% 效率
        minimum_steps=3  # 最少需要 3 步
    ),
    ToolCorrectnessMetric(
        threshold=0.8
    ),
    ArgumentCorrectnessMetric(
        threshold=0.8
    ),
    PlanQualityMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    )
]

执行评估

# 方法1：单次评估
for test_case in test_cases:
    result = travel_agent(test_case.input)
    test_case.actual_output = result

evaluate(test_cases, metrics)

# 方法2：数据集批量评估
from deepeval.dataset import EvaluationDataset, Golden

dataset = EvaluationDataset(goldens=[
    Golden(input="预订明天从北京到上海最便宜的航班"),
    Golden(input="查找下周从成都到昆明的航班信息")
])

for golden in dataset.evals_iterator(metrics=metrics):
    output = travel_agent(golden.input)
    # 评估会自动记录和计算

评估结果解读

DeepEval 会输出每个指标的得分和通过率。假设你得到这样的结果：

指标	得分	是否通过
TaskCompletion	0.85	通过
StepEfficiency	0.45	未通过
ToolCorrectness	0.90	通过
ArgumentCorrectness	0.72	未通过
PlanQuality	0.78	通过

从这个结果你能看出什么？

• 任务完成率挺高（85%），大部分任务能成功
• 步骤效率偏低（45%），Agent 可能走了多余的步骤
• 工具选择正确率很高（90%），但参数正确率不行（72%）

优化方向就很明确了：重点改参数构造逻辑，减少不必要的步骤。

六、生产环境评估实践

开发阶段的评估做完，Agent 上线了，评估就结束了吗？远远没有。

Agent 在生产环境的表现跟开发环境往往不一样。用户输入更随机、边界情况更多、并发压力更大。你需要一套从开发到生产的完整评估闭环。

开发阶段：建立基准线

在开发阶段，你的目标是建立 Agent 的基准能力线。

先用 AgentBench 这类综合基准测一遍，看看你的 Agent 在通用能力上的水平。然后用自定义数据集测具体场景。数据集要覆盖典型任务、边界情况、失败案例。

开发阶段评估要做的几件事：

• 测试数据集覆盖度 ≥ 80% 的用户场景
• 每个指标都有明确的基准值
• 记录失败案例，分析失败原因分布

部署阶段：灰度和 A/B 测试

Agent 要上线，别直接全量发布。先灰度。

灰度评估的核心是对比：灰度组和对照组的表现差异。

# 灰度评估示例
def ab_test_evaluation():
    # 对照组：旧版本 Agent
    control_results = evaluate_agent(old_agent, test_cases)

    # 灰度组：新版本 Agent
    treatment_results = evaluate_agent(new_agent, test_cases)

    # 对比关键指标
    comparison = {
        "success_rate": {
            "control": control_results.success_rate,
            "treatment": treatment_results.success_rate,
            "delta": treatment_results.success_rate - control_results.success_rate
        },
        "step_efficiency": {
            "control": control_results.step_efficiency,
            "treatment": treatment_results.step_efficiency,
            "delta": treatment_results.step_efficiency - control_results.step_efficiency
        }
    }

    return comparison

灰度比例建议：先 1%，观察 24 小时没问题再 5%，然后 10%、20%、50%、100%。每一步都要看关键指标的变化。

生产阶段：持续监控

Agent 上线后，评估变成监控。

监控的重点是异常检测：成功率突然下降、响应时间突然变长、某个工具调用突然失败。这些异常要能及时报警，让你在用户大规模反馈之前发现问题。

采样策略：生产环境不可能评估每个请求，需要采样。我的建议：

• 普通任务：采样 1%-5%
• 关键任务（比如支付、预订）：100% 评估
• 异常请求（失败、超时）：100% 进入评估队列

成本控制：评估本身也有成本，尤其是用 LLM 来评估推理质量。几个技巧：

• 用小模型做评估（比如 gpt-4o-mini）
• 异步评估，不阻塞主流程
• 设置评估熔断，最大样本数 100-1000

人工审查的必要性

自动评估再好，也有边界案例需要人来看。

我现在的做法：自动评估标记为”不确定”的案例，进入人工审查队列。每周抽 10-20 个案例人工看，判断自动评估的准确性。

人工审查还有一个价值：发现自动评估没覆盖的问题。比如 Agent 的回复语气不好、给用户造成困惑——这些自动评估很难发现，但用户体验很差。

一个完整的评估闭环

把整个流程串起来：

开发阶段
├── AgentBench 基准测试
├── 自定义数据集评估
└── 失败案例分析
    ↓
部署阶段
├── 灰度测试（1% → 5% → 10% → ...）
├── A/B 对比评估
└── 回滚机制
    ↓
生产阶段
├── 采样监控（1%-5%）
├── 异常检测报警
├── 人工审查队列
    ↓
优化迭代
├── 失败案例归因
├── Prompt/工具调整
└── 重新评估
    ↓ (循环)

这是一个持续迭代的过程，不是一次性的工作。Agent 的能力会退化、用户场景会变化、新的问题会出现——评估要跟着一起演进。

结论

Agent 评估这事儿，说白了就是：别只看终点，要看轨迹。

我踩过的坑：以为成功率 78% 就够了，结果上线后发现同一个任务成功率波动 30%。以为工具调用没问题，结果 40% 的失败都是参数传错。以为开发评估够了，结果生产环境问题完全不一样。

三层评估框架帮我理清了思路：推理层看规划，行动层看工具，整体执行看结果。5 大基准帮我建立了基准线：AgentBench 综合测，τ-Bench 多轮测，SWE-Bench 代码测。DeepEval 帮我实现了代码化评估：@observe 装饰器追踪组件，6 大指标逐层分析。

下一步可以做什么：

1. 用 AgentBench 测一下你的 Agent，建立基准线
2. 用 DeepEval 做组件级评估，找到薄弱环节
3. 搭一套生产监控，异常检测 + 人工审查

评估不是终点，是起点。Agent 的能力演进，评估也要跟着演进。

Agent 评估实战：用 DeepEval 建立评估体系

从零搭建 Agent 评估体系，覆盖基准测试、指标配置、代码实现和生产监控

⏱️ 预计耗时: 2 小时

1. 1

   步骤1: 建立基准线

   用 AgentBench 或自定义数据集测试 Agent：
   
   • 准备 20-50 个典型任务用例
   • 覆盖正常流程、边界情况、失败场景
   • 记录每个用例的成功率和失败原因
   • 计算整体成功率和各层指标基准值
2. 2

   步骤2: 配置 DeepEval 评估指标

   根据 Agent 类型选择合适的指标组合：
   
   • TaskCompletionMetric：任务完成率，threshold 建议 0.7
   • StepEfficiencyMetric：步骤效率，threshold 建议 0.5
   • ToolCorrectnessMetric：工具正确性，threshold 建议 0.8
   • ArgumentCorrectnessMetric：参数正确性，threshold 建议 0.8
   • PlanQualityMetric：规划质量，需指定 evaluation_model
3. 3

   步骤3: 实现组件追踪

   用 @observe 装饰器追踪 Agent 各组件：
   
   • @observe(type="agent")：Agent 主函数
   • @observe(type="reasoning")：推理层函数
   • @observe(type="tool")：工具函数
   • 追踪数据会自动用于指标计算
4. 4

   步骤4: 执行评估并分析结果

   运行评估并解读指标分布：
   
   • 高成功率 + 低效率：Agent 走了多余步骤
   • 高工具正确率 + 低参数正确率：参数构造逻辑需优化
   • 低规划质量：Prompt 或模型需调整
   • 记录失败案例进入优化队列
5. 5

   步骤5: 搭建生产监控闭环

   部署后持续监控 Agent 表现：
   
   • 采样策略：普通任务 1%-5%，关键任务 100%
   • 异常检测：成功率下降 >10% 触发报警
   • 人工审查：每周抽 10-20 个边界案例
   • 迭代优化：根据监控数据调整 Prompt/工具

常见问题

Agent 评估和普通 LLM 评估有什么区别？

普通 LLM 评估关注输出的准确性（问答对错），Agent 评估关注执行轨迹的合理性。Agent 有自主性，同一个任务每次执行路径可能不同，需要多层评估：推理层看规划、行动层看工具调用、整体执行看结果。成功率数字无法定位问题，需要轨迹分析。

如何选择合适的评估基准？

根据 Agent 类型选择：

• 通用 Agent 选型：AgentBench（8 环境综合评估）
• Web/浏览器 Agent：WebArena（真实 Web 环境）
• 客服/预订 Agent：τ-Bench（多轮对话场景）
• 编程助手 Agent：SWE-Bench（代码修复任务）
• 企业定制评估：ACE-Bench（可配置难度）

DeepEval 和 LangSmith 选哪个？

如果使用 LangChain 开发，优先选 LangSmith（无缝集成、全链路追踪）。如果不使用 LangChain，开发阶段用 DeepEval（组件级评估、开源免费），生产监控用 Arize Phoenix（异常检测、性能分析）。实际项目中 DeepEval + Arize Phoenix 组合效果好。

评估指标里的 threshold 应该设多少？

根据业务场景调整：

• TaskCompletion：0.7-0.8（任务成功率）
• ToolCorrectness：0.8-0.9（工具调用准确率）
• StepEfficiency：0.5-0.7（步骤效率）
• PlanQuality：0.7-0.8（规划质量）

建议先用基准测试确定当前水平，再设置 threshold 为基准的 1.1 倍。

生产环境评估成本太高怎么办？

三个成本控制策略：

• 采样策略：普通任务采样 1%-5%，关键任务 100%
• 模型选择：用 gpt-4o-mini 等小模型做评估，成本降低 90%
• 异步评估：生产请求走主流程，评估异步执行不阻塞
• 设置熔断：最大样本数 100-1000，避免意外成本

16 分钟阅读 · 发布于: 2026年5月3日 · 修改于: 2026年5月4日