让 Agent 可评、可控、可迭代：业务效果导向的评测体系与实践

很多 Agent 的评测仍停留在“回答是否像正确答案”：用一批样本跑一次，算一个通过率，再决定是否上线。这种方式适合问答、摘要或代码生成等有相对明确答案的任务，但不适合直接生成营销、投放、补贴或运营策略的 Agent。

策略类 Agent 输出的不是静态答案，而是可能进入真实业务执行的配置。它通常没有唯一正确解，真正的质量要同时考虑约束合规、事实依据、推理过程、决策合理性、工具执行和业务增量效果。离线看起来合理，也不代表线上 ROI、GMV 或转化一定提升。

本文根据淘天集团业务技术团队公开文章《让Agent可评、可控、可迭代：业务效果导向的评测体系与场景实践》整理。原文团队、实验数字和方法结论属于来源文章的实践分享，不代表 GPT88 已经内置同样的业务评测能力；文末的工程建议是面向通用 Agent 和 GPT88 接入场景的整理与延伸。

一、先看完整方法论

这套方法可以压缩成“五层、四步、三阶段”：

问题	方法	解决什么
评什么	五层评测对象	从 Prompt 约束一直拆到业务效果
用什么评	规则、模型、实验三层方法	按可客观验证程度分工
评完怎么办	四步质量归因	从发现异常走到具体优化和回归
怎么上线	准入、灰度、监控三阶段	控制放量风险并让数据回流

核心闭环是：

业务目标
  → 评测数据集与评估器
  → 分层诊断
  → 根因定位
  → Prompt / 知识 / 工具 / 算法优化
  → 离线回归
  → 灰度实验
  → 线上监控与数据回流

三条原则贯穿始终：

1. 可评：知道系统哪一层出了问题，而不是只看一个总分。
2. 可控：上线前有门禁，线上有护栏、灰度、熔断和回滚。
3. 可迭代：每次评测结果都能路由到明确的改进动作，并在下一轮验证是否真的改善。

二、策略效果类 Agent 为什么难评

1. 反馈稀缺，而且到得很晚

线上 A/B 实验是判断策略偏好的重要来源，但实验资源有限，业务指标通常要到 T+1 甚至更晚才能稳定观察。来源文章以商品营销场景为例：每天运行的对照实验数量有限，积累一段时间后仍只有约百条偏好对。这种数据量很难直接训练出一个稳定、通用的评估器。

因此，评测系统不能只等待线上实验结果，而要在上线前用规则、历史数据、专家反馈和离线 Judge 尽量提前发现问题；但同时必须承认，离线评估不能替代真实实验。

2. 好策略是多个目标之间的权衡

同一个输入下，策略 A 可能更激进，策略 B 可能更保守；一个更看重 ROI，另一个更看重 GMV 或预算安全。业务目标还会随阶段变化，不能假设永远存在一个固定的单一分数。

3. 线上指标不能直接归因给 Agent

大促、货盘、流量、冷启动商品比例和季节性都会改变线上指标。GMV 上涨不一定是策略带来的，ROI 下降也不一定说明 Agent 推理错误。更可靠的设计是比较实验桶与对照桶的增量，而不是把绝对指标直接作为模型质量分数。

三、五层评测对象：先判断问题发生在哪一层

策略 Agent 出错时，根因可能完全不同：Prompt 约束冲突、经验召回错误、工具参数解析失败、推理方向偏差，或者线上环境导致效果未达预期。五层模型的作用，是把一个模糊的“Agent 不好用”拆成可以分工处理的质量对象。

L1：Prompt 与约束

检查角色定义、输入输出协议、业务优先级、禁止事项、预算上限和异常处理是否清晰、一致、可执行。

典型问题包括：

• 同一份 Prompt 同时要求“尽量提高规模”和“绝不增加预算”，但没有优先级；
• 冷启动商品没有历史数据，却没有禁止 Agent 擅自扩大补贴；
• 输出 Schema 没有约束取值范围，后续工具只能被动拒绝；
• 业务规则散落在多份 Prompt 中，变更后出现版本漂移。

L2：知识与上下文

检查 Agent 取到的商品数据、历史最优策略、实验桶、运营规则和时间窗口是否正确、完整、最新。

这里的重点不是“模型是否记住了知识”，而是“决策时拿到的上下文是否适用于当前对象”。召回了错误品类、过期规则或不匹配的历史案例，后续推理即使形式正确，也会得到错误方向。

