AI Agent 逐步进入真实业务系统之后，软件测试面临的问题也在发生变化。

过去测试一个接口，通常只需要判断返回结果是否符合预期。但测试一个能够自主分析数据、调用工具、生成业务策略的 Agent，情况就复杂得多。

例如，一个电商运营 Agent 根据商品历史销量、广告预算、转化率和营销规则，自动生成下一阶段的推广策略。

接口调用成功，输出格式正确，预算也没有超出限制，甚至 LLM-as-Judge 给出了较高的评价。

然而，策略真正上线后，商品 ROI 却下降了。

这时候，问题究竟出在哪里？

是模型推理错误？历史数据不准确？评估器判断失误？还是业务环境发生了变化？

对于策略型 Agent，仅仅验证输出是否正确已经不够，还需要评估决策质量、业务效果及其长期稳定性。

本文从测试开发和质量工程角度，讨论分层评测、Auto Rubrics、LLM-as-Judge、评测数据集、A/B 实验以及持续质量治理的实现方法。

一、策略型 Agent 为什么更难评测？

1.1 没有唯一正确答案

传统软件测试通常能够确定预期结果。

比如：

• 接口返回状态码是否符合要求；
• 数据库记录是否更新成功；
• 页面操作是否完成；
• 自动化测试脚本是否执行通过。

即使是问答类大模型，也可以通过参考答案、事实依据或人工标准来判断回答质量。

但策略型 Agent 不同。

假设两个 Agent 为同一批商品生成营销策略：

两个结果都可能符合业务规则。

究竟哪个更好，取决于当前的业务目标。

如果重点是提高成交规模，A 可能更合适；如果更加关注投入产出效率，B 则可能更优。

这意味着策略型 Agent 评测本质上是一个多目标决策问题。

1.2 三个主要技术难点

第一，真实反馈数据少。

策略质量通常需要通过线上 A/B 实验验证，而实验会消耗真实流量、预算和业务资源。

淘宝技术公开的实践中，每天开展约 3 组对照实验，T+1 获取效果数据，半个月只能积累约 100 条偏好对。

对于复杂的策略空间而言，100 条数据很难全面反映模型能力。

第二，评估标准动态变化。

ROI、GMV、访购率、预算风险等指标的权重可能随着业务阶段发生调整。

如果评测规则完全固定，可能出现模型评分很高，却不符合当前业务目标的情况。

第三，离线评测与线上效果存在差异。

一条策略离线判断合理，上线后仍然可能因为流量变化、商品结构调整、促销周期等因素表现不佳。

因此，需要把离线质量评估和线上业务实验结合起来。

二、Agent 评测体系：规则、推理与业务效果三层验证

不同问题需要使用不同的验证方法。

对于确定性约束，普通测试断言通常更加可靠。

对于业务推理与策略合理性，可以使用经过校准的 LLM-as-Judge。

对于真实业务收益，则需要线上实验和统计分析。

2.1 三层评测架构

例如，Agent 为某商品生成补贴策略。

规则验证层首先检查补贴比例有没有超过业务上限。

通过后，LLM Judge 判断在缺乏充分历史数据的情况下，是否有足够依据增加补贴。

最后，经过前两层验证的策略才进入线上实验，观察真实业务效果。

这里需要注意，LLM Judge 不能替代规则引擎。

对于明确的预算上限、字段类型、参数范围，采用确定性规则可以得到更加稳定的验证结果，也能减少不必要的大模型调用。

2.2 五层质量对象

三层评测架构解决了如何评估的问题。

但实际发生故障后，还需要知道问题产生在哪个环节。

可以进一步将 Agent 质量拆解为五层。

比如某次 Agent 错误地增加了广告预算。

排查时发现，Agent 使用的其实是一份已经过期的商品运营数据。

这类问题应该优先定位到数据与知识层，而不是简单调整模型 Prompt。

这五层既可以分别建立指标，也可以通过执行 Trace 进行关联分析。

对于多步骤 Agent，保存 Prompt 版本、检索结果、工具调用参数、模型输出以及最终业务结果，能够明显提高问题定位效率。

三、LLM-as-Judge：评估器为什么也需要测试？

LLM-as-Judge 利用大语言模型对另一个模型的输出进行评价，是当前 Agent 评测中经常使用的方法。

常见判断形式包括：

• 单条输出评分；
• 是否满足指定 Rubric；
• 两个候选结果的 Pairwise 比较；
• 多维度质量评价。

