第 16 课  搭建评测飞轮

2.1 不需要一开始就测完所有环节

一个 Agent 可能包括模型、系统提示词、上下文、知识检索、记忆、工具、多 Agent 协作、权限控制和前端交互。一次任务还可能经历很多轮判断和行动。

如果一开始就为每个组件、每个步骤都建立完整评测，工作量会很大，而且团队可能花了很多时间测一个并不影响最终结果的环节。

更现实的顺序是：

1. 先用少量典型任务跑通完整流程。
2. 结合执行链路、人工体验和用户反馈定位问题。
3. 找出对任务结果影响最大的失败点。
4. 围绕这些问题建立专项评测。
5. 暂时稳定、影响较小的环节，可以先保留观测，不急着投入复杂评测。

Anthropic 将一次 Agent 评测中的完整记录称为 transcript、trace 或 trajectory，并特别区分了 Agent 的最终回答和环境中的真实结果。例如，Agent 说“机票已经预订”，不代表数据库里真的存在订单。Anthropic：Demystifying evals for AI agents ↗

因此，第一优先级通常不是“每一步是否和设计稿完全一致”，而是“用户的任务是否真的完成”。

2.2 用四个问题判断优先级

可以从四个方面判断一个问题是否值得投入评测：

判断维度	要问的问题	优先级较高的信号
业务影响	出错会影响什么？	任务失败、用户损失、投诉、合规或资金风险
发生概率	这个问题多常见？	高频任务反复失败，或错误在多个场景中出现
不确定性	团队是否知道 Agent 能否稳定做好？	靠人工感觉判断、不同运行结果波动很大
可改进性	测出问题后能否采取行动？	可以调整提示词、上下文、工具、权限或流程

可以把它理解成一个简化的产品判断：

评测优先级 ≈ 业务影响 × 发生概率 × 不确定性 × 可改进性

对于资金、安全、隐私和合规等高风险环节，即使发生频率不高，也应提高优先级；近期频繁修改的环节也更需要回归评测。对于影响很小、已经稳定，而且短期不会修改的环节，可以暂缓专项评测。

2.3 从三层结果中选择评测点

Agent 的评测对象可以分成三层：

层级	主要问题	示例
最终结果	用户目标是否真正完成	是否正确判断可退货，退款单是否真实创建
关键过程	是否在重要节点做对了决定	是否查询正确订单，是否使用有效规则，是否在高风险情况下转人工
运行约束	完成任务的代价和风险是否可接受	是否超时，成本是否过高，是否越权，是否陷入循环

通常先评测最终结果，再评测会影响结果、安全、成本和可解释性的关键过程。

不要因为 Agent 存在十个步骤，就默认需要十套同等复杂的评测。很多情况下，只要确认最终环境状态正确，再对少数关键决策增加检查，就已经能够覆盖主要风险。

2.4 示例：电商客服 Agent 什么值得测

用户问：“我七天前签收的这件商品还能退吗？”

第一版可以优先检查：

• 是否找到了正确订单和签收时间。
• 是否使用了当前有效的退货规则。
• 是否根据商品类型和订单状态得出正确结论。
• 无法确认时，是否说明原因并转人工，而不是编造答案。
• 如果 Agent 执行了退款，退款单是否真的创建成功。

可以暂缓的内容包括：某个低频过渡语是否足够自然、两个都能完成任务的工具调用顺序是否完全一致，以及不影响用户理解的轻微措辞差异。

3.1 第一步：目标和任务

评测前先说清楚 Agent 为什么存在，以及用户希望它完成什么任务。

可以按照下面的顺序拆解：

产品目标
  → 用户任务
  → 成功结果
  → 关键失败
  → 评测任务

例如：

项目	退货咨询示例
产品目标	提高常见售后问题的自助解决率，同时减少错误承诺
用户任务	判断一笔订单是否符合退货条件
成功结果	给出正确结论和依据；需要执行时，真实完成操作
关键失败	用错订单、引用过期规则、错误承诺、越权退款、该转人工时没有转
评测任务	提供订单、商品和规则环境，让 Agent 完成判断或操作

一条合格的评测任务，至少要包含：

• 输入：用户请求，以及 Agent 在真实使用中能获得的信息。
• 环境：可调用的工具、数据状态、权限和必要约束。
• 成功标准：什么结果算完成，哪些错误不能接受。
• 检查对象：最终输出、环境状态，以及确有必要检查的关键步骤。

任务描述要足够清楚。如果两位熟悉业务的人无法对“是否通过”形成基本一致的判断，说明任务或标准还需要继续澄清。每类重要任务最好准备一个确定可以通过评测的参考结果，用来验证题目和评测器本身没有问题。Anthropic：从 0 到 1 建立 Agent 评测 ↗

3.2 第二步：指标和数据 / 用例

3.2.1 选择指标

指标要跟任务目标对应，不要一开始就堆很多分数。

评测维度	可以使用的指标	适用问题
任务结果	任务成功率、正确率、真实操作完成率	Agent 是否完成用户目标
回答质量	正确性、完整性、有依据程度、表达清晰度	最终回答是否可信、可用
工具使用	工具选择正确率、参数正确率、结果处理正确率	Agent 是否正确连接外部能力
安全与边界	越权率、危险操作拦截率、敏感信息泄露率	Agent 是否在允许范围内行动
效率	总耗时、工具调用次数、Token 与单次任务成本	完成任务的代价是否合理
稳定性	多次运行成功率、失败波动、异常终止率	Agent 能否持续稳定地完成任务

一个任务可以有多个指标，但要区分主指标和约束指标。例如，退货咨询的主指标是判断正确率；不能出现越权退款是安全约束；耗时和成本则是效率约束。

