Building Enterprise Realtime Voice Agents from Scratch: A Technical Tutorial

本文提供了一份从零构建企业级实时语音代理的技术教程，通过系统分析指出原生端到端语音模型延迟过高，而采用流式级联架构（Deepgram 语音识别 + vLLM 流式 LLM 推理 + ElevenLabs 流式语音合成）是实现低延迟（P50 约 947ms）的关键，并发布了包含完整可运行代码的开源项目。

要点

这篇论文其实是在教我们如何从零开始搭建一个“像真人一样”的实时语音 AI 助手（比如能帮你挂号、查订单的 AI 客服）。

作者来自 Salesforce AI 研究团队，他们发现虽然市面上有很多现成的工具，但没人把“怎么把这些零件拼成一个能实时对话的系统”讲清楚。

为了让你轻松理解，我们可以把这个过程想象成经营一家“极速语音餐厅”。

1. 核心挑战：为什么“现成的”不行？

在开始之前，作者先排除了一个看似很酷的方案：“端到端”的语音模型（比如 Qwen2.5-Omni）。

• 比喻：这就像你点了一道“分子料理”，厨师（AI）必须先在脑子里把整道菜（整段话）完全想好，然后一次性把整盘菜端上来。
• 问题：虽然这道菜很精致（音质好），但太慢了。等你听到第一句话，可能已经过了 13 秒。在餐厅里，如果客人点菜后等了 13 秒才听到第一句“欢迎光临”，客人早就饿晕了。
• 结论：这种“想完再说”的模式，不适合需要实时对话的场景。

2. 解决方案：流水线作业（Cascaded Pipeline）

作者提出的方案是：流水线作业。

• 比喻：想象餐厅里有三个员工，他们不是等整道菜做完再端，而是边做边传：

  1. 服务员（STT - 语音转文字）：客人刚开口，服务员就立刻把听到的词记下来，一边记一边传给后厨。
  2. 主厨（LLM - 大语言模型）：听到几个词，主厨就开始思考，并立刻把想好的第一句话写在纸条上，传给下一站。
  3. 传菜员（TTS - 文字转语音）：纸条一到手，立刻把文字变成声音，先让客人听到第一句，同时主厨还在写后面的内容。

• 效果：客人不需要等整道菜（整段回答）做完，只要第一句话准备好了，就能立刻听到。这就实现了“实时感”。

3. 这个系统的三个关键零件

作者用三个具体的工具搭建了这个流水线：

1. Deepgram (超级速记员)：
   • 负责听客人说话。它非常敏锐，能把客人的语音实时变成文字，而且能区分“客人还在说”和“客人说完了”。
2. vLLM 服务的 LLM (超级大脑)：
   • 这是 AI 的核心。它负责理解客人的意图（比如“我要挂号”），并调用工具（比如查医生排班）。
   • 关键点：它必须支持“流式输出”，就是像挤牙膏一样，挤出一个字就传一个字，而不是等挤完一整管牙膏再传。
3. ElevenLabs (超级播音员)：
   • 负责把主厨写好的纸条变成声音。它也是“边写边读”，不需要等整段话写完才开始发声。

4. 那个神奇的“句子缓冲区”

这是整个系统最巧妙的地方。

• 比喻：主厨（LLM）写纸条的速度很快，但传菜员（TTS）一次只能读一句话。如果主厨写得太快，传菜员会手忙脚乱。
• 解决方案：在中间加了一个**“句子缓冲区”**（Sentence Buffer）。
  • 它像一个智能分拣员：它会把主厨写出来的零碎单词先攒着，直到攒满了一个完整的句子（比如看到句号、感叹号），才把这一整句交给传菜员去读。
  • 这样既保证了语法的完整，又让传菜员能立刻开始工作，不会卡顿。

5. 最终成果：快到什么程度？

通过这种“流水线 + 实时传输”的方式，作者搭建的系统达到了惊人的速度：