但 Judge 自身也可能产生系统性误差。

3.1 位置偏差：96% 准确率可能是假象

Pairwise 评测通常将两个候选结果分别放在 A、B 位置。

如果效果更好的策略始终放在同一位置，Judge 可能逐渐表现出位置偏好。

在一次公开实验中：

训练结果高达 96%，但验证结果只有 50%。

这意味着模型并没有表现出可靠的跨样本判断能力。

引入 A/B 位置随机化后，准确率虽然下降，却减少了固定排列造成的虚假信号。

工程上可以增加位置交换测试：

def evaluate_pairwise(judge, context, strategy_a, strategy_b):
    forward = judge.compare(context, strategy_a, strategy_b)
    reverse = judge.compare(context, strategy_b, strategy_a)

    # 判断结果需要映射回原始策略 ID
    reverse_mapped = reverse.swap_candidates()

    return {
        "forward": forward,
        "reverse": reverse_mapped,
        "position_consistent": (
            forward.winner == reverse_mapped.winner
        )
    }

这里的关键不在于重复调用，而在于交换位置之后，能否仍然识别出同一条策略。

3.2 选择过拟合：规则对训练集有效，不代表对新样本有效

Auto Rubrics 可以自动生成大量候选规则，但候选数量增加，也带来了规则选择过拟合的问题。

在公开实践中，研究人员曾从 330 条候选 Rubric 中进行贪心选择。

随后通过 Bootstrap 检查规则稳定性：

• 重复执行 200 次子采样；
• 每次使用约 70% 的偏好数据；
• 每轮独立运行规则选择；
• 统计不同 Rubric 的入选频率。

实验发现，没有任何一条规则的入选频率超过 80%。

进一步开展五折交叉验证时，某种加权贪心方案的训练准确率达到 78%，验证准确率却只有 56%。

这说明当前规则组合可能过度拟合了已有样本。

因此，Rubric 筛选至少应包含两个环节：

一是稳定性选择，判断规则是否过度依赖特定数据。

二是交叉验证，判断规则能否迁移到未参与筛选的数据。

3.3 判断稳定不代表判断正确

另一个容易忽视的问题是 Judge 一致性。

如果模型连续三次给出相同判断，是否代表它很可靠？

不一定。

在公开实验中，某个模型的三轮一致率为 80%，但投票准确率只有 55%。

也就是说，它可能稳定地给出错误答案。

因此，需要同时考察：

四、Auto Rubrics：自动构建可解释的评测规则

Rubric 可以理解为一条具有明确评价含义的标准。

例如：

“在缺乏充分历史数据的情况下，策略不应仅凭预测收益进行大幅预算调整。”

相比只输出一个分数，Rubric Judge 还能给出违反了哪条规则、违反原因是什么。

这对于测试定位、规则维护和人工复核非常重要。

但如果完全依赖人工设计和维护 Rubrics，当业务场景不断增加时，管理成本会迅速上升。

Auto Rubrics 的基本思路是：

利用历史策略、业务效果、专家经验和 Bad Case 自动生成候选规则，再通过验证筛选出具有区分能力的规则集合。

4.1 Auto Rubrics 的三层架构

整个流程可拆分为三层：

规则供给不局限于一种方法。

第一条路线是让 LLM 分析好策略与差策略之间的差异，尝试提取隐性的业务规则。

第二条路线是先分析策略参数的统计模式，再将数据特征提供给 LLM，生成具有数据依据的候选规则。

两条路线可以并行运行。

4.2 规则生成与筛选流水线

淘宝技术公开过的一条实验流程曾将 1500 多条候选规则，通过语义去重压缩到约 44 条。

另外的规则筛选实验，也曾从 170 多条原始规则中筛选出约 10 条强规则。

这些结果对应不同的实验设置，不能直接理解为同一批规则的连续筛选过程。

对于工程落地而言，规则数量本身不是目标。

更重要的是规则是否具有区分度，是否能够解释判断结果，以及业务场景变化后能否继续保持有效。

4.3 规则区分度如何计算？

假设需要判断某条 Rubric 是否能够区分好坏策略。

可以分别统计这条规则在两类策略中的违反率。

定义一个简单的区分度指标：

