Voice AI 响应越快越好？这其实是个陷阱

很多人在做语音 AI Agent 时陷入了一个误区：疯狂压低端到端延迟（Latency），觉得响应快就是体验好。但我最近在做个销售培训平台（用 Pipecat + LiveKit + Deepgram + Cartesia 这一套），发现一个反直觉的结论：过快的响应速度反而会放大端点检测（Endpointing）的错误，导致 AI 变成一个没礼貌的“插话王”。

当时我的 p95 延迟压到了 880ms 左右，理论上非常流畅。但实测发现，只要用户在说话时稍微停顿 0.5 秒思考，AI 就会立刻判定用户说完了并抢话。如果 pipeline 慢一点，这种误判反而会被自然掩盖，因为当 AI 准备好说话时，用户可能已经继续说话了，触发打断机制（Barge-in）就能无缝衔接。

简单来说，速度不是免费的，它放大了端点检测的容错成本。

为了解决这个问题，我直接在生产环境做了 A/B 测试，把端点检测的参数调松了：

• Eager end-of-turn： 从 on (0.35) 改为 off
• VOICE_EOT_THRESHOLD： 从 0.5 提高到 0.7
• VOICE_EOT_TIMEOUT_MS： 从 700ms 延长到 1200ms

结果非常明显，AI 不再乱插话了。虽然响应时间整体往后推了半秒，但用户感觉这像是一个自然的对话停顿，而不是延迟。

这里有个实战经验分享：在优化语音 Agent 时，必须把“处理延迟”和“聆听耐心”分开看待。处理延迟（从确认结束到首字节音频）确实得控制在 1 秒内，但聆听耐心（等待用户说完）应该是故意设计的，不应该算在延迟预算里。

另外，关于延迟的衡量，千万不要只看 p50（中位数），那在 Demo 里好看，在生产环境里没用。真正决定用户是否觉得“卡顿”或“诡异”的是 p95。

最后分享一个提升首包速度的小技巧，不用等整个句子生成完，只要有 4-8 个 token 就立即发给 TTS：

# 伪代码逻辑：分块发送首个 TTS 请求
if current_tokens >= 4 and not first_chunk_sent:
    send_to_tts(buffer)
    first_chunk_sent = True

这种 chunking 处理能有效降低体感延迟，而不需要牺牲端点检测的稳定性。