Appearance
Agent 为什么普遍用 SSE?远不止"实现简单"这一条
更新: 7/19/2026 字数: 0 字 时长: 0 分钟
"实现简单"只是 SSE 众多优点中最表层的一个,绝非核心原因。真正的答案是:SSE 的技术特性与大模型 Agent 的通信需求高度契合——即"服务端持续、单向、逐字地把生成结果推给客户端"这一场景。 SSE 恰好是"能力刚好够用、成本又最低"的那个最优解,是一次经过权衡的工程选型,而非偷懒。
真实原因
1. 通信模型天然匹配:Agent 就是"单向流式输出"
大模型生成回复是逐 token(词元)自回归产生的,天然是一个"服务端不断产出、客户端只管接收"的过程。
- SSE 的定位正是 Server-Sent Events(服务器发送事件)——服务端到客户端的单向持续推送。
- Agent 场景中,用户发一次请求后,后续所有内容(逐字回复、工具调用状态、思考过程)都是服务端主动推,客户端不需要在同一连接里反复向服务端说话。
- 这与 SSE"一次连接、持续下发"的模型严丝合缝。用双向的 WebSocket 反而是能力过剩——一半的双向能力被浪费。
2. 带来"打字机"式实时体验,大幅降低感知延迟
- 大模型完整生成一段长回复可能需要数秒到数十秒。若等全部生成完再一次性返回,用户会面对长时间的空白等待。
- SSE 让服务端每生成一小块就立刻推送,前端实现"逐字蹦出"的打字机效果。
- 这把**首字延迟(TTFB / 首 token 时间)**从"等待完整响应"压缩到"等待第一个词",体感响应速度提升巨大——这是产品体验层面 SSE 不可替代的价值。
3. 基于标准 HTTP,基础设施零负担
这是 SSE 相比 WebSocket 最关键的工程优势:
- SSE 本质就是一个
Content-Type: text/event-stream的普通 HTTP 长连接,走的还是标准 HTTP/HTTPS 协议(80/443 端口)。 - 因此它天然兼容现有的一切 Web 基础设施:反向代理(Nginx)、CDN、负载均衡、API 网关、鉴权体系(Cookie/Token)、防火墙,全部无需改造即可使用。
- 而 WebSocket 使用独立的
ws:///wss://协议,需要 HTTP 协议升级(Upgrade)握手,很多代理、网关、企业防火墙对它支持不佳,常需额外配置甚至专门改造,运维和兼容成本明显更高。
4. 内建断线重连与事件机制,健壮性好
- SSE 协议原生支持自动重连:连接意外断开后,浏览器的
EventSource会自动尝试重连。 - 配合
Last-Event-ID机制,重连时可告知服务端"我上次收到哪条了",支持断点续传,避免内容丢失或重复。 - 还内建了事件
id、event(事件类型)、retry(重连间隔)等字段,这些都是协议自带的,无需自己造轮子——这也正是它"看起来简单"的深层原因:简单是因为标准已经帮你做好了。
5. 资源开销小,适合大规模并发
- SSE 是轻量的文本单向流,协议开销远小于维护大量 WebSocket 双向全双工连接。
- 对需要同时服务海量用户的 Agent 服务而言,SSE 在服务端资源占用和横向扩展上更经济。
为什么不是轮询或 WebSocket
| 维度 | 轮询(Polling) | WebSocket | SSE |
|---|---|---|---|
| 通信方向 | 客户端反复问 | 双向全双工 | 服务端→客户端单向 |
| 底层协议 | HTTP | 独立 ws/wss 协议 | 标准 HTTP |
| 实时性 | 差(有轮询间隔) | 好 | 好 |
| 基础设施兼容 | 好 | 较差(需改造) | 好(零改造) |
| 断线重连 | 需自己实现 | 需自己实现 | 协议原生支持 |
| 与 Agent 场景契合度 | 低(浪费请求) | 过剩(能力冗余) | 恰好匹配 |
| 资源开销 | 高(频繁请求) | 中 | 低 |
- 轮询:客户端隔一段时间问一次"好了吗",既有延迟又浪费大量无效请求,体验和效率都差。
- WebSocket:双向全双工能力强,但对 Agent 的"单向输出"场景属能力过剩,且协议特殊、基础设施兼容差、运维复杂。适合真正需要双向高频交互的场景(如在线游戏、协同编辑、实时音视频信令)。
- SSE:能力刚好覆盖"服务端持续单向推流",又完全复用 HTTP 生态,是契合度、成本、健壮性三者平衡的最优选择。
总结
Agent 选用 SSE,表面看是"简单",本质是"契合":它的单向流式模型精准匹配大模型逐字生成的特性,又借标准 HTTP 白嫖了整个成熟的 Web 基础设施与断线重连能力,以最低的工程与运维成本,换来了最佳的实时体验。"实现简单"只是这种高度契合所带来的结果,而非选择它的原因。
补充一点务实认知:SSE 也有边界——它默认只支持文本(二进制需编码)、单连接方向固定。当 Agent 需要全双工实时交互(如实时语音对话、边说边打断)时,业界确实会转向 WebSocket 或 WebRTC。选型永远服务于场景,SSE 是当前主流"文本流式对话"Agent 的最优解,而非唯一解。