SSE、WebSocket和WebRTC怎么选？AI聊天、语音Agent与工具进度推送架构指南

文章摘要

AI应用需要传输文本Token、工具执行进度、语音、图片和用户打断事件。SSE、WebSocket与WebRTC都能实现“实时”，但它们的通信方向、网络适应性、浏览器支持、音视频能力、代理兼容性和开发复杂度完全不同。本文以AI聊天、长任务进度、实时语音、数字人和协同Agent为例，给出协议选型矩阵和混合架构建议。

一、不要只问哪个协议性能最好

真正要问的是：

数据从谁发给谁？
是否需要双向同时发送？
传的是文本还是音视频？
是否需要用户打断？
是否经过企业代理和网关？
是否需要断线恢复？

三种协议的核心定位：

SSE
→ 服务器持续推送文本事件

WebSocket
→ 客户端与服务器双向长连接

WebRTC
→ 面向低延迟音视频和实时媒体

二、SSE适合什么

SSE基于HTTP，响应类型为：

text/event-stream

特点：

  • 服务器到客户端单向推送；
  • 浏览器原生支持EventSource；
  • 与HTTP基础设施兼容；
  • 文本事件简单；
  • 支持事件ID和自动重连；
  • 易于经过Nginx和网关。

适合：

  • AI文本逐字输出；
  • 报告生成进度；
  • Agent工具执行事件；
  • 后台任务状态；
  • 日志与通知；
  • 服务端主动推送低频状态。

优点

实现简单
运维成熟
与HTTP认证体系兼容
容易调试
适合文本事件

局限

主要是服务端到客户端
EventSource默认只支持GET
不适合二进制音视频
浏览器并发连接有限制
复杂交互需要额外HTTP请求

AI聊天通常可以：

POST提交问题
→ SSE或fetch流接收回答

不一定需要WebSocket。

三、WebSocket适合什么

WebSocket握手后建立双向连接：

客户端 ⇄ 服务器

适合：

  • 用户随时发送控制事件；
  • 多Agent实时协同界面；
  • 远程终端；
  • 在线代码执行控制台；
  • 高频双向状态同步；
  • 复杂交互式工作台。

优点

  • 真正双向；
  • 可以发送文本和二进制；
  • 协议开销低；
  • 一个连接承载多种事件；
  • 适合用户中途修改任务。

局限

  • 连接状态管理更复杂；
  • 断线重连需要自己设计；
  • 负载均衡需要连接感知；
  • 网关和安全设备兼容性需要验证；
  • 消息确认、顺序和幂等需要应用层处理。

四、WebRTC适合什么

WebRTC针对实时媒体设计：

  • 音频；
  • 视频；
  • 实时数据通道；
  • 抖动控制；
  • 编解码；
  • 回声消除；
  • NAT穿透。

适合：

  • 实时语音Agent；
  • 数字人；
  • 视频客服；
  • 实时翻译；
  • 低延迟音视频互动。

优点

低延迟媒体传输
浏览器原生支持
音视频编解码
回声消除和抖动处理
适应网络变化

局限

信令仍需额外通道
ICE、STUN、TURN复杂
服务端媒体处理门槛高
企业网络可能限制UDP
调试成本高

如果只是文字聊天，不应为了“实时”直接使用WebRTC。

五、核心对比

维度 SSE WebSocket WebRTC
通信方向 服务器→客户端 双向 双向媒体
主要数据 文本事件 文本与二进制 音视频与数据
浏览器支持 原生 原生 原生
HTTP代理兼容 高 中高 相对复杂
断线恢复 EventSource可自动 自行实现 自行实现
音视频 不适合 可以但不专业 最适合
开发复杂度 低 中 高
AI文本流 最适合 可用 不需要
实时语音 不适合 可传但能力有限 最适合

六、AI文本聊天怎么选

典型需求：

用户提交一条消息
→ 服务端连续返回Token

推荐：

POST＋fetch ReadableStream

或者：

POST创建任务
→ EventSource订阅任务事件

WebSocket只有在以下需求明显时才值得使用：

  • 一个连接内连续多轮；
  • 用户频繁发送取消、暂停、修改；
  • 服务端主动发起多个并行任务事件；
  • 需要双向协作状态。

