评估智能体系统：四轴评估法

2026年初，我在一家北美主要银行进行一项财富管理概念验证。当时正在评估的智能体不是聊天机器人。它存在于一个受管辖的工作流中：接收案例，调用工具（文档检索、筛选检查、账户查询），并生成结构化输出，供下游流程步骤直接使用，无需人工首先阅读。在一次工作会议即将结束时，客户方有人提出了每个企业最终都会问的问题：“为什么是这个模型？每个案例会花费我们多少钱？”

我当时没有一个站得住脚的答案，市场也没有。当时所有关于模型质量的发布内容都是为聊天机器人时代构建的：MMLU 分数、竞技场排行榜、以及基于“感觉”的内部比拼，即有人将相同的提示粘贴到三个模型中，然后选择一个最喜欢的。这些都无法说明这个智能体，在这些工具的配合下，在这个流程中，处理这些案例时，能否以可预测的价格生成正确的字段。排行榜上的 Elo 分数无法告诉你，当案例看起来很常规时，模型是否会悄无声息地跳过制裁检查。

所以我为此构建了一个评估工具。当时，“智能体评估”并不是一个热门类别；没有现成的工具可以评估嵌入流程的智能体，所以我不得不从零开始决定什么值得衡量。我最终确定了四个维度：成本、质量、工具可靠性和温度敏感性。从那时起，这四个维度已应用于许多企业合作项目，而我当时在那个房间里无法回答的问题，现在几乎在每次初次会议中都会被提及。市场已经跟上了这个问题。本指南就是解决之道。

为什么基准评估回答了错误的问题

嵌入流程的智能体与聊天机器人在四个方面有所不同，这些差异使得聊天机器人时代的所有评估技术都失效了。

它在设计上就是多轮的。 一个流程实例是一个循环：模型规划、调用工具、接收结果、再次规划。一个案例可能涉及两次模型调用，也可能是十四次。任何基于“一个提示，一个完成”计算的指标，衡量的是在生产环境中从未发生过的事情。

它调用工具，而工具调用才是真正的工作。 最终答案通常是对话记录中最不有趣的部分。智能体在给出裁决之前是否调用了受益所有权查询，这比裁决的措辞更重要。只检查最终文本的评估，对大多数故障模式是盲目的。

其输出是结构化的，并由机器消费。 智能体输出 JSON，供下游步骤进行路由。没有人在回路中注意到某个字段细微的错误。“听起来没错”不是一个分数；risk_rating要么与黄金标签匹配，要么不匹配。

其成本是整个循环的属性，而非令牌价格列表的属性。 每次工具往返都会重新发送不断增长的对话上下文。对格式错误输出的重试也是模型调用。两个每令牌价格相似的模型，在测量的每个案例成本上可能相差数倍，因为其中一个模型需要更多的迭代才能完成。

维度	基准评估（聊天机器人时代）	流程评估（智能体时代）
衡量单位	一个提示，一个完成	一个流程实例，端到端
交互形式	单轮问答	带有工具调用的多轮循环
判断输出	自由文本，人工偏好	结构化字段，按字段评分
成本模型	每百万令牌价格	每个案例的测量成本，包括重试和工具往返
可见的故障模式	错误或无用的答案	字段错误、跳过工具、工具错误、参数格式错误或幻觉、过早回答
“好”的定义	排行榜位置	流程以可接受、可预测的成本正确完成

本指南的其余部分将逐一介绍这四个维度。每个维度都包含一套具体的日志记录内容和计算指标。它们共同回答了那个房间里的两个问题：哪个模型，以及每个案例的成本是多少。

维度1：每个流程实例的成本

重要的单位不是令牌。它是案例：一份贷款申请、一次 KYC 审查、一项索赔。这是业务部门定价、人员配置和预算的单位，因此也是你的评估必须报告的单位。

每个实例的测量成本是该实例触发的所有模型调用的总和：

• 初始规划调用。
• 每次工具往返一次调用，每次都会重新发送累积的上下文。在一个简单的智能体循环中，输入令牌会随着每次迭代而增长，因此工具密集型案例的成本会比首次调用所显示的更高。
• 每次重试。如果模型输出未能通过模式验证，并且编排层重新提示它，那么这次重试是实实在在的开销，应该计入总数。
• 该模式所需的任何辅助调用：输出验证器、护栏检查、超大工具结果的摘要。

