Agent 评测不能只看回答对不对：从路由、RAG 到工具调用，怎么搭一套上线前评测体系？

Agent 评测不能只看最终回复，真正的风险藏在路由、检索、工具调用等中间环节。本文拆解七层评测体系，从输入到轨迹，教你如何识别高风险错误，确保系统上线安全。

上一篇写智能客服 Agent 架构时，我留了一句话：评测不能只问回答对不对。

文章发出去后，后台的收藏数很快接近点赞数。有人评论，看完一下子就有思路了。我顺着那篇文章继续往下拆，发现评测这一段值得单独写，而且比架构选型更容易踩坑。

架构图画得再专业，Router、RAG、垂直 Agent 和工具都接好了，团队最后还是要回答一个很朴素的问题：它到底能不能上线？

很多团队的办法是准备几十道问题，让 Agent 回答一遍，再由产品、运营和业务同学坐在会议室里看答案。大部分回复读起来没问题，大家就觉得效果不错。

但 Agent 真正危险的错误，经常藏在最终回复之前。

用户只是问退款规则，Router 却把请求送进了退款执行；RAG 找到了过期规则，但 Agent 把答案写得很流畅；工具调用返回成功，实际退款对象却选错了；同一条用例第一次通过，重跑五次失败两次。

最终回复甚至可以完全正确：您的退款已经处理。

问题是，它退错了订单。

所以我对 Agent 评测的判断很直接：

不要给最终回复打一个总分，要检查系统在每个决策点有没有做对，还要确认真实业务状态有没有被正确改变。

一套问答准确率，为什么评不了 Agent

普通问答系统的输入和输出相对清楚。

用户提出问题，系统生成答案。评测可以围绕事实是否正确、表达是否相关、有没有引用依据展开。虽然也不简单，但至少评测对象比较稳定。

Agent 中间多了决策和动作。

它要判断请求属于哪个业务域，决定是否检索知识，选择工具，补充参数，处理工具结果，必要时重试、澄清或转人工。前一步的错误会进入后一步，最后变成业务状态变化。

LangSmith 的官方文档把 Agent 评测拆成三类：最终回复、单步决策和完整轨迹。这个拆法解决了一个关键问题，到达正确答案，不代表过程正确；过程与参考答案不同，也不一定代表结果错误。

假设用户要取消一个还没出库的订单。

路径 A 是先查订单，再调用取消接口；路径 B 是先确认用户指的是哪一笔订单，再查订单状态，最后取消。两个路径都可能正确。如果评测要求工具序列必须与标准答案一模一样，路径 B 会被错判。

反过来，如果只看最终回复，Agent 先取消了订单，再查订单状态，最后告诉用户已经取消，结果虽然对，路径却存在明显风险。

这也是 Agent 评测最麻烦的地方。它不是一道只有标准答案的考试，更像一次带权限的业务操作审计。

至少要判断五件事：

1. 最终结果是不是用户要的；
2. 中间选择的路径是否可接受；
3. 每一次动作是否符合权限和业务规则；
4. 系统最终状态是否一致；
5. 同样的任务重复运行是否稳定。

只测第一项，Agent 很容易在演示里显得聪明，在生产里制造事故。

从一个总分，拆成七层评测

我更建议沿着 Agent 的真实执行链路，把评测拆成七层。每一层回答一个不同的问题，也对应不同的负责人和修复方式。

输入层：测试真实用户怎么说，而不是测试 Prompt 范例

很多测试集看起来整齐得不像真人。

每条问题都有明确意图、完整参数和标准表达，比如查询订单 12345 的物流状态。真实用户更常说的是：我的东西怎么还没到？

输入层要覆盖表达差异，也要覆盖信息状态。

同一个任务至少要有正常表达、口语、省略、错别字、多意图、用户改口、上下文冲突和恶意诱导。需要订单号的任务，要分别测试参数完整、参数缺失、存在多个候选订单以及用户给出无权访问的订单号。

产品经理最容易漏掉的，是业务分布。

测试集里每种意图各放 20 条，看起来很公平。线上可能 60% 是查询，20% 是规则咨询，只有 1% 是高风险退款。如果只算总体准确率，高频简单问题会把高风险任务的失败遮住。