当 D明显为正时，说明这条规则更容易识别出差策略，可能具有一定区分力。 如果 D 接近零，说明这条规则很难区分好坏。 如果 D 为负，还需要检查规则方向是否存在问题。 不过，仅凭违反率差异还不足以证明规则有效，仍然需要结合样本量、不确定性、稳定性和独立数据验证。

五、如何构建可信的 Rubric Judge？

规则本身通过筛选，并不意味着使用它们进行评估的大模型一定可靠。

对于生产级评测系统，建议将 Judge 视为一个独立的软件组件，建立专门的测试流程。

5.1 Judge 可信性验证

首先构建包含可信标签的偏好数据集。

之后执行以下检查：

1. 随机交换候选策略的 A/B 位置；
2. 多次独立调用 Judge；
3. 对比不同调用的判断结果；
4. 检查判断与真实偏好标签的一致程度；
5. 利用独立测试集检验泛化能力；
6. 将冲突样本送入人工复核。

5.2 从评测结果构建 Golden Set

实际业务中，不是每条偏好数据都适合用于模型训练。

一些数据的业务效果差异很小，另一些数据可能受到实验噪声干扰。

一种方法是使用筛选后的 Rubrics，对每组偏好对进行多次独立评估。

例如，进行三轮判断，并随机化策略位置。

只有三轮结论一致，且与可信偏好标签相符的样本，才进入 Golden Set。

不一致或判断错误的样本，则进入待复核数据集。

这里采用的是高精度优先的策略。

虽然最终保留的数据量可能下降，但能够减少明显存在冲突的偏好数据对训练过程的影响。

对于 DPO 等偏好优化方法，训练数据质量尤其重要。

同时需要注意，Golden Set 是经过当前评测标准筛选的高置信数据，并不意味着这些样本永远正确。随着业务目标、数据分布和模型版本变化，还需要持续抽检和更新。

六、Agent 评测数据集应该如何建设？

有了 Judge，还需要一套能够持续发现问题的评测数据集。

仅依靠正常业务样本，不足以支撑 Agent 的上线质量保障。

建议按照三个阶段建设。

数据集建设有两个需要特别注意的问题。

6.1 测试样本比例由风险决定

如果线上 90% 的请求都是正常场景，并不意味着测试集也应该按照同样比例构建。

对于可能造成较大业务损失的场景，应适当增加测试覆盖。

例如：

• 预算接近上限；
• 商品没有历史数据；
• 多个业务目标发生冲突；
• 工具返回异常或过期数据；
• Agent 收到相互矛盾的指令。

这与传统测试中的风险驱动测试设计原则是一致的。

6.2 评估器需要独立的回归基准

在公开实践中，某版 Rubric Judge 出现过明显的准确率下降：

如果只观察第一组结果，可能会对评估器产生过高信心。

因此，无论是替换 Judge 模型、调整 Prompt，还是增加新的 Rubric，都应该执行相关的 Judge 回归测试。

尤其不能在同一批数据上反复筛选规则、调整参数，再把这批数据当作独立的最终测试集。

七、从离线评测到线上业务效果验证

Agent 能否产生真实业务价值，最终需要线上反馈。

但业务指标的绝对增长，并不能直接证明策略有效。

例如大型促销活动期间，即使继续使用旧策略，GMV 也可能自然增长。

如果只看新策略上线前后的业务结果，容易将环境变化误归因为模型能力。

7.1 A/B 实验验证策略增量

可以设置：

• 对照组：使用当前基准策略；
• 实验组：使用新 Agent 生成的策略。

在实验分配、流量口径、观测周期等条件满足要求时，对比两组业务指标。

对于适合使用相对变化率的指标，可采用：

[ \text{相对增量} = \frac{\text{实验组指标}-\text{对照组指标}} {\text{对照组指标}}\times 100% ]

还应结合置信区间、统计显著性、样本量和业务风险门槛综合判断。

对于 ROI 等比例指标，也需要事先统一计算与汇总口径。

7.2 为什么增加稳定性验证组？

仅有实验组和对照组时，部分外部环境因素仍可能增加分析难度。

可以引入第三组：

稳定性验证组：继续运行上一稳定版本策略。

这样有助于分析业务指标变化是否具有共同趋势。

例如，当新策略指标下降时，如果上一稳定版本的表现也同步恶化，就应进一步检查外部环境，而不是立即把问题归因为新模型。

三组数据不能自动消除所有混杂因素，但可以为后续归因提供额外证据。

八、策略效果收敛：如何识别稳定可靠的业务结果？

