如何评估 AI 智能体（AI Agent）？指标、方法与最佳实践

AI 智能体评估（AI Agent Evaluation）是衡量一个 AI 智能体在完成我们交给它的任务时表现如何的过程------既看最终结果，也看它在中间走的每一步、用过的每一个工具。

本文就来聊聊 AI 智能体评估。我们会看到它为什么和 LLM 评估不一样、可以做哪些类型的评估、必须跟踪哪些关键指标、可以用哪些方法，以及应该遵循哪些最佳实践。

我们将覆盖以下内容：

什么是 AI 智能体？
什么是 AI 智能体评估？
为什么需要 AI 智能体评估？
AI 智能体评估和 LLM 评估有什么不同？
AI 智能体评估的类型
- 结果评估
- 轨迹评估
- 工具使用评估
- 规划评估
AI 智能体的关键指标
智能体基准（Agent Benchmarks）
评估 AI 智能体的方法
AI 智能体评估的框架与工具
AI 智能体评估的挑战
最佳实践

什么是 AI 智能体？

在跳进 AI 智能体评估之前，我们得先知道 AI 智能体是什么。

AI 智能体（AI Agent）是一个用 LLM 来做规划、通过工具采取行动、并自主完成任务的系统。

简单说，普通 LLM 只给我们文本。而 AI 智能体不会停在文本上。它可以调用工具、读文件、搜网页、跑代码，为了达成一个目标走上很多步。

假设我们让一个 AI 智能体去做这件事：「订一张周五从德里到班加罗尔的机票。」智能体会思考、调用航班搜索工具、读结果、选一个合适的航班、调用订票工具，最后把确认信息给我们。中间它做了很多步，而我们只看到最终结果。

这就是智能体的威力。它们让我们的生活更省事。但也正因为它们要走很多步、做很多动作，它们也会以很多全新的方式失败。这就是为什么我们需要一套专门的评估方式。

什么是 AI 智能体评估？

AI 智能体评估是衡量一个 AI 智能体在我们期望它完成的任务上表现如何的过程。

简单说，我们给智能体一些任务，从头到尾看它做了什么，然后检查：它是否正确地完成了任务、是否用了对的工具、是否走了对的步骤，以及是不是没有浪费时间和钱。

假设我们做了一个帮用户订机票的 AI 智能体。那么问题是：我们怎么知道这个智能体到底好不好？它选对航班了吗？它正确使用订票工具了吗？缺信息的时候它问用户了吗？它是否用合理的步数完成了任务？要回答所有这些问题，我们需要 AI 智能体评估。

为什么需要 AI 智能体评估？

AI 智能体很强，但也很危险。它们会在真实世界里采取真实行动。它们发邮件、写数据库、花钱、代表我们和用户对话。所以，智能体犯的一个小错，可能造成一个大问题。

因此，在把 AI 智能体交付给用户之前，我们必须知道它在很多情况下会怎么表现。交付之后，我们也必须持续检查，确保它不会随着时间变差。

以下是我们需要 AI 智能体评估的主要原因：

检查智能体是否正确地完成了任务。
确保智能体在正确的时间用了正确的工具。
跟踪智能体在每个任务上用了多少步、花了多少钱。
找出智能体失败的薄弱环节，以便修复。
在改了 prompt 或换了模型之后，比较智能体的不同版本。
确保智能体是安全的，不会采取有害行动。

AI 智能体评估和 LLM 评估有什么不同？

这是个重要问题。大多数人以为 AI 智能体评估就等于 LLM 评估。其实不是。

在 LLM 评估里，我们主要检查最终的文本输出。模型拿到输入、给出输出，我们给输出打分。

但在 AI 智能体评估里，智能体在输入和最终输出之间做了很多事。它做规划、挑工具、调工具、读结果、做决策，出错了还会再试一次。所以我们必须检查的不只是最终答案，还有中间发生的一切。

为了方便理解，我把 LLM 评估与 AI 智能体评估的差异列成表：

方面	LLM 评估	AI 智能体评估
检查什么	最终文本输出	最终输出 + 中间所有步骤
步骤数量	一步	很多步
工具使用	不用工具	大量工具调用
成本跟踪	一次 LLM 调用	多次 LLM 调用 + 多次工具调用
失败模式	文本错了	用错工具、顺序错、死循环，等等

