## 核心矛盾：链路太长

语音智能体（Voice Agent）的体验好坏，用户用"像不像打电话"来投票。核心矛盾就一个：链路太长。VAD 语音检测 → 流式 ASR → LLM 推理 → 流式 TTS → 音频播放，任何一环等"整句完成"才往下传，对话就会出现明显的"思考停顿"，体验立刻出戏。

## 全链路流式化：延迟优化的第一性原理

优化思路只有一条：别等，边做边传。

- ASR 边说边转写，LLM 拿到部分转写结果就开始推理，不必等用户说完整个句子；
- LLM 第一个 token 一出来，TTS 立刻开始合成首句音频，不必等整段生成完；
- 音频边合成边播放，首包音频尽快送达用户耳朵。

工程上还要抠细节：模型部署尽量靠近用户、长连接复用、音频编码选低延迟方案、减少不必要的中间转发。每一处省下的时间串起来，就是"跟得上"和"跟不上"的区别。具体数值因模型与部署架构而异，以实测为准，不要迷信某个固定指标。

## 打断处理：比延迟更影响体感

用户说话中途打断，系统要迅速停掉正在播放的 TTS、截断 LLM 生成、把已说内容纳入上下文。实现要点：

- **回声消除必须过硬**，否则用户听到的系统自己的声音会被误判为打断，陷入"自己打断自己"的死循环；
- 打断后只保留打断点之前的有效上下文，丢弃被打断的半截回复，别让半句话污染下一轮推理；
- 给打断设"冷却"：极短的语音停顿不算打断，避免把正常换气、语气词当成抢话；
- 打断响应和误打断率两个指标要一起看，只优化一个会顾此失彼。

## 轮次管理：对话状态机

维护清晰的对话状态：聆听中、思考中、播放中、被打断。状态转换规则要明确，比如"播放中检测到有效语音 → 进入被打断 → 停止播放 → 重新进入聆听"。混乱的状态机是语音智能体各种灵异 bug 的根源，上线前把状态转换图画出来逐条测试。还要处理边界情况：用户长时间沉默、连续打断、双方同时开口，分别进什么状态、超时多久算放弃，都要预先定义。

## 落地 checklist

1. 端到端延迟按分位数统计，不只看平均值，长尾延迟才是用户投诉的来源；
2. 弱网、高噪声、重口音场景单独压测，别只在安静办公室测；
3. 打断成功率与误打断率双指标验收；
4. 录音留存策略提前定好：存多久、怎么脱敏、合规要求是什么。

## 结语

语音交互没有"差不多能用"：用户要么觉得像真人，要么直接挂断。延迟和打断，就是那条分界线。先把链路跑成全流式，再把打断做扎实，最后才是音色和话术这些加分项。