SSE（Server-Sent Events）
一句话
服务端主动向浏览器推送数据的技术。 HTTP 是「客户端问一次，服务端回一次」，SSE 是「服务端说：别挂，我有数据就推给你」。
核心直觉
HTTP: 客户端 ──问──→ 服务端 ──答──→ 客户端 （一问一答，结束）
SSE: 客户端 ──订阅──→ 服务端 ═══持续推送═══→ 客户端 （长连接，持续流）为什么需要它（在 AI 场景中）
LLM 生成回答往往需要几秒甚至十几秒。如果用传统 HTTP：
用户等 10 秒 → 一次性看到完整回答 → 体验差用 SSE：
用户立刻看到第一个字 → 逐字流式出现 → 体验好这就是 ChatGPT 打字机效果的底层技术——SSE 流式传输。
在 Agent 开发中的位置
NestJS Controller → SSE 写入 Response
→ 前端 EventSource 监听 → onmessage 更新 UILangChain 的 .stream() 天然适合接 SSE——每产生一个 token 就推一个 SSE 事件。
应用场景
| 场景 | 说明 |
|---|---|
| LLM 流式输出 | ChatGPT 逐字回复的核心技术 |
| 实时通知 | 新消息、系统告警 |
| 进度反馈 | 文件上传/处理进度条 |
| Agent 执行过程 | 展示「正在调工具 → 工具返回 → 正在生成回答」的中间状态 |
横向对比：SSE vs WebSocket vs 轮询
| 轮询（Polling） | SSE | WebSocket | |
|---|---|---|---|
| 方向 | 客户端→服务端 | 服务端→客户端 | 双向 |
| 连接 | 每次请求新建 | 长连接 | 长连接 |
| 协议 | HTTP | HTTP | WS（需升级） |
| 复杂度 | ⭐ | ⭐⭐ | ⭐⭐⭐ |
| 断线重连 | 手动 | 浏览器自动 | 手动 |
| 适合 | 不频繁的更新 | 服务端推送 | 双向实时通信（聊天、游戏） |
优缺点
优点： 基于 HTTP（不需要特殊协议），浏览器原生支持自动重连，实现简单 缺点： 只支持服务端→客户端单向推送，连接数多了服务端撑不住
如何选择
只需服务端推送（如 LLM 流式输出）→ SSE。需要双向通信（如聊天）→ WebSocket。偶尔查一次状态 → 轮询或普通 HTTP。
小结
SSE 是 AI 应用流式体验的基石。从 ChatGPT 到你的 Agent 项目，打字机效果的背后都是它。比 WebSocket 简单、比轮询高效——在「服务端推客户端」这个场景中，SSE 是最优解。
下一步
- WebSocket — 需要双向通信时