测试集应该同时保留两种口径：一套均衡集用于发现各场景能力，一套按真实流量加权的分布集用于预测线上表现。

路由层：不只看分对没有，还要看分错的代价

Router 常见指标是意图准确率、Precision、Recall 和 F1。这些指标有用，但不够决定能不能上线。

用户说我不想要了，可能是咨询取消规则，也可能是执行取消。把执行请求分到咨询路径，最多多问几轮；把咨询请求分到执行路径，可能直接改变订单状态。两次错分不能算成同样的一分。

路由评测至少需要三张表。

第一张是意图混淆矩阵，看哪些业务域最容易互相污染。

第二张是风险混淆矩阵，单独统计高风险请求被放进低风险路径的比例。

第三张是兜底表现，观察低置信度时系统能不能澄清、退回 Router 或转人工，而不是硬选一个答案。

这一层真正值得盯的指标不是总准确率，而是高风险漏判率、错误执行入口率和正确兜底率。

一个 Router 总准确率 95%，但把 10% 的退款咨询送进执行链，不能上线。另一个 Router 准确率只有 90%，不确定时会澄清，也许更适合先灰度。

检索层：答案没错，不代表知识链路没问题

RAG 评测经常被压缩成一句：回答是否准确。

这会把检索和生成混在一起。答案错了，团队不知道是没找到正确材料，还是找到了但模型没有忠实使用；答案对了，也可能只是模型碰巧知道，而不是系统取回了企业规定。

Ragas 把这一层拆得更细，包括 Context Precision、Context Recall、Faithfulness 和 Response Relevancy。换成产品语言，就是四个问题：

• 找回来的材料有多少真的相关；
• 应该出现的关键材料有没有漏掉；
• 最终回复是否忠于取回材料；
• 回复有没有真正解决用户问题。

企业场景还要补三个字段：知识版本、有效时间和可见权限。

一段政策内容语义完全相关，但上周已经失效，检索命中不能算成功。内部客服手册回答得很准确，但普通用户无权看到，也不能算成功。

因此，一条 RAG 用例的标准答案不该只有一段文本，还要标注期望知识 ID、允许版本、适用时间和禁止引用的内容。

无答案也是一类正式用例。知识库没有可靠材料时，系统能否承认不知道、补问或转人工，比强行生成一个完整答案重要。

单步决策层：工具选对了，参数从哪里来

进入工具调用以后，评测对象从文字变成结构化动作。

Berkeley Function Calling Leaderboard 关注函数选择、参数、拒绝调用、多轮和状态场景。它提醒了一个常见误区：会输出合法 JSON，不等于会正确使用工具。

工具调用至少要检查五项：

1. 是否应该调用工具；
2. 是否选择了正确工具；
3. 参数名称和类型是否符合 schema；
4. 参数值是否正确；
5. 参数是否来自可信来源。

第五项最容易被漏掉。

用户说帮我退掉刚才那单，Agent 从会话里猜出一个订单号。这个号码恰好存在，schema 校验能通过，接口也能成功。只有追踪参数来源，才能发现它不是用户确认的，也不是当前页面提供的可信上下文。

所以评测数据里需要记录参数 provenance，也就是来源。订单号来自用户明确选择、系统读取、历史会话，还是模型推断，风险完全不同。

还要测试不该调用时是否拒绝。不存在的工具、缺失关键参数、没有权限的动作和超出业务范围的请求，都应该进入测试集。

轨迹层：允许多条正确路径，但禁止危险捷径

轨迹是 Agent 从接收请求到给出结果之间的完整步骤，包括路由、检索、工具调用、状态变化和最终回复。

最简单的评测方法是与标准工具序列做精确匹配。它容易实现，却会误伤正常差异。复杂任务通常不只有一条正确路径。

更实用的做法，是把轨迹标准拆成三类：

1. 必须步骤，例如退款前必须验证订单归属；
2. 允许步骤，例如可以先查询售后单，也可以先查订单状态；
3. 禁止步骤，例如身份未确认前调用退款接口。

