实时语音 Agent 开发完全指南：从 ASR/TTS 到 WebRTC/VAD 的链路拆解-港品优选

AI 语音知识点梳理（ASR/TTS/WebSocket/WebRTC/VAD/实时语音 Agent）

想让 AI 像真人一样和你对话？从麦克风采集到语音回复，中间藏着一条「毫秒级」的生死链路：ASR 听懂、LLM 思考、TTS 开口，还要在嘈杂环境里精准打断、抢话、防回声。本文一次性拆透 PCM/WAV、WebSocket/WebRTC、VAD、实时语音大模型与 Agent 架构，附关键指标与选型建议，助你快速上手实时语音开发。

ASR和TTS

ASR：Automatic Speech Recognition，自动语音识别，和 STT 基本同义，工业里 ASR 更常用。
TTS：Text To Speech。

对比项	传统 STT-LLM-TTS	Speech LLM
中间载体	文本，三段独立模型	语音 token，模型内部跨模态，可无显式文本
错误传播	STT 识别错误会传给后面 LLM	规避 STT 文本转写带来的错误传递
对语音信息	只保留文字内容，丢失语气/停顿	可以保留情绪、语速、韵律信息
模型结构	3 个分开模型	单个融合大模型（音频编码器 + LLM 主干）
边缘部署难度	低，模块可拆分调试	高，模型大、算子复杂，NPU 适配麻烦
适用场景	通用语音助手、机器人，工业落地主流	高质量语音对话、情感交互，前沿方案

常用 Python 库

STT 用faster-whisperPython 库；
TTS 支持 Kokoro / Piper / Supertonic 离线开源 TTS 模型，共 16 语言、56 个声音。

模型 / 工具	Python 库（pip 包名）	底层推理引擎
faster-whisper	faster-whisper	CTranslate2
Piper	piper-tts	ONNX Runtime
Kokoro	kokoro	ONNX Runtime
Supertonic	supertonic	ONNX Runtime

PCM 和 WAV 数据格式

PCM（脉冲编码调制，Pulse Code Modulation）

PCM 是原始的音频裸数据，没有任何文件头，纯声音采样值。
麦克风采集声音：声波 → 电信号 → 按固定频率采样，把连续模拟信号变成一长串数字样本，这串数字就是 PCM。

举个例子：

16bit、单声道、16000Hz 的 PCM：
采样率 16000：每秒采集 16000 个声音点
位深 16bit：每个声音点用 2 字节存储
单声道：只有一路声音
数据内容：[0x01,0x02,0xff,0x05……]，只有样本，没有任何描述信息

WAV（Waveform Audio File Format，波形音频文件）

WAV ≈ PCM 音频数据 + WAV 文件头。本质就是在 PCM 裸数据前面，加了一段固定长度的头部（44 字节最常见）。
头部里面写清楚音频参数：采样率、声道、位深、数据长度等信息。

浏览器可以直接播放 WAV。

WebSocket / WebRTC 两种模式

WebSocket（长连接，全双工）

先用一次 HTTP 请求完成握手，升级协议；
握手成功，TCP 连接保持不断开；
客户端、服务端任何一方都可以随时主动发数据。

客户端：持续把麦克风采集的音频分片推送给服务端（持续追加音频）
服务端：一边接收音频，一边跑 VAD（语音活动检测），检测到一句话说完、静音段时，触发这一轮语音识别，返回识别文本给客户端

WebRTC 协议栈

WebRTC：Web Real‑Time Communication，网页实时通信

WebRTC：整套实时通信技术集合；包含采集 API、传输协议、编解码一整套。
RTCPeerConnection 是 WebRTC 的核心 JS 类，new RTCPeerConnection()得到实例。
它内部统筹一整套事情：
执行 ICE：寻找网络通路（STUN/TURN）
DTLS：协商加密密钥
把传入的 MediaStreamTrack（麦克风音频轨道）打包成 RTP 数据包
SRTP：加密 RTP
收发 RTP 包、处理丢包、时间戳、抖动缓冲
接收远端过来的 RTP，解包，还原成 MediaStream 给播放器
RTP/SRTP 才是网络上传输的数据包格式；RTCPeerConnection 是生成、收发、管理这些包的管理器。

