语音交互模式:AI Agent 的 Voice/Talk 架构
语音交互模式:AI Agent 的 Voice/Talk 架构
概述
语音交互模式(Voice/Talk Architecture)使 AI Agent 能够通过语音而非文本与用户进行自然对话。与纯文本交互不同,语音系统需要处理音频流的捕获、编码、传输、识别、理解、合成和回放,形成完整的双工通信链路。
分层架构
语音交互系统通常采用四层架构,将关注点从物理音频到业务逻辑逐层分离。
Talk Mode:三种交互模式
| 模式 | 描述 | 适用场景 |
|---|---|---|
| Realtime | 直接连接提供实时 API 的模型(如 OpenAI Realtime API),语音输入到语音输出端到端处理 | 低延迟对话、情感丰富的回复 |
| STT-TTS | 分别使用独立的 STT 和 TTS 提供商,Agent 处理中间的文本理解与工具调用 | 多模型组合、自定义处理管线 |
| Transcription | 仅转录模式,将语音转为文本供 Agent 处理,不生成语音回复 | 语音笔记、会议记录 |
Talk Transport:四种传输方式
| 传输方式 | 协议 | 特点 |
|---|---|---|
| WebRTC | SDP 协商 + ICE 穿透 | 低延迟、P2P 直连、支持 NAT |
| Provider WebSocket | JSON-PCM WebSocket | 简单、适合服务端到服务端的连接 |
| Gateway Relay | 网关代理转发 | 适合移动设备通过网关中转 |
| Managed Room | 第三方托管房间(如 LiveKit) | 多参与者、服务端管理混流 |
Talk Brain:三种处理策略
| 策略 | 描述 |
|---|---|
| Agent Consult | Agent 处理每个话轮,生成文本回复,支持工具调用 |
| Direct Tools | 工具调用绕过 Agent 文本生成,直接返回结果(如查询天气) |
| None | 透传模式,音频流直接转发,不经过 Agent 处理 |
音频编解码
语音系统涉及两种核心音频格式:
- PCM16 @ 24kHz:高质量音频,适合 TTS 输出和本地处理
- G711 μ-law @ 8kHz:电话编码格式,带宽效率高,适合 VoIP 传输
PCM 重采样使用 sinc 带限重采样器:
- 31-tap Kaiser 窗滤波器
- 电信目标码率:8kHz
- μ-law 编解码用于电信传输
语音唤醒(Voice Wake)
语音唤醒是语音交互的入口机制:
- 唤醒词检测:设备端持续监听音频流,检测到预设唤醒词后激活 Agent
- 路由机制:网关广播
voicewake.changed和voicewake.routing.changed事件到连接的节点客户端 - Talk 模式触发:唤醒后自动进入 Talk Session,开始捕获用户语音
设计考量
| 考量 | 方案 |
|---|---|
| 隐私 | 设备端处理,音频不发送到云端直到唤醒 |
| 功耗 | 低功耗监听模式,仅在检测到唤醒词后激活 |
| 误触发 | 多模型交叉验证,降低误报率 |
| 网络依赖 | 唤醒检测在本地执行,后续交互需要网络 |
话轮管理(Turn Management)
每个语音对话由一系列话轮组成,每个话轮有唯一标识:
关键事件
语音系统定义了 29 种事件类型,覆盖完整生命周期:
| 类别 | 事件 |
|---|---|
| 会话 | session.started, session.ready, session.closed, session.error, session.replaced |
| 话轮 | turn.started, turn.ended, turn.cancelled |
| 捕获 | capture.started, capture.stopped, capture.cancelled, capture.once |
| 音频 | input.audio.delta, input.audio.committed, output.audio.started, output.audio.delta, output.audio.done |
| 转录 | transcript.delta, transcript.done |
| 工具 | tool.call, tool.progress, tool.result, tool.error |
| 指标 | usage.metrics, latency.metrics |
Barge-in(打断)处理
语音交互中的打断处理是关键的用户体验特性:
- 音频播放标记:使用 Mark 策略检测音频播放状态
- Mark 策略:
transport:将标记转发到输出接收器ack-immediately:自动确认标记ignore:忽略标记
- 强制打断:检测到用户语音输入时,强制清除当前输出缓冲
- 多通道答案抑制:使用
suppressResponse选项避免在多个通道中重复回复
TTS 系统
文本转语音系统的设计要点:
| 组件 | 说明 |
|---|---|
| 提供商解析 | 通过插件能力系统解析 realtimeVoiceProviders / ttsProviders |
| 令牌预算 | TTS 前使用文本摘要适配令牌限制 |
| 流式输出 | 支持增量 TTS 输出,减少首字节延迟 |
设计权衡
Realtime vs STT-TTS
| 维度 | Realtime | STT-TTS |
|---|---|---|
| 延迟 | 极低(端到端优化) | 中等(多跳处理) |
| 灵活性 | 受限于单一提供商 | 可组合最佳 STT + TTS |
| 成本 | 通常较高 | 可优化成本 |
| 工具调用 | 内置支持 | 需要 Agent 中转 |
| 语音质量 | 取决于提供商 | 可独立选择高质量 TTS |
传输方式选择
| 场景 | 推荐传输 |
|---|---|
| Web 应用 | WebRTC |
| 移动应用 | Gateway Relay |
| 服务端集成 | Provider WebSocket |
| 多人会议 | Managed Room |