AI Agent A/B 实验深度解析（下）：从实验设计到上线决策

六、实验数据分析

6.1 总体指标分析

def analyze_agent_ab_results(exp_tasks, ctrl_tasks):
 """
 exp_tasks: 实验组的任务执行结果列表
 ctrl_tasks: 对照组的任务执行结果列表
 """
 results = {}

 # 1. 任务成功率
 exp_success = sum(1 for t in exp_tasks if t["success"]) / len(exp_tasks)
 ctrl_success = sum(1 for t in ctrl_tasks if t["success"]) / len(ctrl_tasks)

 # 比例检验
 from scipy import stats
 n_exp, n_ctrl = len(exp_tasks), len(ctrl_tasks)
 x_exp = sum(1 for t in exp_tasks if t["success"])
 x_ctrl = sum(1 for t in ctrl_tasks if t["success"])

 # 两样本 z-test for proportions
 p_pool = (x_exp + x_ctrl) / (n_exp + n_ctrl)
 se = np.sqrt(p_pool * (1 - p_pool) * (1/n_exp + 1/n_ctrl))
 z_stat = (exp_success - ctrl_success) / se
 p_value = 2 * (1 - stats.norm.cdf(abs(z_stat)))

 results["success_rate"] = {
 "exp": round(exp_success, 3),
 "ctrl": round(ctrl_success, 3),
 "lift": f"{round((exp_success - ctrl_success) * 100, 1)}%",
 "p_value": round(p_value, 4),
 "significant": p_value < 0.05
 }

 # 2. Judge 胜率
 judge_wins = sum(1 for t in exp_tasks if t.get("judge_winner") == "exp")
 judge_losses = sum(1 for t in exp_tasks if t.get("judge_winner") == "ctrl")
 judge_ties = sum(1 for t in exp_tasks if t.get("judge_winner") == "tie")
 win_rate = judge_wins / (judge_wins + judge_losses + judge_ties)

 results["judge_win_rate"] = {
 "exp_wins": judge_wins,
 "ctrl_wins": judge_losses,
 "ties": judge_ties,
 "win_rate": round(win_rate, 3)
 }

 # 3. 护栏检查
 results["guardrails"] = {
 "dead_loop_rate_exp": sum(1 for t in exp_tasks if t.get("dead_loop")),
 "dangerous_ops_exp": sum(1 for t in exp_tasks if t.get("dangerous_op")),
 "avg_steps_exp": np.mean([t["steps"] for t in exp_tasks]),
 "avg_steps_ctrl": np.mean([t["steps"] for t in ctrl_tasks]),
 "avg_cost_exp": np.mean([t["cost"] for t in exp_tasks]),
 "avg_cost_ctrl": np.mean([t["cost"] for t in ctrl_tasks]),
 }

 return results

6.2 假阳性与假阴性：两类错误的代价

在 A/B 实验中，统计检验永远有犯错的可能。

对比维度	假阳性（Type I / α）	假阴性（Type II / β）
含义	无效当有效	有效当无效
通俗说法	谎报军情——把无效变更当成有效优化	错失良机——明明有效却检不出来
典型阈值	α = 0.05（5% 概率误判）	β = 0.20（20% 概率错过）
Agent 场景风险	上线有副作用的变更	错失成功率提升
主要原因	多重比较、偷看数据	样本量不足、方差大

Agent 场景为什么假阴性风险更高？

原因 1：任务成功率方差大。 同一个 Agent 在相同任务上，不同环境状态下的执行路径不同 → 指标方差大 → 需要更大样本量 → 样本量不够时，有效变更可能被错过。

原因 2：多重检验校正的惩罚。 Agent 实验通常看多个指标（成功率、Judge评分、步骤数、费用……）→ 如果做 Bonferroni 校正，α 被除到很小（如 0.05/10 = 0.005）→ 更难检出显著差异。

原因 3：效应量天然小。 Agent 的很多优化是"渐进式"的（Prompt 微调、工具描述优化）→ 效果可能只有 2-3 个百分点 → 小效应量更难被检出。

解决方案：

