“办公助手没反应了。”

下午1点45分，我给AI管家发了这么一句话。

如果是以前，它可能会先问一下”具体什么情况”，或者让我自己重启一下服务。但这一次，它选择了另一种方式——直接开干。

因为就在20分钟前，办公助手还好好的。它在某书上回复消息，处理任务，安排日程，像一个24小时不睡觉的贴心助理。但现在，它彻底哑巴了。

🐛 01 第一次断线：以为只是偶发

它去查了日志。日志显示，办公助手的WebSocket连接，最后一次活动时间是 13:22。

23分钟，没有任何新消息。

WebSocket是一种保持长连接的通信协议，正常情况下，只要连接不断，办公助手就能持续收到某书平台推送的消息。但现在，日志里一片寂静——没有错误，没有异常，没有任何值得关注的WARNING。

就像一个人好端端地走着走着，突然就消失了。没有摔倒，没有呼救，就是……没了。

它试着重启了一下 gateway 服务。3分钟后，办公助手恢复正常。我发了一条消息测试，秒回了。我回了一个”ok”。

又观察了半小时，确认没问题。这事翻篇。

当时我以为，这只是个偶发的网络抖动。

🐛 02 第二次断线：事情不对劲了

下午3点41分，我又给AI管家发了一句：

“办公助手又没反应了。”

我心里咯噔一下。

这次更夸张——从1点45分恢复算起，到3点41分，整整 1小时56分钟，办公助手再次静默断线。

同样的剧本：没有任何error日志，没有任何异常提示，WebSocket的readyState显示OPEN，但就是收不到任何消息。连接看似活着，其实已经死了。

它再次重启gateway。3分钟后恢复。

这次我没把它当偶发事件。

如果一件事连续发生两次，那就是必然。

但问题来了：没有任何错误日志，这怎么查？传统的问题排查套路是——看报错，找异常，定位代码。但现在，错误日志是空的。这感觉就像一个医生面对一个”看起来完全健康但就是醒不过来”的病人，无从下手。

它决定做一件看起来很疯狂的事——

去翻第三方SDK的源码。

🔍 03 翻源码：在一个85000行的文件里找bug

办公助手用的是某办公平台的官方SDK。为了避免广告嫌疑，以下简称”某书SDK”。这个SDK负责维持WebSocket连接，收发消息。

正常来说，SDK是第三方提供的，出了问题应该是SDK的事，跟我没关系。大多数工程师的做法是：等官方修复，或者换一种连接方式。但我不想等官方——鬼知道他们什么时候修。也不想换——这套架构已经跑稳定了。

它决定自己去找根因。

晚上6点19分，它打开了某书SDK的源码。一个巨大的JavaScript文件，85319行。

在一个85000行的文件里找一个问题，这听起来像大海捞针。但如果你知道自己在找什么，就没那么难了。

几分钟后，它找到了关键代码。

WebSocket的ping机制

WebSocket协议本身支持ping/pong机制——客户端发ping，服务器回pong，用来检测连接是否还活着。某书SDK里有一个维持连接心跳的机制。

它的逻辑是这样的：每隔2分钟检查一下连接状态，如果显示”在线”就发一个心跳包出去。

但这里有个致命的问题：它只负责发心跳包，根本不关心对方有没有回应。

SDK就像一个人每隔2分钟给对方打个电话，但电话打通后，他根本不等对方接就直接挂断。他以为”电话能打通 = 对方能收到”，但实际上可能是以下情况：

• 对方已经挂了电话

• 网络中间有个防火墙把数据包拦了

• 路由器已经偷偷断开了连接

这些情况统称为 TCP半开连接——网络层面的连接还保持着（所以状态显示在线），但实际上数据已经过不去了。操作系统不会主动告诉应用程序”这个连接已经半开了”，它只会默默地看着数据送不出去。

只在连接真正断开时才重连

SDK的重连逻辑藏在一个很隐蔽的地方：只有在收到”连接已关闭”或”发生错误”这类明确信号时，才会触发重连。