RTP：Real‑time Transport Protocol，实时传输协议

负责把音频/视频切成小包，带上时间戳，在网络上实时传输。特点：允许丢包，优先保证实时性（通话可以丢一点包，不能延迟太高）。WebRTC 传输音频的载体就是 RTP 包。

SRTP：Secure Real‑time Transport Protocol，安全实时传输协议

RTP 的加密版本。WebRTC 要求加密，所以实际传的是 SRTP，防止音频数据被网络窃听。

DTLS：Datagram Transport Layer Security，数据报传输层安全

作用：通信双方协商密钥，用来加密后面的 SRTP 包。类似 HTTPS 的 TLS，但 DTLS 是给 UDP 这种不可靠报文用的。

NAT：Network Address Translation，网络地址转换

路由器做的内网地址映射。NAT 将「私有 IP 地址」转换为「公有 IP 地址」（出方向），同时建立一张映射表，让返回的数据包能按原路转回（入方向）。

ICE：Interactive Connectivity Establishment，交互式连接建立

解决内网穿透问题：你的电脑在局域网（家里 / 公司路由器后面），怎么找到远端服务器并建立连接。ICE 会尝试多个候选地址，找到一条能通的网络路径。包含 STUN、TURN 两个子协议：

STUN：Session Traversal Utilities for NAT，NAT 会话穿透工具。拿到你的公网 IP。
TURN：Traversal Using Relays around NAT，中继。STUN 打不通时，走中转服务器转发数据。

音频捕获 / 前处理和 WebRTC

Media Capture and Streams API：负责从麦克风采集音频，可以传入 AEC/NS/AGC、采样率等约束。

WebRTC 协议：负责端到端的实时传输，包含 ICE、DTLS-SRTP、RTP 等协议。RTCPeerConnection 只管传输，不做音频降噪回声消除。

WebSocket PCM 流模式 vs WebRTC 模式对比

对比项	WebSocket PCM流模式	WebRTC模式
传输层	TCP	UDP（媒体流）
传输内容	裸 PCM 二进制样本	Opus 压缩音频，封装在 SRTP 包
音频编码	无编码，原始 PCM，体积大	浏览器自动 Opus 压缩，省带宽
丢包策略	TCP 必须重传，弱网下延迟持续上涨、容易卡死	允许丢包，不重传；内置丢包掩盖，优先保实时性
内网穿透 ICE	不需要，普通 HTTP/WS 端口即可	需要 ICE/STUN/TURN，处理 NAT 内网
抖动缓冲	自己在代码里实现，开发量大	浏览器底层自带抖动缓冲，处理网络抖动
开发复杂度	低。只需要采集 PCM 分片发送	高。要处理信令、SDP 协商、ICE 候选、异常断开
barge-in 打断	可以做，但弱网下 TCP 延迟会影响打断体验	原生更适合实时打断，延迟更低
适用场景	内网、稳定网络、Demo 快速开发；面试 Agent 原型	公网、弱网、长时间实时对话、生产环境
数据量	巨大：16k 16bit 单声道 PCM = 32KB/s	很小：Opus 通常几 KB/s~ 十几 KB/s

实时语音大模型

海外一体化实时语音 API

OpenAI Realtime API（OpenAI）

协议：WebSocket + WebRTC两种模式
- WebSocket：传输 PCM 二进制流
- WebRTC 模式：浏览器直接 new RTCPeerConnection，音频走 RTP/SRTP，不用自己处理 PCM 打包
特点：端到端语音模型，自带 VAD、工具调用、barge‑in 打断；支持多模态（语音 + 图片）
音频：输入 16kHz PCM，输出 24kHz PCM

Gemini Live API (Google)

