从编码智能体驱动智能体质量飞轮

从编码智能体驱动智能体质量飞轮

Dima Melnyk，产品经理，Cloud AI。Jason Dai，软件工程师。2026 年 6 月 30 日。

图 1：智能体质量飞轮。

把智能体质量做成工程，而不是凭感觉检查

你已经发布了一个智能体。它能用。你改一条提示，去修用户抱怨的那一件事，在你试过的三个例子上看起来更好了。让你夜里睡不着的问题是：我是不是刚弄坏了另外十个？

「在几个例子上看起来更好」和「在生产里真的更好」之间的这道缝，是做智能体的日常。多数团队某处有评测用例。多数团队会改提示。很少有团队用足够的纪律把这两件事接上，从而知道一次改动是移动了指标，还是只移动了感觉。

最吓人的失败不是吵的那种。是那些看起来在工作的智能体：回答很有信心，计划读起来也没问题，却悄悄把用户真正的目标做错了。在 Cloud Next '26，他们把智能体质量讲成一个三阶段飞轮（flywheel，评测、上线、再学习、再改的循环）：构建与测试 → 发布与监测 → 学习与打磨，并展示了积木。演讲：https://youtu.be/eLQAJqydXqY?si=NM55J24O7ahbMHBv 。今天他们加上面向开发者的路径：一个技能，由你的编码智能体安装，再替你驱动。

这个飞轮，包括方法和处在核心的 AutoRater（自动评分器，由模型给一条轨迹打分并说明原因），建在他们用来评测和改进自己的模型与一方智能体的同一套原则上。AutoRater 与 Google DeepMind 密切合作开发。

把飞轮放大看

这个技能以 构建与测试 为中心，也就是快的迭代环，并把它展开成五个具体阶段。它不限于这一阶段：同样的阶段也可以对着生产轨迹跑，飞轮里更多部分会随时间进入可及范围。第一遍按顺序跑，然后循环第 2 到第 5 阶段，直到质量目标达到：

1. 准备数据：从已有的 OTel 轨迹（OpenTelemetry，一套记录请求经过了哪些步骤的追踪标准）、手工用例，或合成场景，做出评测数据集。文档：https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/tracing
2. 跑推理：让智能体在数据集上跑，产出轨迹；如果你已经有轨迹，就跳过这一步。
3. 打分：用 Google 的自适应 AutoRater，或你自己的自定义指标，给轨迹打分。预定义指标：https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/evaluation/manage-metrics#predefined-metrics 。这是唯一一个总会跑的阶段。
4. 分析失败：读评分量规（rubric，用自然语言写下的合格标准）的裁决，弄清一条用例为什么失败；失败达到十条或更多时，用自动损失分析把它们聚类。文档：https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/evaluation/view-results
5. 优化并迭代：做一个对准的修复，重跑第 2 到第 4 阶段，和上一条基线比较。

多数失败用例要迭代好几轮，指标才会真的动。这个技能把这种纪律写了进去。

优化器从不给自己的工作打分

优化器和评测器保持分开：无论是谁提出修复（你的编码智能体、自动优化器，或你自己），都不给这次修复打分。由 Gemini Enterprise Agent Platform 的 GenAI 评测服务独立打分。一个给自己打分的优化器，会学着去钻指标，而不是改进智能体。一个小的架构选择，比看上去更要紧。

这个技能是什么，不是什么

它是跑在你的编码智能体里面的方法加上编排：它为目标选对指标，跑 GenAI 评测服务，读裁决，提出修复，并比较改前改后。

它不是：

• 自主的。 它提出，你批准。人在环里，不是放手不管。
• 真值的来源。 内置 AutoRater 不只是一个模型给答案打分。对多轮智能体，它们从对话里抽出用户意图，为该用例生成量规，按每条标准校验轨迹，再在多次采样上做多数投票。这很精细，但仍然基于模型：把分数当成强的方向信号，对运行之间的差值，比对任何单个数字当绝对分数，更可信。
• 真实流量的替代。 技能用用户模拟器（User Simulator，由模型扮演用户、生成对话的功能，属于 GenAI 评测服务）生成合成场景，但这是冷启动的引导。合成场景让你动起来；让循环变锐利的是生产数据。文档：https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/evaluation/evaluate-simulated

它以两个包交付，对着同一个 GenAI 评测服务。选适合你技术栈的那个：

• google-agents-cli-eval：如果你用 agents-cli 工具链做 ADK（Agent Development Kit，智能体开发工具包）智能体。安装：http://skills.sh/google/agents-cli/google-agents-cli-eval
• agent-platform-eval-flywheel：如果你直接用 Evaluation SDK（任何框架）。安装：http://skills.sh/google/skills/agent-platform-eval-flywheel

一个真实循环：看起来像成功的失败

下面是在一个真实智能体上的一轮。读的时候注意：开发者从不碰评测命令行，也从不点名一个指标。他们安装技能，用白话描述一个担心，批准一个计划，再读结果。技能决定怎么做。它做出的最有意思的决定，是哪一个指标甚至能够发现这次失败。

