语音交互链路

语音交互把声学、音频、语音算法、语义理解和业务执行串成闭环。用户感知到的是“我说一句，设备能不能及时、准确、自然地回应”，工程上则是多模块的时序协同。

端到端流程

每个模块都可能返回中间状态：

• 采集：音频帧、时间戳、声道。
• 前处理：增强音频、VAD 状态、声源方向。
• 唤醒：置信度、唤醒时间点、唤醒词。
• ASR：中间文本、最终文本、置信度。
• NLU/LLM：意图、槽位、工具调用、回复文本。
• TTS：音频分片、播放进度。

状态机

语音设备通常需要明确状态机，而不是让各模块自由触发。

状态	行为
休眠监听	低功耗采集，只跑唤醒相关链路
唤醒确认	播放提示音或亮灯，启动 ASR
收音中	识别用户命令，处理 VAD 结束
理解中	NLU 或大模型生成结果
执行中	调用设备、服务或工具
播报中	TTS 播放回复
可打断	播放时继续监听，允许用户插话
错误恢复	超时、无网络、识别失败或权限不足

没有状态机时，常见问题是重复唤醒、播报时误识别自己的声音、用户打断无效、网络慢导致界面和音频状态不一致。

全双工与半双工

模式	说明	适用场景
半双工	设备播放时不听用户或弱化监听	简单音箱、低成本设备
全双工	播放时仍能听用户并支持打断	会议、车载、智能助手

全双工需要更强的 AEC 和状态控制。设备播放 TTS 时，麦克风会同时收到扬声器声音和用户声音；系统必须保留用户语音，压制自身播放回声。

打断机制

打断是语音交互体验的关键。用户在设备播报时说“停一下”“换一个”“不用了”，系统应能及时停止或切换。

实现要点：

• 播报时仍保留唤醒或 VAD 监听。
• AEC 参考必须包含当前播放的 TTS。
• 打断词可以用轻量命令词模型或 ASR 短句识别。
• 播放停止后清理 TTS 缓冲和业务状态。
• 对不可打断操作给出明确边界，例如支付确认。

端云协同

语音交互常采用端云协同：

模块	常见位置	原因
唤醒	端侧	常开、低延迟、隐私
前处理	端侧	减少上传噪声和回声
ASR	端侧、云端或混合	短命令端侧，长文本云端
NLU/LLM	云端或本地大模型	需要知识、推理和工具
TTS	端侧、云端或混合	端侧低延迟，云端音质强

弱网场景要设计降级路径，例如本地命令词控制、离线 TTS 提示、网络恢复重试。

时序与延迟预算

语音助手响应慢通常不是单个模块慢，而是多个小延迟叠加。

环节	典型优化
唤醒	小模型常驻、二级确认异步
ASR	流式识别、提前启动
NLU/LLM	意图短路、工具并发、缓存
TTS	按句流式合成、首包优先
播放	预缓冲、统一音频通道

交互系统应记录每段耗时：唤醒耗时、ASR 首字时间、ASR 完成时间、理解耗时、TTS 首包时间、播放开始时间。没有分段耗时，只看总延迟很难定位。

数据闭环

线上语音系统需要留足可诊断数据，但要控制隐私和权限。

建议保留：

• 设备型号、固件版本、算法版本。
• 场景标签：车载、客厅、会议室、耳机。
• 音频摘要指标：SNR、音量、VAD 时长、ERLE。
• 模型输出：唤醒置信度、ASR 文本、置信度。
• 分段耗时。
• 用户反馈和纠错结果。

原始音频涉及隐私，采集、上传、存储和回放都应有明确授权与脱敏策略。

常见故障链路

现象	可能链路
“喊了没反应”	麦克风、前处理、唤醒阈值、功耗状态
“听错命令”	ASR、热词、端点、NLU 槽位
“答非所问”	NLU/LLM 上下文、工具结果、对话状态
“声音打断不了”	AEC、打断模型、播放状态机
“设备自己把自己唤醒”	播放参考、AEC、唤醒负样本
“响应很慢”	ASR 结束点、网络、LLM、TTS 首包

总结

语音交互的质量取决于端到端链路，而不是某一个模型指标。工程上要把音频流、状态机、打断、端云协同、延迟监控和隐私边界一起设计，才能让声学能力稳定落到用户体验上。