语音 Agent 的延迟预算：为什么你的 AI 客服听起来像在走神

用户对语音 AI 的容忍度，比对聊天框苛刻得多。

在打字聊天里，等 3 秒再出回复，用户会觉得”在思考”。在电话里，静默 3 秒，用户会以为断线了。

语音 Agent 的体验优劣，很大程度由延迟怎么分配决定，而不是模型多聪明。

一、可感知阈值

行业里比较稳定的几个经验数字（语音交互场景）：

环节	目标	超出后的感受
用户说完 → 系统开始响应	< 300ms	像人机，>700ms 像机器
单句首字开始播放	< 800ms（端到端）	>1.5s 用户开始”喂？“
句间停顿	< 400ms	>1s 会被误认为断线
打断响应	< 200ms	用户抢话后系统还在说 → 立刻显得蠢

注意”首字”和”整句”的区别。 用户感知的是第一个音出来得快不快，不是整句合成完没完。这条认知直接决定了优化方向：流式，而不是更快。

二、延迟预算表

一条完整的语音链路是四段：拾音 → ASR → LLM → TTS。

合理的端到端预算分配（目标 800ms 首字）：

段	预算	说明
VAD 判定用户说完	150–250ms	静音阈值调优
ASR 最终结果	150–250ms	流式 ASR 提前出部分结果
LLM 首个 token	200–400ms	含系统提示与工具判断
TTS 首包音频	150–250ms	流式 TTS

关键：这四段里最容易被吃光预算的是 LLM 段。 一个 3000 字的系统提示 + 20 个工具定义，首 token 时间能从 200ms 涨到 800ms。

三、五个最有效的优化动作

1. 全链路流式，中间不要”等一下”

最常见的错误是：ASR 等完整句子 → LLM 等完整回答 → TTS 等完整音频。

正确做法是三级流水：ASR 出部分结果就喂给 LLM，LLM 出第一个短句就交给 TTS，TTS 出首包就播。

仅这一项，端到端首字延迟通常能降 40–60%。

2. 让第一句短

LLM 输出第一句的时间，决定用户多快听到声音。

在系统提示里明确要求：“先用不超过 12 个字的一句话确认收到，再展开。”

“好的，我看一下您的订单。“——这 10 个字先出去，用户就知道系统在干活了，后面的等待变得可接受。

3. 精简工具清单

给 LLM 挂 20 个工具的语音 Agent，模型每次都要看一遍全部工具描述。常见做法是按场景分层：默认只挂 3–5 个高频工具，需要时再动态加载。

这一刀既降延迟，也提升工具选择准确率。

4. VAD 阈值分级

静音 300ms 就判定说完，会切断用户思考中的停顿；静音 1000ms，用户会觉得系统反应慢。

可行方案是分级：短句（说完 2 秒内）用 250ms；长句中途用 600ms；检测到”嗯…""那个…”等犹豫词时延长到 900ms。

5. 预生成与缓存

高频开场（问候、确认、常见问题）预生成音频并缓存，直接播放，零 TTS 延迟。

一个实际效果：把”您好，这里是 XX 客服”这类固定话术缓存后，通话前 3 秒的用户感受完全不同。

四、打断处理：比延迟更影响体验

用户抢话时，系统必须在 200ms 内停止播放，并丢弃后续音频。

三个必须实现的动作：

1. 立刻停播，不要播完当前句
2. 清空 TTS 缓冲，否则用户说完后系统会接着念上一句的残余
3. ASR 立刻切换到拾音状态，并保留用户被打断前的问题上下文

未实现打断处理的语音 Agent，用户平均通话时长会显著缩短——因为体验太差，用户会直接挂断。

五、一个反直觉的结论

很多人以为”语音质量”决定体验，花大量时间调 TTS 音色。

但在实际用户反馈里，响应节奏的影响远大于音色。一个音色普通、但反应快、能被打断、句间停顿自然的系统，评分明显高于音色极好但每句都慢半秒的系统。

原因很简单：人对话时的核心期待是”对方在听”，而不是”对方声音好听”。

六、调优顺序

按投入产出比排：

1. 先测基线：把四段延迟分别打点，找出最慢的一段（通常超出直觉）
2. 改流式：如果当前不是全链路流式，这是最大收益项
3. 缩短第一句：改一行提示词的事
4. 精简工具：降延迟 + 提升准确率
5. 调 VAD：影响打断和停顿感受
6. 缓存固定话术
7. 最后才换 TTS/LLM 供应商

第 1 步是最容易被跳过的。 没有分段打点，团队会凭感觉优化——通常优化的是自己最熟悉的那一段，而不一定是最慢的那一段。