AI智能体答对题，可能是走错路做到的

AI智能体不应只根据其最终答案看起来是否正确来评估。同样关键的是，它们是否真正解决了任务、是否使用了正确的工具、是否妥善处理中间结果，以及是否保持在既定的成本、时间和安全边界之内。

正因如此，评估AI智能体比评估单个语言模型输出更具挑战性。智能体是多步骤工作的：它解读目标、选择行动、调用工具、处理结果，然后决定下一步。

本文展示了一个面向实践的测量模型，包含七个适用于许多生产级智能体系统的指标。这并非官方行业标准，而是一个紧凑的评估框架，其思路参考了智能体评估、工具使用和可观测性领域的最新方法。

评估AI智能体意味着什么？

评估AI智能体是对智能体系统达成目标的可靠性、以及达成路径运行情况的系统性检验。

对于经典语言模型，例如可以检查回答是否正确、相关或有用。但对智能体来说，这还不够。

因为智能体可能给出看似正确的答案，却使用了糟糕或高风险的过程。

示例：
一个智能体要查询某产品的当前库存。
它给出了正确的数字——但为此却错误地使用了过时文件，而不是当前的ERP系统。
最终结果看似正确，但执行过程是有缺陷的。

因此，智能体评估至少应考虑两个层面：

结果评估（Outcome Evaluation）——智能体是否实现了目标？
过程评估（Process Evaluation）——它是否为此走了一条合理、正确且受控的路径？

Google Cloud在智能体评估中相应地区分了最终答案的评估与轨迹（Trajectory）的评估，即工具调用序列的评估。Microsoft Foundry同样将端到端成功与各个步骤和工具使用的评估分开。

要点速览

- 对智能体来说，仅有一个好的最终结果是不够的。
- Task Success（任务成功率）衡量任务是否真正被解决。
- Tool Call Accuracy（工具调用准确率）检查外部工具的选择与使用。
- Grounding（事实依据）即错误率，显示陈述是否被可用信息覆盖。
- Human Correction Rate（人工修正率）揭示人类需要干预的频率。
- Safety Violations（安全违规）衡量未经授权或高风险的行为。
- Cost per Successful Task（每成功任务成本）将技术质量与经济性联系起来。
- End-to-End Latency（端到端延迟）显示智能体完成整个任务所需的时间。
- Traces（追踪记录）尤为宝贵，因为它们不仅呈现结果，还让智能体的运行路径可见。

为什么经典LLM评估对智能体不够用

智能体不是单次模型调用。
Hugging Face的smolagents将多步骤智能体描述为反复执行动作并处理环境观察结果的系统。因此，单次运行可能由多个模型决策、工具调用和中间结果组成。

由此产生额外的错误来源：

- 选择了错误的工具，
- 正确的工具收到错误的参数，
- 中间结果被错误解读，
- 执行了不必要的额外步骤，
- 智能体陷入循环，
- 没有进行安全升级，
- 以不成比例的高成本得到正确结果。

因此，核心问题不仅是：

“答案正确吗？”

而且还要问：

“智能体是否以可靠、高效且受控的方式解决了任务？”

AI智能体的7个最重要的指标

为了进行紧凑的实践检验，可以组合七个指标。

这七个指标覆盖三个层面：
质量 → 控制 → 经济性

并非每个智能体都需要完全相同的阈值。研究型智能体与修改订单或处理客户数据的智能体有着不同的要求。

1. Task Success Rate（任务成功率）

最重要的问题是：

智能体是否真正成功完成了任务？

Task Success Rate衡量达到既定目标的测试用例占比。
一个简单的计算公式是：
任务成功率 = 成功完成的任务 ÷ 所有执行的测试任务 × 100

示例：
一个支持智能体处理100个测试用例。

- 82个案例完全解决
- 11个正确升级
- 7个处理错误或不完整

根据定义的不同，正确的升级可以算作成功，也可以单独看待。正因如此，必须在评估前明确“成功”的含义。

Google Cloud也将Task Completion（任务完成）即Goal Satisfaction（目标满足）描述为智能体评估的核心维度。Microsoft Foundry通过Task Completion和Task Adherence提供了可比的评估器。

什么算一个成功的任务？