L3：工具与执行链路

检查字段解析、参数校验、工具调用、权限边界、失败重试和结果回写。L3 可以用大量确定性规则覆盖，例如：

补贴率 ∈ [min_rate, max_rate]
预算消耗 ≤ budget_limit
必填字段不为空
策略版本与实验桶一致

如果 L3 失败，输出往往已经不可执行；不应等到线上业务指标变化后才发现工具参数越界。

L4：推理与策略决策

检查 Agent 是否正确理解约束、使用证据、解释策略变化，并在多目标之间做出符合业务优先级的取舍。

这一层通常需要 LLM Judge 或人工抽检辅助，但 Judge 的结论必须有 Rubric 支撑，不能只要求模型给一个“合理/不合理”的直觉分数。

L5：业务效果与持续回归

检查策略相对于对照基线的增量效果、实验稳定性、风险指标和长期回归表现。L5 只能由真实实验和线上数据最终验证，离线 Judge 只能作为提前筛查和排序工具。

五层之间存在级联关系：L1 不稳定，L2-L5 的评测结果都可能失真；L2 上下文错误，L3 即使执行正确也会执行错误策略；L3 全部通过但 L4 不达标，说明决策质量有问题；L4 得分高而 L5 失败，则要回头检查 Judge 是否对齐业务目标，或实验环境是否引入噪声。

四、三层评测方法：按确定性分工

不同问题需要不同评测方法，不能把所有问题都交给 LLM Judge。

1. 规则层：拦截硬错误

规则层适合判断有明确边界的事实：字段是否合法、参数是否越界、预算是否超限、输出是否符合 Schema、工具是否返回成功。

它的优势是确定、便宜、可审计。规则层应优先拦截高风险错误，并阻止不合格策略进入后面的模型判断或实验流量。

2. 模型层：判断语义与策略合理性

模型层适合判断：是否正确引用上下文、策略方向是否合理、推理是否解释了关键取舍、输出是否符合业务 Rubric。

但 LLM Judge 不是天然可信。它需要金标验证、A/B 位置随机化、多轮一致性测试、交叉验证和 Bad Case 监控。Judge 的分数只能代表“在当前评估器和当前 Rubric 下的判断”，不能直接等价为真实业务收益。

3. 实验层：验证真实业务增量

实验层用对照桶、实验桶和稳定性验证桶回答：策略是否真的带来业务增量，变化是否超过环境噪声，是否值得扩大流量。

来源文章特别强调，实验目标应尽量关注相对提升，而不是绝对值：

策略增量 = 实验桶效果 - 对照桶效果

实际分析还要考虑样本量、置信区间、实验周期、分桶一致性和外部事件。没有这些信息，不能把单日涨跌直接写成策略成功或失败。

五、评测数据集：按失败模式建设，而不是只追求数量

评测集的价值不在于样本越多越好，而在于是否覆盖真实失败模式和高风险边界。

第一批：基础能力集

• 常规测试集：覆盖主流程和高频场景，作为日常水位。
• 回归测试集：Prompt、模型、知识或工具变更后用于对比。
• Bad Case 集：来自线上失败、人工反馈和历史事故，是最直接的问题样本。

这三类是上线前最低门槛。

第二批：边界与风险集

• 线上回流集：随着实验持续收集真实新问题。
• 对抗样本集：覆盖高价格商品、冷启动商品、极端参数和缺失数据。
• 红队样本集：模拟诱导 Agent 绕过预算、上限或权限边界的输入。
• 安全样本集：聚焦超预算投放、错误放量、错误工具调用等高风险行为。

第三批：Judge 验证集

从测试集或人工金标中独立保留一部分样本，只用于验证评估器本身。不能让 Judge 在生成或筛选 Rubric 时看到这部分答案，否则评估器的准确率会被高估。

数据集还要遵循三条原则：

1. 比例由风险决定：高频样本保证日常水位，高风险样本提高权重，不要只按线上频率采样。
2. 持续保鲜：业务目标、Prompt、上下文和策略分布变化后，旧样本可能失效，需要版本化、复核和淘汰。
3. 评估器也要评估：来源文章给出了一个 Judge 从测试集 86%、验证集 68% 到泛化验证集 55% 的衰减案例。这个数字是原文实践数据，不是普适基准，但它很好地说明了训练集高分不等于泛化可靠。