• 从客人开口到 AI 说出第一句话，平均只需要 0.75 秒（750 毫秒）。
• 相比之下，如果用那种“想完再说”的旧模式，需要 13 秒 以上。
• 功能强大：这个 AI 不仅能聊天，还能真正干活（比如查数据库、预约时间），因为它接入了“函数调用”功能。

6. 总结：这篇论文想告诉我们什么？

1. 别迷信“全能模型”：目前最酷的“语音直接变语音”的模型，虽然听起来很未来，但太慢了，不适合做实时客服。
2. 速度来自“配合”：真正的实时感，不是靠某一个超级快的零件，而是靠三个零件同时工作、互相接力。
3. 核心是“流”：就像水管一样，水（数据）要一直流动，不能堵在任何一个环节。
4. 开源教程：作者不仅讲了理论，还把所有代码都公开了，就像把餐厅的装修图纸、员工手册、甚至后厨的配方都免费发给了大家，教你怎么一步步搭建这样一个系统。

一句话总结：
这就好比作者告诉你，别指望一个超人能同时做完所有事（太慢），而是要组建一个配合默契的三人小组（听、想、说），让他们边做边传，这样就能让 AI 像真人一样，在你话音刚落时，立刻给出回应。

技术摘要

这是一份关于 Salesforce AI Research 发布的论文《从零构建企业级实时语音代理：技术教程》（Building Enterprise Realtime Voice Agents from Scratch: A Technical Tutorial）的详细技术总结。

1. 研究背景与问题 (Problem)

随着大语言模型（LLM）推理和工具使用能力的增强，业界对能够自然对话并执行复杂任务（如预约、查库、订单管理）的实时语音代理需求激增。然而，现有的技术生态存在以下关键缺口：

• 组件与系统的割裂：虽然存在 25+ 种开源的“语音到语音”（Speech-to-Speech, S2S）模型（如 Qwen2.5-Omni, Moshi 等）和多种代理框架（如 Pipecat, LiveKit），但缺乏一个从零开始、解释每个组件内部原理并整合成完整实时语音代理的教程。
• 现有方案的局限性：
  • 原生 S2S 模型：虽然架构优雅，但推理延迟过高，且普遍缺乏函数调用（Function Calling）能力，难以满足企业级复杂任务需求。
  • 现有框架：多为“即插即用”的黑盒工具，未深入讲解流式处理（Streaming）和流水线（Pipelining）的内部机制。
  • 评估框架：多基于非实时的轮转式（Turn-based）语音流程，无法反映真实实时交互的延迟挑战。
• 核心挑战：构建实时语音代理的难点不在于语音本身，而在于低延迟的流式处理架构以及LLM 代理的推理与工具调用。

2. 方法论 (Methodology)

作者通过系统性调查和实证分析，提出并实现了一种级联流式流水线（Cascaded Streaming Pipeline）架构，而非依赖单一的原生语音模型。

2.1 架构设计

语音代理被定义为 LLM 代理 + 语音 I/O 层。

• 核心公式：语音代理 = (推理 + 工具) + (STT + TTS + 流式传输)。
• 流水线流程：
  1. **流式语音转文本 **(Streaming STT)：使用 Deepgram (Nova-3) 接收音频流，实时输出最终确认的文本片段。
  2. **流式大语言模型 **(Streaming LLM)：使用 vLLM 部署的 LLM（如 Qwen2.5-7B），通过 Server-Sent Events (SSE) 逐 Token 生成文本，并支持函数调用。
  3. **句子缓冲 **(Sentence Buffer)：这是关键组件。它累积 LLM 生成的 Token，直到检测到完整的句子边界（标点符号 + 空格），避免将碎片发送给 TTS。
  4. **流式文本转语音 **(Streaming TTS)：使用 ElevenLabs (eleven_turbo_v2_5) 接收完整句子并立即开始合成音频流，同时 LLM 继续生成后续内容。
  5. 并发执行：STT、LLM 和 TTS 三个组件并行运行，重叠执行时间，从而大幅降低端到端延迟。

2.2 关键组件实现

