聊到 WebSocket，很多企微二次开发的同行会条件反射想到"消息推送通道"——回调消息推到客服工作台那一层。但 WebSocket 在 AI 机器人场景里还有个更关键的角色：让 AI 的生成过程变成实时可感知的。客户发了一句话，机器人 5 秒后才回一段话和 0.5 秒就开始"打字"、逐步显示生成内容，体验差距是指数级的。这篇从 AI 交互体验角度，聊聊 WebSocket 长连接在 Eyun 企微机器人场景里怎么用。
一、AI 交互的"实时"和消息推送的"实时"是两件事
很多人把 WebSocket 在 AI 场景的用法和消息推送混为一谈，但两者要解决的问题不同：
维度 | 消息推送场景 | AI 交互场景 |
|---|---|---|
数据来源 | 平台回调事件 | 模型生成的 token 流 |
推送频率 | 突发式，事件触发 | 持续高频，每秒几十 token |
延迟要求 | 100ms 内 | 50ms 内 |
顺序保证 | 同会话有序 | 单条生成严格有序 |
交互形态 | 客服看工作台 | 客户看聊天界面 |
AI 交互的特殊性在于流式输出：大模型不是一次性返回完整回复，是按 token 一个个吐出来。客户等 5 秒看到一段话 vs 等 0.3 秒看到第一个字开始"打字"，体验差距是天壤之别。这种流式性靠 HTTP 轮询是做不出来的——你不可能每 50 毫秒去问一次"生成了多少"，那就是 DDoS 自己。
WebSocket 长连接是流式输出的天然载体：服务端每生成一个 token，立刻通过 WebSocket 推给客户端，客户端实时追加显示。
二、AI 流式交互的完整链路
基于 Eyun 平台 + WebSocket + AI 的流式交互链路是这样跑的：
1. 客户在企微发消息 2. Eyun 推回调到你后端 3. 后端快速回 2xx，启动 AI 处理任务 4. AI 模型流式生成 token 5. 每个 token 通过 WebSocket 推给前端工作台 6. 工作台实时显示"机器人正在输入"和生成内容 7. 生成完成，后端调 Eyun sendText 接口正式发出消息 8. 客户在企微收到完整回复第 5 步是关键差异：传统做法是等模型生成完才显示，客户在那干等；WebSocket 做的是流式推送，客服在工作台上能实时看到机器人"正在打字"的过程，发现方向不对可以提前介入打断。
第 7 步也有讲究：模型生成的最终文本要通过 Eyun 接口正式发出去才算完成。生成和发送是两件事，要解耦——生成完不直接发，先存草稿，给客服确认或自动审核后再发。这样可以避免 AI 一时抽风把不该发的内容直接发出去。
三、流式输出的工程细节
流式输出看着简单，工程上有几个坑：
token 缓冲与批量推送。每个 token 推一次 WebSocket 帧开销大，特别是网络差时。要做一个小的 token 缓冲区，攒够 5-10 个 token 或 100ms 时间到再批量推一次。客户端看起来还是连续的，但实际推送次数降到原来的十分之一。
断流处理。模型生成中途网络断了、服务挂了，客户端看到的生成内容是半截。要支持续传：客户端记住已收到的 token 数，重连后告诉服务端"从第 N 个 token 继续推"。服务端要保留中间状态，断流后能在原位置继续。
取消机制。客服看到生成方向不对，要能立刻喊停。客户端发个"取消"指令通过 WebSocket 反向传给服务端，服务端立即中断模型调用。这一步延迟要极低（50ms 内），否则模型生成完了取消也没意义。
生成进度可视化。除了 token 本身，还要推送"模型在思考""正在调用工具查客户档案""工具返回完成，正在组织回复"这种阶段信号。让客服知道机器人为什么慢——是在调工具还是单纯生成慢，决定要不要介入。
四、双向交互：不止是推送
WebSocket 是双向通道，AI 交互场景里反向通道也很重要：
客服打断：客服点击"打断"按钮，停止 AI 生成
客服修改：AI 生成到一半，客服想插入自己的话，模型要能感知后续输入调整生成
客户接管：客户明确要求人工，立刻停止 AI、转人工
客服改写：AI 生成完，客服直接在工作台改写后发出，原 AI 内容丢弃
这些都是客户端 → 服务端的指令，靠 HTTP 轮询做延迟太大。WebSocket 反向通道让客服可以像指挥一个真人同事一样指挥 AI——"等等，这样不对""换个说法""还是我自己来"。
五、会话级状态同步
WebSocket 还能解决一个传统 AI 机器人做不好的问题：多端状态同步。
客服可能同时开三个浏览器标签页（不同客户、不同视图），任何一个标签页里的操作（接管、改派、回复）都要实时同步到其他标签页。靠 HTTP 轮询要么慢、要么冲突。WebSocket 通过"按客服ID 维度的会话广播"实现：客服在自己任何一个标签页做事，所有标签页实时更新。
状态同步的字段包括：
当前 AI 任务执行到哪一步
哪些会话被 AI 接管、哪些被人工接管
客服正在打字（让其他同事知道别重复回）
会话归属变更、改派、转移
客户上下线、消息已读
这套同步做不好，多端协同就崩——客服在这边回了消息，那边标签页还显示"未回复"，重复回复事故频发。
六、AI 多候选回复的实时展示
AI 在高价值场景可以同时生成 2-3 个候选回复，让客服挑一个发。这种"多候选并行"对实时性要求更高：
三个候选要并行生成、并行推送，不能串行等
客服能在三个候选间实时切换、对比
选定一个后，其他两个立即停止生成释放算力
选定的那个可以继续生成（如果还没生成完）
WebSocket 在这种场景下的价值是让客服的"选择动作"实时反馈到生成端。HTTP 模式下选完一个要等下一次轮询才能停止其他生成，浪费算力。
七、性能与稳定性挑战
AI 场景的 WebSocket 比普通推送场景压力大得多：
并发连接数高：每个客服 1 个连接 + 每个 AI 任务 1 个临时连接（用于流式输出）
推送频率高：单个 AI 任务可能每秒推几十个 token 帧
任务持续时间长：AI 生成可能持续 10-30 秒，期间连接要稳
应对策略：
连接复用：不要为每个 AI 任务开新连接，复用客服的长连接，任务结束时关闭流式子通道而非整个连接
背压控制：客户端处理不过来时，服务端要能感知（通过 WebSocket 的 buffer 高水位）并暂停推送，避免堆积
慢消费者保护：客户端卡死、网络极慢时，服务端不能一直堆积消息。设上限超阈值主动断开连接让客户端重连
服务器水平扩展：单机扛不住时按客服ID 分片，前端网关按 ID 路由到对应服务器
八、安全：流式场景的特殊风险
WebSocket 长连接在 AI 场景的安全要点除了常规的鉴权、wss 加密、来源校验，还有几个特殊风险：
流式内容泄露：AI 生成过程中的中间内容可能包含敏感信息（比如模型先输出"客户手机号是 138..."再被审核拦截），中间内容也得过敏感词。
取消指令伪造：恶意客户端伪造"取消"指令，干扰正常 AI 任务。取消指令要带签名验证。
越权接管：客服 A 通过 WebSocket 发指令接管客服 B 的会话，权限校验要做对。
任务冒充：客户端伪造任务 ID 接收别人的 AI 生成结果。任务 ID 要绑定客服身份，跨客服不可见。
写在最后
WebSocket 在 AI 机器人场景里的价值远不止消息推送，它是流式生成、双向交互、多端协同、多候选选择的共同载体。基于Eyun 企微 API做实时 AI 机器人，本质是把"消息收发"和"AI 决策执行"两件事通过 WebSocket 这个实时通道连起来，让客户、AI、客服三方都能感知对方的实时状态。这套实时性做扎实，AI 机器人才能从"等 5 秒回一段话"的笨拙体验升级成"打字感、可打断、可协同"的真人级体验。技术细节看起来碎，但每一条都直接决定客户感受——慢一点客户就觉得对面是机器。
