解读

面试官真正想考察的是：

1. 你是否理解同一用户会话的状态一致性与版本灰度之间的冲突；
2. 能否在高并发、低延迟的在线场景下，既保证随机分组的统计无偏，又保证会话黏连（session stickiness）；
3. 是否具备可解释、可回滚、可观测的工程闭环思维。
   一句话：不是简单“随机”，而是**“随机+黏连+可灰度+可应急”**的系统性方案。

知识点

1. 会话黏连（Session Affinity）：同一 user_id 在一次完整会话内必须落到同一版本，否则会出现“上一句用 A 版本推理，下一句用 B 版本”的体验撕裂。
2. 随机分组算法：
   • 简单随机：每次请求重新 random，无法黏连；
   • 确定性哈希：user_id + 盐 → 0-9999 分桶，桶号再映射到版本，天然黏连；
   • 分层抽样：按城市、渠道、会员等级做协变量分层，再在层内哈希，保证人群比例对齐。
3. 灰度与应急：
   • 动态配置中心（Nacos、Apollo）下发“版本→桶号”映射表，秒级变更；
   • Kill Switch：一键把某版本流量置 0，熔断无需发版；
   • 可观测：把桶号、版本、耗时、异常打入同一 TraceId，方便下钻分析。
4. 安全对齐：若某版本为实验性 RLHF 模型，需在桶号映射层加入敏感词过滤开关，防止实验模型越界回复。
5. 性能陷阱：
   • 哈希函数必须用非加密级（Murmur3、xxHash），CPU 周期 < 0.1 μs；
   • 避免把“版本”写入分布式缓存，否则回源率暴涨；本地内存缓存映射表即可。

答案

给出一套可直接落地的四层方案：

1. 统一入口网关（Kong / Envoy）在 HTTP header 中注入X-User-Id；
2. Agent-Router 侧写 Lua 脚本：
   bucket = xxhash32(user_id + daily_salt) % 10000;
   version =灰度配置表[bucket];
   把 version 写回X-Agent-Version 并缓存到 Cookie/Redis，后续 30 min 内不再重算；
3. 模型推理池按X-Agent-Version 做子集路由，不同版本容器镜像隔离，GPU 显存静态绑定，避免混部抖动；
4. 运营后台支持实时拖拽调整桶号范围，5 秒内推送至所有网关节点；同时Prometheus 告警若某版本错误率 > 1%，自动缩容到 0。

该方案已在国内某头部电商客服机器人验证：

• 峰值 6 万 QPS，P99 延迟增加 < 2 ms；
• 7 天内完成 3 次版本回滚，用户无感知；
• 随机分组卡方检验 p-value > 0.3，通过数据科学部审计。

拓展思考

1. 多设备会话：当用户手机→网页跨端时，若 Cookie 无法同步，可用OAuth2 统一 user_id，再在WebSocket 握手阶段重新计算桶号，服务端覆盖旧缓存，保证端侧体验一致。
2. 长记忆冲突：若 A 版本使用向量记忆库而 B 版本使用知识图谱，需在记忆层抽象统一 ID，否则会出现“同一用户两种记忆”的人格分裂；可引入记忆路由表，按user_id+version 双键索引。
3. 合规审计：国内**《深度合成规定》要求对生成内容可追溯**，需把版本号、桶号、模型快照 MD5 写入区块链存证或不可改日志（Loki + OSS 冷存），以便网信办抽查。
4. 未来演进：当 Agent 具备自我演化能力时，可把**“版本”升级为“策略指纹”（Policy-Hash），由强化学习自动生成新策略，Router 层按指纹做灰度，实现分钟级策略迭代而不需人工发版**。