为什么绝大多数 LLM Agent 优先用 SSE 而不是 WebSocket

在大模型 Agent 开发中，流式输出是标配。SSE 与 WebSocket 都可以实现服务端事件推送，但很多开发者分不清二者适用边界。本文从 Agent 业务场景出发，分析两者差异、取舍逻辑与工程坑点。

基础概念回顾

• SSE（Server‑Sent Events）：基于 HTTP 的服务端单向推送。客户端建立长 HTTP 连接，服务端持续向客户端推送事件；客户端发送数据需要走额外 HTTP 请求。
• WebSocket：全双工通信协议。握手阶段复用 HTTP，握手成功后升级为 ws/wss 独立协议，客户端与服务端可以在同一个连接双向随时收发消息。

核心能力对比

对比项	SSE	WebSocket
通信方向	单向：服务端 → 客户端；上行依赖额外 HTTP 请求	双向全双工：客户端与服务端可随时互发消息
底层协议	原生 HTTP	握手 HTTP，后续为独立 TCP ws 协议
数据格式	仅支持 UTF‑8 文本，二进制需要 Base64 编码	文本、二进制均支持
断线重连	浏览器原生内置自动重连，支持 Last‑Event‑Id 事件续传	无内置重连，需要业务层实现心跳、重连逻辑
代理 / 网关兼容性	极好，普通 Nginx、CDN、网关直接支持	部分代理、防火墙会拦截，网关需要特殊配置
调试便捷度	curl 即可直接调试	需要 wscat 等专用工具
浏览器连接限制	HTTP1.1 下同域名最多 6 个 SSE 连接；HTTP/2 无限制	无此限制
部署扩缩容	无状态友好，适合 Serverless	长连接有状态，负载均衡需要会话粘性

Agent 领域实际使用率

在 LLM Agent、智能助手、工具调用类项目中：

SSE 是绝大多数项目的首选方案，使用率远高于 WebSocket。

OpenAI、Anthropic 官方流式接口，LangGraph、LlamaIndex 等主流 Agent 框架，默认对外暴露的流式接口都是 SSE。WebSocket 只用于特定强双向交互场景。

为什么 Agent 主流选择 SSE

Agent 最常见执行模式：

客户端提交一次请求 → 服务端 Agent 持续推送事件流：思考过程、工具调用、工具返回数据、中间状态、最终结果、结束标记。

客户端大部分时间只做接收；发起任务、取消任务、重试等控制指令，可以走独立 REST 接口，通过会话 ID / 任务 ID 进行关联。

SSE 在该场景下的优势：

1. 部署运维成本低

   完全基于标准 HTTP，不需要协议升级。Nginx、CDN、API 网关、Serverless 平台原生兼容，不需要特殊长连接配置。

2. 浏览器自带断线恢复

   网络抖动、页面休眠后浏览器自动重连，支持事件断点续传，不需要业务写复杂心跳重连代码。

3. 事件模型天然适配 Agent 执行轨迹

   支持自定义事件类型：thinking、tool_call、result、done，可以完整输出 Agent 全链路执行事件。

4. 架构解耦，易于水平扩展

   采用双通道模式：

• SSE 连接：只读事件流，消费 Agent 输出；

• REST POST 接口：下发控制指令（创建任务、取消任务）；

  通过

  task_id / conversation_id
  

  将两条通道绑定，服务端更容易做到无状态。

SSE 的短板

• 单向通道，流内部无法上行发送消息；
• 仅支持文本；
• HTTP1.1 存在浏览器并发连接上限；
• 取消任务需要跨通道通知服务端。

什么场景下 Agent 需要使用 WebSocket

当业务出现下面任意需求，SSE 的双通道模式会变得别扭，优先选用 WebSocket：

1. Agent 运行过程中需要实时下发干预指令：生成途中直接取消、暂停、动态修改 Agent 参数、拦截修改工具调用参数。SSE 模式取消指令走 POST，服务端需要维护任务映射；WebSocket 在同一连接直接下发控制消息，上下文天然绑定。
2. 高频双向交互：持续多轮对话，不想反复新建 HTTP 请求。
3. 二进制流式传输：语音 Agent 双向音频流、实时图片块推送。
4. 多人协同 Agent 场景：多端实时同步 Agent 执行状态。

WebSocket 在 Agent 开发中的代价

1. 长连接有状态，负载均衡需要会话粘性，分布式环境复杂度上升；
2. Serverless 环境不友好，函数实例销毁连接直接断开；
3. 需要手写 ping‑pong 心跳、断线重连、消息丢失补偿、幂等处理；
4. 部分企业内网代理会拦截 ws 协议，线上环境要做兼容兜底；
5. 调试成本更高。

Agent 选型决策树

你的Agent业务场景？
├─普通文本Agent、工具调用、输出思考流，运行中不需要实时干预 → ✅ SSE（首选）
│   └─取消任务、重试等控制指令，走独立POST + task_id关联
├─Agent执行过程，客户端需要随时下发干预指令（打断、修改参数） → ✅ WebSocket
├─语音Agent、二进制流传输 → ✅ WebSocket
└─多人协同实时操作Agent → ✅ WebSocket

生产环境工程实践建议

1. 优先使用 SSE 快速落地，覆盖 90% 以上的 Agent 业务，开发与运维成本最低。
2. 架构层面做传输抽象：将 Agent 事件输出抽象一层，底层可插拔支持 SSE / WebSocket，业务层不感知传输协议，后续需要双向能力时不需要大规模改写业务逻辑。
3. SSE 踩坑清单
   • Nginx 务必配置 X‑Accel‑Buffering: no，关闭代理缓冲，否则事件会堆积不会实时推送；
   • 页面组件销毁时，务必调用 EventSource.close()，避免连接泄漏；
   • 生产环境建议开启 HTTP/2，规避浏览器 6 连接上限问题。
4. WebSocket 踩坑清单
   • 必须实现心跳保活与客户端断线重连；
   • 分布式部署，要么 sticky session，要么基于 Redis 发布订阅做跨节点消息转发；
   • 做好连接泄漏防护，异常场景及时关闭连接。

总结

• SSE 以 HTTP 长连接实现单向事件推送，是当前 LLM Agent 开发主流方案，适合绝大多数文本流式输出场景，通过 REST 接口补充上行控制能力，简单可靠易运维。
• WebSocket 主打同一连接双向全双工通信，适合运行时干预、语音流、多人协同等强双向场景，但会带来更高的开发、运维复杂度。
• 选型核心判断标准：是否需要在 Agent 执行的流通道内，实时下发上行指令。