Voice AI 与实时语音 Agent：从拼装管线到可部署系统

Voice AI 与实时语音 Agent

flowchart LR
  A["Voice AI / 实时语音 Agent"]
  A --> B["分类：前沿探索"]
  A --> C["关键词：Realtime"]
  A --> D["关键词：Speech-to-Speech"]
  A --> E["关键词：低延迟"]
  A --> F["关键词：原生语音模型"]

三年前提到 AI 语音助手，大多数人想到的还是“能用，但不太想多聊”的系统。到 2026 H1，变化已经足够明显：语音交互不再只是给聊天模型外面套一层 ASR 和 TTS，而开始出现更适合直接部署的实时语音系统。

这篇文章会讲什么

如果你在 blog 里只读过 009 Tool Calling 和 029 Multi-Agent，就会发现整本博客里几乎没碰过语音。这是一个真实缺口——因为到 2025 年中，语音确实还停留在”传统 ASR + LLM + TTS 三段管线”的工程拼装阶段，没什么值得专门讲的。

过去一年里，语音这一支发生了几件足够重要的事：

OpenAI Realtime API 在 2025-08 已经走到 GA，并把 speech-to-speech、tool calling、MCP、图像输入、SIP 这些能力拉到同一个生产接口里
ElevenLabs、Hume、Sesame 这一类产品把语音交互的重点从“能说出来”推向“说得更自然、上下文更连贯”
Pipecat / LiveKit Agents 让自建实时语音 Agent 的工程门槛下降，不再需要从 WebRTC 底层自己拼起
多模态实时交互 也开始成形，语音不再是孤立输入，而是在和屏幕、图像、工具调用一起工作

这意味着实时语音 Agent 至少已经跨过了“只能 demo”那条线，进入了可以严肃讨论产品化和部署的阶段。

先说结论

传统三段式管线（ASR → LLM → TTS）正在被原生语音模型挑战——不是因为前者立刻失效，而是后者在延迟和自然度上开始更适合对话型产品
延迟依然是核心体验指标：当响应接近真人接话节奏时，对话质感会明显改善；一旦拖长，用户很快会感觉自己在“等系统处理”
大多数生产场景仍然是混合架构：原生语音 Agent 处理对话主线 + 传统管线处理某些专业场景（医疗听写、低资源语言）
语音 Agent 的工程难点不在模型，在 turn-taking / interrupt / 多模态融合——这些 WebRTC 层的事比 prompt 更难做对

1. 传统语音管线 vs 原生语音模型：架构上是两种东西

1.1 传统管线（2015–2024 主流）

用户语音 → ASR (Whisper / DeepGram) → 文本
                                       ↓
                                   LLM 生成文本回复
                                       ↓
                                   TTS (ElevenLabs / Azure)
                                       ↓
                                   合成语音 → 用户

延迟构成：

环节	典型延迟
ASR 检测语音结束（VAD）	200–500ms
ASR 转写完成	100–300ms
LLM 首 token	200–600ms
LLM 完整回复	1–3s
TTS 首音频段	100–300ms
端到端 TTFB	~1–2s

加起来”用户说完到第一个字出声” 一般在 1.5 秒上下，听感是”在等机器人想”。

1.2 原生语音模型（GPT Realtime / Sesame CSM / Gemini Live）

用户语音 ⟷ 原生 speech-to-speech 模型 ⟷ 用户
            （单一模型同时处理理解 + 推理 + 生成语音）

延迟构成：

环节	典型延迟
流式语音输入处理	持续
模型首音频 token	150–250ms
端到端 TTFB	~200–400ms

听感差异巨大：用户说话过程中模型已经在”想”，话音落下时模型几乎立刻接话——接近真人对话的节奏。

1.3 为什么原生语音模型能这么快

不是优化得更狠，是少了几个串行步骤：

不需要等”完整文本”才开始推理（流式接收音频特征）
不需要等”完整 LLM 回复”才开始合成语音（流式生成音频 token）
不需要 VAD 单独判断”用户说完了没”——模型自己感知 turn-taking
没有”文本 → 语音”中间损失（情绪 / 重音 / 笑声都能保留）

2. 主流实时语音方案 (2026 Q2)