要计算它，需要记录每次模型调用：模型标识符、输入令牌、输出令牌、延迟和完成原因。记录每个实例：迭代次数和重试次数。将令牌数乘以提供商的当前价格并求和。报告中位数和 p95，因为智能体成本分布具有长尾效应；触发三次重试和十二次工具调用的案例，才是最终账单上会显示出来的。

从那时起，一个衍生指标在每次合作中都占据了一席之地：每个正确案例的成本，即每个实例的成本除以模型完全正确完成的实例比例。一个三分之一时间出错的廉价模型并不便宜，因为总有人要为返工买单。

让这个维度在我的工作中声名鹊起的发现是：在首次合作的一个 KYC 任务中，一个中端模型以大约高端模型 1/13 的每个案例成本，达到了与其相同的准确性。不是便宜 20%。是便宜十三倍，而且在该任务上没有测量到质量损失。事后看来，原因并不令人兴奋：该任务是针对明确规范的工具进行提取和遵循规则，而不是开放式判断。现在中端模型在这方面表现良好。但当时房间里没有人会事先押注这个比例，如果没有评估工具，也没有人能证明这一点。每令牌价格列表预测了一个差距；只有测量的每个案例成本才能量化这个差距。

这个维度上的陷阱是比较价格列表而不是实际测量。一个每令牌成本减半，但每个案例平均多出两次循环迭代和一次重试的模型，最终可能会更昂贵。我亲眼见过这种精确的反转发生。衡量循环，而非列表。

维度2：质量，按字段评分

对于嵌入流程的智能体而言，质量意味着：结构化输出是否与一位称职的专家为该案例所产生的输出相匹配？这需要大多数团队会跳过的两件事：一个从真实案例构建的黄金集，以及按字段评分。

构建黄金集。 我的实战经验法则：从真实案例中提取的 10 到 30 个场景，胜过 1,000 个合成场景。合成案例生成器（通常是另一个 LLM）会重现被测模型的相同盲点；它们生成的是干净、格式良好、统计学上平均的案例。真实案例则带有实际会使智能体崩溃的棘手之处：击败匹配启发式的带连字符的姓名、拥有双重国籍的客户、缺少一页的文档、注册地址与运营地址不同的实体。我使用的程序是：

1. 与目前执行该流程的人员坐下来，提取 10 到 30 个真实案例，涵盖常规、边缘和已知困难的类型。
2. 对其进行结构性匿名化：保留困难的形态（连字符、缺失文档），同时替换所有识别性数值。
3. 对于每个场景，让专家写下每个输出字段的正确值，以及正确执行必须调用的工具。第二个标注用于维度3。
4. 请第二位专家审查标签。如果两人意见不一致，则该字段是模糊的；要么收紧其定义，要么将其排除在评分之外。模糊的黄金标签是评估欺骗你的方式。

按字段评分，而非凭感觉。 由于输出是结构化的，大多数评分可以是确定性的：枚举和标识符的精确匹配、姓名和日期的标准化匹配、金额的数字容差。将 LLM 作为评判者保留给自由文本的理由字段，并将这些分数视为方向性的，而非权威性的（关于评判者偏见的更多内容请参见局限性部分）。计算：

• 跨场景的字段准确性，这样你就可以看到entity_type没问题，但source_of_wealth较弱。
• 每个场景的所有字段正确率，这个数字对应着“无需返工的案例”。
• 关键字段准确性作为单独的标题。在合规流程中，pep_flag出错与格式细节出错不同。相应地加权并在报告中说明。

这个维度上的陷阱是评分宽容度的逐渐增加。当模型得分不佳时，人们往往会倾向于放宽匹配器（“差不多就行”），而不是接受分数。在进行内部比拼之前冻结评分规则，并且只有在修改测试套件时才使用的相同严谨性来修改它们。

维度3：工具可靠性，一个无人衡量的维度

这是我从未在其他人的评估中见过的维度，也是改变最多决策的维度。聊天机器人指标没有这个概念，因为聊天机器人没有工具可跳过。

嵌入流程的智能体被赋予工具时，带有一个隐含的契约：对于这类案例，你先调用筛选检查，然后是所有权查询，最后给出答案。模型可能以不产生错误、不抛出异常、最终输出中也没有可见痕迹的方式违反该契约。其中最糟糕的是工具跳过：智能体悄无声息地没有调用它应该调用的工具，然后生成一个看起来完整的答案。