七、工具调用进度怎么选

Agent轨迹：

模型分析
→ 调用搜索
→ 读取文件
→ 执行代码
→ 生成报告

事件格式：

{
  "type": "tool_start",
  "step": 3,
  "tool": "search_web",
  "message": "正在检索官方资料"
}

这种场景使用SSE非常合适。

用户需要取消时，可以另外发送：

POST /tasks/{id}/cancel

不需要仅为了一个取消按钮切换到WebSocket。

八、语音Agent怎么选

实时语音要求：

  • 连续上传麦克风音频；
  • 连续接收模型语音；
  • 用户随时打断；
  • 低延迟；
  • 处理网络抖动；
  • 回声消除。

浏览器和移动端优先：

WebRTC

服务端电话系统可以使用：

SIP
＋WebSocket或专用媒体连接

如果用普通WebSocket传PCM音频，需要自己处理：

  • 音频切片；
  • 时间戳；
  • 抖动；
  • 缓冲；
  • 丢包；
  • 回声；
  • 编解码。

九、数字人场景

数字人包含：

语音
视频
口型
动作
文本字幕
工具状态

推荐混合：

WebRTC
→ 音视频

WebSocket或SSE
→ 字幕、工具、状态、控制

不要把所有控制元数据塞进视频流。

十、企业代理环境下的选择

企业网络通常对HTTP最友好。

优先级：

文本流：SSE
双向控制：WebSocket
音视频：WebRTC并准备TURN回退

上线前测试：

  • 公司VPN；
  • 代理服务器；
  • WAF；
  • 移动网络；
  • 海外网络；
  • 弱网；
  • 长连接超时。

十一、认证方式

SSE EventSource

原生EventSource不方便设置自定义Authorization Header。

常见方案：

  • Cookie会话；
  • 短期一次性Token放Query；
  • 先POST创建任务，再订阅；
  • 使用fetch读取流。

敏感长期Token不要放URL。

WebSocket

可以在握手时使用：

  • Cookie；
  • Query短期Token；
  • 子协议；
  • 第一条认证消息。

WebRTC

信令阶段认证，并由后端生成短期会话凭证。

十二、断线恢复

SSE

可以使用：

id: 123

浏览器重连时携带：

Last-Event-ID

服务端从事件日志恢复。

WebSocket

自行维护：

connection_id
last_sequence
ack
resume_token

WebRTC

媒体会话通常需要重新协商或恢复，需要独立业务状态保证任务不丢失。

十三、背压与慢客户端

不论使用哪种协议，都要处理：

模型输出速度
>
客户端消费速度

策略：

  • 限制缓冲；
  • 合并小Token；
  • 丢弃非关键进度；
  • 慢客户端超时；
  • 断开后保存任务结果；
  • 不把完整内容无限堆在内存。

音视频还需要动态码率和抖动缓冲。

十四、推荐选型矩阵

普通AI聊天

fetch流或SSE

Agent长任务进度

SSE

交互式Agent工作台

WebSocket

语音Agent

WebRTC

电话Agent

SIP＋服务端实时媒体通道

数字人

WebRTC＋WebSocket或SSE

十五、最佳实践：业务事件与传输协议解耦

定义统一事件：

public record AiEvent(
        String type,
        long sequence,
        String taskId,
        Object data
) {
}

传输适配器：

AiEvent
→ SSE Adapter
→ WebSocket Adapter
→ WebRTC DataChannel Adapter

业务层不要直接依赖某一种连接对象。

这样同一个Agent可以同时服务：

  • 网页SSE；
  • 工作台WebSocket；
  • 语音WebRTC。

总结

选型可以概括为：

只需要服务器推送文本
→ SSE

需要高频双向控制
→ WebSocket

需要低延迟音视频
→ WebRTC

成熟AI应用通常不是三选一，而是让不同协议各自承载最适合的数据类型。

延伸阅读

如果你正在关注企业级 AI 应用、Agent、RAG、MCP 与大模型工程化落地，欢迎访问 智元界：

https://www.zyentor.com/

智元界将持续分享可运行的技术实战、架构设计、问题排查与企业应用案例。