Google Cloud公开Agent评测复盘:测试工程师怎样判断它真的做完了?

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

摘要

测试一个会查资料、调用命令、修改数据的Agent，最终回复并不等于执行证据。本文依据Google Cloud 2026年10月16日公开的开发者插件评测复盘，拆解为什么LLM-as-a-judge会把正确执行判成失败，并给出可复用的轨迹检查、业务断言与回归方法。

你让一个Agent清理旧服务。它查了命令帮助，确认目标资源，执行前识别出删除操作不可逆，最后提醒你先核对影响范围。测试平台只看到它没有在最终回复里说“我已经检查过命令语法”，于是评分器打了失败。对测试工程师来说，这不是措辞问题：如果我们把最终回答当成完整证据，就可能把执行正确的任务判失败，也可能把执行错误但表达流畅的任务判通过。

Google Cloud在2026年10月16日发布的文章《Four evaluation engineering lessons learned from building agent plugins》，公开复盘了Google Cloud Developer插件的评测实践。文章提到，他们最初用LLM评审最终文本，11条提示组成的评测中有3条被自动评分器判为失败；打开工具调用日志和完整对话后，团队发现这3条实际上都完成了要求。文章以Cloud Run清理任务为例：Agent第一步运行了帮助命令，最终回复重点在提醒永久删除风险，没有把“我先查过语法”复述出来。这里公开的是评测复盘，不是生产事故，也不代表所有Agent都会出现同样比例的误判。

本文要回答三个更实际的问题：评测对象应该落在最终答案、工具轨迹还是业务状态；怎样把“做对了”写成可以回归的判定；怎样让测试团队在不训练模型的情况下，把一次失败调查沉淀成下一版评测集。核心判断是：Agent任务的质量至少有“答复、行动、结果”三层，不能用一层替代另外两层。

人工智能技术学习交流群

为什么“最后一句话”会误导评分

传统问答里，输入和输出相对清楚。用户问一个知识问题，系统返回一句回答，测试可以核对事实、格式和拒答边界。Agent则会在回答前后执行多步动作：读文件、查系统、调用API、等待结果、重试、修改内容，再把结果汇总给用户。最终文本只是一种摘要，它未必完整记录中间做过什么。

这会带来两种相反的误判。第一种是“做对了但没说出来”：Agent完成了必要的检查，却没有按评测器预期复述过程。第二种是“说得像做对了”：Agent在回复里声称已查库存、已撤销退款，但工具调用没有发生，或者工具返回失败后它仍给出成功话术。只看文本，前一种被误伤，后一种被放过。对业务而言，后者通常更危险，因为用户会依据回复采取行动。

所以，评测目标需要拆开。回答质量问“解释是否正确、是否清楚”；行动质量问“调用了什么工具、参数是否合规、顺序是否合理”；结果质量问“系统状态是否达到了业务目标”。有些任务不需要工具，答案层足够；有些任务会造成资金、权限或数据变更，必须看工具轨迹和落库结果。测试设计的第一步不是挑一个评分模型，而是先决定任务成功究竟意味着什么。

把“做对”拆成三种证据

以清理服务为例，假设我们要验证Agent能否按要求删除一个已经下线的临时服务。下面的矩阵是本文建议的测试设计，不是Google公开文章中的原始验收标准。

同一任务可能需要三层都通过，也可能只要求其中两层。比如只读查询，行动证据和结果证据可以来自日志与数据快照；若任务要求用户确认后才执行，行动轨迹还要证明Agent在确认之前没有调用写接口。测试不能把“模型说它检查过了”当成“检查动作确实发生”。

从一次误判，到可以回归的评测集

如果某条评测被判失败，第一步不是马上改提示词，而是把一次运行恢复成可以复核的时间线。至少保存：任务输入、Agent版本、模型与参数、系统提示词版本、工具清单、工具调用及参数、每次工具返回、最终回复、业务状态快照、评测器版本和判分理由。缺其中一项，团队就可能只能讨论“模型今天是不是不稳定”，而无法定位是规划、工具、权限、状态同步还是判分标准出了问题。