跳过率在演示中是不可见的，但在生产中却是致命的。在演示中，展示的是“快乐路径”案例，输出看起来合理，每个人都点头称是。在生产中，“智能体在 4% 的案例中没有运行制裁检查”是一个监管发现，而不是一个质量指标。唯一的防御措施就是衡量它，这就是为什么黄金集带有预期工具调用标注的原因。我在报告中的固定说法是：跳过率是测量出来的，而不是假设的。

如果你的评估工具只记录了智能体说了什么，那么你评估的只是一个站在工具旁边的文本生成器。记录它做了什么，以及它未能做什么。

从对话记录（你已经为成本维度记录了这些）中，按模型计算：

• 工具召回率：在正确执行所需的工具调用中，智能体实际进行了多少比例？
• 每个工具的跳过率：哪些特定工具被跳过，以及在哪些场景类别中？跳过通常是聚集的；一个被跳过的工具通常是其描述没有明确说明其必要性的工具。
• 工具调用错误率：智能体调用了某个工具，但不是正确的工具。
• 参数格式错误率：未能通过模式验证的调用。
• 参数准确性：通过验证但携带错误值的调用。

工具故障的完整分类，按我担心的程度排序：

工具跳过

智能体本应调用某个工具但没有调用，并且仍然给出了答案。没有任何地方会报错。检测需要预期调用标注；运行时不会告诉你。这是证明整个维度存在合理性的故障模式。

过早回答

跳过的一种系统性变体：智能体开始执行所需序列，但在循环中途决定它已经知道足够多，并在序列不完整的情况下给出了裁决。这在看起来常规的案例中很常见，而这正是审查人员不注意的时候。通过比较执行的调用序列与所需集合来检测，而不仅仅是检查每个工具是否出现在某个地方。

幻觉参数

调用通过了模式验证，运行时也接受了它，但参数值是凭空捏造的，而不是从案例中获取的：一个伪造的账户标识符，一个文档中不存在的日期。这种故障会通过所有自动关卡，并污染下游数据。检测需要参数级别的黄金值或专家抽查；为此做好预算。

工具选择错误

当案例需要筛选工具时，智能体却调用了账户历史工具。这通常是工具描述重叠的症状，而非模型弱点。可根据标注自动检测。

参数格式错误

调用未能通过模式验证。这种故障显而易见，检测成本低，主要是一个重试成本问题，而不是正确性问题，前提是你的编排层确实进行了验证和重试。经常出现参数格式错误的模型，在维度1上也表现为成本高昂，这就是各个维度相互印证的方式。

以下是使这个维度具有可操作性而非宿命论的部分：在我的合作中，很大一部分工具可靠性故障可以追溯到工具规范，而不是模型本身。模糊的描述、重叠的名称、未文档化的枚举、只有编写 API 的人才清楚其用途的参数。修复规范比更换模型更能改善跳过率和工具调用错误率。我将规范方面的规范单独写在了工具契约指南中；评估工具是你发现哪些契约失效的方式，而契约是你修复它的方式。

维度4：温度敏感性

我添加这个维度时，预期它会很无聊。在几个温度下运行网格，确认温度为零会降低输出方差，写一页幻灯片，然后继续。但数据并非如此。

在温度为零时，我测试的模型不仅变得更一致。它们在使用工具方面也变得更彻底：在相同场景和相同提示下，工具召回率更高，跳过率更低。温度正在改变智能体的行为，而不仅仅是其重复性。我的工作解释是机械性的而非神秘的：在每个决策点，模型都会权衡“调用工具”与“根据现有信息回答”，而在较高温度下采样偶尔会选择概率较低的路径，对于一个良好提示的智能体来说，这条路径通常是更“懒惰”的路径。在温度为零时，贪婪路径更常包含工具调用。我对这个解释持保留态度；但我对测量结果坚信不疑。

这个维度之所以存在，是因为受监管的客户会明确要求温度为零，并且供应商通常将其作为一种安全控制措施来呈现。在你向银行重复这一说法之前，你应该了解温度为零对你的特定智能体究竟做了什么，因为“它改变了哪些工具被调用”与“它降低了随机性”是本质上不同的陈述。

在测量出温度为零会改变什么之前，不要告诉受监管的客户它是一种安全控制。在我的运行中，它改变了哪些工具被调用。

