团队让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和优化后PromptGrader版本与Rubric每个Case的原始Trace基线分数和候选分数失败类别及人工复核结果。如果只保留“优化后分数更高”却没有保留使用了哪套Case、哪个裁判、哪个Rubric那么这次提升无法复验也无法进入CI/CD门禁。三、最小可行架构两个角色、三份冻结资产不使用Google平台也可以复用这条原则。系统先拆成两个角色Optimizer读取失败证据提出Prompt、工具或流程修改。 Evaluator只读取冻结测试集和候选运行结果独立给出判定。同时冻结三份资产eval_dataset_v12.jsonl grader_rubric_v5.yaml baseline_agent_20260924.json优化器可以看到失败样本但不能修改正式测试集和评分规则。Evaluator可以读取新旧两个版本的匿名结果却不应该知道哪一份是“优化后版本”避免先入为主。下面是一个简化的盲测流程defblind_compare(dataset,baseline_agent,candidate_agent,evaluator):baseline_runsrun_suite(dataset,baseline_agent)candidate_runsrun_suite(dataset,candidate_agent)pairsanonymize_and_shuffle(baseline_runs,candidate_runs)verdictsevaluator.grade(pairs,rubric_versionv5)returnreveal_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. 失败类型真的发生迁移修复后不只是总分上涨还应该看到目标失败类别减少。如果“忽略最新地址”没减少只是其他容易项得分更高这次优化没有击中问题。可以把这些规则写成发布门禁defquality_gate(report):returnall([report.target_failure_rate0.05,report.holdout_delta0,report.hard_metric_regressions0,report.human_agreement0.8,report.critical_safety_failures0,])阈值要根据业务风险设置示例中的数值只用于展示结构不能直接照搬成行业标准。六、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。