从零搭建 500ms 以内延迟的语音 Agent，一个人一天就够了
做 ofox.ai（多模型聚合平台）让我养成了一个习惯：看到有意思的 AI 应用就想拆解它的技术栈。最近 Hacker News 上一篇文章引起了我的注意——一个开发者用一天时间、大约 100 美元 API 费用，从零搭建了一个端到端延迟低于 500ms 的语音 Agent，而且性能比商业平台 Vapi 快了 2 倍。
这不是一个玩具 demo，而是一个可以投入生产的语音交互系统。它让我重新思考：语音 Agent 的门槛到底在哪里？
语音 Agent 为什么难
和文本聊天不同，语音对话没有明确的”发送”按钮。人说话会停顿、会犹豫、会中途打断，系统必须实时判断：用户说完了吗？该我回答了吗？
这就是所谓的 turn-taking 问题，也是语音 Agent 最核心的难点。
整个流水线包含三个环节：
- STT（语音转文字）：把用户的语音实时转写成文本
- LLM（大模型推理）：理解意图并生成回复
- TTS（文字转语音）：把回复转成自然的语音播放
每个环节都有延迟，叠加起来很容易超过 1 秒。而人类对话中，正常的响应间隔只有 200-300ms。超过 800ms 用户就会明显感觉”卡”。
关键优化：流式串联 + 地理位置
这位开发者的核心思路是 流式处理（streaming）。不是等 STT 完整输出再送给 LLM，也不是等 LLM 生成完整回复再送给 TTS，而是每个环节产出一小段就立即传给下一环节。
具体来说：
- STT 用 Deepgram：支持实时流式转写，延迟极低
- LLM 用 Claude/GPT 的 streaming API：token 级别的流式输出
- TTS 用 ElevenLabs 或 Cartesia：支持流式合成，拿到一句话就开始播
三者并行流动，而不是串行等待。这把端到端延迟从秒级压缩到了 400ms 左右。
另一个容易被忽视的因素是 地理位置。API 服务的服务器分布在不同区域，如果你的服务部署在亚洲，但 STT 和 LLM 的服务器都在美东，光是网络往返就要吃掉几百毫秒。把部署位置和 API 服务器放在同一区域，延迟立刻下降。
开源方案 vs 商业平台
市面上已经有不少成熟的语音 Agent 平台：Vapi、ElevenLabs Conversational AI、Retell 等。它们提供开箱即用的体验，但也意味着你把延迟优化、模型选择、turn-taking 策略的控制权都交了出去。
自己搭建的好处很明确：
- 延迟可控：可以针对场景精细调优每个环节
- 模型可换：STT、LLM、TTS 各环节独立选型，哪个好用哪个
- 成本透明：清楚知道每个 API 调用花了多少钱
代价也很明确：要处理中断检测、静音判断、错误恢复、并发管理等一系列工程问题。
语音 Agent 的下一步
2026 年语音交互正在从”语音助手”进化到”语音 Agent”。区别在于：助手只回答问题，Agent 能执行任务。
想象一下：你对着手机说”帮我把下周三的会议改到周四，然后通知所有参会者”，Agent 不只是理解了你的意思，而是真的去操作日历、发通知、处理冲突。
这需要的不只是低延迟，还有可靠的 function calling、上下文管理和错误处理。目前的语音 Agent 还在解决”听清楚、说流利”的问题，但”做对事”才是更大的挑战。
写在最后
语音 Agent 的技术栈正在快速成熟。一个人、一天、100 美元就能搭出接近商业水准的系统，这在一年前还不可想象。瓶颈正在从”能不能做”转向”做得好不好”——延迟优化、自然度、多轮对话的连贯性，这些细节决定了用户体验的天花板。
对于想入局语音 AI 的开发者，现在是一个很好的时机：基础组件已经足够好，差异化竞争的空间还很大。