方法	解决什么问题	具体操作
增大样本量	假阴性	根据 MDE 提前计算所需样本量，达标再读结果
序贯检验	假阳性（偷看数据）	在实验进行中多次查看，用更严格的 α 补偿
Benjamini-Hochberg	假阳性（多指标）	控制 FDR，而非 Bonferroni 的 FWER
CUPED	假阴性（方差大）	利用实验前数据作为协变量，降低方差 30-50%
分层实验	两者	按任务类型分层，减少组间噪声

多重检验校正 - Benjamini-Hochberg 方法（推荐）：

问题：看 20 个指标，每个用 p<0.05 判断 → 纯概率也会出现 1 个"显著"
解决：控制 False Discovery Rate（FDR），而非控制 Family-wise Error Rate
步骤：
 1. 对所有指标的 p-value 从小到大排序：p1 ≤ p2 ≤ ... ≤ pm
 2. 找到最大的 k，使得 pk ≤ (k/m) × α
 3. 前 k 个指标判定为显著
示例（α=0.05, m=10 个指标）：
 p-values: 0.002, 0.008, 0.03, 0.04, 0.15, 0.22, 0.30, 0.45, 0.60, 0.80
 检验 k=4: p4=0.04 ≤ (4/10)×0.05 = 0.02? → 0.04 > 0.02, 不满足
 检验 k=3: p3=0.03 ≤ (3/10)×0.05 = 0.015? → 0.03 > 0.015, 不满足
 检验 k=2: p2=0.008 ≤ (2/10)×0.05 = 0.01? → 0.008 ≤ 0.01 
 → 前 2 个指标判定为显著

6.3 反转实验：用反面证据验证结论

💡 关键洞察：正实验告诉你"新版本比旧版本好"，反转实验告诉你"真的是这个改动导致的"。反转实验是确立因果关系的最后一道防线，尤其适合 Agent 这种变量多的场景。

什么是反转实验（Reversal Experiment / Holdback Test）：

1. 正实验：对照组（保守策略）vs 实验组（激进策略）→ 实验组成功率显著更高 → 上线激进策略
2. 反转实验（上线后验证）：新基线组（当前激进策略）vs 反转组（改回保守策略）→ 预期反转组成功率下降
3. 如果反转组的成功率确实下降了 → 确认是策略本身的作用 → 因果关系得到"反转验证"
4. 如果反转组成功率没有下降 → 正实验的结论可能有问题 → 可能是周期效应、用户群体变化或其他外部因素

Agent 场景的反转实验示例：

场景：SubAgent 并行策略调整
 策略 A（保守）：最多 2 个 SubAgent 并行
 策略 B（激进）：自动判断，最多 8 个 SubAgent 并行

正实验（A vs B）：
 对照组：策略 A，成功率 75%
 实验组：策略 B，成功率 82%（p=0.003, 显著 ）
 → 结论：激进并行策略更好 → 上线策略 B

反转实验（上线 2 周后）：
 新基线（策略 B，正在线上运行）vs 反转组（改回策略 A）
 收集 1 周数据：
 新基线：成功率 81%
 反转组：成功率 74%（p=0.008, 显著下降 ）
 → 反转验证通过：确实是激进并行策略带来了提升
 → 高置信度保留策略 B

如果反转组成功率没有下降（甚至上升）：
 → 正实验期间可能存在混淆因素（如模型微调、工具更新）
 → 需要重新实验，不要盲目相信第一次的结果

反转实验操作 checklist：

• 只在以下情况做：高风险变更（模型升级、SubAgent 策略大改）；正实验效应量很小但上了线（如 +2%）；实验结果和直觉/离线评测方向不一致；团队对结论有分歧
• 时机：新版本全量上线后至少 2 周（排除新奇效应），用户对新 Agent 行为已经适应
• 判断标准：反转组指标确实朝预期方向相反 → 验证通过；反转组指标无变化 → 正实验结论存疑；反转组指标反而变好 → 正实验结论错误，考虑回滚

6.4 细分分析

Agent A/B 必须做的细分分析：

