团队让AI分析失败用例、修改Prompt，再让同一个AI重新评分。报告显示：通过率提高了，问题解决了。

但上线后，用户仍然遇到同样的错误。

原因可能并不复杂：负责修改答案的模型，也知道裁判喜欢什么。它优化的不是用户体验，而是“怎样更容易拿高分”。如果连评分标准也由它临时解释，Agent质量飞轮很可能越转越快，却一直围着错误指标打转。

Google在Agent Quality Flywheel的工程实践中明确提出：优化器不能给自己的工作打分。 提出修复方案的Coding Agent、自动优化器或开发者，与执行评测的Evaluator必须解耦。Google认为，如果优化器同时负责评分，就可能学会“游戏化指标”，而不是真正改善Agent。

这条原则看起来像一句常识，落到工程里却涉及数据、版本、Rubric、模型和审批权的完整隔离。

一、为什么同一个AI“既答题又阅卷”容易失真

假设一个客服Agent经常忘记用户在多轮对话中修改的新地址。你让模型做三件事：

1. 分析失败Trace；
2. 修改系统提示词；
3. 判断修改后的回答是否更好。

模型非常容易在第三步沿用第二步的意图：既然刚刚加入了“优先使用最新地址”，它就更倾向于把新回答解释成已经遵守规则。哪怕最终地址仍然有歧义，评分也可能变得更宽松。

这不是模型“故意作弊”，而是评估上下文被污染了。优化器掌握了修改目标、预期方向和自己刚写出的方案，已经不再是独立裁判。

传统软件测试里，我们不会让开发代码在运行时偷偷修改断言。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，可以先完成下面四项，不必立刻重建平台：

1. 把“提出修改”和“执行评分”拆成两个独立任务；
2. 将测试集和Rubric放进版本库，禁止优化流程自动改写；
3. 每次比较使用相同Case、相同评分器和匿名的新旧结果；
4. 为本次修复建立一个单独指标，并保留一组未曝光Case。

做完这些，团队至少能回答一个关键问题：这次分数变好，是Agent真的解决了问题，还是它只是更了解裁判想看什么。

Agent质量飞轮的价值不在于“AI自动优化AI”，而在于每一次变化都要经过一个独立、稳定、可复验的质量判断。速度可以交给Agent，裁判权不能一起交出去。

关于我们

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。