六、四步质量归因：让评测结果变成行动

评测的目标不是生成一张分数表，而是告诉团队下一步改什么。

第一步：分层诊断

沿五层对象拆分指标，不把所有问题压成总分。至少可以分别记录：

维度	例子
格式合规	Schema、字段、类型、必填项
事实准确	数据、规则、历史策略是否正确
推理质量	证据引用、约束理解、解释完整性
决策合理	策略方向、优先级和风险权衡
工具执行	参数、权限、调用成功率、回写
多轮稳定	同输入重复运行的一致性
业务效果	相对基线的实验增量和风险指标

第二步：根因定位

同样是推理层得分低，可能是 Prompt 约束冲突、知识召回不准、工具数据缺失或 Judge 自身过拟合。必须继续向下追问“为什么这一层失败”，否则团队容易把所有问题都归因给模型能力。

第三步：路由优化

根因不同，责任和优化通道不同：

根因	优化方向
目标或约束不清	产品、运营和研发共同修订 Prompt 与规则
上下文错误	更新知识库、召回过滤、时间和品类匹配
工具失败	修复 Schema、权限、参数校验和重试
推理偏差	调整示例、模型、Prompt、策略算法或数据
Judge 失真	修订 Rubric、金标、采样和评估协议
线上异常	检查实验环境、货盘、流量和外部事件

第四步：回归验证

任何优化都必须回到评测体系中验证：Prompt 变更跑回归集，数据优化检查训练/验证 Gap，算法优化检查 Pass@N 或关键 Judge 指标并配合实验，知识库更新检查召回率和业务效果。

七、三阶段上线治理：准入、灰度、监控

阶段一：准入

上线前完成规则层硬门禁、模型层评测、回归集对比、风险样本检查和回滚方案确认。任何变更都要绑定与影响域匹配的回归范围：

• Prompt 局部调整：运行受影响的指令遵循和业务子集；
• 模型替换：运行完整 Benchmark 和高风险集；
• Judge 变更：优先验证评估器自身，因为它会影响所有评测结论；
• 工具协议或数据源变更：运行执行链路、权限和数据新鲜度检查。

阶段二：灰度

建议至少区分三类桶：

桶	作用
对照桶	保留旧策略或人工策略作为业务基线
实验桶	运行新 Agent 或新策略
稳定性验证桶	继续运行上一版本，识别外部环境噪声

如果实验桶和稳定性验证桶同时异常，问题可能来自大促、货盘、流量或数据链路，而不是新 Agent。此时直接熔断新策略可能是误判，应先排除环境因素。

阶段三：线上监控与回流

线上监控至少要同时看：业务指标、风险指标、工具错误率、策略分布漂移、评估器置信度和实验分桶健康度。异常进入四步归因时，第一个判断应是“Agent 问题还是结构性问题”。如果同一商品在所有实验桶都劣化，优先检查外部环境、数据缺失和大盘异常。

八、从“打分”转向“比较”：构建偏好数据

直接给策略打 0 到 5 分看起来简单，但有三个问题：

1. 分数有天花板，策略持续变好后无法表达细微差异。
2. 业务目标从 GMV 换成 ROI 后，整套分数区间需要重做。
3. 分数依赖线上结果，而上线前 Judge 必须能够工作，两者很难天然对齐。

因此，可以把问题改写为相对判断：在同一个输入和相近实验条件下，策略 A 与策略 B 谁更好？构建 DPO 风格的偏好对：

输入：实验结果（策略 A vs 策略 B）
输出：chosen = 业务效果更好的策略
      rejected = 业务效果更差的策略

偏好对保留了业务相对关系，避免要求评估器预测一个绝对分数。但它仍然需要控制实验条件、样本量和置信度，不能把未经验证的“看起来更好”直接标记为 chosen。

九、Auto Rubrics：让评估规则从数据中演化

Rubric 是人类可读的评估标准，例如“策略参数必须处于合法区间”“没有历史数据时不得盲目增加补贴”。与黑盒 Reward Model 相比，Rubric 的优势是可解释、可定向更新，并且可以针对某条业务规则追踪失败原因。

Auto Rubrics 把规则建设变成“生成—评估—迭代”的闭环：从 chosen/rejected 偏好对、专家经验和 Bad Case 中自动提出候选规则，再用无偏验证筛选真正有区分力的规则。

一个完整 Pipeline 可以拆成：

