实时语音 Agent 为什么用 WebRTC？它和 WebSocket/SSE 差在哪？

先这样答

语音对话场景需要极低延迟的双向音频流，并要在弱网下保持可用，这脱离了传统请求响应模型。WebRTC 是专为实时音视频设计的协议栈，在底层传输和音频处理上提供了对应机制，WebSocket 和 SSE 无法满足这些条件。

核心差异在于传输协议与对可靠性的取舍。WebSocket 基于 TCP，保证数据可靠有序。但在丢包环境下，TCP 会产生队头阻塞，丢包会导致后续数据等待重传，在语音场景中会造成严重延迟。SSE 是单向文本流，不匹配双向音频需求。WebRTC 基于 UDP 传输，牺牲一定可靠性，允许在网络拥堵时丢弃部分音频帧，以此保证对话实时性。

此外，WebRTC 内置了专为语音通信设计的组件。它集成了抖动缓冲、丢包隐藏以及回声消除机制，支持 Opus 等低码率音频编解码器，并通过 ICE 机制实现 NAT 穿透。典型的语音 Agent 链路中，音频流走 WebRTC 传入，经流式语音识别、大模型处理、流式语音合成后，再经由 WebRTC 回推给客户端。信令交互与文本传输则配合使用 WebSocket。

最后可以这样收束：实时语音的核心是低延迟，WebRTC 放弃绝对可靠性换取音频流顺畅，结合内置处理机制，构成了语音 Agent 的基础设施。

面试官会怎么追问

• 「既然 WebRTC 是点对点协议，Agent 服务端怎么和客户端建立连接？」 业务中通常将服务端作为虚拟对等端接入。服务端运行 WebRTC 协议栈，通过信令交换 SDP 信息建立连接。建立后，客户端将音频流发送给服务端，服务端解包后送入模型链路处理。
• 「如果用户网络环境很好，是不是直接用 WebSocket 传音频也可以？」 网络环境好时 WebSocket 确实能传音频，但真实场景中网络抖动是常态。WebSocket 缺乏内置的抖动缓冲、回声消除和丢包隐藏等算法。若强行使用，开发者需在应用层重新实现这些机制，工程成本高且效果不如 WebRTC。
• 「你提到信令可以使用 WebSocket，WebRTC 为什么不自己把信令也做了？」 WebRTC 标准将信令层留空，不规定具体的传输协议，只负责媒体流的建立和传输。这种设计使得业务可以灵活选择信令通道。开发者通常复用现有的 WebSocket 接口来交换网络信息和媒体配置。

回答的坑

不要只说 WebRTC 速度快，必须指出 WebSocket 基于 TCP 带来的队头阻塞是语音卡顿的核心原因。 不要将 SSE 视为双向通信协议，SSE 仅支持服务器向客户端的单向文本流推送，无法用于音频流上传。