使用AI工具时，有一种故障很容易让排查走偏：回复停在半句，页面却仍能访问，连接检查也显示正常。直接归因于模型服务，或者立刻更换线路，都显得顺理成章。但我整理的一次运维实验记录提醒我，首先要问清楚：刚才检查的，究竟是哪一条连接？
一次新请求成功，只说明它在那个时刻完成了通信。已经持续传输的回复，可能处在另一个会话里。用短探针检查新连接，再据此判断旧回复一定健康，中间缺了一段证据。这不是措辞上的细节，它直接影响后续选择是等待、重连，还是继续定位。
用会话与序号看清是否续上了
当时的实验没有发送真实模型请求，而是使用独立测试进程，让测试源站持续发送带序号的数据，并保留会话标识。故障只注入测试流量，生产连接保持原状。这样就能观察：中断后接着收到的数据，来自原来的会话，还是一次重新开始的请求。
记录显示，短暂中断后，部分测试流能在原会话里继续接收，序号也保持连续；更长的中断使旧连接结束。网络恢复以后，新请求又能成功。这几个结果可以同时存在。“恢复后能访问”和“刚才那条回复接着往下传”，确实需要分别检查。
这里还有一个必须保留的实验边界：故障注入针对特定测试传输，对照连接在那次实验中保持连续，不能据此推导某一类协议永远稳定。它也没有复现最初自然故障的根因。实验回答的是中断条件下的恢复行为，而不是给所有断连找到一个统一解释。
绿色面板遗漏了什么
更有启发的是随后留下的自然故障记录。部分独立请求失败，已有长流也停滞，但原来的优选机制仍把相关路径判为健康。原因在于它主要读取短探针结果，健康输入没有覆盖那条正在卡住的长流。调整评分权重之前，先补上观察对象，才有机会让判断贴近使用感受。
对AI应用来说，我会因此把检查分开：能不能建立新请求；原会话有没有继续收到数据；应用是否重新发起了请求。最后一项尤其需要辨认。界面恢复显示内容，背后可能发生过重试，不能仅凭文字重新滚动，就宣称底层连接已经无缝续传。
重试之前，先知道它会做什么
重试本身也需要知道请求的含义。一次纯文本生成、一次可能计费的调用、一次会修改文件的工具操作，重发后的后果并不相同。在没有确认上一次是否完成之前，我不会把“自动再发一次”视为通用修复。更可靠的做法，是优先利用应用已经明确支持的恢复机制，并核对有没有重复结果或重复动作。
这也影响了我会交给AI什么排查任务。我更愿意让它根据同一时间段的现象区分事实与假设：哪个新请求失败了，哪个旧流还在接收，哪些记录缺失，哪些时间对不上。只有“用户感觉卡”和一张绿色面板时，AI可以提出检查方向，但还没有足够依据替我决定应该改哪项网络设置。
本文依据的是当时的隔离实验与运维总结，没有重新测试当前环境。记录证明了短时中断后的部分恢复行为，也明确保留了长中断后的旧流续接缺口。这个案例给我的判断标准很具体：以后看到“连接已恢复”，我会继续确认恢复的是新请求，还是刚才那段尚未结束的工作。
本文根据个人实践整理，已移除非公开信息。
具体结论以文中所述的验证范围为限。