对于智能体，成功应尽可能具体地定义。
不是：

“智能体应该是有帮助的。”

而是例如：

“智能体应正确查询当前订单状态、告知交货时间，并在数据缺失时升级给工作人员。”

成功定义越精确，评估就越可靠。

2. Tool Call Accuracy（工具调用准确率）

工具使用是聊天机器人（Chatbot）与具备行动能力的智能体之间最重要的区别之一。
智能体可以例如：

- 查询数据库，
- 使用API，
- 打开文件，
- 执行代码，
- 使用CRM系统，
- 调用搜索功能，
- 使用其他智能体或模型。

因此，Tool Call Accuracy至少应回答三个问题：

- 是否选择了正确的工具？
- 是否传递了正确的参数？
- 是否在正确的时机使用了工具？

Microsoft Foundry在工具评估中区分了Tool Selection（工具选择）、Tool Input Accuracy（工具输入准确率）、Tool Output Utilization（工具输出利用）以及综合的Tool Call Accuracy。Google Cloud同样使用Tool Correctness和Trajectory Evaluation等指标。

示例

一个智能体要查找发票RE-2026-3817。

正确：
工具：invoice_lookup
invoice_id: RE-2026-3817

错误：
工具：customer_search
customer_id: RE-2026-3817

在某些情况下，最终答案看起来可能仍然是合理的。但工具评估会揭示智能体采取了错误的行动。

工具准确率不仅仅是“工具运行无错误”

API调用可能在技术上成功，但在业务上却是错误的。
HTTP 200并不自动意味着：动作正确。
因此，应将技术成功率与语义上的工具准确率分开看待。

3. Grounding Error Rate（事实依据错误率）

智能体应尽可能将陈述建立在它实际可用的信息之上。
Grounding Error Rate衡量智能体生成的主张有多频繁地没有被上下文、工具结果或可信来源充分支撑。

例如，Google Cloud为智能体引入了Hallucination（幻觉）指标，检查陈述是否由现有上下文和工具结果所支撑。

一个可能的内部定义是：
事实依据错误率 = 包含无依据或矛盾事实陈述的回答 ÷ 所有被检查的回答 × 100

示例

工具结果：
交货状态：延迟
新日期：未知

智能体回答：

“您的订单将在周五送达。”

这一陈述没有被工具结果支撑。
问题不在于工具调用，而在于对结果的解读。

为什么这个指标特别重要

智能体可以触发真实世界的动作。
聊天中一条无依据的陈述是有问题的。但一个无依据的假设如果随后触发了一个API动作，后果可能会大得多。

4. Human Correction Rate（人工修正率）

智能体可能在纸面上“成功”完成许多任务，却仍然造成大量人工工作量。
因此，一项记录人类需要多少次纠正性干预的指标是值得的。

人工修正率 = 需要人工修正的任务 ÷ 所有已处理的任务 × 100

修正可能是必要的，例如因为：

- 回答需要在专业上改进，
- 工具调用准备错误，
- 决定被撤回，
- 文档需要返工，
- 流程需要手动终止。

Human-in-the-Loop（人在回路）并不自动是错误

重要的是区分：
有计划的人工审批
与
计划外的人工修复。

在转账场景中，审批可以是有意设计的流程环节。这不会提高错误率。
相反，如果员工因为智能体选择了错误的收款人而需要经常纠正，那就是质量问题。

5. Safety Violation Rate（安全违规率）

智能体被允许的行动范围越大，这个问题就越重要：

它是否只执行在其规则和权限范围内的操作？

例如，安全违规可能出现在以下情况，当智能体：

- 泄露敏感信息，
- 执行未经授权的操作，
- 绕过安全规则，
- 未经验证就采信来自不可信来源的输入，
- 对Prompt Injection（提示注入）作出响应，
- 超出其既定的任务范围行事。

Microsoft Foundry为此提供了独立的Risk和Safety评估器。Google Cloud同样将安全作为独立的评估维度。

一个简单的指标：
安全违规率 = 存在规则或安全违规的测试用例 ÷ 所有安全测试用例 × 100

在安全关键型应用中，仅凭平均值往往不够。
例如，一个智能体可能在1000个案例中的999个都正确运行。但如果那一个错误执行了未经授权的转账，纯粹的成功率就没有多大说服力。