分析维度	分组	关注点
按任务难度	简单（1-3步）/ 中等（4-8步）/ 复杂（9+步）	差异在复杂任务上最明显；可能出现"简单任务劣化、复杂任务提升"
按任务类型	代码生成 / 搜索分析 / 文件操作 / 多工具编排	不同维度的优劣势可能不同
按用户分群	新用户 vs 老用户 / 高频 vs 低频 / 不同角色	新老用户可能结论相反
按时间趋势	实验第1周 vs 第2周	排除"新奇效应"——用户因变化觉得新鲜而非真的更喜欢

6.5 决策矩阵

场景	成功率	质量评分	死循环	耗时	费用	决策
理想	↑ 显著	↑ 显著	0%	→ 持平	↓	上线
质量换效率	→	→	0%	↓ 显著	↓	上线
效率换质量	↑ 显著	↑	0%	↑ 可接受	↑ 可接受	视ROI
安全劣化	↑	↑	> 0%	—	—	禁止
全面退化	↓	↓	任何	↑	↑	放弃

特殊决策场景：

• 质量 ↑↑ 但费用 ↑↑：（成功率 +15%，费用翻倍）：成功率提升能否带来足够业务价值？能减少人工介入 → 可能值得；边际改善 → 不值得
• 质量 ↑ 但耗时 ↑↑：（成功率 +5%，耗时 +50%）：用户"等结果继续工作"→ 不能接受；用户"发任务后去做别的事"→ 可能可以接受
• 细分群体方向不一：（新用户 +10%，老用户 -3%）：看战略优先级——要增长还是要留存？不能同时看"全体用户"结果做决策

七、灰度放量与上线决策

7.1 实验五步走

步骤 ② 离线验证（Agent A/B 独有的关键步骤）：

为什么 Agent 实验必须先离线？① 线上 Agent 实验风险高（执行的是真实操作）；② 离线可以用更大的样本量快速判断方向；③ 如果离线就劣化 → 省去线上实验的时间和风险。

离线验证清单： 回放 500+ 线上真实任务； 任务成功率不劣化； Judge 结果评分不下降； 死循环率 = 0； 危险操作率 = 0； 耗时和费用在可接受范围。→ 全部通过后才能进入线上实验。

7.2 1%→100% 放量节奏与间隔时间

变更等级	放量阶梯	每阶段停留	全流程	额外要求
L1 低风险（Prompt 调整、工具描述优化）	5% → 20% → 100%	5% ≥ 1天（200+任务）；20% ≥ 1天（500+任务）	2-3 天	主要看成功率 + 死循环率 + 错误率
L2 中风险（模型升级、工具增删）	1% → 5% → 20% → 50% → 100%	1%:1-2天, 5%:2-3天, 20%:3-4天, 50%:3-5天	9-14 天	每阶段确认死循环=0、无新增危险操作、成功率不低于基线
L3 高风险（框架升级、核心逻辑重构）	内部测试 → 1% → 5% → 20% → 50% → 100%	内部:1周, 1%≥3天, 5%≥1周, 20%≥1周, 50%≥1周	4-6 周	每阶段出分析报告 + 收集用户反馈 + 人工抽查 trace + oncall 值班

每阶段观察 Checklist：

放量决策：何时加速 vs 暂停 vs 回滚：

决策	触发条件	操作
加速放量	连续三阶段所有指标正向或持平 + 护栏全绿 + 实验超建议时长 1.5 倍	加速到下一阶段，或直接 20%→100%
暂停放量	核心指标 p-value 在 0.05-0.10 之间；样本量未达标；某细分群体劣化	延长当前阶段 1-3 天，收集更多数据
回滚	任何安全红线（死循环>0/危险操作>0）；成功率下降>5%且显著；用户投诉超基线3倍；新类型错误	立即切回上一版本，保存全部数据日志，24h内出事故报告，修复后从1%重新开始

周末效应与工作日效应的处理：

