如何构建低于500毫秒延迟的语音Agent（读书笔记）

作者：Nick Tikhonov | 来源：ntik.me | 发布日期：2026年2月9日

概述

Nick Tikhonov是一位创业者，在过去六个月中与一家全球消费品公司合作构建Agent原型。他使用了现成的语音Agent平台如Vapi和ElevenLabs，但逐渐意识到这些平台隐藏了大量复杂性。恰逢ElevenLabs获得大额融资和新一代前沿模型发布，他决定自己动手构建一个语音Agent的编排层。

结果令人惊讶：他仅用约一天时间和100美元的API积分，就构建出了一个延迟约400ms的语音Agent，在延迟上比Vapi的同等配置快2倍。

为什么语音Agent很难

与文本Agent相比，语音Agent的复杂度有质的飞跃。

文本 vs 语音的根本差异

文本Agent的用户行为自然地协调了整个流程：用户阅读模型输出的文字，打字回复，点击发送——这个动作自然地定义了对话轮次的边界。在文本交互中，直到用户主动推进流程，系统不需要做任何事情。

语音Agent则完全不同。编排是连续的、实时的，必须同时精心管理多个模型。系统在任何时刻都必须回答一个核心问题：用户是在说话，还是在听？ 这两种状态之间的转换才是真正困难的地方。

核心挑战：抢话处理

关键挑战在于抢话（barge-in）处理：

当用户开始说话时，Agent必须立即停止说话——取消生成、取消语音合成、刷新任何缓冲的音频
当用户停止说话时，系统必须自信地判断用户已经说完，并立即开始回应，延迟最小化

这不是简单地测量音量就能解决的。人类语言包含：

停顿、犹豫
填充词（"嗯"、"啊"）
背景噪音
非语言认可（"对"、"明白"）

随之而来的是所有人都能注意到的端到端延迟、尴尬的沉默、Agent打断用户或与用户同时说话等问题。

人类对语音交流质量的判断是潜意识的，因为这在我们的本质中根深蒂固。在文本中可以接受的小时间误差——这里的停顿，那里的延迟——在语音中会立即感觉不对。

在实践中，一个好的语音Agent不是关于任何一个单一的模型。这是一个编排问题。你将多个组件串联起来，体验的质量几乎完全取决于这些pieces在时间上的协调方式。

核心架构：轮次转换循环

Nick首先在ChatGPT中迭代架构，建立了一个心智模型。他将整个问题简化为一个循环和一个微状态机。

两种状态

一个语音Agent只需要回答一个问题：用户是在说话，还是在听？

系统有两种状态：

用户说话中 🗣️
用户倾听中 👂

两个转换

两个转换发生的地方：

当用户开始说话时 → 必须立即停止所有Agent音频和生成
当用户停止说话时 → 必须以最小延迟开始生成和流式传输Agent响应

第一步：VAD与预录制响应

Nick首先避开了转录、语言模型和文本转语音，选择了最简单的检查点。

技术栈

Web服务器：FastAPI
电话集成：Twilio（WebSocket，8kHz，μ-law音频，~20ms帧）
语音活动检测：Silero VAD（开源模型，约2MB）

工作原理

Twilio通过WebSocket流式传输音频
每个音频包被解码并输入Silero VAD
VAD判断当前音频是否包含语音
状态机（布尔标志）跟踪用户是在说话还是倾听
当检测到用户停止说话 → 播放预录制WAV
当检测到用户重新说话 → 发送clear信号刷新缓冲音频并立即停止播放

结果

即使没有转录或生成，这个循环已经感觉有些对话感了：

Agent在用户停止说话时立即响应
用户打断时Agent立即闭嘴

这也给了Nick一个有用的延迟基准：带有急切轮次结束和预录制响应的系统代表语音Agent可能感觉到的最低延迟边界。

VAD-only方法的局限性

检测语音的存在与知道用户何时完成思考是不同的：

一个说话慢的人可能会句子中间停顿几秒钟
纯VAD会急切地判断轮次已经结束并过早开始说话

实际上，真实的轮次转换需要将低级音频信号与转录本的高级语义线索结合起来。

第二步：Flux与真正的语音Agent管道

下一步是用专为生产设计的东西替换手写的轮次检测：Deepgram的Flux。

Flux的核心能力

Flux是一个流式API，将转录和轮次检测结合在一个模型中：

你向它提供连续的音频流
它发出事件——最重要的是"轮次开始"和"轮次结束"
最后包含最终转录本

Flux成为Agent应该什么时候说话、什么时候立即停止并倾听的真实来源。

Agent轮次管道

当Flux发出用户轮次结束的信号时，启动一个实时序列：