6. Cost per Successful Task（每成功任务成本）

智能体可能需要多次模型调用、多个工具和多次重试。
因此不应只衡量单次LLM调用的价格。
更有意义的问题是：

一个真正成功解决的任务要花多少钱？

每成功任务成本 = 所有智能体运行的总成本 ÷ 成功完成的任务数量

其中可以包括：

- 模型推理，
- 外部API，
- 搜索，
- 数据库访问，
- 代码执行，
- 存储，
- 额外的评估模型或评判（Critic）模型。

示例

方案A：

100个任务
90个成功
总成本：9欧元

9欧元 / 90 = 每个成功任务0.10欧元

方案B：

100个任务
95个成功
总成本：28.50欧元

28.50欧元 / 95 = 每个成功任务0.30欧元

方案B在质量上可能更好，但每个成功任务的成本是方案A的三倍。
哪种方案更合理取决于应用场景。

这一指标防止智能体只按质量进行优化而在经济上失控。

7. End-to-End Latency（端到端延迟）

智能体通常需要经过多个步骤。
因此，系统可能给出非常好的结果，但完成一个简单任务耗时过长。
End-to-End Latency衡量总时间：
用户输入 → 智能体运行 → 工具调用 → 中间步骤 → 最终回答/动作

Google Cloud明确将延迟作为Agent Evaluation和Agent Observability的性能指标。

在生产系统中，除了平均值之外，通常还应关注百分位数：

- 中位数 / p50
- p95
- 如有必要，p99

因为平均值可能掩盖极端的异常值。

示例

p50 = 4.1秒
p95 = 16.8秒

这意味着：
一半的请求大约在4秒内完成，但5%的请求需要超过约17秒。
对于交互式智能体来说，这可能是决定性的。

Agent Evaluation Stack（智能体评估堆栈）

七个指标可以概括为一个简单的堆栈。

┌───────────────────────────────┐
│          OUTCOME              │
│      Task Success Rate        │
├───────────────────────────────┤
│          TOOL USE             │
│      Tool Call Accuracy       │
├───────────────────────────────┤
│         GROUNDING             │
│      Grounding Error Rate     │
├───────────────────────────────┤
│      HUMAN OVERSIGHT          │
│     Human Correction Rate     │
├───────────────────────────────┤
│           SAFETY              │
│     Safety Violation Rate     │
├───────────────────────────────┤
│            COST               │
│   Cost per Successful Task    │
├───────────────────────────────┤
│          LATENCY              │
│      End-to-End Latency       │
└───────────────────────────────┘

这个结构是有意保持简单的。
它不是为了取代完整的分类体系，而是为了回答一个实际问题：

如果智能体要投入生产，我会首先测量哪七个数值？

结果与过程分开测量

一个特别重要的原则是：
不要把Outcome（结果）和Trajectory（轨迹）混在一起。

一个智能体可能：

- 以糟糕的过程得到正确的结果，
- 以良好的过程因外部错误而失败，
- 用错误的参数调用正确的工具，
- 为简单任务执行了不必要的过多步骤。

因此，Google Cloud提供了专门的轨迹指标，如Exact Match（精确匹配）、In-Order Match（顺序匹配）、Precision（精确率）和Recall（召回率），用于工具序列。

不过，并不是每个智能体都需要唯一完美的轨迹。
研究型智能体可以通过多种合理的路径达成同一目标。
因此，应区分两类过程：

确定性过程

示例：
验证身份 → 获取账户余额 → 检查限额 → 准备交易

在这种情况下，预期的顺序可能是合理的。

开放性过程

示例：

“为这个任务调研五个合适的模型。”

在这里，不同的搜索和分析路径可能都是有效的。
在这种情况下，更应检查：

- 是否使用了必要的工具？
- 是否避免了不必要的步骤？
- 是否考虑了相关来源？
- 最终决策是否可追溯？

Golden Dataset（黄金数据集）：良好智能体评估的基础

评估需要可复现的测试用例。
为此，带有代表性任务的Golden Dataset（黄金数据集）是合适的。
一个简单的数据集可能如下所示：

