团队让AI分析失败用例、修改Prompt，再让同一个AI重新评分。报告显示：通过率提高了，问题解决了。
但上线后，用户仍然遇到同样的错误。
原因可能并不复杂：负责修改答案的模型，也知道裁判喜欢什么。它优化的不是用户体验，而是“怎样更容易拿高分”。如果连评分标准也由它临时解释，Agent质量飞轮很可能越转越快，却一直围着错误指标打转。
Google在Agent Quality Flywheel的工程实践中明确提出：优化器不能给自己的工作打分。提出修复方案的Coding Agent、自动优化器或开发者，与执行评测的Evaluator必须解耦。Google认为，如果优化器同时负责评分，就可能学会“游戏化指标”，而不是真正改善Agent。
这条原则看起来像一句常识，落到工程里却涉及数据、版本、Rubric、模型和审批权的完整隔离。
一、为什么同一个AI“既答题又阅卷”容易失真
假设一个客服Agent经常忘记用户在多轮对话中修改的新地址。你让模型做三件事：
- 分析失败Trace；
- 修改系统提示词；
- 判断修改后的回答是否更好。
模型非常容易在第三步沿用第二步的意图：既然刚刚加入了“优先使用最新地址”，它就更倾向于把新回答解释成已经遵守规则。哪怕最终地址仍然有歧义，评分也可能变得更宽松。
这不是模型“故意作弊”，而是评估上下文被污染了。优化器掌握了修改目标、预期方向和自己刚写出的方案，已经不再是独立裁判。
传统软件测试里，我们不会让开发代码在运行时偷偷修改断言。Agent系统同样需要把被测对象、测试数据和评分逻辑分开版本管理。
二、Google的五阶段飞轮，关键不在“自动”，而在证据链
Google把一次Agent质量迭代拆成五个阶段：准备数据、运行Agent生成Trace、评分、分析失败、针对性优化并重新比较。
很多人看到这里，会把重点放在“Coding Agent能自动帮我完成评测”。真正重要的其实是：每次优化都必须留下可比较的前后证据。
一个完整周期至少要固定这些对象：
- 测试集版本；
- 被测Agent版本；
- 优化前Prompt和优化后Prompt；
- Grader版本与Rubric；
- 每个Case的原始Trace；
- 基线分数和候选分数；
- 失败类别及人工复核结果。
如果只保留“优化后分数更高”，却没有保留使用了哪套Case、哪个裁判、哪个Rubric，那么这次提升无法复验，也无法进入CI/CD门禁。
三、最小可行架构：两个角色、三份冻结资产
不使用Google平台，也可以复用这条原则。
系统先拆成两个角色：
Optimizer：读取失败证据，提出Prompt、工具或流程修改。
Evaluator：只读取冻结测试集和候选运行结果，独立给出判定。
同时冻结三份资产：
eval_dataset_v12.jsonl
grader_rubric_v5.yaml
baseline_agent_20260924.json
优化器可以看到失败样本，但不能修改正式测试集和评分规则。Evaluator可以读取新旧两个版本的匿名结果，却不应该知道哪一份是“优化后版本”，避免先入为主。
下面是一个简化的盲测流程：
def blind_compare(dataset, baseline_agent, candidate_agent, evaluator):
baseline_runs = run_suite(dataset, baseline_agent)
candidate_runs = run_suite(dataset, candidate_agent)
pairs = anonymize_and_shuffle(baseline_runs, candidate_runs)
verdicts = evaluator.grade(pairs, rubric_version="v5")
return reveal_versions_and_aggregate(verdicts)
这里有三个关键点：
- 新旧结果先匿名，再交给Evaluator；
- 两边使用同一份数据和同一版Rubric；
- 评分完成后才揭示版本并聚合。
这样能减少“我知道这是新版本，所以应该更好”的偏差。
四、不要用一个总分掩盖你真正想修的问题
Google原文用了一个很典型的多轮旅行Agent案例：用户在对话中途修改日期、酒店或人数，Agent内部状态可能已经更新，但最终回复仍然回显旧信息。
如果只看综合的多轮任务成功分，这个错误可能只是多个评分项中的一个，总分仍然不低。Google的做法是把“是否遵守用户最新修改”提升成独立的分类指标revision_honored，结果分为HONORED、IGNORED、PARTIAL和NO_REVISION。
第一次运行中，IGNORED占21%。加入针对性修复并重新运行同一套评测后，IGNORED降到5%。这是Google该案例的前后对比，不是所有Agent都能获得同样的改善。
这给测试团队一个重要提醒：如果这次改动只针对一个高风险行为，就必须为它建立稳定、单独的指标。一个会变化的综合Rubric适合观察整体健康度，却不适合证明某个具体缺陷真的被修好。
五、怎样判断“分数上涨”是真提升，不是讨好裁判
可以设置五道检查：
1. 冻结集上涨，保留集也上涨
正式测试集可以被优化器反复看到，久而久之会出现“刷题”。因此需要保留一批优化器从未见过的Holdout Cases。只有正式集和保留集都改善，才更像真实能力提升。
2. 硬指标不退化
开放式体验分提高的同时，工具参数正确率、禁止动作、最终业务状态等硬指标不能下降。不能用“回答更自然”抵消“订单号传错”。
3. 换一个裁判仍能复现方向
不要求两个LLM裁判分数完全一致，但改善方向应该大体一致。如果裁判A认为明显提升，裁判B认为明显退化，需要人工检查Rubric或样本。
4. 人工盲评能看到差异
抽取部分样本，让领域专家在不知道版本的情况下做成对比较。模型评分与人工完全背离时，先校准Evaluator。
5. 失败类型真的发生迁移
修复后不只是总分上涨，还应该看到目标失败类别减少。如果“忽略最新地址”没减少，只是其他容易项得分更高，这次优化没有击中问题。
可以把这些规则写成发布门禁：
def quality_gate(report):
return all([
report.target_failure_rate <= 0.05,
report.holdout_delta > 0,
report.hard_metric_regressions == 0,
report.human_agreement >= 0.8,
report.critical_safety_failures == 0,
])
阈值要根据业务风险设置，示例中的数值只用于展示结构，不能直接照搬成行业标准。
六、AutoRater也不是“真实答案机器”
Google同时提醒：AutoRater仍是基于模型的评分器。它可以从多轮对话中提取意图、动态生成Rubric、按标准检查Trace，并通过多次采样投票，但不等于绝对真相。
Google建议更信任多轮迭代之间的变化趋势，而不是把某一个单次分数当作绝对成绩；合成场景可以帮助团队冷启动，真实生产数据才会让评测循环越来越准确。
这说明“独立评分”只是第一步。Evaluator还需要：
- 自己的版本管理；
- 与人工标注的一致性校准；
- 对不确定样本给出Unknown或进入复核；
- 定期用新线上Case检查Rubric是否过时。
否则，独立裁判也可能是一个独立但错误的裁判。
七、测试团队可以先做的最小改造
如果你们目前已经在用AI自动改Prompt，可以先完成下面四项，不必立刻重建平台：
- 把“提出修改”和“执行评分”拆成两个独立任务；
- 将测试集和Rubric放进版本库，禁止优化流程自动改写；
- 每次比较使用相同Case、相同评分器和匿名的新旧结果；
- 为本次修复建立一个单独指标，并保留一组未曝光Case。
做完这些，团队至少能回答一个关键问题：这次分数变好，是Agent真的解决了问题，还是它只是更了解裁判想看什么。
Agent质量飞轮的价值不在于“AI自动优化AI”，而在于每一次变化都要经过一个独立、稳定、可复验的质量判断。速度可以交给Agent，裁判权不能一起交出去。
主要来源：Google Developers Blog，《Driving the Agent Quality Flywheel from Your Coding Agent》，2026-06-30。