这就是 AI 智能体评估与 LLM 评估的不同之处。接下来，我们来了解 AI 智能体评估的类型。

AI 智能体评估的类型

AI 智能体评估有四种主要类型。我们会逐一详细说明。

结果评估（Outcome Evaluation）------只检查任务的最终结果。
轨迹评估（Trajectory Evaluation）------检查智能体为达成结果所走的每一步。
工具使用评估（Tool Use Evaluation）------检查智能体是怎么使用工具的。
规划评估（Planning Evaluation）------检查智能体所做规划的质量。

这四种各有优缺点。在真实项目里，我们通常会把其中不止一种组合起来用。

下面逐个讨论。

结果评估

结果评估意味着我们只看任务的最终结果，忽略中间的一切。

假设我们让智能体去做：「找出周五从德里到班加罗尔最便宜的航班并预订。」我们不在乎智能体是走了 5 步还是 50 步。我们只在乎：它有没有订到周五最便宜的那班？如果是，结果就是对的；如果不是，结果就是错的。

这是最简单的评估形式，对有明确正确答案的任务非常有效。

一些常见的结果类指标：

任务成功率（Task Success Rate）------智能体正确完成的任务占比。
最终答案准确率（Final Answer Accuracy）------最终答案是否和期望答案一致？
目标达成（Goal Completion）------智能体是否达成了用户的目标？

优点：

定义和度量都很简单。
与用户真正在意的东西一致。
在有明确正确答案时效果很好。

缺点：

我们不知道智能体为什么失败。
智能体可能走了很多错步，靠运气拿到正确答案。
智能体可能拿到了正确答案，却浪费了大量金钱和时间。

只有当我们能说清「什么才算正确的结果」时，结果评估才成立。这件事本质上取决于我们如何定义「完成」（Definition of Done）。

以上是关于结果评估的全部内容。接下来我们看轨迹评估。

轨迹评估

轨迹评估意味着我们要看智能体为达成结果所走的每一步，以及这些步骤的顺序是否正确。

简单说，轨迹（trajectory）就是智能体经历过的完整行动与思考路径。我们一步一步地检查这条路径。

假设我们的智能体需要回答这个问题：「班加罗尔明天天气如何，我该带伞吗？」一条好的轨迹是这样的：

第 1 步：以 city = Bangalore、date = tomorrow 调用天气工具。
第 2 步：读结果，降雨概率 70%。
第 3 步：判断用户应该带伞。
第 4 步：回复用户。

那么，如果智能体跳过了第 1 步、直接猜了个答案，即使最终答案因为运气而正确，这条轨迹也是错的。

在轨迹评估中，我们检查这些内容：

精确匹配（Exact Match）------智能体是否完全按期望的步骤序列执行？
顺序匹配（In-Order Match）------智能体是否按正确顺序执行了必需的步骤，即使多做了几步？
任意顺序匹配（Any-Order Match）------智能体是否完成了全部必需的步骤，即使顺序不同？
精确率（Precision）------在智能体走过的所有步骤里，有多少是有用的？
召回率（Recall）------在所有必需的步骤里，智能体做了多少？

最后两个就是给任何分类系统打分时用的精确率与召回率（Precision / Recall）。

优点：

我们能精确定位智能体到底哪里出错了。
我们能区分「靠运气」和「真的理解了」。
有助于调试并改进智能体。

缺点：

很难定义唯一正确的轨迹，因为常常存在很多条同样好的路径。
比只检查最终答案更贵。
如果我们要求精确匹配，评判会过于严苛。

这就是轨迹评估的工作方式。但在评估一条轨迹之前，我们首先得捕获智能体走过的每一步------而捕获这些步骤，正是 AI 智能体可观测性（AI Agent Observability）要做的事。下面我们进入工具使用评估。

工具使用评估

工具使用评估意味着我们检查智能体是如何使用它手上这些工具的。

工具是智能体的手。如果智能体挑错了工具，或者传错了参数，整个任务都可能失败。所以我们必须非常仔细地检查工具使用情况。

主要检查这几项：

