摘要

Google 在 Agents CLI 的官方演示里做了一件很有参考价值的事：把天气 Agent 的提示词换成一个不相关的"厨师人格"，代码没动，平均评测分从4.00掉到2.75。真正暴露问题的不是均分，而是个案里它不再正确调用天气工具。

本文讲清楚三件事：为什么最终回复通过不等于 Agent 没问题、怎样把产品承诺改写成可失败的断言、怎样用官方评测命令搭一个能守住的回归闭环。**

Google 在2026年10月28日的 Agents CLI 演示里，故意做了一次破坏性实验：把天气 Agent 的提示词换成一个完全不相关的"厨师人格"。代码一行没改，平均评测分从4.00掉到2.75（满分5）。

如果只看这个均分，你大概会得出"质量下降了"这种正确但没用的结论。官方示例里真正有价值的线索是另一句：个案显示，它不再正确使用天气工具。均分只是把几十条对话压成一个数字，而工具的调用序列、参数的来源、失败后的分流，全都在压缩过程中被丢掉了。

这就是 Agent 测试和传统功能测试最大的差别。功能测试里，“结果对"通常意味着"过程对”；Agent 里，结果对可能只是因为它把错误包装得很好。用户看到一句礼貌、通顺、格式完整的"您的退款正在处理中"，背后可能是订单号为空、重试三次、读了不属于当前用户的缓存。最终输出是唯一被断言的东西，也是唯一不能证明过程的东西。

把承诺改写成"可失败的句子"

评测最容易犯的错，是先选指标再找数据。更可靠的顺序是：先写关键旅程，再把旅程里的每个承诺改写成一句能判真假的断言。

假设一个"修改收货地址"的客服 Agent（这是本文构造的推演场景，不是某家公司的真实案例），产品文档通常只写"用户可以修改未发货订单的地址"。这句话没法测。拆成可失败的句子，它至少是：

承诺（可失败句）	断言	需要的证据	失败长什么样
必须先确认用户身份	未认证会话不得进入改址流程	鉴权日志	未登录也能改
必须先取到订单号	缺订单号时追问，不得猜测	对话轮次 + 工具入参	自己编一个单号
只能改本人订单	跨用户订单返回拒绝	权限判断记录	改到别人订单
只有未发货可改	已发货状态必须转人工	状态查询返回	直接改成功
地址必须来自用户输入	回复中的地址与入参一致	入参 + 回复文本	用了历史地址
超时必须给人工入口	超时后出现转人工动作	分流记录	静默失败

六句话对应六类证据：鉴权、参数来源、权限、状态、事实一致性、失败分流。它们共同回答"为什么这次算通过"，而不是只留下一个分数。

Trace 要看四件事

拿到一条失败会话的 Trace，先别读自然语言，按这个顺序看：

1. 工具序列：该调的调了吗？顺序对吗？有没有该停不停（缺参数还继续往下走）；
2. 参数来源：每个关键参数是从用户输入、工具返回，还是模型自己补的？这是幻觉最常出现的地方；
3. 重复与循环：同一工具连续调用几次？token 是不是异常高？循环往往比错误答案更贵；
4. 失败分流：工具报错之后，是重试、降级、转人工，还是假装成功？

这四件事恰好是"最终回复断言"看不见的部分，也是 Agent 事故成本最高的部分。

官方指标怎么用，才不会被指标骗

Google Cloud 的 Agent 评测文档给了四类内置指标：最终回复质量、工具使用质量、幻觉、安全。它们有价值，但有个前提——这些是基于评分准则（rubric）的模型评分，不是确定性断言。官方演示本身也提示了三点局限：AI 评审并不完美、小数据集容易过拟合、评测会调用付费模型并传输测试提示，别放真实客户敏感信息。

所以实用的分工是：关键路径用确定性断言，主观质量才交给 Judge。身份、权限、状态、金额这类有唯一答案的，写死断言；语气、完整性、帮助性这类没有唯一答案的，用 Judge 打分，并且定期用人工标注样本校准它。

回到开头那次官方演示，现在能更清楚地看出它为什么值得反复讲：

一个能跑起来的闭环

官方 CLI 的四步很适合直接搬进 CI：生成（对数据集跑 Agent、存 Trace）、评分（按配置的指标打分）、对比（两次运行结果对比）、归因（把失败聚成模式）。演示用的命令结构是这样（官方示例，需按自己项目调整）：

agents-cli eval generate --dataset tests/eval/datasets/basic-dataset.json -o tests/eval/output/
agents-cli eval grade --traces tests/eval/output/eval_dataset_*.json --config tests/eval/eval_config.yaml
agents-cli eval compare --base prev.json --candidate curr.json
agents-cli eval analyze --traces tests/eval/output/

要守住它，还得加三条纪律：数据集进版本库，和代码一起评审；每次提示词、模型、工具变更前后各跑一次；失败用例按模式归因后，转成新的固定用例沉淀下来。20条高质量对话起步就够，关键是每条都能失败、都能解释。

评测集从哪来

20条用例不会从会议室里长出来。四个来源最实用：

一是真实对话的失败样本：客服工单里"答非所问"的记录，脱敏后直接变成用例，这是价值最高的一类；二是产品承诺的反面：每条需求都问一句"如果它做不到，会怎么表现"，把答案写成用例；三是工具契约的边界：空返回、超时、字段缺失、重复调用；四是对抗样本：诱导跳过校验、要求编造信息、跨用户查询。

四类里，第一类决定你测的是不是真问题，第四类决定上线后会不会出事。只做第二、三类，很容易得到一份"全都通过"的评测集。

Judge 怎么校准，才不至于自欺

模型评分的问题不是不准，是"不准得很稳定"——它可能系统性地偏爱长回答、偏爱格式漂亮的输出、偏爱排在前面的一段。校准要做三件事：

1. 取20—30条人工标注样本，让 Judge 打分，算一致性；一致率低于约定阈值，就不许进发布门禁；
2. 把同一对回答交换位置再打一次，看分数是否翻转，翻转率高说明位置偏差严重；
3. 定期混入已知的差答案（金丝雀样本），如果 Judge 给了高分，说明它已经漂移。

这三件事做完，你才能说"这个分数可以参考"。没做过校准的评分，本质上是另一个模型的意见，不是证据。

一个常见坑：工具返回被缓存

构造这样一个场景（推演）：Agent 查退款状态，工具返回"处理中"；三分钟后用户再问，工具其实已经变成"已退款"，但中间层缓存了上一次结果，Agent 照着缓存回答，还加了一句"请耐心等待"。

这条链路上，Agent 的推理没错、措辞没错、格式没错，错在数据新鲜度。如果你的断言只检查"回复是否包含状态词"，它会通过。所以旅程断言里要加一条时间维度：关键状态必须来自本次会话内的工具调用，缓存命中要记录、要标注、要在超过时效时强制刷新。

边界

小数据集会过拟合，别拿"20条全过"当上线依据；Judge 有位置偏差和稳定性问题，别把它的分数当验收结论；这套方法证明的是"已知旅程没退化"，证明不了"未知旅程没问题"。它替代不了探索性测试，只是把探索出来的结论固化下来。

Agent 测试的交付物，正在从一份测试报告变成一份可回归的证据集。报告会过期，证据集不会——下次换模型、改提示词、加工具，它能替你回答同一个问题：这次改动，到底动了哪里。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。