文章摘要

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。

五、核心对比

六、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

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

定义统一事件：

publicrecordAiEvent(Stringtype,longsequence,StringtaskId,Objectdata){}

传输适配器：

AiEvent → SSE Adapter → WebSocket Adapter → WebRTC DataChannel Adapter

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

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

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

总结

选型可以概括为：

只需要服务器推送文本 → SSE 需要高频双向控制 → WebSocket 需要低延迟音视频 → WebRTC

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