最后再限制成本与效率，包括最大轮数、重复调用次数、总延迟和单次任务成本。

这样评测的不是 Agent 有没有背出唯一流程，而是它有没有跨过必须经过的门、有没有踩进禁止区域、有没有用离谱的成本完成一件简单任务。

OpenAI 在讨论第三方 Agent 评测时也特别强调运行配置：模型、工具权限、harness、重试次数、token、耗时和成本都属于评测结果的一部分。换一个工具集或允许多次重试，成功率就可能完全不同。

只报某模型成功率 90%，却不说它能重试几次、花了多少钱、用了哪些工具，这个数字没法支持产品决策。

状态层：别相信回复，要查数据库最后变成了什么

工具返回 success，不等于任务真的完成。

取消订单可能涉及订单状态、支付退款、库存释放和用户通知。主接口成功了，库存回滚失败，Agent 仍然可以回复取消成功。只检查对话和接口响应，发现不了系统已经进入部分成功状态。

τ-bench 的做法很值得借鉴。它不只比较 Agent 说了什么，而是把对话结束后的数据库状态与目标状态比较。

业务 Agent 的端到端评测也应该这样设计。

每条执行类用例要定义初始状态、目标状态、不允许改变的字段以及可接受的中间状态。评测运行在隔离沙箱中，完成后直接查询业务对象，而不是从 Agent 的回复里判断成功。

例如取消订单的目标状态可以写成：订单已取消、支付进入退款中、库存已释放、未创建重复售后单。用户通知失败可以标成可补偿异常，但订单仍处于已支付就必须判失败。

这一步把评测从聊天质量检查，推进到了业务一致性检查。

业务层：自动化率不是越高越好

最后才看自助解决率、转人工率、处理时长、满意度、投诉率和单次解决成本。

业务指标适合回答这套 Agent 有没有价值，却不适合单独定位问题。

转人工率下降，可能是 Agent 能力提升，也可能是它没有识别风险；平均处理时长变短，可能是路径更好，也可能是系统过早结束对话；自动化率升高，可能同时带来更多错误退款。

业务指标必须与风险指标成对看。

比如自动解决率旁边放错误执行率，平均处理时长旁边放一次解决率，转人工率旁边放应转未转率。否则一个漂亮数字，很容易把事故藏在平均值里。

一条真正有用的评测样本，应该长什么样

很多团队建立测试集，就是 Excel 里的三列：问题、标准答案、是否通过。

到了 Agent，这个结构装不下真实任务。

一条合格样本至少包含八部分：

1. 用户输入与多轮上下文；
2. 初始业务状态；
3. 任务目标；
4. 期望路由与风险等级；
5. 必须、允许和禁止的步骤；
6. 工具参数与可信来源；
7. 目标业务状态；
8. 评分规则与失败严重度。

标准答案也不必只写一段固定文案。

对于规则问答，可以标注关键事实和禁止承诺；对于工具调用，可以标注允许的工具集合和参数约束；对于复杂任务，可以用 rubric 描述必须满足的业务条件。

这能避免两个极端。

一个极端是过度精确，Agent 换一种正确说法也判错。另一个极端是过度宽松，只要最终读起来顺就算通过。

样本从哪里来

第一批样本不应该由大模型凭空生成。

先从历史工单、业务 SOP、线上日志、客服质检和事故记录中抽取任务。产品经理与业务负责人共同写少量高质量黄金样本，把什么叫做做对说清楚。

LangSmith 的官方建议很实际：先为每个关键组件人工整理 5 到 10 个好例子。这些样本不是为了追求统计显著，而是逼团队先统一标准。

有了种子集以后，再扩展四类样本：

1. 等价表达：口语、错别字、省略和同义说法；
2. 边界样本：金额刚好在阈值上下、规则刚好过期、多个对象同时存在；
3. 对抗样本：诱导越权、伪造身份、要求忽略规则、把外部文本当系统指令；
4. 失败回流：灰度和线上真实失败，经脱敏标注后加入回归集。

生成式扩写可以提高覆盖面，但它不能替代业务标注。大模型很擅长生成看起来像用户的话，也很擅长一起生成看起来合理但并不存在的业务规则（这一步真的别偷懒）。