排查可以按三个问题推进。第一，任务目标本身是否明确？“清理旧资源”没有定义资源范围、保留期限和谁有权批准，模型与人工可能都无法形成同一标准。第二，评测规则是否观察到正确的行为？要求“先确认影响再删除”，应直接检查工具调用顺序与确认状态，而不能要求模型在自然语言里说一句固定口令。第三，结果是否被独立验证？工具返回200不代表业务状态已经变更，必要时还要查询资源状态、审计记录或下游数据。

这不是说LLM评审没有价值。它适合评估语义质量、解释是否贴合用户问题、拒答是否合理等难以用字符串断言的部分；但它看不到自己没有收到的轨迹，也不应该代替系统状态检查。可以把评审器看作质量信号的一部分，而不是任务完成的唯一裁判。凡是可以从系统日志、数据库或确定性规则验证的事实，优先用可重复的程序断言；只有语义判断才交给模型，并用人工抽检校准。

一套小团队也能复制的四步做法

第一步：给每个业务任务写成功条件。把“Agent会退款”改成“订单属于可退范围、用户已确认、退款金额等于实付金额、退款请求只提交一次、最终状态可查询”。如果无法写出成功条件，就先不要把任务交给自动评分器。

第二步：为每个条件指定证据源。文本用来判断表达；工具轨迹用来判断行为；业务数据库或外部系统状态用来判断结果；人工审批记录用来判断授权。一个条件对应一个来源，不要让judge猜它没有观察到的事。

第三步：保留正反样本。成功样本要覆盖不同措辞、不同工具返回和中途重试；失败样本要包括越权调用、参数错误、工具失败却宣称成功、确认前执行、正确执行但表达不完整。每次误判都要标注“真实行为”和“评测误差”是否被混淆。

第四步：在变更后重跑关键切片。提示词、模型、工具Schema、权限策略、评测器任一发生变化，都可能影响其他环节。用固定小规模回归集先跑高风险样本，再扩展到更大集合。不要只报一个平均通过率，同时展示关键任务的成功数、误报数、漏报数和证据缺失率。

边界：轨迹更完整，也要保护敏感信息

保存轨迹并不意味着把所有用户内容永久记录。工具参数可能包含个人信息、密钥、订单号或内部路径。团队需要定义脱敏规则、采样范围、保存周期和访问权限；对无法保存原文的字段，可以保留哈希、类型、长度或规则化事件。测试可复现性和隐私保护要一起设计。否则为了排错而把凭证写进日志，会制造比模型误判更实际的安全风险。

还要防止测试集被“背答案”。如果所有回归题都固定并且提示词可以读取它们，模型可能学会针对样本投机。保留一部分只用于验收的隐藏样本，定期加入新的失败模式，并对严重业务规则设计独立确定性门禁。评测集的价值来自覆盖真实风险，不来自数量本身。

测试工程师的工作从“看答案”走向“定义证据”

Agent出现之后，测试人员的判断价值没有消失，而是更早地进入任务定义。产品说“自动处理退款”，测试要追问：哪些订单可处理？用户确认以什么事件为准？重复点击如何防重？工具超时后如何确认是否已经提交？模型回答成功但状态未更新时，系统如何对用户说明？这些问题决定了Agent能否安全地进入业务流程。

Google Cloud这篇公开复盘给出的直接启发，不是某个特定评分器的配置，而是评估对象要贴近系统真正做过的事。对测试团队而言，可复制的交付物是一组任务成功条件、一份证据映射表、一套带工具轨迹的回归样本，以及一份误报/漏报复盘记录。下次模型升级时，团队就不必只凭几段对话争论“看起来变好了没有”。

如果你正在测试会调用工具的AI，先挑一个有明确后果的任务，沿着“回复、行动、结果”各写一条断言，再检查现有评测是否真的能观察到它们。真正值得进入发布报告的，不是一个脱离上下文的总分，而是这次任务为什么通过、凭什么通过，以及失败时能不能还原。

推荐学习

🔥 推荐这节公开课：用jev决策模型提速Web测试智能体，实现10倍速度提升。

不讲空概念，直接拆：Web测试智能体的工具与技能、jev/laya决策模型怎么用、Token压缩和知识图谱召回怎么降本、断言体系怎么设计。

做AI测试、Agent落地的同学别错过。扫码进群，锁定席位！