策略型 Agent 往往会持续调整大量商品的配置。

如果某些商品已经形成稳定的正向策略，就需要判断是否可以暂停频繁调整，将其纳入已收敛策略集合。

问题在于，单日业务数据的波动可能非常明显。

特别是长尾商品，少量订单就可能造成较大的百分比变化。

采用四层过滤机制。

第一层解决数据够不够的问题。

第二层判断结果是否在时间上保持稳定。

第三层通过贝叶斯收缩等方式，降低小样本极端结果对评分的影响。

第四层从多个商品的组合表现出发，进一步验证整体效果是否满足要求。

这套方法与前面的 Rubric 筛选具有相似之处。

二者都强调从不稳定候选中筛选可信对象，再通过组合验证提升最终结果的可靠性。

但是，组合验证同样存在过拟合风险，必要时应使用独立时间窗口检查策略是否仍然稳定。

九、Agent 质量治理：把评测变成持续回归机制

离线评测和线上实验如果只用于生成报告，很难形成长期质量保障能力。

更合理的方式，是将评测接入 Agent 的发布与迭代流程。

9.1 四步质量归因

可以采用四步处理机制。

分层诊断： 根据 Prompt、知识、工具、推理和业务效果分别定位异常层次。

根因定位： 利用完整 Trace、上下文快照、工具日志及业务数据分析问题来源。

路由优化： 根据问题类型，分别调整 Prompt、知识库、数据处理、工具链路或模型策略。

回归验证： 修复后运行相关测试集，确认问题得到解决且没有引入新的能力退化。

9.2 三阶段上线治理

发布流程分为三个阶段：

9.3 测试开发平台需要记录哪些信息？

如果需要把以上能力工程化，建议在 Agent 执行链路中增加质量观测数据。

有了这些数据，才能进一步实现自动化评测、执行轨迹分析、失败归因以及版本间质量对比。

需要注意的是，不是每次 Prompt 修改都要执行完整 Benchmark。

测试范围应根据变更影响确定。

不过，对于底层模型替换、核心评估器修改、业务规则发生较大调整等全局性变更，应进行更全面的回归验证。

十、对测试开发人员意味着什么？

策略型 Agent 的质量保障，正在形成与传统自动化测试有所不同的技术体系。

传统测试开发人员已经具备的接口自动化、规则校验、数据验证、异常测试和 CI/CD 能力，仍然是重要基础。

在此之上，还需要增加几个新的工程方向。

第一，Agent 过程评测。

不仅验证最终输出，还需要检查工具调用、上下文使用、执行轨迹和决策依据。

第二，LLM Judge 可信性验证。

评估器不能只看准确率，需要同时测试位置偏差、稳定性、泛化能力与关键 Bad Case 的识别情况。

第三，评测数据工程。

除了常规测试集，还需要建设偏好对数据集、风险样本、Golden Set 和独立 Judge 验证集。

第四，业务效果质量验证。

让 Agent 评测能够连接 A/B 实验、业务指标、灰度发布和异常归因，而不是仅停留在离线打分阶段。

第五，持续质量治理。

将线上问题重新转化为可复现的测试样本，形成从发现问题到回归验证的完整机制。

这也意味着，未来 Agent 测试平台的核心能力不只是“自动执行测试”和“调用大模型评分”，还包括评估标准管理、Judge 校准、质量归因和业务效果验证。

总结

策略型 Agent 评测有三个核心问题需要解决。

首先是可评估。

通过多层质量对象、确定性规则、LLM Judge 和可信数据集，建立能够解释评测结论的质量标准。

其次是可控制。

通过发布准入、业务护栏、灰度实验、持续监控与回滚机制，降低错误策略进入真实业务后的风险。

最后是可迭代。

将 Bad Case、实验反馈和评测结论持续回流到 Prompt、知识、模型、规则和工具的优化流程中。

Auto Rubrics 为评估标准的自动生成和演化提供了一种技术路径，但它并不能自动解决所有质量问题。

规则本身需要验证，Judge 需要校准，训练数据需要检查，最终业务效果仍然需要独立实验。

对于测试开发团队而言，构建可靠的 Agent 质量体系，关键是将这些原本分散的能力组织成一套可观测、可复现、可回归的工程流程。

Agent 评测的终点不是得到一个更高的分数，而是能够持续判断系统的决策是否可靠，以及这些决策是否真正符合业务目标。

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