别让测试集被自己污染

Prompt 调了几十轮以后，团队很容易记住测试题，并围绕固定样本做局部优化。分数越来越高，线上问题没少。

测试集至少分成开发集、回归集和保留集。

开发集允许研发反复查看，用于快速定位；回归集在每次模型、Prompt、知识库、工具和策略变化后运行；保留集限制可见范围，用来验证团队有没有把系统调成只会做熟题。

线上真实流量还要保留小比例抽样，持续验证离线分数与业务表现是否一致。

评分不能只有平均分，上线要有否决项

假设一套 Agent 的路由 95 分、RAG 92 分、工具调用 90 分、最终回复 94 分，平均 92.75 分。

能上线吗？不能从平均分判断。

如果剩下 10% 的工具错误都是重复退款，平均分越精确，决策越荒唐。

评测结果至少要分三档。

第一档：安全与合规否决项

包括权限越界、敏感信息泄露、未确认就执行不可逆动作、重复扣款或退款、高风险请求未转人工、绕过策略引擎等。

这类指标不参与平均，直接设置上线门槛。高风险动作通常要求测试集中零严重事故；无法做到零风险的场景，也必须给出明确容忍度、人工兜底和事故半径。

第二档：任务成功指标

包括路由正确、检索命中、工具与参数正确、目标状态达成、任务一次解决等。

这类指标按业务场景分别统计，不能只看全量平均。退款、挂失、信息查询和投诉分流应有各自门槛。

第三档：体验与效率指标

包括回复相关性、对话轮数、延迟、token、调用成本和用户满意度。

它们决定产品好不好用，也决定自动化是否划算。但在安全和任务成功没有过线之前，不要拿更自然的语气和更短的延迟掩盖功能错误。

还要报告置信区间与样本量。十条样本全对和一千条样本 99% 正确，不是一回事。

LLM-as-a-judge 很好用，但不能当唯一裁判

人工逐条评审很慢，LLM-as-a-judge 很自然地成为评测工具。它适合判断回复是否相关、事实是否一致、是否遵循一段复杂 rubric，也能检查一条完整轨迹是否合理。

但 Judge 本身也会漂移。

换一个评测模型、Prompt 顺序或评分描述，分数会变。Judge 还可能偏爱更长、更像标准答案或与自己表达习惯相近的回复。

更稳妥的组合是：

• 能用代码确定的，优先用确定性规则，例如 schema、金额、权限、数据库状态；
• 需要语义判断的，再用 LLM Judge，例如解释是否完整、轨迹是否符合 rubric；
• 高风险和低置信度样本，由人工复核；
• 定期抽样比较 Judge 与人工一致率。

评测工具也需要评测。先做一批人工金标，确认 Judge 在当前业务上能稳定区分通过与失败，再让它参与大规模自动评分。

OpenAI 内部数据 Agent 的做法就是一个具体例子。它不只比较生成 SQL 的文本，还会执行 SQL、比较结果，再把多种信号交给 grader。因为两段 SQL 写法可以不同，但得到的业务结果相同。

Agent 评测也一样。能确定的结果先确定，再让模型判断无法写成硬规则的部分。

上线前，不是跑一次大考，而是建立持续闭环

Agent 的模型、Prompt、知识、工具和业务规则都在变。一次评测通过，只能证明这个版本在这批样本上通过。

我会把完整闭环拆成五步。

建立基线

先固定模型版本、Prompt、知识快照、工具 schema、策略版本和运行预算。用种子集跑出每一层的基线，不急着追一个综合分。

做变更回归

任何模型切换、Prompt 修改、知识更新、工具新增和策略调整，都触发对应回归集。变更只影响 RAG，也要检查端到端任务，因为知识变化可能改变后面的工具选择。

做故障与对抗测试

主动制造超时、空结果、重复回调、过期知识、权限不足、部分成功和用户中途改口。系统必须知道是重试、查询状态、补偿还是转人工。

顺风顺水的 happy path 只能证明 Demo 能跑。

小流量灰度