方法：在每个候选温度下运行完整的黄金集（我使用 0、一个低值如 0.2 到 0.3，以及提供商默认值），每个设置下的每个场景重复多次，以便你可以将方差与水平分离。报告其他三个维度按温度细分的结果：准确性、工具召回率、跳过率和每个案例的成本，以及作为方差度量的运行间差异。来自实战的两个注意事项：一些推理类模型完全忽略或拒绝温度参数，因此请验证设置是否实际应用；温度发现是针对每个模型和每个提供商的，因此当其中任何一个发生变化时，请重新测量，而不是直接套用结论。

这些数据对你的架构意味着什么：模型路由

这四个维度不是一份要归档的成绩单。它们是路由输入。

将每个候选模型绘制成一个点：一个轴上是测量的每个案例成本，另一个轴上是所有字段正确率。这些点描绘出一条成本-质量曲线，而这条曲线的形状就是决策依据。三种形状反复出现：

• 平坦曲线。 中端模型以高端模型一小部分成本达到相同的质量。这就是 KYC 风格的发现：相同的准确性，大约 1/13 的成本。决策：运行中端模型，将高端模型作为升级目标，并节省差价。平坦曲线在具有良好工具契约的提取和规则遵循任务中很常见。
• 悬崖曲线。 低于某个模型层级时，质量会急剧下降。在需要真正的多步骤判断或跨多个文档进行综合的任务中很常见。决策：支付悬崖以上层级的费用；不要让采购部门说服你选择更低的层级。
• 白花钱曲线。 高端模型更昂贵，但并没有更好，有时在工具召回率上甚至更差（更大的模型并非总是更好的智能体；要测量，不要假设）。决策：显而易见。

更深层次的后果是按步骤路由。嵌入流程的智能体并非一个模型决策；它是每一步一个决策，因为编排层（在我的构建中是 Camunda，但 Temporal、LangGraph 或手写的 Node.js 循环也能提供相同的接口）独立地将模型绑定到每个任务。这使得我如今在每次合作中都采用多模型理念：

• 为每一步选择合适的规模。 文档提取和分类步骤交给评估显示足够的中端模型。需要权衡矛盾证据的步骤则使用高端模型。按步骤运行评估工具，而不仅仅是按流程。
• 根据信号路由到高端模型，而非默认。 模型报告的置信度低、模式验证失败，或黄金集识别出的困难案例类别，可以将实例路由到高端模型，或路由给人工处理。升级决策存在于流程定义中，在那里它是可见且可审计的，而不是隐藏在提示中。
• 最便宜的模型就是不用模型。 如果某个步骤的评估测量行为可以通过规则引擎或查找表重现，那么就完全将 LLM 从该步骤中移除。评估通常是你发现这一点的方式：当一个模型在所有层级上对某个步骤都获得 100% 的分数时，该步骤可能根本不需要模型。

流程层面的每个案例成本就变成了各步骤的加权和，你就可以用一个带有误差范围的数字，而不是耸耸肩，来回答房间里的第二个问题（“每个案例会花费多少钱？”）。

持续运行评估

评估工具的首次运行回答了“哪个模型”。随后的每次运行都回答了一个更重要的问题：“我们是不是把它搞砸了？”

嵌入流程的智能体至少有五个变化面，每个变化面都可能悄无声息地改变这四个维度：

1. 提示词编辑。 无害的措辞调整，却使工具召回率下降了十个百分点。我曾见过一句提示词“澄清”使跳过率翻倍。
2. 工具规范变更。 重命名参数、添加工具、收紧描述。这些变化都会影响模型选择什么以及它如何与模式进行交互。
3. 模型版本升级。 有意的升级。切勿假设新版本在所有四个维度上都优于旧版本；尤其要检查工具召回率。
4. 提供商漂移。 在提供商端更新后，你未被告知的情况下，相同的模型别名表现出不同的行为。在提供商允许的情况下，固定精确的模型版本；如果不允许，定期重新运行评估工具就是你的漂移检测器。
5. 配置变更。 温度、令牌限制、重试策略。维度4之所以存在，是因为这些并非中立的。

因此，将评估工具视为一个回归测试套件。将黄金集与提示词和工具规范一起版本控制在同一个仓库中。用包含提示词版本、工具规范版本、模型标识符和温度的配置哈希值标记每次评估运行，这样任何分数都是可重现的，任何回归都是可二分查找的。像代码门禁一样对变更进行门禁：一个导致工具召回率下降的提示词编辑应该在到达生产环境之前就未能通过审查，而评估报告就是审查的产物。

