Agent 的 A/B 测试和 Shadow 测试怎么做
1️⃣ 考察意图
面试官想看你能否设计 Agent 系统的在线测试策略。刁钻点在于：Agent 的输出质量不像传统软件可以用"成功率"单一指标衡量——需要多维评估（任务完成率、安全性、用户满意度、成本），而且 Agent 的长链路特性使得 A/B 测试的样本量计算更复杂。答好了能展示你的实验设计能力和数据驱动决策思维。
2️⃣ 标准答
Agent 在线测试有三种模式，适用于不同场景：
1. A/B 测试：对比两个版本的线上表现
- 流量分配：按用户 ID 哈希分流（如
hash(user_id) % 100 < 50→ A 组，否则 B 组）。确保同一用户始终在同一组，避免体验不一致 - 评估指标（多维，不能只看单一指标）：任务完成率（Task Success Rate）：用户是否完成了目标任务。用自动化判断（如工具调用是否成功）+ 人工抽样
- 平均交互轮数（Conversation Turns）：完成任务的轮数。轮数少可能意味着效率高，也可能意味着 Agent 过早给出答案（质量下降）
- 用户满意度（CSAT/NPS）：对话结束后弹出评分。注意幸存者偏差——只有完成任务的用户才会评分
- 安全性指标：拒绝率（危险操作被拒绝的比例）、误拒率（正常操作被误拒的比例）
- 成本指标：每次任务的 token 消耗、工具调用次数、总推理成本 样本量计算：Agent 任务完成率通常在 70-90%。要检测 5% 的差异（如 80% → 85%），显著性水平 0.05，功效 0.8，需要约 1000 次/组。如果日活 10000，A/B 测试需要 2 天陷阱：
- Simpson's Paradox：整体看 B 组更好，但分用户群看 A 组更好。需要按用户群（新/老用户、不同场景）做分层分析
- Novelty Effect：B 组初期表现好是因为用户觉得新鲜，长期效果可能衰减。需要跑至少 1-2 周看趋势是否稳定
2. Shadow 测试：新版本接收真实流量但不返回给用户
- 原理：用户请求同时发给 A 版本（线上版本）和 B 版本（候选版本）。A 的输出返回给用户，B 的输出只记录用于对比。用户无感知
- 优势：零用户体验风险——B 版本即使有严重 bug 也不影响用户。可以测试 100% 流量而非 50%
- 实现：
用户请求 → A 版本 → 返回用户 ↘ B 版本 → 记录输出（不返回）用消息队列异步执行 B 版本，避免增加用户延迟 - B 版本的工具调用用 Mock（不能真的发邮件/删数据），或执行在沙箱中 对比维度：
- 输出一致性：A 和 B 的输出在语义上是否一致（embedding 相似度）
- 行为一致性：工具调用序列是否相同
- 质量差异：LLM-as-Judge 评分对比
- 成本差异：token 消耗对比
3. Canary 发布：渐进式流量切换
- 策略：1% → 5% → 25% → 50% → 100%。每个阶段观察 4-24 小时
- 自动回滚：设定核心指标阈值（如任务完成率 <70%、P99 延迟 >10s、错误率 >5%），触发阈值自动回滚到上一版本
- Canary 的 Agent 特殊考虑：Agent 的错误可能延迟暴露——用户在第 1 步没发现问题，但第 10 步才发现 Agent 的规划错误。需要延长观察时间
- 多 Agent 系统的 Canary 更复杂——Orchestrator 和 Worker 可以分别 Canary，但需要考虑版本兼容性
3️⃣ 答题模板（30 秒电梯版）
"Agent 在线测试三种模式。A/B 测试：按用户ID哈希分流，多维评估（任务完成率+交互轮数+CSAT+安全性+成本），检测5%差异需1000次/组，注意Simpson悖论和Novelty效应。Shadow测试：新版本接收真实流量但不返回用户，用Mock工具+沙箱执行，零风险测试100%流量，对比输出一致性和质量差异。Canary发布：1%→5%→25%→50%→100%渐进切换，设自动回滚阈值，Agent错误可能延迟暴露需延长观察时间。"
4️⃣ 高频追问 & 应对
追问 1：Shadow 测试中 B 版本的工具调用用 Mock，但如果 Mock 行为和真实工具不一致怎么办？
三种方案：(1) 录制-回放 Mock——从生产环境录制工具的真实返回值，Shadow 测试时用录制的返回值而非 Mock。保证数据真实性，但需要定期更新录制数据；(2) 影子工具——工具的真实执行在沙箱中进行（如发邮件到测试邮箱而非真实收件人），返回值与真实工具一致但无副作用。成本较高但最真实；(3) 双写模式——工具调用真实执行（如真的查询数据库），但写操作只写到影子库（不影响生产数据）。读操作可以真实执行，写操作用影子库。选择标准：读操作用双写模式（最真实），写操作用录制-回放（最安全）。
追问 2：Agent 的 A/B 测试周期比传统软件长，怎么缩短？
三个加速策略：(1) 分层 A/B——不是对整个 Agent 做 A/B，而是对单个组件（如 RAG 检索策略、prompt template、工具选择逻辑）做 A/B。组件级别的差异更容易检测，样本量需求更小（约 200 次/组）；(2) 离线预筛 + 在线确认——先用回放测试在离线环境筛选出"有改进"的版本，再放到线上做小流量 A/B 确认。离线预筛可以跑 10000 次（无成本），线上确认只需 200 次；(3) 自适应实验——用 Multi-Armed Bandit 替代固定分流 A/B。Bandit 会自动把更多流量分配给表现好的版本，减少"差版本"的曝光量。实测 Bandit 比 A/B 节省 30-50% 的样本量。
追问 3：多 Agent 系统的 A/B 测试怎么做？如果 Orchestrator 升级了但 Worker 没升级，会不会有兼容性问题？
兼容性是多 Agent A/B 的核心挑战。方案：(1) 版本契约——Orchestrator 和 Worker 之间定义 API 契约（如 protobuf schema），只要契约不变就可以独立升级。A/B 测试时 Orchestrator 新版本与 Worker 旧版本通信，只要契约兼容就不会出问题；(2) 整条链路 Canary——不是单独对 Orchestrator 做 Canary，而是对"Orchestrator + Worker"组合做 Canary。1% 流量同时切换到新版 Orchestrator 和新版 Worker。代价是回滚范围更大，但避免了兼容性问题；(3) 兼容性测试——CI/CD 中自动测试"新版本 Orchestrator + 旧版本 Worker"和"旧版本 Orchestrator + 新版本 Worker"的组合，确保向前和向后兼容。推荐方案：小团队用整条链路 Canary（简单可靠），大团队用版本契约（灵活性高）。
5️⃣ 避坑 · 常见错误答法
- ❌ "A/B 测试看任务完成率就够了" → ✅ "Agent 质量是多维的——任务完成率可能提升但安全性下降（Agent 更激进地执行操作），或成本上升（更多工具调用）。需要多维指标综合评估。"
- ❌ "Shadow 测试可以完全替代 A/B 测试" → ✅ "Shadow 测试不能评估用户体验——B 版本的输出不返回给用户，无法测量用户满意度和行为变化。Shadow 适合'安全验证'，A/B 适合'效果验证'。"
- ❌ "Canary 发布 1% 跑 1 小时没问题就可以全量" → ✅ "Agent 的错误可能延迟暴露——用户在多轮交互中才发现问题。Canary 每个阶段至少观察 4-24 小时，特别关注长程任务的完成率。"
6️⃣ 简历呼应
- 如果你有 Agent 实验平台项目：从"A/B 测试平台建设"切入，描述你设计的多维评估体系、Shadow 测试 pipeline、Canary 自动回滚机制，给出数据（如实验周期缩短 40%、回滚准确率 95%）
- 如果你只做过传统 A/B 测试：用"Web A/B 测试"迁移，说明分流失策、样本量计算、Simpson 悖论等概念直接适用。Agent 特有的是"长链路评估"和"Shadow 测试中的 Mock 工具"问题
- 如果你是校招无项目：设计一个 Agent A/B 测试框架，实现多维指标采集+Shadow 测试+自动 Diff 报告，用模拟数据演示实验设计和结果分析
- "Experimentation in AI Systems: Challenges and Best Practices" (Kohavi et al., 2024)
- "Trustworthy Online Controlled Experiments" (Kohavi et al., 2020)
- "Testing LLM Systems: A Multi-Dimensional Approach" (Truera, 2024)