简诗低延迟语音助手设计

实时语音应用的核心矛盾

语音助手的体验是两极分化的：要么像魔法一样即时响应，要么因为肉眼可见的延迟而让人瞬间失去耐心。当你还在说话时，系统却要等整句识别完才慢吞吞地开始生成回复，最后再整段播放出来——这种体验是毁灭性的。用户会停顿、打断，然后怀疑自己面对的到底是一个智能系统，还是一个笨拙的电话录音。

问题的根源在于，实时语音不是把几个模块串起来就行。它需要对延迟预算进行精细编排。从用户开口到听到回复的每一毫秒都需要被考虑。

技能如何工作

这个技能围绕几个关键架构决策展开：

流式处理是硬性要求
非流式管道会引入数秒延迟，彻底破坏对话节奏。技能要求全链路流式：

• STT 输出 interim results（中间结果）
• LLM 使用 token streaming 逐词生成
• TTS 采用 chunk streaming，在 LLM 还没输出完时就开始合成

打断处理（Barge-in）
忽略用户打断是严重的体验缺陷。技能指导实现 VAD（语音活动检测）来识别用户开始说话，立即停止 TTS 播放并清除音频队列，让对话保持自然。

多供应商组合优于单一锁定
没有单一供应商在所有维度上都最优。技能推荐混合方案：

• Deepgram 做 STT（速度 + 准确率）
• ElevenLabs 做 TTS（语音质量）
• OpenAI/Anthropic 做 LLM（推理能力）

此外，技能覆盖 OpenAI Realtime API（GPT-4o 原生语音到语音）、Vapi（电话代理与快速部署）、LiveKit 与 WebRTC 实时音频基础设施。

适用边界与注意点

延迟受供应商和网络状况影响，存在波动。每分钟成本会持续累积。调试复杂度高，因为管道跨越多个服务和音频处理阶段。质量高度依赖部署环境的网络条件。