这是负担得起的，因为黄金集很小。二十个场景，三次重复，一个模型：这只是一次喝咖啡休息时间的运行，足够便宜，可以附加到每次有意义的变更上，而不是留到季度内部比拼时才进行。维度2中 10 到 30 个场景的原则不仅仅关乎标签质量；它使得持续评估在经济上变得“无聊”，而这正是它能够实际发生的原因。

本方法未能解决的问题

这是坦诚的部分，因为一个你过度信任的方法，比没有方法更糟糕。

黄金集会过时。 流程变化、文档格式变化、法规变化，黄金集会悄然停止代表生产环境。黄金集是流程在起草时的一个快照。每当流程本身被审查时，就审查黄金集，并淘汰不再发生的场景。一个针对去年案例仍能得分“绿色”的评估工具，是一种虚假的安慰。

小样本量提供排名，而非认证。 10 到 30 个场景将可靠地对模型进行排名并捕获大的回归。它无法在审计文档中支持“94.2% 准确”的说法；20 个案例的置信区间很宽，假装不是这样是渎职行为。将评估工具用于工程决策。如果合规职能需要一个经过认证的准确性数字，那是一个更大、独立受管辖的抽样工作。

LLM 作为评判者带有已知偏见。 冗长偏见、位置偏见和自我偏好（模型偏向于评价自己家族的输出）都已被记录在案。这就是为什么该方法将评分推向确定性的按字段检查，而结构化输出使得这成为可能。在评判者不可避免的情况下（自由文本理由），使用与任何被测候选模型不同家族的模型，采用固定的评分标准，并定期进行人工一致性检查。并将评判者分数排除在主要数字之外。

评估也像其他一切一样会过拟合。 如果你针对黄金集调整提示词数周，你就是在“应试教育”，分数将不再能预测生产环境的表现。保留一些从不用于提示词变更的场景，并随着新真实案例的到来轮换加入。当保留场景的分数与开发分数出现分歧时，相信保留场景的分数。

四个维度并非全部维度。 本方法未涉及对抗性鲁棒性、通过工具结果进行的提示注入、长程记忆或人在回路交接的质量。这些需要各自的评估。这四个维度回答了企业实际问我的问题；它们是底线，而非上限。

一段话版本

聊天机器人时代的评估无法告诉你哪个模型应该运行嵌入受管辖流程的智能体，因此请以业务部门体验它的方式来衡量智能体：构建一个包含 10 到 30 个真实匿名案例的黄金集，其中包含每个字段的预期输出和预期工具调用，然后从四个维度评估每个候选模型：每个流程实例的成本（每次循环迭代、重试和工具往返，按案例报告，其中一个中端模型曾以大约高端模型 1/13 的成本达到相同的准确性），针对黄金标签的字段准确性（确定性匹配，而非凭感觉），工具可靠性（跳过率、工具选择错误以及格式错误或幻觉参数，这些都是测量而非假设的，因为悄无声息地跳过合规检查在演示中是不可见的，但在生产中却是致命的），以及温度敏感性（在我的运行中，温度为零改变了工具的彻底性，而不仅仅是方差，因此在称其为安全控制之前请先进行测量）。将由此产生的成本-质量曲线用于按步骤的模型路由，在每次提示词、工具和模型变更时将评估工具作为回归测试套件重新运行，并在方法薄弱之处对结果持保留态度：小规模黄金集可以对模型进行排名但不能认证它们，并且黄金集会过时。

参考文献

• Anthropic，《创建强有力的实证评估》：docs.anthropic.com/en/docs/build-with-claude/develop-tests
• Anthropic，《构建高效智能体》：anthropic.com/engineering/building-effective-agents
• OpenAI，《Evals》指南：platform.openai.com/docs/guides/evals
• Zheng 等人，《用 MT-Bench 和 Chatbot Arena 评估 LLM 作为评判者》（关于评判者偏见的经典论述）：arxiv.org/abs/2306.05685
• Yao 等人，《τ-bench：真实世界领域中工具-智能体-用户交互的基准》：arxiv.org/abs/2406.12045
• 伯克利函数调用排行榜，用于公开的工具调用比较（有用的背景信息，不能替代你自己的黄金集）：gorilla.cs.berkeley.edu/leaderboard.html
• Hamel Husain，《你的 AI 产品需要评估》：hamel.dev/blog/posts/evals
• 关于工具可靠性规范方面的配套指南：工具契约
• 本方法提取自与大型金融机构合作的生产概念验证工作；这些合作项目已进行泛化处理，且无客户评估代码公开。