效应	现象	处理方式
工作日效应	工作日任务量大、类型以代码为主	放量至少覆盖 1 个完整工作周（周一到周五）
周末效应	周末任务量少、类型不同（个人项目/学习类）	L2 变更必须覆盖至少 1 个周末
周期效应	月末/季末任务量激增，紧急任务比例上升	L3 变更至少覆盖 1 个完整业务周期（4 周+）
节假日效应	长假期间任务量和类型与平时差异极大	避免节假日前 1 天放量，节后 2 天再评估

关键原则：不要在周五下午放量。 周末人力不足，出现问题无法及时响应。最佳放量时间：周二或周三上午（有完整工作周观察）。

7.3 实验监控与告警

指标	对照组	实验组	状态
任务成功率	78%	82%	🟢 +4%
死循环次数	0	0	🟢 正常
危险操作	0	0	🟢 正常
平均步骤数	5.2	4.8	🟢 -8%
平均耗时	45s	38s	🟢 -16%
平均费用	$0.12	$0.10	🟢 -17%
用户中断率	8%	6%	🟢 -2%

告警级别：🔴 P0（死循环 > 0 / 危险操作 > 0 / 成功率骤降 > 10%）→ 立即响应；🟡 P1（成功率 ↓ > 5% / 错误率 ↑ > 50%）→ 1 小时内；🟢 P2（费用 ↑ > 30% / 耗时 ↑ > 30%）→ 下个工作日。

八、开源 A/B 实验平台与方法论

8.1 在线实验平台

平台	定位	特点	适用度
GrowthBook	开源 Feature Flag + A/B	多种分流策略、Bayesian 引擎、可视化看板	需自定义 Agent 指标
Unleash	开源 Feature Toggle	灵活分流规则、支持逐步放量	分流层，指标需自建
Flagr	轻量级开源 Flag	简单易部署、支持 Entity 级分流	轻量场景
Eppo	商业实验平台（有开源组件）	方差缩减（CUPED）、序贯检验、多臂老虎机	统计方法强

推荐方案：GrowthBook（分流和实验管理）+ 自建 Agent 指标管道（Agent 专属指标采集和计算），两者通过 experiment_id 关联。

8.2 LLM 离线评测框架

框架	定位	核心能力	Agent 适用性
LangSmith	LLM trace + 评测	自动记录 Agent trace、标注、数据集管理、对比实验	原生支持 Agent
Braintrust	LLM 评测平台	评测模板、Judge 打分、回归测试	评测友好
Log10	LLM 日志与评测	自动采集 LLM 调用、反馈标注、离线评测
Promptfoo	Prompt 评测	配置化评测、多模型对比、安全扫描	Prompt 变更场景

LangSmith 在 Agent A/B 实验中的典型用法：

1. 自动采集所有 Agent 执行 trace（带 experiment_id tag）
2. 离线回放：用同一批任务，在两套配置下重放
3. 对比 Run：成功率 diff / 步骤数 diff / 费用 diff / 工具选择 diff

8.3 统计方法与工具库

方法	适用场景	核心优势	Agent 场景推荐度
Fisher's Exact	小样本（< 100/组）	精确 p-value，不做大样本近似
Bootstrap	非正态分布指标	不依赖分布假设
Bayesian A/B	想随时看结果	可提前停止，直接给出"更好的概率"
CUPED	方差大的指标	利用实验前数据降方差 30-50%
SPRT（序贯检验）	想提前终止	中期分析不增加 α
MAB（多臂老虎机）	多组实验	自动把更多流量分配给好的变体

💡 推荐组合：CUPED（降方差）+ Bayesian A/B（灵活停止）+ Bootstrap（置信区间），这是 Agent 场景最实用的统计方法组合。

九、Agent A/B 实验的特殊陷阱

陷阱 1：环境状态污染

Agent 任务会修改环境（代码文件、数据库、配置），两次实验的环境起点不同，结果不可比。

• 示例：任务"重构 auth 模块"→ Agent A 执行后代码仓库变了 → Agent B 再执行起点已不同
• 对策：离线实验每次重放前重置环境（git reset --hard）；在线实验只做并行对比（两个用户独立环境）；记录环境快照事后对比

陷阱 2：Agent 交互的"学习效应"