转录本 + 对话历史 → 发送给LLM开始生成
第一个token到达 → 立即通过WebSocket流式传输到TTS
TTS产生的每个音频包 → 直接转发到Twilio Socket

核心思想：尽可能地管道化每个流以最大程度减少延迟。

关键优化：保持连接温暖

建立到ElevenLabs的新WebSocket会增加几百毫秒的延迟，所以Nick保持一小池预连接的socket存活。这alone大约减少了300ms的响应时间。

打断处理（对称式）

当Flux检测到用户开始说话时：

取消LLM生成
拆除TTS
发送clear消息到Twilio刷新任何缓冲的音频
Agent立即沉默，Flux恢复监听

本地运行 vs 托管部署

本地运行（土耳其）

从土耳其本地运行，端到端延迟：

平均约1.6秒（服务器测量）
加上Twilio媒体边缘约~100ms
总感知延迟约1.7秒

这离Vapi的~840ms延迟相当远，慢了两倍多。对话开始变得犹豫，停顿刚好拉长到令人尴尬的程度。

托管部署（欧盟）

将系统部署到Railway的欧盟区域，并配置Twilio、Deepgram和ElevenLabs使用欧盟部署：

平均延迟降至~690ms
加上Twilio边缘约~790ms
超过2倍的改进！

作为比较，Vapi中同等配置估计约~840ms。在这个设置中，自定义编排实际上比Vapi自己的估计快约50ms。

模型选择：Groq的突破

TTFT（Time to First Token）的重要性

Nick之前使用gpt-4o-mini，似乎是OpenAI最低延迟的模型。但深入研究后发现：Groq的llama-3.3-70b推理延迟可能快3倍。

测试结果

在生产服务器上测试了360次聊天完成，在收到第一个token后立即取消请求：

供应商	首个Token延迟
Groq	~80ms（最快）
OpenAI	慢3倍

~80ms比人类眨眼还快——通常被引用为约100ms。

最终效果

用Groq的llama-3.3-70b替换gpt-4o-mini后：

平均端到端延迟约~400ms
回听录音，Agent回复比用户还快
打断处理感觉"戏剧性地更好"——Agent的声音几乎在用户开始说话后立即消失

技术要点总结

延迟优化

用户感受到的"响应性" = 从用户停止说话到听到Agent响应第一个音节的时间

这个路径经过：

轮次检测
转录
LLM首个token时间（TTFT）
文本转语音合成
出站音频缓冲
所有网络跳点

优化方法：识别哪些阶段在关键路径上，确保没有不必要的阻塞。

模型选择和TTFT

在语音系统中：

收到第一个LLM token是整个管道可以开始移动的时刻
TTFT占了一半多的延迟
选择像Groq这样的延迟优化推理设置产生了最大的差异
模型大小也很重要：更大的模型带来更明显的延迟成本

管道化Agent轮次

生产语音Agent不能作为 STT → LLM → TTS 三个顺序步骤构建。

Agent轮次必须是流式管道：

LLM token在到达后立即流入TTS
音频帧立即流向手机
目标：永远不不必要的阻塞生成

取消进行中的调用

打断处理必须立即传播到Agent轮次的所有部分：

取消LLM生成
拆除TTS
刷新任何缓冲的出站音频

遗漏任何一个都会使抢话感觉坏了。

地理位置是一等设计参数

一旦编排多个外部服务（电话、STT、TTS、LLM），位置主导一切：

如果这些服务没有co-located，延迟会迅速累积
移动编排层并使用正确的区域端点将端到端延迟减半

现成vs定制

这不是反对Vapi或ElevenLabs等平台的论点。这些系统提供：

API
可观测性
可靠性
深度配置选项

对于大多数团队来说，重建所有这些将是一个错误。

但自己构建语音Agent——即使是一个精简的——仍然是一个值得做的练习：

迫使你理解参数实际控制什么
理解为什么存在某些默认值
理解真正的瓶颈在哪里
这种理解使你更好地配置现成平台

语音是一个编排问题。一旦你清楚地看到循环，它就变成了一个可解决的工程问题。

源码

完整源代码已开源：github.com/NickTikhonov/shuo

观点存疑

技术可行性的普适性：作者在土耳其远程木屋搭建的环境与生产环境差异巨大。网络抖动、多区域部署兼容性、与各种电话网络的集成都是未经验证的。
成本核算不完整：虽然提到"~a day and roughly $100 in API credits"，但这只是原型阶段。真实产品还需考虑：可靠性工程、合规隐私、规模化边际成本、客户支持维护。
Vapi对比的公平性：声称"outperformed Vapi by 2×"但建立在对Vapi配置的假设上。Vapi可能优先考虑稳定性而非极致延迟。
Groq模型的可持续性：Groq的低延迟来自专用推理架构，但成本结构、长期可用性和扩展性尚待验证。