Four evaluation engineering lessons learned from building agent plugins

四条评估工程经验 | Google Cloud 博客

开发者与从业者

从构建代理插件中学到的四条评估工程经验

2026年10月17日

##### Casey West

Google Cloud AI基础设施与应用工程开发者关系负责人

##### 今天试用Gemini

职场AI的入口

立即试用

构建代理系统真正的挑战不是构建本身，而是衡量。

评估工程是构建可靠AI系统的关键基础。建立系统化、可重复的测试来衡量代理的真实行为，这将决定你交付的工具是值得信赖的，还是在静默中崩溃、无法调用API或出现错误。

我在Google多年主导评估工程实践，而新发布的Google Cloud开发者插件的开发则成为了一个实时测试场，用于在真实开发者工作流中对这些关键原则进行压力测试。

以下是我们在构建新插件过程中学到的四条评估经验，你可以将它们应用到自己的开发中。

1. 评估执行步骤而非总结

我们最初评估代理时，设置了一个以大语言模型作为评判者的系统，用于检查代理的最终文本回复并根据检查表打分。但很快我们意识到这种方法存在根本性缺陷，因为评分者只能看到代理写的内容，而无法看到它实际执行的操作。当我们在Google Cloud开发者插件上运行最初的11个提示词评估套件时，自动化评分系统标记出三个提示词未通过。但当我们查看原始工具调用日志并阅读对话记录时，插件实际上已经通过了这三个测试。例如在Cloud Run清理提示词中，我们的评分标准要求在执行任何操作前检查命令语法。代理将gcloud help run services list作为第一步执行了操作。它确实完成了工作，但最终信息的重点是警告用户关于永久数据丢失的风险，而非复述它已检查了帮助文档。

评分者因为代理没有在总结中炫耀自己的正确操作而对其进行了惩罚。如果你的评分标准写着"是否执行了X操作？"，除非你评估实际的工具调用轨迹，否则大语言模型评判者只能进行猜测。

要点：不要根据代理的总结陈述进行评分。通过评估原始执行轨迹来验证实际执行、验证和范围限定的命令。

2. 为异步操作设计评估

当你开始阅读工具调用轨迹时，如何提取这些遥测数据与你阅读的内容同样重要。将代理遥测数据提取为扁平化的事件列表会掩盖并发工具调用，而这是导致行为失败的关键原因之一。现代代理框架通常会通过调用数组将多个工具调用合并到单个助手回合中。

在我们的评估中，当代理被要求检查环境并查找文档时，框架会在单个tool_calls负载中同时发送技能加载调用和两个文档搜索请求。由于激活技能是一个多阶段过程（初始调用返回一个简短的启动存根，后续回合注入完整指令正文），本应指导搜索的指令在系统已执行搜索后才出现在提示词上下文中。

系统从未为该技能分配过专属回合，使其指导无法影响代理的行为。如果遥测管道剥离回合结构并合并调用到扁平时间线中，工程师将浪费数天时间，疑惑为什么代理忽略了开发者嵌入技能中的明确指令。

要点：在遥测提取器中保留回合结构，以便识别客户端并行分发工具调用时是否在注入指导进入上下文窗口前出现问题。

3. 并排测试实时运行和"模拟运行"

你需要检查真实的API调用，才能发现诸如并行分发等工具特性。但如果你只在单一环境条件下测试代理，就相当于蒙眼飞行。从第一天起，你需要并行运行两种条件：实时运行和仅计划运行。在实时条件下，代理拥有真实沙箱凭证并实际执行命令。这能让你验证语法是否有效、参数是否能干净序列化，以及代理在执行破坏性操作前是否保持克制。

实时运行经常在第二步就遇到意外权限错误并中止，甚至在你尝试测试的目标行为之前就终止了。这就是为什么你需要仅计划条件——剥离凭证并让代理解释它会执行什么操作而无需实际运行。这能消除权限障碍，展示模型纯粹的推理和路由意图。我们最重要的发现中约有一半来自两种运行方式的差异。

例如，在我们某个引导提示中，实时运行在项目列表调用时立即被阻断。而仅计划运行则顺利通过，生成了8000字符的计划，完全忽略了组织策略、管理员审批和治理规则。实时运行掩盖了一个重大认知缺陷，而仅计划运行在几秒钟内就暴露了这个问题。

要点：并排运行实时和仅计划评估。实时运行测试实际执行和安全克制；仅计划运行展示模型的原始推理和路由逻辑，不会因权限错误而受阻。

4. 使用"黄金数据集"作为持久基准

前沿模型架构每几个月就会变化，代理工具链持续改进，插件清单标准也必然演变。在构建Google Cloud Developer插件时，我们将评估视为这些非确定性环境的持续集成测试。这意味着我们对复合堆栈进行了压力测试，包括工具链、实时模型以及在真实任务上协同运行的工具。

与其猜测最终文本输出，这种方法会捕捉完整轨迹：代理的思考过程、实际执行的命令，以及是否在不破坏任何东西的情况下解决问题。然后你将这些运行结果与由真正了解理想路径的人类专家精心整理的黄金数据集进行比对。

要点：基于整个系统在真实场景中应实际执行的操作构建黄金数据集，包括你的工具链、模型和插件。模型会变化，但这些基准运行就是你的安全网。

提醒：使用评估套件而非"一次性演示"

我经常看到工程师犯的一个常见错误，我称之为"一次性演示"。当有人将提示输入LLM，观察它一次性生成完整3D游戏或解决魔方，就将其称为评估时，这实际上只是一个虚荣指标。

要高质量地使用人工智能，我坚信你需要评估套件。没有评估，团队就犹如盲目地冲进黑暗的洞穴。构建企业级代理意味着测试系统处理多步骤交互、管理权限以及避免破坏性结果的能力，例如因要求其"寻找节省成本的机会"而意外删除项目。

接下来的方向

构建代理插件或MCP服务器只是起点。要交付一个能够真正信任并部署在真实云基础设施上的产品，需要在评估方面投入大量工作，以确保其行为符合预期。归根结底，唯一能超越模型迭代的只有经过压力测试的评估套件。查看Google Cloud Developer插件文档或通过这个codelab开始在Antigravity中使用插件。

Posted in

• Developers & Practitioners
• AI & Machine Learning