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 results6.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）：
- 正实验：对照组（保守策略）vs 实验组（激进策略）→ 实验组成功率显著更高 → 上线激进策略
- 反转实验（上线后验证）：新基线组（当前激进策略）vs 反转组（改回保守策略）→ 预期反转组成功率下降
- 如果反转组的成功率确实下降了 → 确认是策略本身的作用 → 因果关系得到"反转验证"
- 如果反转组成功率没有下降 → 正实验的结论可能有问题 → 可能是周期效应、用户群体变化或其他外部因素
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 实验中的典型用法：
- 自动采集所有 Agent 执行 trace（带 experiment_id tag）
- 离线回放：用同一批任务，在两套配置下重放
- 对比 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，可以上线"。
 agent和组件)