方案	类型	延迟	优势	现实坑
OpenAI Realtime	原生	低延迟	工具调用、MCP、图像输入、SIP 都已进入正式接口	成本与会话治理仍要仔细算
Gemini Live	原生 / 多模态	低延迟	语音和视觉结合得更自然	可用范围与产品边界仍在变化
Sesame CSM	原生	低延迟	拟人感和语音表现力很受关注	商业化与接入细节不如大平台稳定
ElevenLabs Conversational	半原生 / 组合式	低延迟	声音表现和语音品牌感强	仍需和其它模型栈协同
Hume EVI	情绪导向	中低延迟	情绪感知和表达是亮点	不一定适合所有任务型场景
传统三段管线 (DeepGram + GPT + ElevenLabs)	拼装	~800ms–1.5s	完全可控、可换零件	延迟拐点之上，听感差
Pipecat / LiveKit Agents（自建）	框架	看你接的模型	完全自有、本地化、可接任意模型	需要 WebRTC 工程能力

2.1 选型经验

要最完整的生产接口：优先看 Realtime API 这类已经把工具、会话和接入方式做全的方案
要最强语音表现力：优先看 ElevenLabs / Hume / Sesame 这类更强调声音与情绪的产品
要看屏幕同时听语音（教学 / 客服远程辅助）：优先看多模态实时方案
要完全本地化 / 不出域：Pipecat + 本地 Whisper + 本地 TTS（如 Kokoro / OpenVoice），延迟会牺牲到 ~700ms 但可控
预算敏感、对话量大：传统三段式 + DeepGram Nova-3 + 一个便宜 LLM 仍是单价最低的选项

3. 工程难点：模型不是最难的，turn-taking 和 interrupt 才是

如果你以为接好 GPT Realtime API 就完事了，会很快踩到这些坑：

3.1 Interrupt（用户中途打断）

真实对话里，用户经常在 Agent 还没说完时打断。这件事难在：

怎么判断”用户是真的要打断”还是”只是”嗯""啊”的附和”
打断后 Agent 应该立刻停下，还是说完当前句子？
被打断的内容要不要进入 conversation history？

GPT Realtime / LiveKit Agents 都内置了 interrupt handling，但具体策略要根据场景调。

3.2 Turn-taking（轮次切换）

谁先说？什么时候算用户说完？这件事在传统管线里靠 VAD 硬判，在原生模型里靠模型隐式学习。但都有边界情况：

用户在长沉默后才补一句话
用户语速慢、停顿多
背景噪音让 VAD 误判
多人对话场景

3.3 Tool Calling 期间的”沉默问题”

Agent 在调用工具（查数据库 / 查日历）时，用户听到的是几秒钟的沉默。这听感非常糟糕。Q2 主流做法：

Filler audio：调用前先说”让我查一下”再发起 tool call
Streaming progress：边查边说”在查 X，预计还要 N 秒”
Background tool：把查询放后台，先继续对话直到结果回来

3.4 Barge-in 和 Echo Cancellation

用户在播放语音时说话，麦克风会同时录到自己设备播放的声音 + 用户声音，造成 echo。WebRTC 的 AEC（Acoustic Echo Cancellation）必须配置好，否则模型会把自己的回声当成用户输入。

3.5 多模态融合的”哪个先”问题

Gemini Live 这类同时接收视频 + 语音的 Agent，在工程上要解决：

视频帧采样率（5fps? 1fps?）
视频和音频的时间对齐
模型上下文成本（视频 token 比音频贵很多）

4. Voice Agent 适合做什么、不适合做什么

4.1 已经稳定可用的场景

场景	为什么适合
客服与电话支持	标准化对话、tool 接 CRM 已成熟
教育与口语练习	对话感是核心价值、错误容忍度高
车载与设备语音助手	双手不方便、场景天然语音
无障碍辅助	替代视觉交互、对延迟敏感但容忍轻度错误
会议记录与会中助手	流式 + tool calling + 长上下文都已具备

4.2 仍有明显问题的场景

场景	为什么还不行
高准确度听写（医疗 / 法律）	原生模型的 ASR 准确度不如专门 ASR；建议传统管线
超长对话（>30 分钟）	上下文成本快速上升，质量下降
多人会议中的发言识别（speaker diarization）	原生模型在多人辨识上仍不如专门方案
强专业术语（医学名词 / 化学式）	原生模型容易听错，仍要后处理

4.3 与 Computer Use Agent (073) 的关系

Voice Agent 和 Computer Use Agent 是两条互补线：

维度	Voice Agent	Computer Use Agent
输入	音频	截屏
输出	音频	鼠标 / 键盘
延迟要求	极高 (<400ms)	中等 (1–3s 可接受)
适合任务	对话型	操作型
典型场景	客服、教育	自动化办公、爬数据

