“用户说话→转文字→丢给大模型→把回答播出来”，跑通这条链路只需三段 API 调用；但做出可用的语音 Agent 是实时系统工程——延迟预算以百毫秒计，用户随时打断，噪声与回声随时干扰。本文讲清语音链路的延迟构成、流式设计的必要性、打断处理与端到端模型的演进方向。

语音链路总览

级联式语音 Agent 的完整链路是：麦克风采集 → 前处理（回声消除 AEC、降噪 NS、自动增益 AGC）→ VAD 判断说话边界 → 流式 ASR 转写 → LLM 理解与生成（可带工具调用）→ 流式 TTS 合成 → 客户端边收边播。VAD（语音活动检测）不识别内容，只输出”开始说话/说话结束”这类控制信号，却直接决定对话节奏：静音判定太短会切断自然停顿，太长则每轮交互都慢半拍。

端到端延迟的构成

文字聊天慢一秒用户能忍，语音对话慢一秒就像”对面没反应”。一轮交互的延迟来自各环节叠加：

环节 主要耗时来源 优化方向
采集与编码 音频帧大小、上行分块 小帧采集，分块不宜过大
VAD 端点检测 静音确认等待 动态阈值，结合 ASR 增量结果
ASR 上传、解码、转写稳定 流式识别、业务热词
LLM 首 Token 延迟、工具调用 Prompt 缓存、先说短句、异步工具
TTS 首包合成、声码器推理 句子级流式合成
播放 网络抖动、缓冲 边收边播、控制播放队列

每段多 200 ms，整轮就是”慢半拍”。优化要盯端到端 P95/P99，而不是单个组件的跑分。

为什么必须流式

非流式方案下，总延迟 = 说话时长 + 整段识别 + 整段生成 + 整段合成，任何一个长回答都会让等待失控。流式把等待拆散：ASR 边说边出增量结果，出现稳定前缀就能提前做意图预判；LLM 边生成边按句切分，凑够一个完整句子立刻提交 TTS；TTS 边合成边推音频分片，客户端入队即播。首段语音不必等整段回答生成完毕，体感延迟被压缩到”端点检测 + 首 Token + 首包合成”之和。慢工具调用期间还可以先播一句过渡语（”我查一下最近的订单”），进一步掩盖等待。

打断（Barge-in）处理

真人对话可以互相插嘴，语音 Agent 必须支持打断。打断不是暂停按钮，它有三层语义：

  1. 播放层：立刻停掉本地播放、清空未播队列，不能继续播旧回答；
  2. 生成层：取消服务端仍在运行的 LLM 与 TTS 流，否则会出现”一边听新问题、一边播旧答案”的混乱；
  3. 上下文层：按播放进度记录”已播出到哪句”，未播出的内容不能当成”已说过”写进对话历史。

实现难点在检测端：AI 播放的声音被麦克风回收会触发误打断，需要 AEC 与播放参考信号配合；简单的”AI 说话期间丢弃麦克风音频”又会把真实插话一并丢掉。较稳妥的做法是在 AEC 处理后的音频上跑端侧 VAD，结合置信度与播放状态判断是否为真实插话。从状态机看，打断是几乎可从任何状态进入的控制事件；若打断发生在写工具执行中途，还要有幂等、补偿或人工确认流程兜底。

端到端语音模型的演进方向

级联链路（ASR→LLM→TTS）的优势是中间过程可观测、可审计、组件可独立替换，代价是延迟叠加、文本中间层丢失语气与情绪。以 OpenAI Realtime API、Gemini Live、Qwen-Omni 为代表的原生 Speech-to-Speech 模型把音频进、音频出融进统一多模态链路，端到端延迟与自然度更好，还能保留副语言信息；代价是中间过程更黑盒、文本审计需额外设计、私有化部署受限。

另两条演进路线：一是端云混合，把 VAD、固定提示音、断网兜底下沉到端侧，复杂理解与统一审计留在云端；二是本地部署开源 ASR/TTS（如 faster-whisper、CosyVoice）满足数据合规，但要自行承担流式推理与容量压测的工程成本。务实建议是先把级联链路跑通并建立延迟与成本基线，再按瓶颈评估是否引入原生实时模型，不要第一天就上混合架构。

小结

  1. 语音 Agent 是实时系统，延迟预算按全链路 P95/P99 管理，而非追求单组件最优。
  2. 流式是体感的根基：ASR 增量输出、LLM 按句切分、TTS 按片合成、客户端边收边播。
  3. 打断要同时处理播放、生成、上下文三层语义，并解决回声导致的误触发。
  4. 级联链路可观测、易审计，原生端到端模型在延迟与自然度上更优，按实时性、合规与运维能力取舍。