做 Agent 的人都有一个尴尬时刻：你改了一版提示词，觉得比原来好用多了，但拿不出证据。给同事演示时挑了两个漂亮的例子，上线之后却发现另一批场景开始频繁答错——到底是变好了还是变差了，谁也说不清。
这不是能力问题，是方法问题。人眼比较几个例子，本质上是在挑自己爱看的样本；而 Agent 的输出天然带随机性，同一个问题问两遍结果都不一样。想判断一次改动到底有没有用，得靠对照实验，不能靠感觉。
先说清楚这篇在站内的位置：AI Agent 评测怎么做 讲的是离线——用固定任务集在发布前判断好坏；版本升级后怎么做回归测试 讲的是「新的别把旧的弄坏」；用 LLM 当裁判的评分器 讲的是怎么自动打分。这一篇讲的是另一层：改动上线之后，怎么用真实流量证明它真的更好。三件事不冲突，是发布流程的三个阶段。
一、先分清三件事：离线评测、灰度放量、A/B 实验
- 离线评测：用一批固定样本，上线前跑一遍。优点是快、可重复；缺点是样本是你自己挑的，未必代表真实流量。
- 灰度放量：先让一小部分流量跑新版，确认没有明显崩坏再逐步扩大。它回答的是「会不会炸」，不回答「有没有变好」。具体做法可以参考 OpenClaw 版本管理与灰度发布。
- A/B 实验：把流量随机分成两组，一组用旧版、一组用新版，用同一口径的指标对比。它才是回答「这次改动值不值」的那一步。
很多人把前两件事当成第三件事，结果就是「灰度放完就全量了」——等于默认新版更好，而这恰恰是唯一该被验证的假设。
二、实验开始前，先把四样东西定死
实验最容易翻车的地方不在跑，而在跑之前没定规则。四样必须提前写下来：
- 唯一的主指标。这次改动想改善什么，只能有一个主指标（比如任务一次完成率）。指标一多，必然出现「这个涨了那个跌了」，最后靠嘴解释。
- 护栏指标。主指标涨了，别的不能坏。常见护栏：转人工率、单任务成本、平均耗时、差评比例、涉及金额的操作出错次数。
- 分流单位。按什么把人分到两组——用户、会话还是单次请求。这个选择决定后面会不会互相污染。
- 判定规则。跑多久、看多少样本、达到什么条件算赢、什么情况直接叫停。这三条必须在看到数据之前写下来。
之所以强调「提前」，是因为人一旦看到数字，就会本能地去找「再跑两天说不定就显著了」的理由。
三、指标口径：同一个词，两种算法差很远
Agent 的指标比网页转化率难定义，因为它经常是「一个任务拉了十几轮」。三个具体建议：
- 先定「一个样本」是什么。是一次提问，还是一个完整任务？按次提问算，多轮任务的中间步骤会把成功率稀释得很难看；按任务算，就要明确什么算「完成」。评测样本怎么建 里那套「要覆盖失败边界」的思路，在定义线上指标时同样适用。
- 长尾看分位数，别只看平均值。平均耗时 8 秒听着不错，但如果 P95 是 90 秒，那 5% 的用户体验极差。Agent 场景里分位数往往比均值更能说明问题。
- 把返工和人工介入算进去。只看「答得快不快」会得出错误结论。一个方案如果快 20% 但让人多返工 30%，它其实是亏的——成本怎么算 里讲过，返工和工具调用不能漏。
四、分流：随机只是最低要求
A/B 实验听起来简单，真正难的是让两组「可比」。三条硬要求：
- 同一主体始终进同一组。同一个用户在实验期间应该一直看到同一个版本，否则他今天问新版、明天问旧版，体验混乱，数据也没法归因。
- 别让两组互相影响。共用的知识库、共用的缓存、共用的工具配额，都可能让一组的结果污染另一组。尤其是结果缓存：A 组算完的结果被 B 组命中，实验基本就废了。
- 先算样本量，再开机。改动带来的提升通常只有几个百分点，样本太小的话，两组之间的差异完全可能是随机噪声——你会把一个正常波动当成显著性胜利。
还有一个常被忽略的点：Agent 的改动往往不是单一变量。你同时换了模型、改了提示词、加了知识库，那即使指标变好了，也说不清是哪个起的作用。想搞清楚，一次只改一样。
五、护栏指标：什么情况下必须立刻停
护栏的作用不是「顺便看看」，而是触发即停。建议设三条硬线：
- 体验线：转人工率或用户追问次数明显上升 → 立即停。
- 成本线：单任务成本涨超过预设比例 → 立即停（新版往往更贵，这一条经常救预算）。
- 风险线：涉及资金、外发、删除这类动作的出错次数出现任何一次 → 立即停并人工复盘。
护栏要配一个「自动停」的机制，而不是靠人盯。可以参考 AI Agent 质量门禁怎么设 里那套「不达标就不放行」的思路，只是这里管的是上线后的实时状态。
六、跑多久、什么时候能看结果
两条纪律：
- 提前定时长，中途别偷看。反复看数据、一看到显著就停，会系统性高估效果。要么跑满预设时长，要么用事先约定好的统计方法。
- 把「统计显著」和「业务值得」分开。样本足够大时，1% 的提升也能显著。这时要问的是：为了这 1%，多出来的维护成本划算吗？
还要注意时间带来的偏差：Agent 的使用本身有学习曲线，员工刚上手和熟练之后的行为完全不同；节假日、大促这类周期性因素也会干扰。稳妥的做法是至少覆盖一个完整的业务周期。
七、Agent 特有的四个坑
- 输出非确定性。同一输入多次输出不同，单次结果没有代表性——必须看分布，不能看个例。这也正是 输出不稳定怎么治 里要固定参数的原因。
- 任务周期长。一个长任务可能跑几天，用「当天完成率」当指标会把还没跑完的算成失败，得出错误结论——要按队列口径处理，或者把未完成单独统计。
- 外部依赖在变。模型供应商更新了版本、工具接口改了返回格式，这些都在实验期间发生，干扰来源不止你的改动。
- 人也在变量里。人机协同场景中，人的行为会因为「知道有新版本」而变化，两类指标要分开看：机器自己的完成率，和最终的业务结果。
八、五个常见的坑
- 没有基线就上线。连「现在是多少」都不知道，改完之后也无从比较。
- 主指标太多。五个指标里三个涨两个跌，最后只能靠主观挑一个汇报。
- 一次改多个变量。结论只能到「这版比上版好」，没法知道好在哪。
- 样本量不够就宣布胜利。把噪声当成效果，是 A/B 实验最经典的错误。
- 只看主指标，不看护栏。主指标涨了、成本翻倍，账面赢了，实际亏了。
九、适合谁用，不适合谁用
适合：Agent 已经真实跑在业务里、每天有一定调用量、有明确业务指标可以对齐的团队。哪怕不做严格的统计检验，只要做到「随机分组 + 同一口径指标 + 护栏监控」，判断质量就比拍脑袋高一个量级。
不太适合：还在原型阶段、每天只有几十次调用、连基础数据都没打通的场景。这个阶段更该做的是离线评测——样本少但能反复跑，成本低、反馈快。等流量上来了，再谈线上实验。
总结
验证 AI Agent 的改动，本质上是把「我觉得好了」换成「数据说好了」。要做的事情并不复杂：定一个主指标和几条护栏，随机分流，按批次跑够样本，规则写在看数据之前。离线评测管发布前，灰度管会不会炸，A/B 实验管值不值得——三件事各司其职，Agent 的迭代才不会变成一场凭感觉的赌博。