但TCP半开连接不会触发这些事件。连接看起来是在线的，只是数据送不出去而已。SDK会一直以为连接还活着，继续发心跳包——但这些心跳包永远石沉大海，永远不会有回应。

这就是为什么连接会在大约2小时后”静默断开”。

不是我们的代码问题，不是网络问题，是某书SDK的设计缺陷。

🐕 04 看门狗方案：既然改不了SDK，就在外面守

找到bug的那一刻，说实话我挺震撼的。但问题来了——

这是第三方SDK的源码，改不了。

总不能每次出问题了去给SDK提PR、等官方合并、发布新版本吧？太慢了。

AI管家想了一个办法：在外面加一个看门狗。

看门狗的作用是：定时检查办公助手的状态，如果发现异常，就自动重启服务。这就像在公司门口安排一个保安，每隔30分钟进来逛一圈，发现谁不在工位就直接打电话叫回来。

它把任务派给了团队的CTO。

4分19秒后，CTO交付了一个看门狗脚本。脚本逻辑很简单：

1. 检查gateway进程是否还在运行

2. 检查最近2小时有没有活动日志

3. 如果进程不在了，或者超过2小时没活动，就触发重启

它看了一下脚本，逻辑基本OK，但有几个细节需要调优。

🔧 05 验收翻车：CTO的脚本有3个坑

晚上6点25分，它开始测试看门狗脚本。

测完发现，CTO写的脚本有 3个问题：

问题1：macOS上进程匹配不稳定

脚本用 pgrep 命令来找进程，但在macOS上，这个命令对某些进程的匹配不灵敏，有时候进程明明在，命令就是找不到。

修复： 改用更可靠的进程查询方式。

问题2：判断逻辑太保守

脚本只在检测到”没有日志”时才触发重启。但这次问题的特征恰恰是——没有任何错误日志。静默断开的意思就是：连日志都没有。

修复： 改为”超过2小时无活动即判定断开”。

问题3：所有账号都监控会误报

办公助手绑定了多个某书账号，其中有些是冷账号——可能几天才收到一条消息。如果所有账号都监控，那些冷账号分分钟触发误报。

修复： 只监控高频使用的账号（定义为”过去24小时有活动”的账号）。

它花了2分钟修复了这3个问题，再测一遍——

脚本正确检测到了断线状态，并成功触发了重启。

验收通过。

🚀 06 部署上线：从此断线不超过30分钟

晚上6点27分，看门狗脚本正式部署。

加入定时任务，每30分钟执行一次，巡检一次。另外加了2个保护机制：

1. 5分钟冷却：每次重启后，5分钟内不再触发重启，防止连续重启

2. 锁文件：用锁文件防止多个看门狗实例同时运行

从用户第一次报告问题（13:45），到最终完全部署修复（18:40），总共用了 4小时55分钟。但从AI定位到bug（18:19）到看门狗部署上线（18:27），只用了8分钟。

从那以后，办公助手再也没出现过”失联超过30分钟”的情况。看门狗会在后台默默守护，一旦检测到异常，自动恢复。

📊 07 复盘

Bug找到了，方案上线了，办公助手活得好好的。

整个过程从用户报告到完全修复，花了将近5个小时。但最核心的8分钟，是AI翻完85000行源码、定位根因、交付解决方案的时间。

这不是什么偶发事件。SDK的心跳机制有缺陷，连接会在2小时后静默断开——这个问题可能在官方代码里躺了很久，没被发现。因为没有任何错误日志，传统排查方式根本找不到北。

是AI改变了游戏规则。

故事讲到这，该结束了。

办公助手现在活得好好的。

对了，连这篇文章，也是AI写的。

如果你也有类似的”AI员工”故事，欢迎在评论区聊聊。或者，你想知道更多关于AI自主排查问题的技术细节，也可以留言。

关注我，下期讲讲我是怎么用AI搭了一套”永不遗忘”的记忆系统。