多平台客服值守有个日常到不能再日常的场景运营把客服接待台最小化让 AI 在后台自动回复自己去处理别的事。某天下午运营同事反馈京东那边没自动回复了我们拉了当天的账从中午到傍晚六个多小时京东渠道零唤醒、零消息读取、零新会话记录同一时段千牛渠道正常处理了五十多条。AI 引擎没坏回复链路没坏是把窗口叫回来的唤醒网整个哑了。这篇把排查过程和三层修法记下来核心教训一句话守候分支里读状态的信号天然等不来真值。## 守候分支一个设计上就不扫描的盲区先说架构。接待台在前台时有主动扫描分支按节奏轮询各平台的消息列表最小化时走守候分支——设计上守候分支不做扫描一方面省资源一方面避免后台程序反复抢屏靠唤醒信号把自己叫回来。这个设计本身是合理的问题在于守候分支依赖的三条唤醒信号真机实测全部恒为假守候分支实际上是一个永不被叫醒的盲区。一条条对着真机取证头一条宿主窗口标题里不携带未读提醒字样平台根本不往标题里写这类信息标题匹配永远落空第二条平台的家族提醒窗确实常驻在桌面上但处于隐藏状态而我们的检测函数只认可见窗口隐藏窗口一概从结果里剔掉于是提醒窗存在这个事实永远探测不到第三条只读探针整个下午跑了一千五百多次读回来的会话区域内容全是空文档零有效数据——后来确认是只读方式在最小化状态下拿不到真实渲染内容拿到的永远是占位空壳。三条信号每一条单独看都在工作函数被调用了、没有报错、返回了结果。合起来就是守候分支从下午一直装睡到傍晚。这类问题的迷惑性在于任何一条信号单独做单元测试都可能绿——测试里给的是理想输入而真机的最小化形态恰恰是输入的盲区。## 焦点哨兵早就在代码里只是没接上排查中最有意思的发现代码库里其实已经有一个现成的活信号源——焦点哨兵它监测平台家族窗口什么时候拿到前台一直在跑、一直在记日志。但它只被接在窗口被挪到屏幕外那条分支的唤醒逻辑上日志里三十八次命中全部来自那条分支最小化分支从头到尾没有接这根线。也就是说修复不是发明新机制而是把既有信号接进正确的分支。这类零件都在、电路没接的问题比缺零件常见得多——尤其在一个多分支的值守程序里每加一种窗口形态就多一条分支信号源很容易只接进先写的分支后加的分支抄模板时抄了结构漏了接线。接的时候踩了一个信号类型的坑值得单独讲焦点信号是电平信号窗口在前台期间它持续为真不是一跳一沿的脉冲。如果按沿信号的思路做去重——初次为真算触发、之后为真算重复——那么窗口拿到一次前台只唤醒一次运营没点任何东西、平台又来了第二条消息时信号还是那个持续的真值去重逻辑把它拦下第二条消息永远唤不醒第二次。修法是承认它是电平信号按节流处理十秒内不重复动作过了节流窗再次为真就再次唤醒。电平做沿处理是唤醒类逻辑的经典错法。## 修好唤醒还有唤而不回和一个静默自锁唤醒请求发出去只是前半程。前端收到之后如果接待台已经挂在当前店铺视图上旧逻辑直接跳过后续动作——可它此刻多半是最小化的跳过就等于唤而不醒日志里已处理写得清清楚楚屏幕上什么都没发生。补上已是本店也要重新嵌入视图的分支才算闭环恢复窗口、重读布局、刷新会话列表一步不能省。联调阶段新写的测试还当场抓了一个我们自己的存量 bug守候的到期计算用了饱和减法正常情况下它把时间差钳在零以上没问题但时钟一旦回拨——NTP 校时跳变是真实会发生的事——时间差算出负数被饱和成零再减下一次触发时间被推到一小时之后值守静默停摆一小时全程无任何报错。修法是把算出负数当作立即到期处理。一小时听起来小事对一个全年无休的值守程序小概率乘以天数就是必然而且它失效的形态和这次事故一样安静。## 给守候分支立规矩事件信号加独立计数修完之后我们给守候分支立了两条设计约束。一至少接入一个事件型信号源窗口前台变化、系统通知回调状态读取只做辅助校验——状态在最小化、隐藏、空文档这些正常形态下天然为假等不来真值事件才有穿透形态的能力。二每个信号源挂独立的命中计数不做汇总——第二天早上看一眼夜里哪条信号活过、哪条装死、各唤醒了几次一目了然汇总计数会把一条信号独活掩盖成系统健康的假象。顺带记一条排查时排除掉的假线索日志里疑似出现两个监听器并发工作的痕迹追了很久最后发现是把跨天的日志轮转看成并发了实测只有一套。凌晨排查时这种误读特别常见先确认日志的时间边界再谈并发。## 小结这次事故的账很简单六个半小时的沉默同期友邻渠道五十多条消息问题不在 AI不在回复链路在唤醒网的三条假信号和一个没接线的哨兵。AI 自动回复的可用性下限往往不在模型和回复生成而在把窗口叫回来这些边角上而边角失效的特点是安静——没有报错、没有异常栈只有账目上对不上的零。## 参考文章- 企业微信自动回复设置从接入到转人工的完整方案- 微信客服自动回复怎么设置入口与规则详解