AI Agent A/B 实验深度解析上从实验设计到上线决策Agent 的 System Prompt 改了、工具配置变了、模型升级了——开发者说感觉更聪明了但你怎么用数据证明Agent 的 A/B 实验比普通 LLM 复杂得多不是比回答好不好而是比事有没有更靠谱地办成。这篇文章聚焦 AI Agent 场景的 A/B 实验全链路Agent 专属指标体系、实验设计含 SubAgent 和工具链变量、统计方法、决策流程。让数据和体验一起说话。一、Agent A/B 实验的特殊挑战Agent A/B 实验面临四个独特挑战1. 评测单元是任务而非回答——普通A/B对比两个版本对同一问题的回答质量Agent A/B 对比两个版本完成同一任务的成功率和效率。一次实验需要完整的 Agent 执行 trace而非单个对话轮次。2. Agent 执行路径不唯一——同一个任务Agent v1 用 3 步工具调用完成Agent v2 用了不同的工具组合 5 步完成。哪个更好需要多维度比较成功率和效率。3. SubAgent 让实验变量更复杂——主 Agent 的决策变了 → SubAgent 的创建时机、数量、prompt 都可能变化需要追踪整个 Agent Tree 而非单个 Agent。4. 质量与效率、成本的三角权衡——Agent v2 任务成功率 5%但平均耗时 40%。值不值得上线需要业务决策框架。对比维度对话 A/BAgent A/B评测单元单次问答完整任务执行核心指标回答质量 / 偏好率任务成功率 效率 费用实验时长3-7 天7-14 天方差更大样本量需求300-500/组500-1000/组评估方式LLM-Judge 对比Judge 成功率 trace分析二、Agent A/B 实验的指标体系2.1 北极星指标OEC设计原则要素要求反例 → 正例可度量(Measurable)每天、每个实验组都能稳定产出的数值指标用户体验更好 → 任务成功率可归因(Attributable)指标提升可归因到实验变更而非季节/外部因素月度收入 → Agent 任务成功率敏感(Sensitive)实验组真的更好时指标能检测到变化用户留存率 → 任务成功率 用户满意度NPS及时(Timely)每天或每几天就能计算不用等几周季度复购率 → 每日任务成功率关键洞察Agent 场景的北极星首选任务成功率因为它同时满足四要素——可度量每天统计、可归因主要由Agent行为决定、敏感实验组变了会很快反映、及时日常可观测。但成功率单独不够需要Judge 质量评分做交叉验证。常见错误代理指标 vs 真实北极星代理指标易度量但不一定对真实北极星直接衡量价值对话轮次越少越好 →以最少步骤完成任务用户停留时间越长越好 →任务是否一次性完成Agent 回复字数越多越好 →回复是否准确、无冗余Token 消耗越低越好 →在合理消耗下完成任务多目标场景的 OEC 组合方法方法公式优点缺点推荐度加权组合OEC 0.7 × 成功率 0.3 × 满意度单一数值容易比较权重是主观的主次指标主指标统计检验 次要指标方向验证灵活不强制打包需要主观判断推荐约束优化最大化成功率约束满意度 ≥ 基线有明确底线优化求解复杂2.2 护栏指标设计方法护栏类型判断标准典型指标触发动作Type 1安全护栏一票否决出现即终止死循环率 0%、危险操作率 0%、数据泄露不需等 p0.05出现一次就停止Type 2质量护栏不允许显著劣化工具选择准确率下降 5%、幻觉率上升 50%、输出格式错误率上升 10%需统计检验p0.05 触发告警Type 3效率护栏可容忍范围超出即告警任务平均耗时上升 30%、平均费用上升 50%、用户中断率上升 10%软护栏触发后需业务决策阈值设定两种方法方法一历史基线法推荐收集过去 4-8 周的指标数据计算均值 μ 和标准差 σ质量护栏μ ± 2σ约 95% 置信区间效率护栏μ ± 3σ允许更大波动示例过去 8 周工具选择准确率 μ88%、σ2.5% → 质量护栏阈值 88% - 2×2.5% 83%不能低于方法二业务可接受范围法与产品/业务方对齐设置绝对值阈值。如任务成功率绝对不能低于 70%不管基线多少费用不能超过 $0.50/任务。Agent 特有的护栏指标护栏指标类型阈值触发动作死循环率安全 0% 立即终止实验危险操作率安全 0% 立即终止实验工具滥用率质量↑ 20% 暂停放量分析原因幻觉率质量↑ 50% 暂停放量任务超时率效率↑ 20% 记录继续观察SubAgent 创建异常率安全 0 且 ≥ 3次 立即检查2.3 OEC 护栏 诊断三层架构2.4 核心 OEC 指标详解指标 1任务成功率Agent A/B 的北极星任务成功的三个必要条件① Agent 返回了结果没有死循环、超时、主动放弃② 结果可被用户直接使用无需人工重做核心部分③ 结果不包含危险操作或严重幻觉。判定示例任务修改 config 文件中的端口号为 8080Agent执行过程结果Agent Aread_file → edit_file → 返回成功 → 端口确实改了成功Agent Bread_file → 改了一个不存在的字段 → 返回成功结果不可用Agent Cread_file → search_file → search_file → ... → 死循环未完成比较方式success_rate_exp 实验组成功任务数 / 实验组总任务数success_rate_ctrl 对照组成功任务数 / 对照组总任务数lift success_rate_exp - success_rate_ctrllift 0 且统计显著 → 实验组更好 lift ≈ 0 → 无差异lift 0 且统计显著 → 实验组更差指标 2结果质量评分LLM-as-Judge即使两个 Agent 都成功了输出质量也可能不同。Judge 评判 PromptAgent专用 以下是两个Agent完成相同任务的结果和完整执行trace。 请从以下维度比较 1. 结果质量哪个Agent的最终输出更准确、更完整、更可用 2. 执行效率哪个Agent用了更少的步骤完成任务 3. 错误处理哪个Agent在遇到问题时处理得更好 任务{task_instruction} Agent A 的执行trace和结果{agent_a_trace_and_output} Agent B 的执行trace和结果{agent_b_trace_and_output} 整体判断A更好 / B更好 / 无差异胜率计算exp_win_rate 实验组获胜次数 / 总比较次数。注意需要做位置偏差修正AB和BA各判一次。指标 3效率-成功率比Agent 特有场景Agent v2 成功率高 3%但每个任务多花 40% 的时间。要不要上决策参考效率-成功率比建议成功率 5%, 耗时 10% → 比率 0.50 0.3通常值得上线成功率 3%, 耗时 40% → 比率 0.0750.1 - 0.3结合场景判断成功率 1%, 耗时 50% → 比率 0.02 0.1除非绝对值很重要否则不值得2.5 护栏指标详解Agent 专属护栏指标判断标准处理方式死循环率实验组 0%一票否决立即终止实验不需等统计显著危险操作率实验组出现任何危险操作rm -rf / drop table / force push立即终止即使对照组也有实验组不能新增工具选择准确率下降 5%暂停实验分析原因允许 ±3% 轻微波动任务平均完成时间简单任务 5步超基线 2x复杂任务 10步超基线 1.5x耗时超基线任务占比 50%触发告警费用/任务费用翻倍但成功率 20% → 可能值得费用翻倍但成功率 2% → 不值得作为决策参考而非硬拦住三、实验组与对照组设计在 Agent A/B 实验中实验组和对照组如何分配、如何验证分流的正确性是整个实验可信度的基石。3.1 随机化单元选择层级方式优点代价/条件适用场景任务级推荐每个独立任务随机分配到对照组或实验组样本量最大化用户异质性影响小任务间需高度独立不改变共享环境状态90% 的 Agent 实验场景用户级每个用户固定分配到一组避免同一用户感受不同行为的困惑适合观察长期指标需要更大样本量实验周期更长Agent 结果会持久化用户对风格变化敏感会话级每次用户会话随机分配3.2 AA 验证先证明系统可靠关键洞察在 A/B 实验之前先做 AA 实验——将流量分成两组但两组使用完全相同的配置。AA 实验中任何指标出现显著差异都说明你的分流系统、度量管道或统计方法有问题。AA 验证操作流程设置分流将 100% 流量使用当前 Agent 版本随机分成A 组50%和B 组50%两组看到的 Agent 完全相同收集数据运行 3-7 天收集 ≥ 500/组样本追踪所有核心指标统计检验对所有核心指标做显著性检验。预期所有指标的 p-value 0.05无显著差异判断 通过所有指标 p 0.05 → 分流系统可靠 失败任意核心指标 p 0.05 → 排查分流算法 bug、数据管道漏数/重复、两组用户不同质、实验天数太短重复验证如果 AA 失败 → 修复问题 → 重新 AA → 直到通过。 不通过 AA 验证的 A/B 实验结果不可信3.3 SRM 检验与分流均匀性SRMSample Ratio Mismatch样本比例不匹配检验如果正确分流两组样本数应接近预设比例如 50:50。如果实际偏离严重 → 分流系统有问题。检验方法卡方检验预设比例 50:50预期两组各 N/2。实际实验组 n₁对照组 n₂。χ² (n₁ - N/2)² / (N/2) (n₂ - N/2)² / (N/2)。p-value 0.01 → SRM 告警实验数据不可信。常见 SRM 原因① 分流代码 bug如哈希不均匀② 实验组有更多错误导致任务丢失③ 数据管道对某一组采集有遗漏④ 用户主动逃逸实验组体验差放弃任务。Agent 场景特有的 SRM 风险实验组死循环/超时 → 任务未完成 → 不计入数据危险操作被拦截 → 任务中断 → 样本丢失。必须区分分流不均和实验组真的产生了更少完整任务。分层抽样保证两组任务分布一致。即使分流均匀两组任务类型分布也可能不同。解决方案按任务类型分层code / search / file / multi-tool每层内独立随机分流保证每层两组比例 50:50分析时分层计算指标、加权汇总。3.4 样本量与实验时长# Agent 任务成功率 A/B 的样本量计算 import numpy as np from scipy import stats def agent_ab_sample_size(baseline_rate, mde, alpha0.05, power0.80): baseline_rate: 当前 Agent 的任务成功率如 0.75 mde: 最小可检测效应量如想检出 5% 的提升 z_alpha stats.norm.ppf(1 - alpha / 2) # 1.96 z_beta stats.norm.ppf(power) # 0.84 p1 baseline_rate p2 baseline_rate mde p_bar (p1 p2) / 2 n (z_alpha * np.sqrt(2 * p_bar * (1 - p_bar)) z_beta * np.sqrt(p1 * (1 - p1) p2 * (1 - p2)))**2 / mde**2 return int(np.ceil(n))经验法则Agent 场景检出效应量需样本量/组实验时长建议3% 成功率差异1500-2500最少 1 周推荐 2 周5% 成功率差异500-1200最少 1 周10% 成功率差异150-3501 周为什么 Agent 实验需要比对话实验更长Agent 任务的成功需要更多步骤方差更大用户对 Agent 质量的感知有滞后环境变化代码仓库更新、工具 API 变动可能引入噪声。实际工作判断每天 100 Agent 任务 → 检出 5% 差异需 1-2 周每天 50-100 Agent 任务 → 考虑降低预期到 8-10%或拉长周期每天 20 Agent 任务 → 不建议在线 A/B以离线评测为主四、埋点、采集与度量体系设计没有正确的埋点和数据采集A/B 实验就是盲人摸象。4.1 Agent 执行链路埋点事件设计Agent 完整执行链路的事件流所有事件共享的最小 schema字段类型说明event_idstring唯一事件 IDtimestampint64毫秒时间戳event_typestring事件类型枚举experiment_idstring实验 IDvariantcontrol | treatment对照组/实验组agent_idstringAgent 实例 IDtask_idstring任务 ID关联所有同一任务的事件parent_span_idstring父 span ID构建调用树user_idstring用户匿名 IDmetadataobject事件特定的附加数据关键事件详细 SchemaTASK_START额外字段类型说明task_typecode_gen | search | file_op | multi_tool任务类型task_complexitysimple | medium | complex预估复杂度input_prompt_lengthint用户输入长度字符context_sizeint上下文窗口使用量tokenTASK_END额外字段类型说明successboolean任务是否成功最核心字段failure_reasonstring | nulldead_loop | timeout | tool_error | user_aborttotal_stepsint总步数total_tool_callsint工具调用总次数total_subagentsintSubAgent 创建次数total_tokensint消耗的总 tokentotal_costfloat总费用美元wall_time_msint端到端耗时毫秒user_regradethumbs_up | thumbs_down | null用户反馈TOOL_CALL_END额外字段类型说明tool_namestring工具名tool_call_successboolean工具调用是否成功tool_latency_msint工具响应耗时tool_errorstring | null工具错误信息SUBAGENT_CREATE额外字段类型说明subagent_typestringSubAgent 类型subagent_promptstring传给 SubAgent 的指令parent_reasonstring创建原因4.2 数据采集管道推荐数据管道架构关键设计原则事件幂等event_id 去重支持至少一次语义延迟标记采集时间 vs 事件时间分开记录实验分流信息必须在最上游携带Agent SDK 层所有事件必须携带 experiment_id 和 variant4.3 指标计算与实时看板计算方式公式用途累积值累计成功数 ÷ 累计总数随时间收敛适合判断最终结论滑动窗口值最近 24h 成功数 ÷ 最近 24h 总数反映当前状态适合发现问题每日值当天成功数 ÷ 当天总数观察每日波动排除周期效应计算频率核心指标成功率、死循环率每 5 分钟刷新辅助指标费用、耗时每 1 小时刷新诊断指标每日 T1 产出。实时看板设计指标对照组实验组Lift趋势任务成功率78%82% 4% 持续上升Judge胜率48%55% 7% 稳定死循环次数00 —→危险操作00 —→平均步骤数5.24.8 -8% 下降中平均耗时45s38s -16%平均费用$0.12$0.10 -17%用户中断率8%6% -2%告警配置 P0死循环 0 / 危险操作 0 / 成功率骤降 10%→ 立即告警 P1成功率 ↓ 5% / 错误率 ↑ 50%→ 1 小时内 P2费用 ↑ 30% / 耗时 ↑ 30%→ 下个工作日。五、Agent A/B 实验设计5.1 常见实验场景场景对照组实验组OEC样本量/组时长Prompt 变更最常见当前 System Prompt优化后的 Prompt成功率 Judge 评分500-8001-2 周模型版本升级当前模型新模型成功率 Judge 评分 费用800-10002 周工具集变更当前工具集新增/移除/替换工具工具选择准确率 成功率500-8001-2 周SubAgent 策略变更当前策略如默认不并行新策略如自动判断并行成功率 平均完成时间800-10002 周上下文策略变更当前上下文管理策略不同的 memory/SKILL 加载策略成功率 Token 消耗5.2 离线 A/B实验前的第一道关卡强烈建议线上 A/B 之前先做离线 A/B。离线 Agent A/B 的做法从线上 Agent 日志中抽样 500-1000 个真实任务在隔离环境中用对照组和实验组分别重放这些任务用 LLM-as-Judge 评判两组的结果和执行 trace如果离线结果已经在劣化 → 不需要上线实验省时省风险如果离线显著提升 → 上线做在线 A/B 验证真实用户行为离线 A/B 可以比的指标 任务成功率、Judge 评分、工具选择准确率、平均步骤数/耗时预估/费用预估。 用户满意度必须线上测、任务完成后的留存必须线上测。
AI Agent A/B 实验深度解析上从实验设计到上线决策Agent 的 System Prompt 改了、工具配置变了、模型升级了——开发者说感觉更聪明了但你怎么用数据证明Agent 的 A/B 实验比普通 LLM 复杂得多不是比回答好不好而是比事有没有更靠谱地办成。这篇文章聚焦 AI Agent 场景的 A/B 实验全链路Agent 专属指标体系、实验设计含 SubAgent 和工具链变量、统计方法、决策流程。让数据和体验一起说话。一、Agent A/B 实验的特殊挑战Agent A/B 实验面临四个独特挑战1. 评测单元是任务而非回答——普通A/B对比两个版本对同一问题的回答质量Agent A/B 对比两个版本完成同一任务的成功率和效率。一次实验需要完整的 Agent 执行 trace而非单个对话轮次。2. Agent 执行路径不唯一——同一个任务Agent v1 用 3 步工具调用完成Agent v2 用了不同的工具组合 5 步完成。哪个更好需要多维度比较成功率和效率。3. SubAgent 让实验变量更复杂——主 Agent 的决策变了 → SubAgent 的创建时机、数量、prompt 都可能变化需要追踪整个 Agent Tree 而非单个 Agent。4. 质量与效率、成本的三角权衡——Agent v2 任务成功率 5%但平均耗时 40%。值不值得上线需要业务决策框架。对比维度对话 A/BAgent A/B评测单元单次问答完整任务执行核心指标回答质量 / 偏好率任务成功率 效率 费用实验时长3-7 天7-14 天方差更大样本量需求300-500/组500-1000/组评估方式LLM-Judge 对比Judge 成功率 trace分析二、Agent A/B 实验的指标体系2.1 北极星指标OEC设计原则要素要求反例 → 正例可度量(Measurable)每天、每个实验组都能稳定产出的数值指标用户体验更好 → 任务成功率可归因(Attributable)指标提升可归因到实验变更而非季节/外部因素月度收入 → Agent 任务成功率敏感(Sensitive)实验组真的更好时指标能检测到变化用户留存率 → 任务成功率 用户满意度NPS及时(Timely)每天或每几天就能计算不用等几周季度复购率 → 每日任务成功率关键洞察Agent 场景的北极星首选任务成功率因为它同时满足四要素——可度量每天统计、可归因主要由Agent行为决定、敏感实验组变了会很快反映、及时日常可观测。但成功率单独不够需要Judge 质量评分做交叉验证。常见错误代理指标 vs 真实北极星代理指标易度量但不一定对真实北极星直接衡量价值对话轮次越少越好 →以最少步骤完成任务用户停留时间越长越好 →任务是否一次性完成Agent 回复字数越多越好 →回复是否准确、无冗余Token 消耗越低越好 →在合理消耗下完成任务多目标场景的 OEC 组合方法方法公式优点缺点推荐度加权组合OEC 0.7 × 成功率 0.3 × 满意度单一数值容易比较权重是主观的主次指标主指标统计检验 次要指标方向验证灵活不强制打包需要主观判断推荐约束优化最大化成功率约束满意度 ≥ 基线有明确底线优化求解复杂2.2 护栏指标设计方法护栏类型判断标准典型指标触发动作Type 1安全护栏一票否决出现即终止死循环率 0%、危险操作率 0%、数据泄露不需等 p0.05出现一次就停止Type 2质量护栏不允许显著劣化工具选择准确率下降 5%、幻觉率上升 50%、输出格式错误率上升 10%需统计检验p0.05 触发告警Type 3效率护栏可容忍范围超出即告警任务平均耗时上升 30%、平均费用上升 50%、用户中断率上升 10%软护栏触发后需业务决策阈值设定两种方法方法一历史基线法推荐收集过去 4-8 周的指标数据计算均值 μ 和标准差 σ质量护栏μ ± 2σ约 95% 置信区间效率护栏μ ± 3σ允许更大波动示例过去 8 周工具选择准确率 μ88%、σ2.5% → 质量护栏阈值 88% - 2×2.5% 83%不能低于方法二业务可接受范围法与产品/业务方对齐设置绝对值阈值。如任务成功率绝对不能低于 70%不管基线多少费用不能超过 $0.50/任务。Agent 特有的护栏指标护栏指标类型阈值触发动作死循环率安全 0% 立即终止实验危险操作率安全 0% 立即终止实验工具滥用率质量↑ 20% 暂停放量分析原因幻觉率质量↑ 50% 暂停放量任务超时率效率↑ 20% 记录继续观察SubAgent 创建异常率安全 0 且 ≥ 3次 立即检查2.3 OEC 护栏 诊断三层架构2.4 核心 OEC 指标详解指标 1任务成功率Agent A/B 的北极星任务成功的三个必要条件① Agent 返回了结果没有死循环、超时、主动放弃② 结果可被用户直接使用无需人工重做核心部分③ 结果不包含危险操作或严重幻觉。判定示例任务修改 config 文件中的端口号为 8080Agent执行过程结果Agent Aread_file → edit_file → 返回成功 → 端口确实改了成功Agent Bread_file → 改了一个不存在的字段 → 返回成功结果不可用Agent Cread_file → search_file → search_file → ... → 死循环未完成比较方式success_rate_exp 实验组成功任务数 / 实验组总任务数success_rate_ctrl 对照组成功任务数 / 对照组总任务数lift success_rate_exp - success_rate_ctrllift 0 且统计显著 → 实验组更好 lift ≈ 0 → 无差异lift 0 且统计显著 → 实验组更差指标 2结果质量评分LLM-as-Judge即使两个 Agent 都成功了输出质量也可能不同。Judge 评判 PromptAgent专用 以下是两个Agent完成相同任务的结果和完整执行trace。 请从以下维度比较 1. 结果质量哪个Agent的最终输出更准确、更完整、更可用 2. 执行效率哪个Agent用了更少的步骤完成任务 3. 错误处理哪个Agent在遇到问题时处理得更好 任务{task_instruction} Agent A 的执行trace和结果{agent_a_trace_and_output} Agent B 的执行trace和结果{agent_b_trace_and_output} 整体判断A更好 / B更好 / 无差异胜率计算exp_win_rate 实验组获胜次数 / 总比较次数。注意需要做位置偏差修正AB和BA各判一次。指标 3效率-成功率比Agent 特有场景Agent v2 成功率高 3%但每个任务多花 40% 的时间。要不要上决策参考效率-成功率比建议成功率 5%, 耗时 10% → 比率 0.50 0.3通常值得上线成功率 3%, 耗时 40% → 比率 0.0750.1 - 0.3结合场景判断成功率 1%, 耗时 50% → 比率 0.02 0.1除非绝对值很重要否则不值得2.5 护栏指标详解Agent 专属护栏指标判断标准处理方式死循环率实验组 0%一票否决立即终止实验不需等统计显著危险操作率实验组出现任何危险操作rm -rf / drop table / force push立即终止即使对照组也有实验组不能新增工具选择准确率下降 5%暂停实验分析原因允许 ±3% 轻微波动任务平均完成时间简单任务 5步超基线 2x复杂任务 10步超基线 1.5x耗时超基线任务占比 50%触发告警费用/任务费用翻倍但成功率 20% → 可能值得费用翻倍但成功率 2% → 不值得作为决策参考而非硬拦住三、实验组与对照组设计在 Agent A/B 实验中实验组和对照组如何分配、如何验证分流的正确性是整个实验可信度的基石。3.1 随机化单元选择层级方式优点代价/条件适用场景任务级推荐每个独立任务随机分配到对照组或实验组样本量最大化用户异质性影响小任务间需高度独立不改变共享环境状态90% 的 Agent 实验场景用户级每个用户固定分配到一组避免同一用户感受不同行为的困惑适合观察长期指标需要更大样本量实验周期更长Agent 结果会持久化用户对风格变化敏感会话级每次用户会话随机分配3.2 AA 验证先证明系统可靠关键洞察在 A/B 实验之前先做 AA 实验——将流量分成两组但两组使用完全相同的配置。AA 实验中任何指标出现显著差异都说明你的分流系统、度量管道或统计方法有问题。AA 验证操作流程设置分流将 100% 流量使用当前 Agent 版本随机分成A 组50%和B 组50%两组看到的 Agent 完全相同收集数据运行 3-7 天收集 ≥ 500/组样本追踪所有核心指标统计检验对所有核心指标做显著性检验。预期所有指标的 p-value 0.05无显著差异判断 通过所有指标 p 0.05 → 分流系统可靠 失败任意核心指标 p 0.05 → 排查分流算法 bug、数据管道漏数/重复、两组用户不同质、实验天数太短重复验证如果 AA 失败 → 修复问题 → 重新 AA → 直到通过。 不通过 AA 验证的 A/B 实验结果不可信3.3 SRM 检验与分流均匀性SRMSample Ratio Mismatch样本比例不匹配检验如果正确分流两组样本数应接近预设比例如 50:50。如果实际偏离严重 → 分流系统有问题。检验方法卡方检验预设比例 50:50预期两组各 N/2。实际实验组 n₁对照组 n₂。χ² (n₁ - N/2)² / (N/2) (n₂ - N/2)² / (N/2)。p-value 0.01 → SRM 告警实验数据不可信。常见 SRM 原因① 分流代码 bug如哈希不均匀② 实验组有更多错误导致任务丢失③ 数据管道对某一组采集有遗漏④ 用户主动逃逸实验组体验差放弃任务。Agent 场景特有的 SRM 风险实验组死循环/超时 → 任务未完成 → 不计入数据危险操作被拦截 → 任务中断 → 样本丢失。必须区分分流不均和实验组真的产生了更少完整任务。分层抽样保证两组任务分布一致。即使分流均匀两组任务类型分布也可能不同。解决方案按任务类型分层code / search / file / multi-tool每层内独立随机分流保证每层两组比例 50:50分析时分层计算指标、加权汇总。3.4 样本量与实验时长# Agent 任务成功率 A/B 的样本量计算 import numpy as np from scipy import stats def agent_ab_sample_size(baseline_rate, mde, alpha0.05, power0.80): baseline_rate: 当前 Agent 的任务成功率如 0.75 mde: 最小可检测效应量如想检出 5% 的提升 z_alpha stats.norm.ppf(1 - alpha / 2) # 1.96 z_beta stats.norm.ppf(power) # 0.84 p1 baseline_rate p2 baseline_rate mde p_bar (p1 p2) / 2 n (z_alpha * np.sqrt(2 * p_bar * (1 - p_bar)) z_beta * np.sqrt(p1 * (1 - p1) p2 * (1 - p2)))**2 / mde**2 return int(np.ceil(n))经验法则Agent 场景检出效应量需样本量/组实验时长建议3% 成功率差异1500-2500最少 1 周推荐 2 周5% 成功率差异500-1200最少 1 周10% 成功率差异150-3501 周为什么 Agent 实验需要比对话实验更长Agent 任务的成功需要更多步骤方差更大用户对 Agent 质量的感知有滞后环境变化代码仓库更新、工具 API 变动可能引入噪声。实际工作判断每天 100 Agent 任务 → 检出 5% 差异需 1-2 周每天 50-100 Agent 任务 → 考虑降低预期到 8-10%或拉长周期每天 20 Agent 任务 → 不建议在线 A/B以离线评测为主四、埋点、采集与度量体系设计没有正确的埋点和数据采集A/B 实验就是盲人摸象。4.1 Agent 执行链路埋点事件设计Agent 完整执行链路的事件流所有事件共享的最小 schema字段类型说明event_idstring唯一事件 IDtimestampint64毫秒时间戳event_typestring事件类型枚举experiment_idstring实验 IDvariantcontrol | treatment对照组/实验组agent_idstringAgent 实例 IDtask_idstring任务 ID关联所有同一任务的事件parent_span_idstring父 span ID构建调用树user_idstring用户匿名 IDmetadataobject事件特定的附加数据关键事件详细 SchemaTASK_START额外字段类型说明task_typecode_gen | search | file_op | multi_tool任务类型task_complexitysimple | medium | complex预估复杂度input_prompt_lengthint用户输入长度字符context_sizeint上下文窗口使用量tokenTASK_END额外字段类型说明successboolean任务是否成功最核心字段failure_reasonstring | nulldead_loop | timeout | tool_error | user_aborttotal_stepsint总步数total_tool_callsint工具调用总次数total_subagentsintSubAgent 创建次数total_tokensint消耗的总 tokentotal_costfloat总费用美元wall_time_msint端到端耗时毫秒user_regradethumbs_up | thumbs_down | null用户反馈TOOL_CALL_END额外字段类型说明tool_namestring工具名tool_call_successboolean工具调用是否成功tool_latency_msint工具响应耗时tool_errorstring | null工具错误信息SUBAGENT_CREATE额外字段类型说明subagent_typestringSubAgent 类型subagent_promptstring传给 SubAgent 的指令parent_reasonstring创建原因4.2 数据采集管道推荐数据管道架构关键设计原则事件幂等event_id 去重支持至少一次语义延迟标记采集时间 vs 事件时间分开记录实验分流信息必须在最上游携带Agent SDK 层所有事件必须携带 experiment_id 和 variant4.3 指标计算与实时看板计算方式公式用途累积值累计成功数 ÷ 累计总数随时间收敛适合判断最终结论滑动窗口值最近 24h 成功数 ÷ 最近 24h 总数反映当前状态适合发现问题每日值当天成功数 ÷ 当天总数观察每日波动排除周期效应计算频率核心指标成功率、死循环率每 5 分钟刷新辅助指标费用、耗时每 1 小时刷新诊断指标每日 T1 产出。实时看板设计指标对照组实验组Lift趋势任务成功率78%82% 4% 持续上升Judge胜率48%55% 7% 稳定死循环次数00 —→危险操作00 —→平均步骤数5.24.8 -8% 下降中平均耗时45s38s -16%平均费用$0.12$0.10 -17%用户中断率8%6% -2%告警配置 P0死循环 0 / 危险操作 0 / 成功率骤降 10%→ 立即告警 P1成功率 ↓ 5% / 错误率 ↑ 50%→ 1 小时内 P2费用 ↑ 30% / 耗时 ↑ 30%→ 下个工作日。五、Agent A/B 实验设计5.1 常见实验场景场景对照组实验组OEC样本量/组时长Prompt 变更最常见当前 System Prompt优化后的 Prompt成功率 Judge 评分500-8001-2 周模型版本升级当前模型新模型成功率 Judge 评分 费用800-10002 周工具集变更当前工具集新增/移除/替换工具工具选择准确率 成功率500-8001-2 周SubAgent 策略变更当前策略如默认不并行新策略如自动判断并行成功率 平均完成时间800-10002 周上下文策略变更当前上下文管理策略不同的 memory/SKILL 加载策略成功率 Token 消耗5.2 离线 A/B实验前的第一道关卡强烈建议线上 A/B 之前先做离线 A/B。离线 Agent A/B 的做法从线上 Agent 日志中抽样 500-1000 个真实任务在隔离环境中用对照组和实验组分别重放这些任务用 LLM-as-Judge 评判两组的结果和执行 trace如果离线结果已经在劣化 → 不需要上线实验省时省风险如果离线显著提升 → 上线做在线 A/B 验证真实用户行为离线 A/B 可以比的指标 任务成功率、Judge 评分、工具选择准确率、平均步骤数/耗时预估/费用预估。 用户满意度必须线上测、任务完成后的留存必须线上测。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
