163、Agent的灰度发布与A/B测试

163、Agent的灰度发布与A/B测试昨晚上线了一个新版本客服Agent，只是把system prompt里的“你是客服”改成了“你是资深客服”，并加了一句“如果用户情绪激动，先道歉再解释”。结果今天上午监控群里炸了：转人工率上升了18%，用户差评里都在说“机器人变笨了”。我第一反应是回滚，但回滚之后指标并没有立刻恢复，又过了几个小时才慢慢回到正常水位。查日志发现，问题根本不在prompt，而是新prompt触发了模型在少数场景下更长篇的道歉话术，而这些话术被用户当成“听不懂人话”的敷衍。更坑的是，回滚代码只是改了配置，但线上已经有一部分长会话被新prompt产生过记忆，旧版本读不了那些新格式的memory，会话状态直接错乱。这个事故让我重新理解了Agent发布这件事：传统软件发布是“换版本”，Agent发布是“换行为分布”。你没法保证同一个prompt和模型，今天和明天输出完全一样。所以灰度发布和A/B测试不是可选项，是保命项。先说灰度发布。传统服务的灰度，按IP、按用户ID分桶就完了。Agent不行，因为Agent是有状态的多轮对话。如果你按请求维度分流，同一个用户上一轮走了A版本，下一轮走了B版本，轻则风格突变用户察觉，重则工具调用的上下文对不上，触发一连串诡异错误。我的做法是严格按会话（session_id）维度分流，一个会话内无论多少轮请求，必须锁定同一个Agent版本。实现上，我习惯在接入层加一个简单的路由中间件，拿到请求里的session_id或user_id，然后查一下这个会话已经被分配了哪个版本。没有的话就按配置规则分配一次，并把分配结果写进Redis，带过期时间。