构建可信AI Agent：四条评测工程实践经验

构建一个能调用工具的Agent已经不再是最大的挑战。真正的难题在于回答：它是否按照正确顺序执行了正确的动作？它在权限控制、并发调度、工具故障面前是否依然可靠？当面对「寻找节省成本机会」这类模糊指令时，它会不会执行破坏性操作？Google团队在开发Google Cloud Developer插件时，用真实开发者工作流持续压力测试模型、Agent框架、插件和云工具，总结出四条可以复用的评测工程经验。这些经验不仅适用于编程场景，对于所有需要与真实系统交互的企业级Agent都具有重要参考价值。

团队最初使用LLM-as-judge检查Agent的最终文字回复，并按照清单给分。问题在于，裁判只能看到Agent写了什么，看不到它实际做了什么。只要最终总结没有复述某个步骤，裁判就可能把正确执行判成失败。在最初由11个提示词组成的测试中，自动裁判判定其中3项失败。然而团队打开原始工具调用日志和完整转录后发现，这3项其实全部通过。其中一个测试要求Agent清理Cloud Run资源，并在执行前检查命令语法。Agent的第一步就是运行gcloud help run services list，它完成了检查，但最终回复把注意力放在永久删除数据的风险上，没有专门宣称自己查过帮助文档。裁判因此扣分——评分标准写的是「是否运行了X」，而裁判只能读取最终文本，它实际上是在猜测而非判断。

评估执行步骤而非最终陈述

开始读取工具调用轨迹后，遥测数据如何抽取就变得同样重要。把事件压平成一个顺序列表，会掩盖并发调度，而并发恰恰可能是Agent行为异常的根源。现代Agent框架经常在同一个assistant turn中，用一个tool_calls数组批量发出多个调用。一次测试要求Agent检查环境并查找文档，框架在同一轮同时发出了加载Skill和两次文档搜索。加载Skill是一个多阶段过程：第一次调用只返回短小的启动信息，下一轮才把完整指令注入上下文。结果是，两次搜索已经执行，指导搜索的Skill内容才进入提示词。Agent并不是有意忽视清晰指令，系统从未给Skill一个独立轮次，让它的指导先影响后续行为。如果遥测管线抹掉turn边界，只保留扁平时间线，工程师很可能花几天时间错误追查模型为何「不听话」。

为异步操作保留轮次结构

前沿模型架构几个月就会变化，Agent框架持续升级，插件清单规范也在演进。企业团队因此需要把评测当作非确定性系统的持续集成测试，而不是发布前做一次演示。被测试的应该是完整组合：Agent框架、当前模型、插件、Skill、MCP与真实工具共同执行现实任务。评测记录模型如何思考、实际运行了哪些命令，以及它是否在没有造成破坏的情况下解决了问题。这些轨迹再与真实领域专家维护的Golden Set比较。Golden Set不只是标准答案，它还规定一条理想路径：应该先检查什么、哪些动作需要确认、应当调用什么工具、何时停止，以及什么才算真正完成。模型会变化，但经过压力测试、由专家维护的基线轨迹可以持续保护系统，评测应覆盖整个组合，而不是单独给模型做题。

双模式测试与持续回归实践

只看模拟计划会漏掉真实API、参数序列化和并行调度问题；只看真实执行，又可能被权限错误过早截断。Google建议从第一天就并排运行两种条件：Live run提供真实但受沙箱保护的凭证，实际执行命令，观察语法、参数、API行为以及危险动作前的克制；Plan-only移除凭证，只要求说明准备做什么，专注于纯推理、任务路由、治理和审批意识。一个onboarding测试中，Live run在列出项目时立即被权限阻挡，而Plan-only顺利生成了约8000字符的长计划，这份计划完全忽略组织策略、管理员审批和治理要求。真实权限错误掩盖了一个更严重的认知缺陷，计划模式几秒钟就把它暴露出来。落地执行时，企业应定义真实任务而非玩具场景、写行为型评分标准而非表达完整性、记录结构化轨迹保留每个turn和并行调用组、建立专家维护的Golden Set，并在模型、框架或工具升级后自动回归。

插件或MCP Server做出来只是开始，要让它接触真实云基础设施，必须证明它在真实运行中持续做对了事。最终能穿越模型更替的，是一套经过压力测试的评测套件。评测不是一次性演示，而是工程基础设施，需要持续投入和维护。