用户和 Agent 配合 3-5 次后会学会"怎么和这个 Agent 配合"。实验组新 Agent 行为不同，用户需要重新学习——学习期内指标可能暂时偏低，但学会后可能更高。

• 对策：实验至少跑 2 周排除学习期影响；单独分析"前 3 次交互"和"第 4 次以后"的指标差异；如果"前 3 次差，后面好"→ 给实验组更多时间

陷阱 3：工具依赖的外部变化

Agent 依赖的外部 API 变化了（如 GitHub API 限流、文件系统权限变了），导致实验指标波动。

• 判断方法：检查同期系统级指标（API 延迟、错误率）；实验组和对照组同时波动 → 外部因素；只有实验组波动 → 实验组的问题

陷阱 4：SubAgent 的隐性成本

只看主 Agent 的费用，忽略了 SubAgent 的 Token 消耗。新策略创建了更多 SubAgent → 主 Agent 费用看起来没变，但总费用（主+所有 Sub）大幅增加。

• 对策：费用指标必须统计 Agent Tree 的总费用；单独看 SubAgent 的平均数量和平均费用

陷阱 5：成功率提升但"质量泡沫"

Agent 学会了"取巧"——降低输出质量换取更高成功率。比如让它"找出所有安全问题"，它只找了最明显的 2 个，返回成功，但漏掉了 3 个隐蔽的问题。

• 对策：不能只看成功率，必须同时看 Judge 质量评分；离线评测时检查"覆盖度"指标；人工抽检实验组的"成功"案例，确认是真高质量成功

十、总结

Agent A/B 实验的全链路核心原则：

一、指标体系

• 成功率是北极星，但需要 Judge 质量评分做交叉验证——成功率告诉你"事办没办成"，Judge 评分告诉你"事办得有多好"
• OEC 必须满足四要素：可度量、可归因、敏感、及时
• 死循环和危险操作是一票否决——Agent 的底线安全指标，不需要等 p < 0.05，出现一次就该查
• 护栏分三层：安全（一票否决）、质量（不允许劣化）、效率（可容忍范围）

二、实验设计

• AA 验证是 A/B 的前置条件——先证明分流系统可靠，再比较版本差异
• SRM 检验是实验健康检查——样本比例不对，结论一定有问题
• 随机化层级选对：任务级适合大多数场景，用户级适合长期观测
• Agent 实验的样本量需求比对话 A/B 大 2-3 倍，方差大是核心原因

三、数据基础设施

• Agent 必须在 SDK 层埋全链路事件（TASK_START → ... → TASK_END）
• 每个事件携带 experiment_id 和 variant，这是 A/B 对比的基础

四、数据分析与决策

• 离线 A/B 是 Agent 实验的特有步骤——先离线验证，再上线实验
• 假阳性浪费工程资源，假阴性错失有效优化——Agent 方差大，假阴性风险更高
• 多重检验要用 Benjamini-Hochberg 校正 FDR，而非 Bonferroni
• 反转实验是因果验证的最后一道防线——正实验说"好"不等于真的是这个改动导致的
• 实验数据要拆分看——简单任务和复杂任务、新用户和老用户可能结论相反

五、放量与上线

• L1/L2/L3 变更要有不同的放量节奏，高风险变更（L3）需要 4-6 周
• 不在周五下午放量；每阶段必须过安全 checklist
• 效率、费用的 trade-off 需要业务决策——+5% 成功率值不值 +40% 耗时，取决于你的用户场景

六、工具与生态

• 开箱即用：GrowthBook（实验管理）+ LangSmith（Agent trace）+ 自建指标管道
• 推荐统计方法：CUPED（降方差）+ Bayesian A/B（灵活停止）+ Bootstrap（置信区间）

💡 一句话总结：Agent A/B 实验不是"比较两个回答"，而是比较两套 Agent 系统在真实世界中的任务完成能力。它需要更严谨的实验设计（AA 验证 + SRM）、更全面的指标（OEC + 护栏 + 诊断）、更长的实验周期、以及更复杂的数据管道。但做好之后，你得到的不是"感觉更好了"，而是"显著 +4%，p<0.01，可以上线"。