工具选择（Tool Selection）------智能体是否为当前任务挑对了工具？
参数正确性（Argument Correctness）------智能体是否给工具传了正确的参数？
工具调用成功（Tool Call Success）------工具调用是否返回了有效结果，还是抛了错？
结果处理（Result Handling）------智能体是否正确地使用工具结果来推进下一步？
无幻觉工具（No Hallucinated Tools）------智能体是否试图调用一个并不存在的工具？

看个例子。假设我们的智能体有这些工具：search_flights、book_flight、send_email。用户说：「订一张周五去班加罗尔最便宜的机票。」

一个好的智能体会先调用 search_flights，再用最便宜的那条结果调用 book_flight，最后调用 send_email 做确认。一个糟糕的智能体则可能先调用 send_email，或者在没选航班的情况下就调用 book_flight，又或者去调用一个不存在的工具，比如 cancel_flight。工具使用评估帮我们把这类错误全都抓出来。

优点：

能抓住智能体最常见的失败原因。
因为工具调用是结构化的，所以容易自动化。
有助于改进工具描述和 prompt。

缺点：

不告诉我们最终答案的质量。
需要一个明确的「该用哪个工具」的标准答案，而这有时很难定义。

以上就是工具使用评估。接下来该聊规划评估了。

规划评估

规划评估意味着我们检查智能体在采取行动前所做规划的质量。

很多智能体会先写一份计划，然后按计划一步步执行。如果计划本身是坏的，那工具再好智能体也会失败。

假设我们的智能体要规划一次旅行。一份好的计划是这样的：

第 1 步：找出给定日期范围内的航班。
第 2 步：选出符合用户日程的最便宜航班。
第 3 步：找目的地附近的酒店。
第 4 步：在预算内选出评分最高的酒店。
第 5 步：把完整行程发给用户。

在规划评估中，我们检查这些内容：

完整性（Completeness）------计划是否覆盖了完成任务所需的全部步骤？
正确性（Correctness）------步骤顺序是否正确？
可行性（Feasibility）------每一步是否真的能用现有工具做到？
效率（Efficiency）------计划是简洁干净的，还是有不少多余步骤？

优点：

能在智能体浪费时间执行坏计划之前就发现问题。
有助于我们理解智能体的思考方式。

缺点：

只适用于会预先产出计划的智能体。
很难定义唯一正确的计划，因为常常存在很多份同样好的计划。

对于那些智能体必须先想再做的复杂任务，规划评估非常有用。这也是「先规划后执行」（Plan-and-Execute）这类智能体模式的核心考量。

AI 智能体的关键指标

现在我们已经了解了评估的类型，接下来看看要为 AI 智能体跟踪的关键指标。

最重要的几项如下：

任务成功率（Task Success Rate）------智能体正确完成的任务占比。这是最重要的指标。如果成功率很低，其他都无从谈起。
工具调用准确率（Tool Call Accuracy）------正确且有用的工具调用占比。
每任务步数（Number of Steps per Task）------智能体完成任务用了多少步？步数越少通常说明智能体越好。
每任务成本（Cost per Task）------智能体完成一个任务，在 LLM 调用和工具调用上花了多少钱？这对生产环境的智能体至关重要。
每任务延迟（Latency per Task）------智能体完成任务花了多长时间？用户不会无限等下去。
恢复率（Recovery Rate）------某次工具调用失败时，智能体能否恢复并仍然完成任务？
安全评分（Safety Score）------智能体是否采取了它不该采取的有害或高风险行动？
循环检测（Loop Detection）------智能体是否卡在死循环里，一遍又一遍地调用同一个工具？

在真实产品里，我们必须把这些指标一起跟踪。如果每个任务都很贵或者很慢，再高的成功率也没用。这些数字大多其实是对智能体「循环」（loop）的判决------如何设计这个循环，属于循环工程（Loop Engineering）要解决的问题。

智能体基准

和 LLM 一样，AI 智能体也有用来互相比较的基准（benchmark）。不同的基准测的是不同的能力。我们按类别分组，这样就能知道每个基准是干什么的。

函数调用（Function Calling）

BFCL（Berkeley Function-Calling Leaderboard）------测试模型挑选正确函数并传入正确参数的能力。工具使用方向上被引用最多的基准。

客服智能体（Customer Service Agents）

τ-bench / τ²-bench（tau-bench）------在贴近真实的客服环境中评估智能体，它们必须使用工具并遵守公司政策。原始 τ-bench 是单控（single-control）设定，即只有智能体对环境采取行动。τ²-bench 增加了双控（dual-control）设定：智能体和模拟用户各自拥有工具，并在同一个共享世界里行动。

