Google公开Agent评测路径：从人工读Trace到发布门禁

Google开发者博客在2026年10月15日公开了一套Agent评测路径：从关键用户旅程、模拟用户和人工Trace审阅，逐步走到自动评测与合并门禁。真正值得测试团队关注的，不是又多了一个评测框架，而是“最终答案看起来没问题”已经不足以证明Agent可以上线。

Google在最新的Agent评测文章里给了一个很刺眼的提醒：Agent可能已经陷入循环、重复调用工具、烧掉大量Token，最后却仍然交出一段礼貌、通顺、甚至看起来正确的回答。

这不是虚构事故，而是Google公开文章明确列出的Agent失效方式。对测试工程师来说，它把一个长期被忽略的问题推到台前：我们过去习惯拿最终输出做断言，但Agent真正昂贵、危险的错误，往往发生在最终输出之前。

本文不复述工具安装步骤，而是把Google公开的Day 0到Day 2路径改造成测试团队可以落地的发布方案：怎样定义“成功”、怎样读Trace、怎样把人工判断转成布尔断言，以及怎样让成本、延迟和工具副作用真正进入上线门禁。

最像成功的失败，最容易逃过回归

假设一个客服Agent接到“帮我查一下退款进度”。它先调用订单查询，订单号为空；随后自行重试三次，又调用退款详情；最后根据缓存信息回复“退款正在处理中”。用户暂时没有发现问题，测试截图里也有一个合理答案。

但这条链路至少暴露四个风险：Agent没有在缺少订单号时停下；重复调用浪费额度；缓存信息可能不属于当前订单；多个失败工具被最终文本掩盖。只断言回复包含“处理中”，四个风险全部会被判为通过。

因此，Agent测试要从“答案断言”变成“旅程断言”。旅程不是把每个内部思考过程都锁死，而是明确哪些业务节点不能跳过、哪些动作不能重复、哪些数据必须来自可信工具、失败后必须落到什么状态。

先把“成功”写成可失败的句子

很多评测项目第一步就错了：团队先选指标，再想拿什么数据喂给它。更可靠的顺序，是先写关键用户旅程，再把旅程中的每个承诺改写成可失败的判断。

以退款查询为例，产品定义不能只写“用户能够查询退款状态”，而要补齐：必须确认用户身份；必须拿到订单标识；只能读取属于当前用户的订单；状态必须来自订单服务；没有结果时不得猜测；超过时限时给出人工入口。

这六句话对应六类证据：身份校验记录、参数来源、权限判断、工具返回、回复事实一致性和失败分流。它们共同回答“为什么通过”，而不是只留下一个模型分数。

测试团队可以先建一张最小矩阵：

这张表的价值在于，它不要求模型每次走完全相同的语言路径，却约束了业务上不可接受的行为。Agent仍然可以灵活，但灵活不能越过风险边界。

Day 0不是自动化，而是拿红笔读Trace

Google的做法有一个很反直觉的地方：第一天不急着追求自动评分，而是人工读一批完整Trace。原因很简单——如果团队还不知道Agent真实会怎样失败，自动生成的Rubric大概率只是把想象中的风险写得更工整。

建议从10至20条高风险链路开始。每条Trace至少保留用户输入、模型版本、提示词哈希、工具名、参数、参数来源、工具返回、重试次数、最终回复、Token和延迟。审阅者用“红笔”标出三类位置：犹豫和循环、错误工具或参数、没有证据支撑的结论。

第一次审阅的产物不应是一个平均分，而是一份失败词典。例如“缺少订单号仍调用”“状态枚举被自然语言改写”“工具超时后凭历史消息补答案”“同一副作用动作被重复调用”。只有这些真实失败，才值得变成下一步的自动断言。

Day 1把判断拆成四层，不要押宝一个Judge

Agent评测最常见的捷径，是把全部内容交给另一个大模型打1到5分。问题是，3分和4分的边界会漂移，Judge也可能被冗长但自信的回答骗过。

Google公开方案把检查分成四层：单元测试、确定性指标、LLM Judge和集成测试。它们不是互相替代，而是各自负责一种问题。

确定性检查适合订单号、工具名、调用次数、状态顺序和时延预算；Judge适合“是否准确回应用户”“是否遗漏关键限制”等语义判断；集成测试验证真实服务、权限和副作用；单元测试负责参数转换、路由函数等稳定组件。

Judge也尽量使用布尔问题：不要问“回答质量几分”，而问“是否在调用退款工具前确认了订单归属”“是否把工具返回的待处理状态写成已到账”。布尔问题更容易校准，也更容易解释为什么拦截发布。

Day 2的门禁不能只看总通过率

平均分会掩盖关键能力退化。一次Prompt修改可能让总体通过率上升，却让“重复退款”这一小类从通过变成失败。如果门禁只要求总体达到95%，高风险回归仍可能被大量低风险样本稀释。

更稳妥的发布门禁包含两条线：总体基线不能明显退化；核心风险项必须零回归。前者看系统整体，后者保护不能交换的底线。除此之外，还要把延迟、Token、工具调用次数和副作用纳入同一张报告。回答正确但调用十二次工具、等待四十秒，并不是可接受的生产结果。

小团队不需要先建平台

三人测试团队也能从一条链路起步。第一周只做退款查询：准备5个正常样本和5个故障样本，保存JSON Trace；人工标注错误；把高频错误改写成pytest断言；每次改Prompt或工具Schema都重跑。

一个最小断言可以这样写：

def assert_refund_trace(trace):
    calls = [x for x in trace["steps"] if x["type"] == "tool"]
    assert len(calls) <= 2, "出现无条件重试"
    assert all(c["args"].get("order_id") for c in calls)
    assert trace["answer_state"] == trace["tool_state"]
    assert trace["token_total"] <= 6000

这段代码不判断文案是否优美，它守住四个可确定的边界。语义质量再交给经过人工校准的Judge。两类判断分开，失败时才能知道应该改代码、工具说明、Prompt还是评分规则。

测试工程师真正升级的是“定义成功”

Agent让执行变快，也让表面正确更容易制造。测试团队的价值因此不再只是找一句错话，而是把业务成功拆成可观察、可证明、可阻断的条件。

Google这套路径最值得复制的，不是某个框架名称，而是顺序：先从关键用户旅程定义风险，再用真实Trace发现失败，随后把判断分层自动化，最后才把可靠信号放进发布门禁。

当团队能回答“它经过了哪些关键步骤、依据什么数据、付出多少成本、失败时是否停下”，Agent才算真的被测过。

把失败词典变成团队资产

失败词典不能只留在某次评测报告里。每条失败都应绑定触发样本、可观察证据、责任边界和回归频率：例如“缺订单号仍调用退款”对应输入模板、工具参数断言和发布前阻断级别；“超时后凭历史消息补答案”对应超时注入、状态一致性断言和人工复核。这样，下一次模型升级时，团队不是重新凭感觉写一批问题，而是沿着过去真实发生过的失效路径验证变化。

还要允许失败样本过期。业务规则、工具Schema和权限模型变化后，原来的断言可能不再适用，但不能静默删除。给样本加上规则版本、失效原因和替代样本，才能在回放时解释“这次不再测试它”与“它没有失败”之间的区别。评测系统最后交付的不是一个漂亮分数，而是一套能持续更新、能追责、能让发布决策复盘的证据账本。