这周有两篇论文连起来看不太舒服：一篇说 LLM agent 能改自己的执行 trace，另一篇说在普通任务压力下 agent 会主动绕开监控。叠在一起意思很直白——你拿来算 A/B 的那份数据，是被测量对象自己产出的。我现在设计实验，第一件事是判断仪表盘可不可信，第二件才是分组。
先花两周只观测，不分组
传统功能的 A/B 好做，是因为指标稳。按钮颜色的转化率今天是 3%，明天还是 3%，样本量算出来就能用。Agent 不是。同一条 prompt、同一个模型版本，因为工具返回格式、重试次数、上下文长度，同一个任务的完成率能上下抖。你要是不先把这个抖动量出来，四周实验跑完，两组之间的差异可能全在噪音带里。
我的做法是开实验前先跑一段纯观测：一个版本，不加任何变量，每天记同一个指标，看它自己波动多大。波动大到盖过你想分辨的那点差异，这个指标就不能当主指标，或者得换更粗的粒度。这一步没做就直接开分组，等于在读噪音。
用户会适应，第八周和第一周不是一个实验
坑二更阴。用户第一次见到 agent 会试探，会写很长的 prompt，会在它做错的时候立刻接手；用熟之后行为完全变了，prompt 短了，接手更早，或者干脆不用了。这周 HN 上有个帖子讲 Claude Code 只有在遥测打开时才读 AGENTS.md——连读不读配置文件这种事都能被一个开关影响。用户行为在四周里保持恒定？我不信。
所以用户适应本身就是结果的一部分，不是要洗掉的噪音。前两周数据好看，很可能只是新鲜感。
反面：那就不测了？
有人会顺着上面两条推：Agent 别做 A/B 了，凭感觉上线。这个我不接受。
有些东西还是能测的，关键是把实验对象切小。工具调用走不走某条固定路径、检索取几条、路由规则怎么分——这类子流程方差小、量大，短周期实验照样能读出结论。HEXIS 那篇把技能编译成扩展有限状态机，就是这个思路：先把控制流做成确定的，剩下的不确定部分才好测。真正做不了短周期 A/B 的是端到端整体体验，别把这两件事混在一起。
Screen Before You Serve 讲的是另一条路，上线前用模拟筛，规模到 140M 那种。模拟替代不了线上数据，但能把明显不行的版本挡在实验之前，省掉一半 A/B 轮次。
四周起步，主指标选「无人工介入完成率」
我现在的默认配置：至少四周，主指标是「无人工介入完成率」——一次会话里用户从头到尾没插手，任务才算成。这个指标把「agent 自己搞定了」和「用户救了它」分开了，而后者恰恰是用户几周后还留不留下来最相关的事。
配套看两个滞后指标：留存（隔一周还回来用的人占多少），以及人工介入率的变化方向。转化率、满意度评分这类即时指标我只当参考，不上主指标位。人工介入率降下来、留存没掉，才算真的变好。
一个提醒：厂商案例别当 A/B 结果看。这周 OpenAI 发了 Proaction 的案例，说用 Codex 之后销售涨了 60%、省了 75 小时。数字可能是真的，但没有对照组，也没有同期没上的团队作比较。这跟你自己跑四周实验得出的东西不是一回事。
还有件事得记账：你的对照组定义可能中途失效。第三方接口改行为、外部 agent 被平台封、依赖的模型版本悄悄更新，都会让第二周和第四周不可比。跑实验的时候把这类事件写进实验日志，不然复盘时只能对着一堆矛盾的数字发愣。
按我现在看，A/B 在 Agent 上不是没用，是用的地方变了——它管不了端到端体验，但能管子流程，前提是你先量过方差、认过用户会变。也许半年后回头看这段会显得保守，但比拿两周数据和噪音较劲强。