Google 把 Agent 评估接上生产:同一套分数,能不能让质量循环成立?Chapters1×0:08开场与事件1:09一条评估循环怎么跑2:14评分进入生产4:17工程意义与落地建议0:005:560:08主播早上好,这里是 AI Loop Engineering。今天只讲一条发生在七月三十一日的更新:Google 宣布,Gemini Enterprise Agent Platform 里的 Agent 与模型评估服务正式进入一般可用阶段。我的判断先放在前面:重点不是多了几种评分,而是开发测试、生产 trace 和质量漂移告警,开始使用同一条评估链路。工程团队要回答的,也从「怎么给 Agent 打分」变成了「同一个分数,能不能跟到生产」。0:43主播Google 的公告说,这套评估可以在开发阶段对着测试用例跑,也可以在上线后评估 Agent 实际完成过的任务,入口包括软件开发工具包、命令行工具、云控制台和 ADK。一般可用不等于所有区域、每种安全能力和每种 Agent 都自动得到同样支持,具体范围仍要看文档。1:09主播把它还原成工程流水线:先定义评估用例。用例可以带多轮对话、Agent 初始状态和用户回应计划。然后执行推理,让 Agent 真正跑一遍;系统把输入、输出和工具调用记成 trace。再计算指标,检查任务有没有完成、工具选得对不对、参数是否合规、执行路径是否合理,以及有没有安全或事实性问题。最后分析失败、修改提示词或工具配置,再跑一轮和旧基线比较。1:45主播这条链的关键,是评分能回到具体行为。Google 还提供案例生成器、用户模拟器和环境模拟器:前者从 Agent 的指令和工具定义里生成测试案例,后两者模拟多轮用户,或向工具调用注入数据、错误和延迟。这样可以专门测试超时、五百错误、空结果和重复提交,而不是只测一条正常路径。2:14主播Google 说目前有二十多种预置指标,覆盖质量、安全、事实依据、工具使用和执行轨迹。确定性任务可以用精确匹配、ROUGE、BLEU、MetricX、COMET;复杂任务则可以用自适应评审标准判断任务成功、工具使用质量、轨迹质量、最终回答、幻觉和资料支撑。团队也能写代码指标,或注册自己的模型评审指标。2:45主播自适应评审的设计值得注意:它不是拿一条固定提示词去问所有案例,而是根据当前用例、开发者指令和工具声明,生成这一个案例的通过或失败条件。Google 公告还说,指标会进入版本化、组织级的注册表,让离线实验和线上监控尽量使用同一份定义。但评审模型不是事实裁判,仍要用人工标注或确定性规则校准它。3:15主播上线后,Online Monitor 会从 Cloud Trace 和 Cloud Logging 里按条件取样,调用评估服务,再把结果写回 Cloud Monitoring。文档描述的常见节奏约是每十分钟一轮,可以评估全部 trace,也可以只看耗时或 token 用量异常的请求,并限制每轮样本数。分数能画成时间曲线,也能触发告警;文档举的例子是,任务成功率在三十分钟窗口内低于百分之八十就触发事件。3:49主播这条线上循环有两个前提。Agent 必须导出足够的 OpenTelemetry 信号,至少能识别 Agent 和会话,并捕获输入输出、系统指令和工具定义。其次,在线监控通常要采样,不会评每一条请求;成本降下来了,长尾失败也可能漏掉。模型评审要付模型调用费用,服务端实验还会产生 Cloud Storage 费用。4:17主播这意味着评估从发布前门禁,变成了运行时控制面。一个可行回路是:开发时建立基线,上线后从真实 trace 抽样,发现指标持续下降,就把失败样本带回离线用例,再验证修复有没有副作用。收益不是分数更高,而是同一个问题能被定位、复现和回归测试。4:44主播如果今天落地,我会做四件事。第一,定义 trace 契约:每次运行都留下会话、工具、状态变化和业务结果。第二,先用少量确定性指标建基线,再加自适应评审,不要用一个总分管理所有质量。第三,用模拟器专门打异常路径:超时、五百错误、空结果和重复提交。第四,线上从小比例样本开始,按风险设过滤和告警,同时保留人工抽查、权限隔离和回滚开关。5:20主播最后留一个问题:线上分数变红时,你的系统能不能回答「哪一个工具调用、哪一段状态转换、哪一个业务结果出了问题」,并且知道谁有权决定下一步?如果只能看到总分,这还是报表;只有分数能带回可复现的 trace,并触发受控的修复流程,它才真正进入了 Agent 的质量循环。这里是 AI Loop Engineering,我们明天见。