协议：WebSocket (PCM 流)；第三方封装支持 WebRTC
输入：16 kHz PCM；输出：24 kHz PCM；多模态语音 + 图像实时对话

Azure Voice Live（微软）

协议：WebSocket，也支持搭配 WebRTC 信令
特点：微软 Azure 原生语音 Agent，和 Azure OpenAI Realtime 接口规范接近；内置 AEC/NS/VAD 等语音增强能力，中文支持不错，企业合规强。

国内一体化实时语音 API

Qwen-Audio / Qwen-Omni Realtime

协议：WebSocket，PCM 流输入输出；支持 WebRTC 接入
模型：qwen-audio-realtime、qwen-omni-realtime，原生语音到语音，自带 VAD，中文强。
输入固定 16kHz PCM，输出 24kHz PCM，和 OpenAI Realtime 音频格式对齐，迁移成本低

StepAudio Realtime

协议：WebSocket，原生流式全双工；支持硬件端低延迟流式接入
模型：StepAudio Realtime，原生语音到语音一体化模型，内置副语言感知 VAD，中文口语/对话节奏极强。

副语言感知 VAD = 不再只靠音量/静音时长判断有没有说话，而是由语音大模型原生同时听懂【文字语义 + 副语言声学信号（停顿、犹豫、轻笑、叹气、喘息、语气）】，来决定话轮切换、抢话打断、判断用户是否说完。

输入支持 16kHz PCM，输出 24kHz PCM；同时开放独立 ASR/TTS/AudioGen/Music 子模型接口，既可端到端语音对话，也能拆分单独调用，和 OpenAI Realtime 接口范式对齐，开发者迁移成本低。

VAD

VAD 语音活动检测（Voice Activity Detection）持续对每一小段音频做判断，输出两种状态：

语音段（speech）：检测到人声
非语音段（non‑speech /silence）：静音、环境噪音、呼吸声

端侧和服务端 VAD 可以组合使用，但并非固定架构。

狭义 VAD（纯模型）

给音频帧 → 返回概率。仅此而已，没有事件，没有状态。你拿到一串数字，自己写代码去判断什么时候说话开始、结束。

广义 VAD（完整组件）

VAD 神经网络（狭义 VAD）每一帧音频进模型，输出 0~1 概率：

帧1:0.02，帧2:0.04，帧3:0.71，帧4:0.82，帧5:0.78，帧6:0.41，帧7:0.15，帧8:0.08 ……

内置状态机（silent/speaking）持续记录当前状态，统计连续语音时长、连续静音时长，做防抖：
- 当前状态：silent
- 连续多帧概率 > 0.5，并且累计语音时长 ≥ 100 ms → 状态切换为speaking，抛出speech_start事件，带上时间戳，开始缓存音频。
- 之后概率回落，开始统计连续静音帧数；
- 当连续静音累计达到 500 ms → 状态切回silent，抛出speech_end事件。
额外辅助逻辑（广义 VAD 常附带）
- 异常帧过滤、音频采样率校验
- 事件防抖，防止概率抖动频繁来回切换状态
- 时间戳对齐，把帧索引换算成会话绝对时间

silero‑vad

silero‑vadPython 库内置状态机，你直接喂音频流，配置：

threshold：语音概率阈值
min_speech_duration_ms：最短有效语音
min_silence_duration_ms：静音等待时长

SDK 直接抛出speech_start/speech_end事件，或输出语音片段时间戳列表。

实时语音为什么比文字对话难这么多？

难点一：延迟预算非常紧

难点二：打断处理不是暂停按钮

识别出这是用户在说话，而不是背景噪声或扬声器回声
立即停止本地播放队列，不能继续把旧回答播完
取消服务端仍在生成的 LLM 和 TTS 流
把已经播放、未播放、被打断的内容写进对话状态
用新的用户音频开启下一轮理解

怎么让语音 Agent 支持打断

打断（barge-in）的三层含义

播放层打断：用户说话时，停止当前音频播放
生成层打断：取消服务端正在生成的 LLM 和 TTS
上下文层打断：正确记录已播放和未播放的内容