1. 数据模式分析：先统计 chosen 与 rejected 在参数差异、分位数和显著模式上的区别，把客观规律注入规则生成上下文。
2. 候选生成：让 LLM 从偏好对中提取好策略特征和坏策略缺陷，多轮采样以获得多样候选。
3. 语义去重：合并表述不同但含义相同的规则。
4. 双侧验证：分别统计 Rubric 在 good case 与 bad case 中的违反率。
5. 比较评估：让模型比较 A/B 哪个更严重违反某条规则，而不是孤立判断一个输出是否违反。
6. 稳定性筛选：通过 Bootstrap 和选择频率排除依赖特定样本的噪声规则。
7. 交叉验证与端到端验证：在未参与规则选择的数据上估计泛化能力，再检查完整 Rubric 集合的整体准确性。
8. Memory 增量更新：把规则标记为 active、degraded、remove 或 recover，保存每次运行的版本快照。

十、LLM-as-Judge 的三个系统性陷阱

陷阱一：位置偏差

如果 chosen 总是放在 A、rejected 总是放在 B，模型可能学到位置而不是策略质量。来源文章中，固定位置时训练准确率曾达到 96%，但验证集只有 50%；引入 A/B 随机化后，训练准确率回落到 69.3%，但这个数字更接近真实信号。

最低要求是随机交换 A/B。更严格的方案是正序和逆序各运行多次，检查结论是否一致，并把位置一致率作为评估器指标。

陷阱二：选择过拟合

从几百条候选 Rubric 中按训练集区分度贪心选择，容易选出只适合当前样本的规则。来源文章记录了 330 条候选中没有任何规则选择频率超过 80%，并且训练和交叉验证准确率出现明显落差的案例。这说明“被选中”本身也可能是噪声。

应使用 Bootstrap 稳定性选择和 K-Fold 交叉验证：在不同子样本上重复选择，统计每条规则的入选频率；最终评估必须使用未参与选择的数据。

陷阱三：一致性不等于正确性

一个模型可能每次都稳定地判断错误。多轮评估时必须同时看一致率和正确率，不能只因为输出稳定就认为 Judge 可靠。更稳妥的做法是：多个随机种子、多个 A/B 顺序、人工金标和一致性过滤一起使用。

十一、三层 Rubric Judge 架构

Layer 1：Rubric 供给层

从偏好对中自动挖掘隐性规则，同时从数据本身提取统计模式，形成规模较大且互补的候选池。两条路线不能互相替代：LLM 擅长解释语义差异，统计分析负责给候选规则提供事实锚点。

Layer 2：Rubric 筛选层

先用双侧违反率过滤方向错误和低区分度规则，再用 A/B 比较和位置交换提高稳定性，最后用 Bootstrap 与交叉验证控制选择过拟合。

Layer 3：可信数据验证层

对每组偏好对用完整 Rubric 集合独立判断多次，并随机化 A/B 位置。只有结论一致、方向正确的样本才进入 Golden Set；不一致样本暂不用于高置信训练或模型校准。

这种做法的取舍是覆盖率可能下降，但精度和可信度更高。对高风险策略任务，宁可让一部分样本进入“需要人工复核”，也不要把不可靠偏好混入训练和准入依据。

十二、策略收敛判断：不要被单日涨跌骗到

同一策略今天提升 20%、明天下降 15%，不一定是策略变化，可能只是数据波动。长尾商品一天少一单就可能产生 50% 的表面跌幅，单日指标无法支撑“已收敛”的结论。

来源文章给出的四层漏斗是：

全量商品
  → Layer 1：量级过滤，排除低成交、零销量和缺失数据
  → Layer 2：时间一致性，要求连续多天方向稳定
  → Layer 3：稳定性评分，结合贝叶斯收缩、波动和趋势
  → Layer 4：组合口径验证，形成 Clean Set

Layer 1：量级过滤

先排除数据天数、成交量或对照基准不足的商品。被过滤不代表策略失败，只代表证据不足。

Layer 2：时间一致性

要求效果在连续多天达标，且大多数观测日方向一致，避免把偶然单日波动当成真实效果。

Layer 3：稳定性评分

贝叶斯收缩的直觉是：样本少时让评分更保守，向整体平均水平收缩；样本多时才更相信商品自身数据。再结合达标天数占比、波动程度和趋势方向，筛选更可信的对象。

Layer 4：组合验证

