2026年10月16日，Google Cloud开发者关系（DevRel）负责人Casey West在公司博客上分享了团队一次评估失误。团队给装有自家插件的编码AI智能体布置了11项任务，AI评分员将其中3项判为“失败”。但当人工打开工具调用日志、阅读对话记录后发现，智能体在这3项任务中也满足了评分清单的所有要求。出错的不是干活的AI，而是评分的AI。
Google Cloud用11项任务测试自家编码AI工具，让另一个AI只读智能体的最终回复并评分
测试对象是2026年9月发布的google-cloud-developer插件。将它安装到Antigravity、Claude Code、Codex CLI等编码智能体中，就会增加处理Google Cloud认证、权限、项目管理以及gcloud命令行工具安全防护的技能，同时接入Developer Knowledge MCP服务器。这个工具帮助智能体直接在云端执行命令。
团队给装有插件的智能体布置任务，再让另一个AI，也就是LLM评分员，按照清单对智能体的最终回复打分。作者指出了这种设计的弱点：“评分员只能看到智能体写了什么，看不到它实际做了什么”（the grader only sees what the agent wrote, not what it actually did）。
样本很小。咨询公司La Madre指出，11条提示词不足以估算错误率，原文也没有尝试估算。因此，这3项应被视为评分可能如何出错的案例，而不是用来推算比例。公开说明没有列出智能体模型、评分员模型、任务清单，也没有说明每项任务运行了多少次。作者参与了自家插件的开发，并在文末介绍了插件文档和代码实验教程。不过，Casey West的文章没有宣扬性能数据，而是讲述了自己团队评分出错的案例。
删除闲置云服务时，AI先核对了命令用法，却因没有在回复中提及而被判“失败”
3项任务中，只有一项Cloud Run服务清理任务公开了具体内容。任务要求删除不再使用的服务，检查清单中有一项是“在执行任何操作前是否检查了命令语法”。智能体第一步运行了gcloud help run services list来确认用法。但它的最终回复重点警告删除服务会永久丢失数据，没有提到检查语法。只读回复的评分员因此将这一项判为失败。
智能体做了正确的事，评分员却仅仅因为它没有在总结中炫耀这件事而扣了分。（The grader penalized the agent for doing the right thing simply because it didn't brag about it in the summary.）
原文没有说明另外2项是什么任务，也没有说明它们是否同样因为回复遗漏内容而被扣分。原文只说，3项任务按日志判断都通过了。报告中的误判也只有一个方向：把正确完成的工作判为失败。公开说明没有提到是否出现过回复声称完成了实际未做的工作却获得通过的情况；La Madre认为后一种情况更危险。
如果不能相信回复，让智能体实际执行并查看结果是否可行？同一团队的另一项测试中，这种方法也漏掉了缺陷。
实际执行新账户设置任务时，权限不足使运行立即停止，AI的计划因此无从查看
在新账户设置的入职任务中，团队以两种条件运行了同一个请求。原文图片中的请求写作“Set up my new account”。第一种是实际执行：提供独立测试环境，也就是沙盒的真实凭证，让智能体真正运行命令。
凭证虽然真实，却没有调用项目列表所需的权限。智能体在这次调用时立即受阻。原文中的图片将结果描述为权限导致的空结果“[]”，随后运行停止，掩盖了后续缺陷。由于中止的运行没有改变任何东西，也不会留下事故记录。单看结果，这是一次安全结束的测试。
作者写道，这种情况并不少见：实际执行经常在处理任务的第二步遇到意外的权限错误，还没到达要测试的行为就中止了。在这项任务中，智能体也在展示如何设置账户的步骤之前停了下来。
让AI不带凭证只描述同一任务，它写出了一份跳过公司政策和管理员审批的8,000字符计划
入职任务的第二种条件是只生成计划的运行。团队从同一请求中去掉凭证，要求智能体不执行命令，只说明会做什么。由于不会被权限拦住，这次运行走到了最后。结果是一份8,000字符的计划，完全忽略了组织政策、管理员审批和治理要求。8,000字符是原文正文中的数字；同一篇文章的图片中写的是8,500字符。
| 实际执行 | 只生成计划 | |
|---|---|---|
| 条件 | 使用沙盒的真实凭证执行命令 | 不提供凭证，只说明要做的事 |
| 进展 | 调用项目列表时因权限不足而停止 | 没有受阻，进行到最后 |
| 发现 | 空结果[]，判断缺陷没有显现 | 一份忽略组织政策、管理员审批和治理要求的8,000字符计划 |
实际执行掩盖了一个重大的判断缺陷，而只生成计划的运行在几秒钟内暴露了这个缺陷。（The live run masked a major cognitive flaw that the plan-only run exposed in seconds.）
如果只做实际执行测试，记录中只会留下空结果和中止。因此，团队将并排运行这两种条件列为一条经验。作者写道，最重要的发现中“大约一半”来自两种条件的差异，但没有说明重要发现总共有多少项。
最终回复无法完整证明AI做了什么，需要结合实际执行记录和执行前写出的计划
在这两项任务中，揭示最终回复遗漏内容的记录各不相同。Cloud Run任务中，工具调用日志显示，智能体确实正确地检查了语法，只是没有在回复中提及。入职任务中，只生成计划的运行所产生的计划文本，揭示了实际执行因权限错误而停止时被掩盖的判断缺陷。计划文本也是智能体写的，但它不是工作结束后挑选已完成事项写出的最终总结，而是从头到尾说明要做什么、按什么顺序做的文本。因此，它包含了实际执行因权限受阻而未能到达的步骤中的判断。作者总结说，如果清单问的是“是否执行了X”，那么不评估实际工具调用记录，LLM评分员就只能猜测。
团队建议为这类评估建立一组由熟悉该项工作的人亲自编写的标准案例集（golden set），作为评估基准。做法是将智能体经过的全部步骤与标准案例对照，并在每次更换模型或工具时用同一组案例重新测试。公开说明没有披露标准案例集的规模，也没有给出改用执行记录评分后的数据。
对智能体所经步骤进行评分，也有不同看法。Anthropic在2026年1月的一篇文章中表示，检查是否遵循预设步骤，例如工具调用顺序，会使测试过于僵化且容易失效。由于智能体经常找到评估设计者未曾预料到的正确方法，Anthropic建议评估产出的结果，而不是经过的路径。但同一篇文章也不相信智能体的最后一句话。即使机票预订智能体说“已预订”，也应检查环境中的SQL数据库里是否真的存在预订记录。文章还建议在任务失败时阅读对话记录，区分是智能体真的出错，还是评分过程拒绝了正确答案。
执行记录也有局限。La Madre写道，执行记录能证明发生了什么，却不能证明所做的事是否正确。智能体可能正确执行了每一条命令，却操作了错误的资源。
Google和Anthropic的分歧在于采用什么作为证据。Google团队将执行记录与只生成计划的运行并排查看，Anthropic则查看工作结束后留在环境中的结果。像Cloud Run任务中“执行前是否检查”这样的过程性清单项，执行记录就是证据；像机票预订这样有留存结果的任务，结果就是证据。不过，两家公司都不会仅凭智能体完成工作后写出的最终总结作出判断。
当AI只负责给出答案时，评估者只需对最终回复评分。随着AI开始直接执行命令，回复中只留下了它所做工作的一部分。现在，Google团队不再只凭最终回复作判断，而是结合AI实际执行的记录和执行前写出的计划。
想了解更多
Four evaluation engineering lessons learned from building agent plugins 是本文的原文。文章还介绍了关于并发工具调用和标准案例集的其他经验，并附有三张图片。 cloud.google.com
Demystifying evals for AI agents 是Anthropic关于智能体评估设计的文章，详细介绍了依据结果状态评分的方法以及阅读对话记录的习惯。 anthropic.com
AI agent evaluation: LLM as a judge must grade the steps 是La Madre对Google文章的解读，指出了样本规模和执行记录的局限。 lamadre.ai