被测智能体是 travel-concierge，来自 google/adk-samples 的一个 ADK 多智能体行程规划器（灵感 → 规划 → 预订 → 行前／行中／行后）。仓库：https://github.com/google/adk-samples 。它把正在用的行程放在会话状态里，这正好埋下一种具体、细微的失败。

你告诉编码智能体的话：

在这个仓库上使用 quality-flywheel 技能。我担心 travel-concierge 会不会尊重对话中途的改动。当用户在中途修改行程（不同日期、不同酒店、不同人数）时，最终计划是反映出改动，还是继续按原来的做？想办法测它，并在跑任何东西之前提出计划。

这就是全部接口。没有开关，没有指标名。技能的工作是把这个目标翻译成正确的评测。它先读智能体的代码，再带回一个计划。它用上两个内置的多轮 AutoRater，然后做了一件固定脚本不会做的事：在它们之上加一条自定义量规，专门把改前改后钉在你问的那个行为上。

编码智能体上的 quality-flywheel 技能这样说：

multi_turn_task_success 和 multi_turn_trajectory_quality 是自适应的：它们会为每个用例生成量规，并会在里面露出一次修订被错过。但它会落成若干条标准里的一条，而且每次运行重新生成的方式不同，再折进一个混合分；没有一个稳定的「是否尊重修订」数字可以拿来做阈值或看趋势。所以我把这一个担心提升成自己的指标：自定义量规 revision_honored，裁决是分类的（HONORED／IGNORED／PARTIAL／NO_REVISION），我可以计数，可以设门（若超过 20% 返回 IGNORED 就采取行动），并一轮一轮跟踪。我用用户模拟器引导 25 个场景，分到五种修订类型上。继续吗？

你批准。这段话后面，技能跑用户模拟器合成这些场景，并用两个内置评分器加上它自己的 revision_honored 量规给轨迹打分。只有少数用例失败，低于聚类划算的阈值，所以它直接读这些裁决，而不是去用自动损失分析。它实际跑的是：

# one User Simulator pass per revision type (×5: party_size, destination, dates, hotel, dropped_stop)
agents-cli eval dataset synthesize -n 5 --max-turns 8 --model gemini-3.5-flash \
    --instruction "$(cat instr_party_size.txt)" \
    --environment-context "$(cat synthesize_env_context.txt)" \
    -o traces_party_size.json

# merge the five trace files, then grade all 25 in one pass
agents-cli eval grade --traces traces_merged.json --config eval_config_revisions.yaml

这些都不是你写的。技能选了指标、模拟器和划分；你描述了目标。

第一遍。 三个指标都触发了。内置 AutoRater 已经显示出明显低于合格线的质量（均值在 0.6 中段，对照严格门槛时通过率低），自定义量规则单独量出其中有多少是修订问题：

图 2：第一遍指标。

在这条量规上，IGNORED 的意思是修订被丢掉了（其他裁决是 HONORED、PARTIAL 和 NO_REVISION）。这 21% 过了技能自己的行动阈值。裁决还把失败定位得很准。它不是你会猜的那样：智能体并没有自信地确认一份错误行程。四次失败里有三次，它的内部状态是对的（存了正确的值，调了正确的工具），但给用户的最终消息仍然回了过期的值。智能体内部做对了，嘴上却自相矛盾。一条裁决把它说具体：

智能体在第 3 轮对 start_date 和 end_date 的内部 memorize 调用，正确地存了 '2027-04-15' 和 '2027-04-19'，但在用户明确更正之后，它没能在给用户的最终输出里给出正确日期。

这就是「看起来在工作」的失败的缩小版：没有崩溃，计划快速扫一眼也还行，智能体听起来像做了你要求的事，但用户实际收到的答案是错的。这些用例的共同原因：根智能体的指示里，没有任何一句让它在发送前把最终回复和用户最近一条消息对一下。

你可能会问，自定义量规到底有没有必要：内置的毕竟是自适应的。结果是，发现问题不是难点，把失败单独拆出来才是。拿那一条 IGNORED、但内置任务成功仍给出舒服的 0.80 的用例：party_size_02。用户把酒店请求改成某家旅舍的宿舍房间。下面的标注说明原因：评分器确实为这个请求生成了一条标准，并标成未满足（它抓住了错过并解释了），但这一条坐在四条通过的标准中间，所以混合分仍然高。内置评分器给不了你的，是在全部 25 个用例上一个单独的「它有没有尊重修订」数字。把这个担心提升成自己的分类指标，才让 21% 到 5% 的改前改后可以计数。

一个用例，三个评分器：party_size_02

用户先要一个 5 人、便宜的柏林到阿姆斯特丹行程，对话中途把酒店请求改成「Hostel World Amsterdam 的宿舍房间」。

revision_honored（自定义）→ IGNORED。 智能体承认了请求，但重新拿出较早的结果，而不是按修订后的条件去搜，也从未记住新的偏好。