对于首次测试，几十个精心挑选的案例往往比数百个任意提示更有价值。
重要的是组合：

- 标准案例，
- 边界案例，
- 错误输入，
- 缺失信息，
- 矛盾数据，
- 工具故障，
- 安全攻击尝试，
- 应有意识地升级的任务。

Google Cloud同样将Eval Cases描述为定义好的智能体任务，带有预期结果和可选的模拟对话流程。

为什么Traces（追踪记录）对智能体如此有价值

Trace显示智能体运行期间发生了什么。
根据系统的不同，它可以包含：

- 用户输入，
- 模型调用，
- 工具选择，
- 工具参数，
- 工具结果，
- 错误，
- 运行时间，
- 最终回答。

这样就从一个结论：

“智能体出错了。”

变成了一个明显更好的诊断：

“智能体在第三步选择了正确的工具，但传递了错误的参数，随后将空返回值解读为成功。”

正是这种过程视角，是智能体评估与简单答案评估之间最大的区别之一。

示例：评估一个支持智能体

一个支持智能体应该：

- 理解客户问题，
- 获取订单数据，
- 选择适当的解决方案，
- 在不确定时升级。

我们定义100个测试用例。
评估后我们得到：

这意味着什么？
88%的任务成功率乍一听不错。
但额外的指标揭示了更多信息：

- 工具使用相对可靠。
- 3%的事实依据错误可能仍然偏高。
- 9%的任务需要计划外的人工修正。
- 在安全测试中未观察到违规。
- 现在可以将成本和延迟与替代的智能体版本进行比较。

只有组合这些数值，才能得到一幅有用的图景。

那Escalation Rate（升级率）呢？

升级率同样是一个重要的指标，但并不是在每个场景中都自动属于七个核心指标之列。

升级率 = 移交给人类的任务 ÷ 所有任务 × 100

高升级率可能意味着两种截然不同的事情：
正面：智能体可靠地认识到自己的边界。
负面：智能体过于不确定，几乎无法实现任何自动化。

因此，升级率应与Task Success（任务成功率）、Human Correction（人工修正）和预期的自动化程度一起解读。

离线评估与在线监控

在生产部署之前，智能体应首先经过受控测试。

离线评估

适用于：

- 新的智能体版本，
- Prompt（提示）更改，
- 新工具，
- 新模型，
- 回归测试，
- 安全测试。

为此需要反复执行固定的测试用例。

在线监控

部署后会产生真实的Trace。
届时可以观察到：

- 错误率，
- 工具错误，
- 延迟，
- 成本，
- 升级，
- 修正，
- 任务成功率的变化。

组合是关键：
离线评估
↓
部署
↓
在线追踪
↓
新的错误案例
↓
扩展黄金数据集
↓
再次评估

这样就形成了一个持续的评估循环。

应该多久重新评估一次AI智能体？

不仅仅是首次部署前。
在以下变更之后，重新评估尤其有意义：

- System Prompt（系统提示），
- 模型，
- 工具定义，
- API，
- 数据源，
- 检索（Retrieval），
- 记忆（Memory），
- 编排逻辑，
- 权限，
- 安全规则。

即使智能体本身没有变化，当外部系统或数据源被调整时，它也可能间接发生变化。
因此，评估应更多地像软件测试那样对待，而不是一次性的基准测试。

LLM-as-a-Judge（LLM作为裁判）：有用，但不能单独使用

一些质量特征可以通过编程方式检查。
示例：

- 是否使用了工具X？
- 客户编号是否正确？
- 延迟是否低于阈值？
- 是否调用了被禁止的工具？

其他标准则更难：

- 回答是否有帮助？
- 问题是否被完全解决？
- 解释是否可理解？

这里可以使用基于模型的评估器，即LLM-as-a-Judge（LLM作为裁判）。
例如，Microsoft Foundry使用Rubric-Evaluatoren（评分标准评估器），可以用它定义智能体的标准，然后进行自动化评估。

但这类“裁判”不应被视为绝对真理。
对于重要系统，建议组合使用：

- 确定性检查，
- 基于LLM的评分标准，
- 人工抽样，
- 生产指标。

一个简单的企业评估流程

对于第一个生产智能体，评估不必以复杂的方式开始。