编程智能体（Coding Agents）

SWE-bench Verified------来自开源项目的真实 GitHub issue。是衡量编程智能体在真实软件任务上表现的广泛使用的基准。
Terminal-Bench------智能体在沙箱化的命令行环境里完成真实任务，比如训练一个机器学习模型、从源码构建 Linux，或者逆向一个二进制文件。它是真正意义上的「智能体式」------智能体执行 shell 命令，而不是只打一个 diff 补丁。
MLE-bench------取自 Kaggle 竞赛的机器学习工程任务。

通用助手（General Assistants）

GAIA------需要把推理、工具使用和网页浏览结合起来的通用助手任务。

网页浏览智能体（Web Browsing Agents）

WebArena------供浏览器类智能体使用的仿真网站。
VisualWebArena------需要对页面做视觉理解的网页任务。
BrowseComp------开放网络上的信息检索任务。

电脑操作智能体（Computer Use Agents）

OSWorld------真实的桌面环境，智能体在其中操控一整台电脑。
AppWorld------智能体通过 API 与日常应用交互。

看完这些类别后，我们还需要理解关于智能体基准的两个重要概念。

饱和（Saturation）------随着模型进步，顶尖智能体在某个基准上的得分开始接近天花板。当智能体之间的差距小到失去意义时，这个基准就失去了区分「好」与「极好」的能力。这也是为什么 SWE-bench Verified 正在被 Terminal-Bench 这类更难的基准补充，以便我们仍能把强的编程智能体区分开。
真实世界差距（Real world gap）------在公开基准上得高分，并不意味着智能体在我们的产品里就能表现良好。公开基准很少与我们真正关心的任务完全吻合。所以，我们必须始终构建与自身用例相匹配的自有评估。

以上就是智能体基准。接下来我们看评估 AI 智能体的方法。

评估 AI 智能体的方法

那么下一个大问题是：这些评估实际上要怎么跑？答案是我们有三种主要方法。

自动评估（Automated Evaluation）

我们写代码，让智能体跑一组测试任务，然后把输出和轨迹与期望值做比对。这是最快、最便宜的方法。

例如，如果智能体需要返回一个航班号，我们直接把返回的航班号和期望的比一下就行。如果智能体需要调用某个特定工具，我们可以检查工具调用日志。

优点：快、便宜、可重复。

缺点：只在有明确标准答案时才成立。

LLM 作为评判者（LLM as a Judge）

当不存在唯一正确答案时，自动检查就失效了。这时就该 LLM 作为评判者出场了。我们用一个强 LLM 来评判智能体的输出与轨迹。我们把用户的请求、智能体的完整轨迹和最终答案交给评判者，让它在正确性、有用性、效率等不同维度上按 1 到 5 打分。

为了便于理解，我们看一个评判者 prompt 的示例。

text 复制代码

You are an expert evaluator. Read the user request, the agent trajectory, and the final answer.
Rate the agent on a scale of 1 to 5 on the following aspects:
- Did it finish the task?
- Did it use the right tools?
- Did it take an efficient path?
- Was the final answer correct?

Give a short reason for each rating.

User request: {request}
Agent trajectory: {trajectory}
Final answer: {answer}

优点：容易扩展，适用于开放式任务。

缺点：评判者自身可能带有偏差，所以我们必须用人工评分来校验它。

人工评估（Human Evaluation）

由真人查看智能体的轨迹和最终答案并打分。对于自动化指标和 LLM 评判者都可能漏掉细微问题的复杂任务，这是黄金标准。

优点：判断质量最高。

缺点：慢、贵、难以规模化。

在真实产品里，我们通常会把三种方法都结合起来。用自动评估拿快速反馈，用 LLM 作为评判者做日常监控，用人工评估做出货前的最后把关。

AI 智能体评估的框架与工具

要把这些方法规模化跑起来，我们会用评估框架。它们给我们一套结构化的方式：定义测试任务、运行智能体、捕获完整轨迹、给每次运行打分、并在看板上查看结果。

以下是可用于 AI 智能体评估的主流框架：

