如何对 Skill 进行 A B 测试？在 Agent 场景下与传统 Web 服务的 A B 测试有何不同？
“Skill 的 A/B 测试本质上也是在验证‘新版本是否比旧版本更好’，但因为 Agent 系统的链路长、非确定性输出多，所以不能直接把 Web 那套搬过来。我设计的方案分了四个关键步骤，每一步都得针对 Agent 的特性做调整。
第一步：定义测试单元和分流策略
传统 Web 通常是‘页面 A vs 页面 B’，分流按用户 ID 哈希。Skill 的 A/B 测试粒度更细，可能是一个 Skill 的两个版本，也可能是两个不同供应商的同功能 Skill，甚至是两种编排路径（比如‘先查天气再订机票’ vs ‘并行查天气和机票’）。
分流策略上，因为 Agent 场景里用户会多次和同一个 Skill 交互，为了保证体验一致性，同一会话内必须走同一个版本。所以分流键我会用用户 ID + 会话 ID 的组合哈希，确保回话中不跳变。
第二步：构建多维度评估指标
Web A/B 主要看转化率、点击率、页面停留时间。Skill 的评估得加上‘Agent 特色’的指标：
-
任务完成率：用户用这个 Skill 后，整个任务是否最终成功。这是最终极的北极星指标。
-
澄清轮次：Skill 为了确认参数反问用户的次数。轮次越少通常体验越好，但也不是越少越好——关键操作多一轮确认反而是加分项。
-
用户修正率：用户在拿到 Skill 输出后，立刻纠正或覆盖的比例。这个信号比‘踩’更即时。
-
可信度评分：Skill 返回结果时，校验层给出的分数。如果新版本可信度显著低于旧版本，即使任务没失败，也是质量下降。
-
用户留存和回用：用完后 24 小时内是否再次使用同类 Skill，反映长期价值。
-
成本指标：平均 token 消耗、API 调用费用。因为 Agent 里的 Skill 经常调用大模型，成本也是重要维度。
我把这些指标加权成一个综合得分，权重根据业务场景调整。比如交易类 Skill，任务完成率权重 50%；闲聊类 Skill，用户回用率权重 40%。
第三步：解决非确定性输出的评估问题
这是 Agent A/B 测试最难的地方。传统 Web 的输出是确定性的——同一请求返回同一页面，一眼看出差异。但 Skill 调用 LLM 时，同样的输入每次输出可能不同，你怎么知道新版本的‘好’不是随机波动？
我的做法是多维度自动化评估 + 人工抽样。
自动化评估包括：
-
结构合规率：新版本输出是否遵循声明的 JSON Schema。
-
事实一致性：如果 Skill 输出包含从数据库或 API 查到的数字（如价格、时间），直接和源头数据比对，不能错。
-
LLM 成对评判：用强模型（如 GPT-4）对两个版本的输出做盲评，在相同输入下，判断‘哪个回复更符合用户意图、更安全、更完整’。做 100 次盲评，统计胜率。
人工抽样则是每周从两个版本的执行日志中各抽 100 条，让标注团队按评分标准打分，验证自动化评估的准确性。
第四步：实验周期与统计显著性
传统 Web 大流量，一天就能跑出显著性。Agent Skill 的调用量可能没那么高，尤其是细分领域的 Skill，需要更长的实验期。我的底线是至少 200 次有效调用才做判断，并且用贝叶斯因子替代频繁的显著性检验，因为可以在实验过程中随时查看概率，而不需要等样本量达标才‘开盲’。