客服群里最常见的抱怨不是机器人不会答，而是它答着答着就"断片"了：客户前三句话说得好好的，到第四句机器人突然换了个话题，重新问一遍客户的订单号。客户体感是"这机器人没记性"，团队体感是"模型不行"。我们排查了三个多月的多轮断片问题，结论是：十次断片里八次和模型无关，根因都藏在会话状态管理里。把排查路线写成五步，给遇到同样问题的团队省点弯路。

头一步：先确认断片的边界

动手查之前先把现象收窄。把一周内的断片会话拉出来逐条标注，问三个问题：断在第几轮？断之前客户说了什么？断之后机器人回的内容像不像"新会话"？标完发现断片集中在两类场景：一类是客户隔了很久才回下一句，另一类是客户一次发了好段话。这两类场景对应两种完全不同的病根，混在一起查永远查不清。

第二步：查会话超时配置

头一类断片，隔久了就忘，病根多数在会话超时。很多客服系统默认的会话有效期是三十分钟，客户中午问了一句，下午两点回来接着问，系统早把会话关了，机器人自然从头再来。我们当时把超时从三十分钟调到两小时，断片投诉立刻少了一半。但超时不是越长越好，隔天的对话接着聊，上下文里堆着昨天的商品和昨天的情绪，反而容易答错。比较稳的做法是把"会话超时"和"上下文保留"拆成两个配置：会话关了没关系，客户身份和订单信息保留二十四小时，新会话自动带上。

第三步：查消息合并与截断

另一类断片，客户一次发一大段就出错，病根多在消息处理层。客户习惯把三件事写在一条消息里，如果系统按长度截断，后面的事就丢了；如果系统按条拆分，又可能把一段话拆成三个问题分别回答，答案看起来像答非所问。我们踩的坑更隐蔽：消息里带图片时，文字和图片被拆成两条处理，文字那条还排错了顺序。修法是把消息预处理做成显式环节——超长先分段落保留全文，图文合并成一个载荷再进对话引擎，每条消息进引擎前打一个序号戳，排查时能回放。

第四步：查上下文的写入时机

前面两步都正常还断片，就要看上下文是"什么时候"写的。我们出过一次这样的事故：机器人回复之后才更新会话状态，如果回复过程中用户秒回了一条消息，状态更新就会覆盖掉用户的追问，那句话等于没进过上下文。这种竞态问题在低峰期几乎不出现，高峰期爆单时集中爆发，特别有迷惑性。修法不复杂：状态写入改成队列串行，每轮对话结束再统一落盘；同时在会话记录里加一列"上下文版本号"，断片复盘时一眼就能看出哪一轮的上下文丢了。

第五步：查槽位与话题切换策略

最后一步查的是策略层。有些系统设计了话题识别，客户问到新话题就自动切知识库分支，切的时候把旧上下文清空——本意是防止串味，代价是客户在同一单里先问发货再问退款时，机器人把发货信息忘得一干二净。我们的改法是槽位分级：订单号、收货地址这类实体槽位永远保留，话题性的临时状态才允许切换时清掉。改完之后"换话题不忘单"成了客户反馈里好评率提升最明显的一条。

把断片当成可回放的事故来管

三个月排查下来我们最深的收获不是修了几个 bug，而是建立了一套断片的取证流程：每通会话保存完整的上下文快照，出现断片就回放当时的版本号和消息序号，十分钟内定位是超时、截断、竞态还是策略切换。客服系统的对话问题，靠猜是猜不出来的，靠日志回放才能落地。团队里谁都能提断片工单，但修复必须附上回放结论——这套规矩立了之后，断片类问题从每周二十几起降到每周三四起，剩下的都是真疑难。机器人有没有记性，客户说了算；记性为什么丢，工程说了算。两边的账都能对上，这个系统才算健康。