LangSmith------为追踪与评估 LangChain、LangGraph 智能体而构建，对轨迹检视的支持很强。
DeepEval------开源库，内置大量针对智能体、工具使用和 RAG 的现成指标。

我们不需要把它们全学会，但必须知道它们存在，这样在自己搭建智能体评估系统时才知道该搜什么。

AI 智能体评估的挑战

AI 智能体评估很难。主要挑战如下：

多条正确路径------对大多数任务来说，不存在唯一正确的轨迹。智能体可以用很多不同的方式完成任务，而且都很好。这让轨迹比对变得棘手。
非确定性------同一个智能体对同一个输入可能给出不同答案，因为 LLM 不是确定性的。所以每个测试我们都要跑很多次才能得到稳定的分数。
长轨迹------真实世界的智能体任务可能有 20 步、50 步甚至 100 步。人工逐条审阅这么长的轨迹非常累。
环境变化------智能体经常与搜索引擎、数据库这类真实系统交互。结果可能每天都不一样，这让评估难以复现。
级联失败------第 2 步的一个小错，可能造成第 10 步的大失败。我们必须把失败追溯到根因。
安全风险------智能体会采取真实行动。一个坏动作可能花掉真金白银，或者给真实用户发一封错邮件。我们必须在它们发生之前抓住这些问题。
评估成本------让智能体跑大量测试任务很贵，因为每个任务都要消耗大量 LLM 调用和工具调用。

那么下一个大问题是：这些挑战该怎么应对？答案是我们遵循一些最佳实践。

最佳实践

以下是 AI 智能体评估的最佳实践：

构建一个扎实的测试集------创建一组与用户真实行为相匹配的真实任务。包含简单任务、困难任务、边界情况和对抗性案例。
同时评估结果与轨迹------结果告诉我们任务是否完成，轨迹告诉我们为什么失败。两者都需要。
每个测试跑很多次------由于非确定性，每个任务至少要跑 3 到 5 次，并且看平均值和最差情况，而不是只看一次运行。
使用沙箱环境------不要在产线上测智能体。用带假工具、假数据的沙箱，这样就能安全地测，没有风险。
从第一天就跟踪成本与延迟------一个每任务要 5 分钟、每次调用成本很高的「完美」智能体，在生产环境里活不下来。
校验评判者------使用 LLM 作为评判者时，在一小部分样本上把它的评分与人工评分做对比，确认评判者是可靠的。
建立回归测试------每次改动 prompt、工具或模型，都跑一遍完整测试集，确认没有任何东西变差。
留意循环与超时------始终设置最大步数和最大时长。否则一个坏掉的智能体可以一直跑下去，花掉很多钱。
把人留在回路里------即使全自动化了，每周也要人工抽查一小部分轨迹。这能抓住指标漏掉的问题。

这样，我们就能用 AI 智能体评估，打造出在生产环境中真正值得信任的 AI 智能体。

常见问题（FAQ）

智能体给出了正确答案，是否仍可能评估不通过？

会。智能体可能走了很多错步后靠运气拿到正确答案，也可能拿到了正确答案却浪费了大量金钱和时间。这就是为什么我们既要评估结果，也要评估轨迹。结果告诉我们任务是否完成，轨迹告诉我们为什么失败。

基准分数高，就足以信任一个 AI 智能体吗？

不够。在公开基准上得高分，并不意味着智能体在我们的产品里就能表现良好。公开基准很少与我们真正关心的任务完全吻合。所以我们必须始终构建与自身用例相匹配的自有评估。

评估 AI 智能体时，每个测试应该跑多少次？

每个任务至少跑 3 到 5 次。同一个智能体对同一个输入可能给出不同答案，因为 LLM 不是确定性的。所以我们看平均值和最差情况，而不是只看一次运行。

智能体评估可以直接信任 LLM 作为评判者的评分吗？

只有校验过之后才可以。评判者自身可能有偏差，所以我们要在一小部分样本上把它的评分与人工评分对比，确认它可靠。一旦通过校验，LLM 作为评判者扩展性好，也适用于开放式任务。

应该在产线上测试 AI 智能体吗？

不应该。我们不该在产线上测智能体。智能体会采取真实行动，比如发邮件、花钱，所以一个坏动作可能造成真实伤害。我们使用带假工具、假数据的沙箱，这样就能安全测试、没有风险。