第1步：定义成功

描述：

什么情况下一个任务算成功？

第2步：收集30–100个代表性测试用例

不仅仅是简单的示例。
也纳入边界和错误案例。

第3步：记录七个核心指标

至少：
Task Success（任务成功率）
Tool Accuracy（工具准确率）
Grounding（事实依据）
Human Correction（人工修正）
Safety（安全）
Cost（成本）
Latency（延迟）

第4步：保存Traces

以便错误日后可解释。

第5步：定义阈值

示例：
Task Success ≥ 90%
Safety Violations = 0
Human Correction < 5%
p95 Latency < 15秒

这些数值只是示例。合理的阈值取决于具体的流程和风险。

第6步：比较版本

不仅仅问：

“智能体版本B好吗？”

而是：

“版本B与版本A相比是否有可衡量的改进——并且成本如何？”

评估AI智能体时的常见错误

只检查最终答案

这样工具选择和轨迹中的错误仍然不可见。

只使用平均值

平均延迟或成功率可能掩盖有问题的异常值。

使用过于简单的测试用例

一个只见过理想条件的智能体，看起来比它在日常中实际表现更好。

忽视成本

更多的模型调用可以提高质量，但会降低经济效益。

把正确的升级算作错误

智能体应该被允许识别不确定性。

从不更新测试数据

生产错误应该转化为新的评估案例。

FAQ：评估AI智能体

如何衡量AI智能体的质量？

不是用单一指标。合理的做法是组合Task Success（任务成功率）、工具使用、Grounding（事实依据）、人工修正、安全性、成本和延迟。

什么是最重要的智能体指标？

对于许多应用来说，Task Success Rate（任务成功率）是最重要的端到端指标。但它不应被孤立看待，因为智能体也可能通过错误或低效的流程达成目标。

什么是Tool Call Accuracy（工具调用准确率）？

Tool Call Accuracy衡量智能体是否选择了正确的工具并使用适当的参数。根据评估系统的不同，工具选择、参数和工具结果的利用可以分别评估。

什么是Agent Trajectory（智能体轨迹）？

轨迹是智能体在任务期间所走的路径。特别包括其动作和工具调用的顺序。

每个智能体都需要Golden Dataset（黄金数据集）吗？

对于可复现的评估，一套固定的代表性测试用例非常有帮助。它支持回归测试以及不同智能体、模型或Prompt版本的比较。

需要多少测试用例？

没有普遍适用的数字。对于第一次内部测试，几十个有针对性的案例可能比大量缺乏代表性的Prompt更有价值。随着生产应用的扩展，测试套件也应扩展。

LLM可以评估其他AI智能体吗？

可以。基于LLM的评分标准或裁判评估器用于定性标准。对于关键检查，应将其与确定性测试、人工控制和生产指标结合使用。

应该持续评估AI智能体吗？

是的。新的模型、Prompt、工具、API或数据源都可能改变行为。生产Trace还可以提供新的错误案例，随后应纳入测试套件。

结论：智能体评估必须衡量完整的路径

AI智能体与简单聊天机器人的区别在于它们能够多步骤行动并使用工具。
正因如此，仅评估最终答案是不够的。

一个可靠的评估应回答三个问题：
智能体是否实现了目标？它是否为此采取了正确的行动？路径是否安全且经济上可接受？

对于精炼的入门，七个指标是合适的：

- Task Success Rate（任务成功率）
- Tool Call Accuracy（工具调用准确率）
- Grounding Error Rate（事实依据错误率）
- Human Correction Rate（人工修正率）
- Safety Violation Rate（安全违规率）
- Cost per Successful Task（每成功任务成本）
- End-to-End Latency（端到端延迟）

它们加在一起并不构成一个通用的基准系统，而是为开发和生产智能体的比较提供了一个贴近实践的起点。

方法论说明：本文总结的“7个指标”是一个面向实践的编辑性评估框架，而非某个供应商的官方标准。其选择参考了反复出现的评估维度，如任务完成（Task Completion）、工具使用（Tool Use）、事实依据/幻觉（Grounding/Hallucination）、安全性（Safety）、人工监督（Human Oversight）、性能（Performance）和运营成本（Betriebskosten）。