单个商品数据量仍然不足时，可以将多个商品组成候选组合，每加入一个就验证组合在每个观测日是否仍满足约束。不满足就跳过，最终形成更稳定的 Clean Set。

Rubric 筛选和策略收敛判断背后是同一原则：先过滤不可信候选，再做组合验证；高精度优先于虚假的高覆盖率。

与传统 Reward Model 的对比也应保持谨慎：Rubric Judge 提供更强的可解释性和规则可更新性，但仍然需要金标、交叉验证和线上校准；它不是无需验证的“真值模型”。

十三、面向 GPT88 Agent 的工程落地建议

这套方法可以映射到 GPT88 的模型调用和 Agent 工作流，但不能把来源文章的业务结果直接当作 GPT88 平台承诺。接入时建议把责任拆开：

组件	适合交给模型的工作	必须由确定性系统负责的部分
任务模型	生成候选策略、解释证据、提出替代方案	权限、预算、参数范围和最终执行
Judge	按 Rubric 判断推理和策略合理性	金标维护、偏差检测、版本冻结
业务实验	汇总和分析结果	分桶、随机化、统计显著性、熔断和回滚
数据回流	归纳 Bad Case、生成候选 Rubric	数据脱敏、来源追踪、训练集/测试集隔离

一个可审计的运行记录至少包含：

{
  "run_id": "eval_2026_09_19_001",
  "model": "<current-model-id>",
  "prompt_version": "prompt-v12",
  "judge_version": "rubric-judge-v4",
  "dataset_version": "business-prefs-v7",
  "ab_randomized": true,
  "metrics": {
    "rule_pass_rate": 0.0,
    "judge_accuracy": 0.0,
    "position_consistency": 0.0,
    "business_lift": null
  },
  "decision": "needs_review"
}

模型 ID、价格、上下文和配额应以 GPT88 当前模型列表和控制台为准，不要把博客中的示例模型名称写成长期承诺。API Key 通过环境变量或密钥管理注入，不要放进评测数据、日志、Prompt、截图或 Git。

十四、上线前质量门禁

• Prompt 的硬约束、工具协议和输出 Schema 已冻结，不能被自由变异。
• 规则层已经覆盖预算、参数、权限和 Schema 硬错误。
• 测试集、验证集、泛化集和线上回流集严格隔离。
• Bad Case、边界、红队和安全样本已经纳入评测。
• Judge 有人工金标，并验证了正确率、一致率和 A/B 位置偏差。
• Rubric 筛选使用了交叉验证或等价的未见数据评估。
• 线上实验有对照桶、实验桶和稳定性验证桶。
• 业务增量和绝对指标分开记录，不能直接把单日涨跌归因给 Agent。
• 评测异常能路由到 Prompt、知识、工具、算法、Judge 或外部环境责任方。
• 灰度有预算、流量、风险阈值、熔断和回滚。
• 每次模型、Prompt、Judge、数据或工具变更都有版本和回归记录。
• 评估器自身也持续接受人工和业务效果校准。

十五、结语

Agent 评测不是上线前一次性的验收，而是驱动系统持续进化的基础设施。五层评测对象让团队知道评什么，三层评测方法让不同问题由合适的证据回答，四步质量归因让分数变成优化动作，三阶段上线治理则把离线判断接入真实发布流程。

最需要警惕的是评估器带来的虚假信心。一个未经校准的 Judge 可能稳定、快速、看起来很专业，却系统性地偏好错误方向。因此，任何要用于模型选型、训练数据筛选、Prompt 回归或质量准入的 Judge，都必须检查位置偏差、选择过拟合、一致性与正确性、Bad Case 覆盖以及线上效果相关性。

对于策略类 Agent，最成熟的目标不是追求一个漂亮的离线分数，而是建立一条可解释、可阻断、可灰度、可回滚、能持续吸收新证据的质量飞轮。

来源与说明

• 原文：让Agent可评、可控、可迭代：业务效果导向的评测体系与场景实践，大淘宝技术，2026 年 9 月 19 日。
• 原文作者：叱干、王菲，淘天集团业务技术-营销&交易技术团队。
• 本文保留原文配图并使用本地静态资源；正文为结构化整理和工程化补充，不代表原作者或其团队对 GPT88 的产品背书。
• 原文中的实验数据、准确率、过滤比例和业务指标属于特定项目上下文，不能直接外推为通用基准。