• **语音活动检测 **(VAD)：使用 Silero VAD 模型检测用户说话状态，实现自然的打断（Interruption）和轮流对话机制。
• WebSocket 通信：服务器与浏览器客户端通过 WebSocket 传输二进制音频帧（PCM int16），控制消息通过 JSON 传输。
• 企业级功能：实现了递归的工具调用循环，支持预约、查询等复杂任务，这是原生 S2S 模型目前无法做到的。

2.3 对比实验

作者对比了原生 S2S 模型（以 Qwen2.5-Omni 为例）与级联流式流水线：

• Qwen2.5-Omni：采用"Thinker-Talker"架构，但 Talker 部分无法增量生成音频，必须等待整句文本生成完毕。
• 级联方案：利用流式传输和流水线并行，实现“边想边说”。

3. 主要贡献 (Key Contributions)

1. 全面的现状调研：调查了 25+ 种 S2S 模型和 30+ 种语音代理框架，明确指出原生模型缺乏函数调用支持且延迟过高，而级联方案是当前的最优解。
2. 实证分析：通过实验证明原生 S2S 模型（如 Qwen2.5-Omni）的首次音频延迟（TTFA）高达 13 秒以上，无法满足实时交互；而级联方案可将延迟降至亚秒级。
3. 完整的开源教程：发布了一个包含 9 个章节的渐进式教程，提供了从 STT、LLM 流式生成、TTS 到 WebSocket 服务器、VAD 和 Web 客户端的完整、可运行、经过测试的代码。
4. 工程最佳实践：揭示了构建实时语音代理中的关键工程细节（如 Sentence Buffer 的设计、VAD 状态机、流式协议处理等）。

4. 实验结果 (Results)

实验在 NVIDIA A10G GPU 和云端 API 环境下进行了严格测试：

• **首次音频延迟 **(TTFA)：

  • 级联流水线（本方案）：
    • 使用云端 LLM (GPT-4.1-mini)：P50 为 958ms，最佳情况 715ms。
    • 使用自托管 vLLM (Qwen2.5-7B)：P50 为 947ms，最佳情况 729ms。
    • 实测端到端流水线延迟：755ms。
  • **原生 S2S 模型 **(Qwen2.5-Omni)：
    • 批量模式：~26,500ms。
    • 句子级流式：~13,200ms。
  • 结论：级联方案比原生 S2S 方案快约 17 倍。

• 组件延迟分解：

  • Deepgram STT (P50): ~337-402ms。
  • LLM 首 Token 延迟 (TTFT, P50): ~337-457ms。
  • ElevenLabs TTS (TTFB, P50): ~219-221ms。
  • 关键发现：LLM 的延迟方差最大（尤其是冷启动），而 TTS 最为稳定。

• 功能支持：级联方案完美支持函数调用（Function Calling），能够处理多步工具链任务，而原生 S2S 模型目前均不支持此功能。

5. 意义与结论 (Significance & Conclusion)

• 重新定义“实时”：论文指出，“实时”并非来自某个单一的超快模型，而是来自流式传输（Streaming）。通过让 STT、LLM 和 TTS 并行工作，用户感知到的响应几乎是即时的。
• 架构选择：对于企业级应用，级联流水线（STT → LLM → TTS）是目前唯一可行的方案，因为它在保持低延迟的同时，提供了原生 S2S 模型所缺乏的复杂推理和工具调用能力。
• 教育价值：该工作填补了学术界与工业界之间的空白，提供了一个从底层原理到生产级实现的完整参考，帮助开发者理解如何构建低延迟、高可用的语音代理系统。
• 未来展望：虽然原生 S2S 模型在架构上更优雅，但在推理速度和功能完备性上仍有巨大差距。在技术成熟之前，优化的级联流水线是构建企业级实时语音代理的标准路径。

总结：这篇论文不仅是一个技术教程，更是一份关于如何构建高性能语音代理的“工程蓝图”。它通过数据证明了流式级联架构的优越性，并开源了全套代码，极大地降低了构建企业级实时语音代理的门槛。