不要把所有指标简单加权成一个总分后就停止分析。总分可以用于快速比较版本，但具体改什么，仍然需要回到单项分数、失败类型和执行链路。

3.2.2 建立测试用例

第一批用例可以来自：

• 产品需求中明确要求支持的典型任务。
• 团队每次发布前都会手动检查的场景。
• 线上用户反馈、失败记录和人工接管案例。
• 低频但损失较大的安全、资金或合规场景。
• 容易混淆的相似情况，以及“应该做”和“不应该做”的对照案例。

起步阶段不一定需要几百条数据。Anthropic 的实践建议是，可以先从 20～50 条来自真实失败和人工测试的简单任务开始，再随着产品成熟扩充覆盖范围。这个数量不是硬标准，重点是用例具有代表性，并能帮助团队做出决策。Anthropic：Demystifying evals for AI agents ↗

可以把用例集分成三组：

用例集	内容	用途
核心任务集	高频、代表性的主要任务	比较整体能力，建立版本基线
回归集	曾经出错并已经修复的案例	防止旧问题再次出现
风险与边界集	高风险、异常输入、工具失败、权限限制	验证安全边界与异常处理

每条用例还可以标记任务类型、难度、风险等级、数据来源和首次出现版本，方便按问题类别查看结果。

一份简化的用例可以这样写：

用例名称：签收第 7 天的普通商品退货咨询
用户输入：这件商品还能退吗？
环境状态：订单已签收 7 天；商品不属于特殊品类；规则版本为 v3
期望结果：可以申请退货；说明截止条件；不承诺立即退款
必须检查：订单查询正确、规则版本正确、最终结论正确
禁止行为：编造订单状态、直接创建退款、引用旧规则

3.2.3 同时使用离线评测和线上信号

• 离线评测：在上线前，用固定数据集比较不同模型、提示词或流程，适合基线测试和回归测试。
• 线上评测：对真实运行数据进行抽样打分、用户反馈分析和异常监控，适合发现测试集没有覆盖的新问题。

离线评测可重复、便于版本比较，但可能与真实用户分布脱节；线上数据更真实，但通常缺少标准答案，而且问题已经发生在用户面前。两者应该互相补充：线上问题进入离线回归集，离线改进上线后继续接受真实流量检验。LangSmith：Evaluation types ↗

3.4 一些 Agent 评测平台和产品

平台可以帮助管理数据集、运行实验、保存分数和比较版本，但平台不能替代业务目标、指标和用例设计。

平台 / 工具	适合的使用方式	主要特点
LangSmith ↗	希望把 Trace、数据集、实验、离线与线上评测放在一起	支持代码评测器、LLM-as-a-Judge、成对比较、人工标注等方式
Langfuse ↗	重视可观测性与评测联动，并希望保留云服务或自托管选择	支持人工分数、代码评测器、LLM Judge、数据集实验和线上规则
Arize Phoenix ↗	希望使用开源方案完成 Trace 分析、数据集实验和评测	支持代码评测、LLM Judge、人工标签和 OpenTelemetry / OpenInference 接入
Braintrust ↗	希望管理实验、评分器、CI 回归和线上质量监控	支持数据集、实验快照、代码或模型评分器，以及线上评分
Promptfoo ↗	偏好配置文件和命令行，希望在本地或 CI 中比较模型与 Agent	支持规则断言、模型评分、工具调用与 Agent 轨迹检查

选型时需要比较：现有技术栈、是否需要自托管、数据是否可以上传、团队是否需要界面化标注、是否要接入 CI，以及调用与存储成本。工具能力变化较快，正式采用前应再核对当前版本、部署方式和价格。

不需要等 Agent 完全开发完成再开始评测。第一版可以按下面的顺序搭建：

1. 选择任务：选出 3～5 类最重要的用户任务。
2. 跑通流程：用少量真实或接近真实的案例完成人工测试。
3. 定位问题：结合 Trace 找到影响任务结果的主要失败点。
4. 确定指标：每类任务设置一个主指标，再补充安全、成本或延迟约束。
5. 建立用例集：收集 20～50 条代表性用例，包含正常、异常和高风险情况。
6. 组合评测器：能用代码确定的先用代码，开放质量使用 LLM Judge，高风险和争议案例保留人工复核。
7. 建立基线：记录当前版本的结果，而不是一开始就追求高分。
8. 一次解决一类问题：先针对最有价值的失败点修改 Agent。
9. 运行回归：既测试专项问题，也测试核心任务集，避免局部改善造成整体退化。
10. 上线继续观察：把新的真实失败加入回归集，进入下一轮迭代。

以退货咨询为例：

线上发现 Agent 经常引用过期退货规则
  → 将相关失败按商品类型和订单状态分类
  → 选出影响最大的典型案例
  → 增加“规则版本正确率”和回归用例
  → 修改检索过滤与规则版本管理
  → 重跑专项用例和核心任务集
  → 确认正确率提高，且耗时、成本、转人工率没有异常退化
  → 上线后继续观察真实退货咨询

这就是评测飞轮：不是一次性做一份测试报告，而是不断把问题变成用例，把用例变成改进证据。

请选择你的 Agent 中一个最重要的任务，完成一张评测设计卡：

任务名称：
用户目标：
为什么值得测：
成功结果：
不可接受的失败：
需要检查的最终状态：
需要检查的关键过程：
主指标：
约束指标：
第一批用例：
评测方法：人工 / 代码规则 / LLM-as-a-Judge / Agent-as-a-Judge
回归触发条件：

本课产出：一份 Agent 评测方案，明确高价值评测任务、指标与用例、评测方法和工具，以及从真实问题进入持续迭代的评测飞轮。