Turn Detection 与打断优化

先把问题从“延迟高”拆开

很多 Voice Agent 的体验问题看起来像延迟，其实是 turn detection 没有被拆开测。用户还没说完时 Agent 抢答，是 endpointing 太激进；用户说“等一下”但 Agent 继续念完，是 barge-in 没接住；客厅电视或外放回声触发打断，则是 VAD 和回声控制没处理好。不要一上来换大模型，先把“用户开始说话、用户停止说话、STT partial、LLM 首 token、TTS 首音频、播放取消”这些时间点记录下来。

适合已经有可运行 Agent 的团队

这篇更适合已经跑通电话 Agent、网页语音助手、AI tutor 或陪伴应用的开发者。你不需要先重写全套架构，只要能导出事件日志和一小段真实音频，就可以开始调参。相反，如果你的 Agent 还没有稳定业务逻辑，先别花太多时间调 50ms 的 VAD；脚本、工具调用和错误恢复更可能是瓶颈。

不要把 VAD 当成理解能力

VAD 只判断“有没有人在说话”，不能判断用户是在回应、插话、清嗓子还是背景噪声。更稳的做法是把 VAD 作为低延迟门控，再结合 STT endpointing、语义 turn detector 或业务层策略。LiveKit 文档也把实时模型、STT endpointing、模型式 turn detection 和手动控制分成不同路线。

按可回放的顺序调优

第一轮不要追求完美，只要建立可复现样本。录 20-30 段真实通话，覆盖安静耳机、手机免提、车内、多人背景声、口音、长停顿和用户中途打断。每段都标注失败类型：误抢答、漏打断、dead air、截断首字、噪声误触发。没有这个样本集，调参只是在凭感觉。

先调 VAD 和回声，再调语义判断

如果 Agent 播放自己的声音时被麦克风收回，任何高级 turn detector 都会被污染。浏览器端优先用 WebRTC 的 echo cancellation；电话或嵌入式设备要做单独链路测试。之后再调 VAD threshold、min speech duration、silence timeout 和 endpoint delay。目标不是“永远快”，而是在真实噪声里少犯可见错误。

给打断设业务规则

用户说“停一下”“不用了”时要立即取消 TTS；用户只是“嗯”“好”这样的 backchannel，不一定要打断长解释。更危险的是工具调用：如果 Agent 正在写数据库、改订单或发短信，不能因为用户插话就取消一半。生产系统要区分可取消播放、可取消推理和不可取消动作。

选工具时看你要控制哪一层

如果要自己掌控 WebRTC、VAD、turn detector、回放和多 provider，LiveKit 或 Pipecat 更适合；开源路线免费但工程成本会转移到测试、部署和监控。Silero VAD 适合做本地活动检测，但要和 endpointing 或语义判断配合。

托管平台适合先验证用户感受

Retell AI、Vapi 适合先验证电话 Agent 的打断体验，尤其是你还没有媒体基础设施团队时。Retell 官方价格页显示 AI Voice Agent 为 $0.07-$0.31/分钟，约 RMB 0.5-2.2/分钟；Vapi 还要叠加模型、STT/TTS 和电话费用。不要只看平台费，要用 100 通真实电话算全链路成本。

模型原生路线减少拼接，但降低可见性

OpenAI Realtime 这类 speech-to-speech 路线能减少 STT、LLM、TTS 串联带来的断点，适合自然对话优先的产品。但当失败发生时，你能看到的中间状态比模块化链路少，所以必须保留事件日志、用户音频样本、工具调用结果和播放取消记录。页面里的 Vapi 实战视频可以用来对照一次完整实时 Agent 构建，再把重点放到打断测试上。

上线前检查真实失败

上线前至少保留一张失败矩阵：噪声误触发、用户打断无效、长停顿抢答、首字被切、Agent 自己的声音造成回声、工具调用中断。每种失败都要有样本、当前参数、修复方案和回归测试。最终指标不要只看平均延迟，还要看 P95 dead air、missed barge-in rate、false interruption rate 和用户要求重复的比例。

发布后继续监控漂移

语音输入会随设备、地区、季节和流量渠道变化。新用户从耳机切到免提、客服话术变长、TTS 音量变大，都可能让原来稳定的阈值失效。把 turn detection 当成持续运营项，而不是一次性调参；每周抽样回放失败通话，比盲目升级模型更有用。