2026 Q2 出现的一些”Voice + Computer Use 融合”产品（比如能同时听你说话 + 看你屏幕 + 帮你点按钮的 IDE 助手），是下一阶段值得关注的方向。

4.4 与 Hermes Agent (072) 的关系

Hermes Agent 目前主要走文本 gateway（Discord / Telegram / Email）。Voice gateway 是它在 roadmap 里的下一项——一旦接上，“24/7 个人 Agent + 实时语音”会是一个新形态。但这件事到 Q2 末仍未 GA，值得跟踪。

5. 一个最小生产架构（自建实时语音 Agent）

如果你要自建一个能上线的实时语音 Agent，这是 2026 Q2 最常见的最小架构：

浏览器 / App
    ↕ WebRTC
    LiveKit / Daily Cloud（信令 + 媒体转发）
    ↕
    Pipecat Agent Worker（Python / Node）
        ├─ Speech-to-Speech: GPT Realtime / Sesame CSM
        ├─ Tools: 通过 MCP 接业务系统
        ├─ Memory: 接 Honcho / Mem0 (参见 068 持久记忆)
        └─ Observability: 接 Langfuse / Helicone
    ↕
    业务系统（DB、CRM、日历）

几个工程要点：

WebRTC 媒体层用托管服务（LiveKit Cloud / Daily），别自建 TURN/STUN
Agent worker 用容器化部署，按 concurrent call 数水平扩展
每路通话有独立 session，不共享 LLM context
录音必须默认开启（合规需要 + 故障复盘需要）
告警重点关注：interrupt 失败率、tool 超时率、echo 误识别率——这三个指标比延迟更重要

6. 现实成本

GPT Realtime 在 Q2 的价格（参考）：

项	价格
音频输入	~$0.06 / 分钟
音频输出	~$0.24 / 分钟
文本输入（系统提示）	~$5 / 1M tokens
文本输出	~$20 / 1M tokens

实际场景估算：

一通 5 分钟的客服电话 ≈ $1–2 模型成本（不含 WebRTC 媒体费）
加上 LiveKit / Daily 媒体费 ≈ $1.5–3 / 通话
客户成本敏感时，建议传统三段管线（DeepGram + 便宜 LLM + ElevenLabs）能压到 $0.3–0.5 / 通话

这个差距在 2026 H2 大概率会缩小，因为各家都在压原生语音模型成本。

7. 仍未解决的几个问题

问题	现状	估计什么时候解决
超长对话的 context 成本	1 小时对话音频 token 量惊人	等扩散语音模型 / 更高效压缩
多语种能力不均	英语 / 普通话好，小语种差距大	2026 H2
真实情绪生成的边界（什么时候该笑 / 该叹气）	做得过头反而恐怖谷	长期问题
本地化大模型语音（在手机 / IoT 跑）	Phi-4 / MiMo Pro 接近能用	2026 H2
Voice + Vision + Tool 的真正一体化	仍是分散接入	2027

8. 给开发者的几条实用建议

不要用 ASR + LLM + TTS 这种三段管线给新项目重新写——除非你有强合规 / 本地化诉求。直接上 GPT Realtime 或 Pipecat
延迟拐点在 ~300ms 左右：低于这个数，用户会觉得”和真人聊”；高于这个数，听感掉一个档位
interrupt / turn-taking 会决定产品体验上限，比模型选择更重要
Tool calling 期间一定要有 filler audio，否则用户会以为掉线
录音和合规先行：实时语音的合规问题比文本 chat 复杂得多（GDPR / HIPAA / 录音同意）

小结

到 2026 Q2，实时语音 Agent 已经从”工程上能拼起来但体验差”走到”端到端原生模型 + 250ms 延迟 + 接近真人对话节奏”。这是过去 18 个月里 AI 用户体验变化最大的一条线。

但与此同时：

它不是”最强模型 + 最强 TTS”的简单加法——架构换了
延迟、interrupt、turn-taking 这些 WebRTC 层的事，比 prompt 难做对
成本仍是门槛：原生语音模型一通电话 $1–3 是普遍区间
应用场景已经清楚：客服、教育、车载、无障碍、会议记录都已可生产

如果你团队还没认真看过实时语音 Agent，2026 Q2 是一个明确的时间点：不再是”实验阶段”，而是”该不该做”的决策。