multi_turn_task_success（内置）→ 0.80。 五条生成的标准，四条通过：便宜的 5 人行程；航班选项；easyJet 的选择已确认；提供了酒店选项。第五条失败：提供 Hostel World Amsterdam 的宿舍房间选项。智能体没能提供被要求的具体信息，因为它声称工具能力不够。修订被错过是真的，也被点了名；它只是五条里的一条，所以混合分仍然高。

multi_turn_trajectory_quality（内置）→ 0.67。 这里的错过是评测配置的产物，不是缺陷：智能体的工具模式没有暴露给评分器，所以它把合法调用（flight_search_agent、memorize_impl）标成「不允许的工具」。因此改前改后他们倚重自定义量规和任务成功，而不是轨迹质量。

修复和重跑。 你批准一个对准的改动：在根智能体的指示里加三句话，让它把最终回复和用户最新的修订对齐。技能重跑同一份评测：

图 3：改前与改后。

你甚至不需要一个具体目标

上面那一轮从一个清楚的目标开始。但当你还没有目标、说不出哪里错了，这个技能同样能用。冷冷地指着一个智能体说「找一个真实失败并修好」，它会跑得很宽：合成多样的场景，用内置多轮指标打分，自己把占主导的失败簇露出来。

他们在另一个智能体上原样试了：来自 google/adk-samples 的 software-bug-assistant，一个接到真实工具上的缺陷分诊助手（MCP 工具箱后面的 Postgres 工单库，加上网页和 StackExchange 搜索）。仓库：https://github.com/google/adk-samples 。没有假设时，技能立刻露出一个簇：15 个用例里有 14 个，智能体把工作做对了，但从未告诉用户它调用了哪些工具。它自己的指示要求这样做，模型却悄悄把它当成可选。一段话的修复，要求每个回复现在都以类似「Tools used: search-tickets, get-ticket-by-id」的页脚结束，在全部 15 个用例上把这件事从 0% 做到 96%，只要一轮。

同一个技能，更松的提示。「这是我的目标」和「给我找一个问题」都能落地。

两轮里手法相同：为你改过的那个行为选一个稳定度量（自定义量规或简单计数），把自适应的内置评分器当作宽的健康信号，因为它们的量规会随运行变化。

从内环到生产环

图 4：开发侧按需，生产侧持续，同一套 AutoRater。

上面的循环用了用户模拟器，因为当时还没有真实使用，这是按需的、开发侧的环。智能体成熟并服务真实流量之后，生产会话变成最有价值的输入：每一条都是真实请求，来自用户、另一个智能体或上游服务，每一次失败都是下一轮现成的测试用例。同样的阶段，现在由真实使用喂，而不是模拟。

同一个技能对着生产流量跑；你只要把它指到真实轨迹，而不是合成轨迹。让它给上周的生产会话打分。因为这些轨迹已经完整，它完全跳过「跑推理」，就地用同一批评分器打分。在线监测持续评测线上流量，并把质量分写到 Cloud Monitoring。文档：https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/evaluation/evaluate-online 。分数漂移时，你把失败轨迹交给同一个技能，就是刚才看到的评测—修复环。同一个飞轮，不同节奏：生产里持续，开发里按需，两边由同一批 AutoRater 打分。

今天，这个技能按需跑内环，并在你指过去时给生产轨迹打分。方向是让它自己多驱动外环：看着监测，露出回归，并在流量变化时提出修复。

今天就开始

你需要：一个打开了 Agent Platform GenAI Evaluation Service 的 GCP 项目，一个要评测的智能体（ADK 或任何框架），以及一个来驱动技能的编码智能体。要给生产流量打分，你的智能体还应发出 OpenTelemetry 轨迹（ADK 默认会发）。

安装编码智能体将要驱动的技能：

# CLI-driven (ADK + agents-cli):
npx skills add https://github.com/google/agents-cli --skill google-agents-cli-eval

# SDK-driven (any framework):
npx skills add https://github.com/google/skills --skill agent-platform-eval-flywheel

然后开始一轮：把它指到你的智能体，描述你想测量什么。其余由编码智能体接手。

你的智能体不必完美。它必须能被改进。

致谢：质量飞轮技能和底层服务由 Jason Dai、Ludwik Trammer、Iwo Naglik、Xi Liu、Aleksandra Grzegorczyk，以及更广的 Cloud AI Agent Platform 团队做出。它所依据的演讲在 Cloud Next '26 由 Alex Martin（Google）和 Daniel J. Lewis（Geotab）发表。

更多资料：Cloud Next '26 演讲 https://youtu.be/eLQAJqydXqY?si=NM55J24O7ahbMHBv ；智能体评测文档 https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/evaluation/agent-evaluation ；agents-cli https://skills.sh/google/agents-cli/google-agents-cli-eval ；google/skills https://skills.sh/google/skills/agent-platform-eval-flywheel 。

出处：Dima Melnyk，Jason Dai，Driving the Agent Quality Flywheel from Your Coding Agent，2026-06-30，https://developers.googleblog.com/driving-the-agent-quality-flywheel-from-your-coding-agent ，CC BY 4.0。