110、WebSocket实时通信Agent最近在调一个Agent服务，前端页面上的对话气泡总是卡在“思考中……”半天不动，后端日志里却能看到LLM的token早就流完了。我一开始怀疑是SSE的缓存问题，后来抓包一看，WebSocket连接早就断了，前端还在傻乎乎地等onmessage。这种问题很典型——Agent的实时通信不能简单套用传统的请求-响应模型，尤其是当你的Agent需要同时处理流式输出、工具调用状态回传、多客户端广播的时候，WebSocket的坑一个接一个。今天就把我调这个问题的全过程记录下来，顺带聊聊Agent场景下WebSocket到底该怎么用。先说那次调试的现场。服务端用的是FastAPI + WebSocket，客户端是React的useWebSocket库。Agent每轮回复包含三个阶段：先推送一个“开始思考”事件，然后逐字推流LLM的token，最后推送一个“工具调用完成”事件。问题就出在第二阶段，token推流稍微慢一点，比如超过60秒，浏览器端的连接就被断了。为什么？因为WebSocket是长连接，但中间任何一层代理（Nginx、云负载均衡）都可能有一个空闲超时时间，默认60秒或更短。你的连接没有数据流动，代理就认为是空闲连接，直接给你掐了。解决方式很简单，但很容易被忽略——必须定期发心跳包。注意心跳包不能和业务消息混在一起，得单独定义一个事件类型，比如{"type":"ping"}，服务端收到后回{"type":"pong"}。而且心跳间隔要小于代理超时时间，但也不能太频繁，否则白白消耗资源。我一般设置30秒一次，写个定时器，在onopen里启动，