难点三：真实噪声环境比测试环境复杂太多

这会影响整条链路：

VAD 把噪声当成人声，导致误触发
ASR 把背景人声转成文本，污染用户意图
TTS 播放被麦克风采集，造成自我打断

缓解方案：

音频前处理三大核心算法（AEC / NS / AGC）

重点：AEC、NS、AGC 是浏览器本地音频预处理，属于 Media Capture API 的能力。

AEC：Acoustic Echo Cancellation，声学回声消除
你开扬声器播放 Agent 语音，声音又被麦克风录进去，形成回声。AEC 算法把这部分回声信号抵消掉。
NS：Noise Suppression，噪声抑制 / 降噪
过滤环境背景噪音（风扇、键盘、空调杂音），保留人声。
AGC：Automatic Gain Control，自动增益控制
自动调节麦克风音量：人离麦远就放大声音，离太近就压低，防止爆音、忽大忽小。

麦克风输入 │ ▼ ┌─────────────────────────┐ │ AEC (回声消除) │ 消除扬声器播放的声音 └─────────────────────────┘ │ ▼ ┌─────────────────────────┐ │ NS (噪声抑制) │ 压低背景噪声 └─────────────────────────┘ │ ▼ ┌─────────────────────────┐ │ AGC (自动增益控制) │ 让音量更稳定 └─────────────────────────┘ │ ▼ ┌─────────────────────────┐ │ VAD (语音活动检测) │ 判断是否有人声 └─────────────────────────┘ │ ▼ 编码输出

难点四：上下文不只是文字历史

当前用户是否正在说话
上一段回答播放到了哪里
用户是正常提问，还是正在打断
ASR 的增量文本是否稳定
用户语气是疑问、否定、犹豫，还是不耐烦
当前是否有工具调用正在执行

解决方案：
用 WebSocket 消息类型区分不同状态：
isFinal是 ASR 事件状态，true 只表示这一段 ASR 转写已经结束或稳定
如果产品采用手动提交，应由独立的control: 'submit' | 'cancel' | 'pause'事件确认；

难点五：AI 回声导致的误打断

缓解方案：

AI 说话时继续接收音频，但不发到 ASR
在 AEC 处理后的音频上运行端侧 VAD，而非原始麦克风音频
结合回声参考、连续帧能量、VAD 置信度和播放队列状态判断是不是用户真的在插话

难点六：端侧能力决定体验下限，云端模型决定上限。

端侧至少应该承担这些职责：

麦克风采集和音频前处理
VAD 或轻量打断检测
播放缓冲和取消播放
网络断开时的提示和重连

两种架构方案

方案一：级联式 ASR + LLM + TTS

音频 -> VAD -> 流式 ASR -> LLM -> 流式 TTS -> 音频

它适合的场景：企业知识问答、客服工单、需要合规审计的业务系统。

方案二：原生 Realtime Speech-to-Speech

音频 -> VAD -> 流式 ASR -> LLM -> 流式 TTS -> 音频

代表方案：OpenAI Realtime API、Gemini Live API、阿里通义 Qwen-Omni。

怎么设计一个实时语音 Agent？

链路：客户端采集音频，VAD 判断说话边界，ASR 流式转写，LLM 做意图理解和工具调用，TTS 流式合成，客户端边收边播。
难点：实时语音核心难点是端到端延迟、用户打断、噪声环境、上下文状态和端云协同。
状态机：需要管理 listening、thinking、speaking、interrupted 等状态，打断时要取消播放、取消生成，并处理已播放和未播放上下文。
选型：云端 API 上线快，本地模型可控但工程成本高；端云混合和 Speech‑to‑Speech API 是否合适，要根据延迟、合规、成本和可观测需求评估。

生产环境还要记录：

上行音频时长
有效人声时长
ASR token 或分钟数
LLM 输入输出 token
TTS 字符数、音频秒数、被打断秒数
每轮端到端延迟和取消次数

企业官网建设流程全解析