实时通信

为什么WebSocket对AI Agent至关重要 AI Agent系统的核心特征是持续对话和流式响应。传统HTTP的请求-响应模式天然不适合这种场景： sequenceDiagram participant C as 客户端 participant S as 服务端 participant AI as AI模型 Note over C,AI: HTTP模式（高延迟） C->>S: POST /chat S->>AI: 调用模型 AI-->>S: 完整响应（等待3秒） S-->>C: 返回完整响应 Note over C,AI: WebSocket模式（流式） C->>S: 建立连接 ✓ C->>S: 发送消息 S->>AI: 调用模型 loop 每100ms AI-->>S: Token片段 S-->>C: 实时推送 end 关键差异: WebSocket让用户在AI"思考"的同时就能看到响应，感知延迟降低80%以上。 性能瓶颈全景图 在生产环境中，WebSocket性能问题通常出现在四个层面： flowchart TB subgraph "🔴 连接层" C1[连接建立慢] C2[连接频繁断开] C3[连接数达上限] end subgraph "🟡 消息层" M1[消息序列化开销] M2[大消息阻塞] M3[消息积压] end subgraph "🟢 应用层" A1[AI推理延迟] A2[业务逻辑阻塞] A3[内存泄漏] end subgraph "🔵 基础设施层" I1[单机瓶颈] I2[跨节点通信] I3[负载不均] end C1 & C2 & C3 --> M1 & M2 & M3 M1 & M2 & M3 --> A1 & A2 & A3 A1 & A2 & A3 --> I1 & I2 & I3 连接管理：稳定性的基石 连接生命周期 stateDiagram-v2 [*] --> 连接中: 发起握手 连接中 --> 已连接: 握手成功 连接中 --> 连接失败: 超时/拒绝 已连接 --> 活跃: 收发消息 活跃 --> 空闲: 无消息>30s 空闲 --> 活跃: 收发消息 活跃 --> 心跳检测: 发送Ping 心跳检测 --> 活跃: 收到Pong 心跳检测 --> 连接异常: Pong超时 空闲 --> 心跳检测: 定时触发 连接异常 --> 重连中: 启动重连 重连中 --> 已连接: 重连成功 重连中 --> 连接失败: 超过重试上限 连接失败 --> [*]: 通知用户 note right of 重连中 指数退避策略 1s → 2s → 4s → 8s... end note 心跳策略对比 策略 间隔 优点 缺点 适用场景 固定心跳 30s 简单可靠 资源浪费 连接数少 自适应心跳 30s-5min 节省资源 实现复杂 移动端 按需心跳 仅空闲时 最省资源 检测延迟 高频消息 应用层心跳 业务决定 灵活可控 需要配合 定制场景 重连的艺术 指数退避（Exponential Backoff）是重连的标准策略，但细节决定成败： ...