先开放只读、可逆、低金额和低事故半径的任务。灰度期间同时记录 Agent 轨迹、业务状态和人工接管结果。

每次只扩大一个变量，例如用户比例、任务类型或自动执行额度。否则指标变化后很难归因。

让线上失败回到评测集

线上监控发现新的错分、知识缺口、工具异常和用户表达后，经过脱敏、复现和标注，加入回归集。

评测集不是上线前交付物，而是 Agent 的长期产品资产。

产品经理真正要交付的，不是一张指标表

Agent 评测很容易被理解成算法同学的工作。模型指标和评测代码当然需要技术实现，但业务里的正确答案，技术团队无法替产品和业务负责人定义。

产品经理至少要推动五个交付物。

1. 任务地图。 把一个主题拆成真实任务。例如退款包含规则咨询、资格判断、进度查询和执行退款，而不是统一写成退款问题。
2. 风险分级表。 记录每个任务能否修改状态、错误代价、是否可逆、是否需要确认和谁承担责任。
3. 黄金样本集。 写清初始状态、目标状态、允许路径、禁止动作和评分规则，不只写标准话术。
4. 版本化评测报告。 每次结果都绑定模型、Prompt、知识、工具、策略和预算。没有版本信息的分数不能比较。
5. 上线闸门。 哪些指标必须达到多少，哪些严重错误一票否决，灰度范围多大，出现什么问题自动回退。

产品经理最关键的工作，是把业务里的做得不错，改写成机器和团队都能重复判断的通过条件。

用一次电商退款，把整套评测跑通

最后放一个完整例子。

用户说：我刚买错了，帮我退掉。

初始状态是用户有两笔最近订单：订单 A 已支付未出库，订单 B 已发货。当前页面没有绑定订单，用户也没有明确说是哪一笔。

正确目标不是立即完成退款，而是先确认对象，再根据订单状态进入不同流程。

1. 输入层要判断这是一条参数缺失、多候选对象的执行请求。
2. 路由层应进入售后域，并打上写操作与资金风险标签，不能送到普通退款政策问答。
3. 检索层可以读取当前退款规则，但规则只用于解释资格，不能替代订单状态查询。
4. 单步决策层应该先调用订单列表查询，不能直接猜订单号。Agent 向用户展示候选订单并获得明确选择后，参数 provenance 才变成用户确认。
5. 轨迹层的必须步骤包括确认订单归属、确认目标订单、查询状态和执行前二次确认。允许步骤可以包括先解释退款影响。禁止步骤是在对象不明确时调用退款接口。
6. 状态层需要检查订单是否进入正确售后状态、退款单是否只创建一次、库存与支付是否进入预期状态。接口超时后，Agent 应先查询退款结果，不能直接重试。
7. 业务层再统计任务是否一次解决、用了几轮、耗时多少、是否转人工以及用户是否重复咨询。

这条用例第一次成功还不够。至少重复运行多次，并测试用户改口、接口超时、订单刚好出库、金额超过自动额度和退款成功但通知失败。

τ-bench 用 pass^k 衡量 Agent 多次运行的一致性，这个思路很适合生产场景。用户不会接受一个退款 Agent 平均表现不错，但同样操作偶尔会退错单。

平均正确，是模型能力；每次守住边界，才是产品能力。

下一次有人问 Agent 效果怎么样，别再只展示十段看起来很聪明的对话。

把它做过的每一步、调用过的每个参数、最终改变的业务状态，以及失败后怎么收回来，一起摆在桌面上。

能把这些问题回答清楚，才到了讨论上线的时候。

主要参考资料

OpenAI：How evals drive the next chapter in AI for businesses

OpenAI：Inside OpenAI’s in-house data agent

OpenAI：A shared playbook for trustworthy third party evaluations

LangSmith：Application-specific evaluation approaches

LangSmith：Evaluation concepts

Ragas：Available metrics

AgentBench：Evaluating LLMs as Agents

BFCL：From Tool Use to Agentic Evaluation of Large Language Models

τ-bench：A Benchmark for Tool-Agent-User Interaction in Real-World Domains

本文由 @葛葛的产品日记 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议