一个 Voice Agent 的平均响应时间是 1.2 秒，听起来不错；但用户在高峰期偶尔等到 4 秒才听到第一个字，体验仍然像“系统没反应”。平均值会把这种长尾藏起来，也把 ASR、编排、TTS 和播放器之间的等待混成一个数字。

要优化语音交互，先把“延迟”拆回用户真正经历的时间线：什么时候识别到一句话结束，什么时候模型开始输出，什么时候拿到第一段可播放音频，什么时候扬声器真的发出第一个字。

目录

• 平均值为什么会误导排障
• 四个关键时间点
• 首字、首包和首播分别说明什么
• 用分位数而不是一句平均话术
• 一段可复现的统计代码
• 优化顺序与测量边界

平均值为什么会误导排障

语音链路是串联的：端点检测晚 300 毫秒、模型首 token 慢 400 毫秒、TTS 首包再慢 500 毫秒，用户侧就是一段明显空白。若只记一个总时长，工程团队很难知道该调 VAD、提示词、流式协议还是播放队列。

更重要的是分布。十次里九次 800 毫秒、一次 4 秒，平均约 1.12 秒，却无法代表第十位用户的感受。需要同时看 P50、P95、P99 和样本量。

四个关键时间点

• t_end：判定用户这一轮结束的时刻。
• t_first_token：编排或模型产生第一个可消费文本片段的时刻。
• t_first_audio_packet：TTS 返回第一段音频数据的时刻。
• t_first_play：播放器实际开始播放的时刻。

其中 t_first_audio_packet - t_end 是首包等待，t_first_play - t_end 是用户实际听到声音前的首播等待。二者相差大，常见原因是缓冲阈值、解码或队列调度，而不一定是 TTS 慢。

首字、首包和首播分别说明什么

首字适合看文本链路是否早启动；首包适合看流式 TTS 是否尽早产出；首播才是最接近用户体感的指标。若产品还想衡量“第一句是否说完整”，可以增加首句结束时刻，但不要把它替代首播。

使用 RTP 或其他实时传输协议时，时间戳、序列号和接收端时钟需要分别记录；RTP 的基本时序与序列字段定义可参见 RFC 3550。

用分位数而不是一句平均话术

日报至少输出：首播 P50/P95/P99、首包 P95、打断后重新首播 P95、取消请求仍继续播放的比例，以及按网络/地区/版本的样本量。没有足够样本时，标注“观察中”，不要把单日波动当作优化成果。

不同供应商或不同云区域的数据也不能直接横比，除非网络、文本长度、声音配置、并发和播放器策略一致。

一段可复现的统计代码

def percentile(values, p):
    values = sorted(values)
    index = round((len(values) - 1) * p)
    return values[index]

traces = [
    {"end": 0, "packet": 620, "play": 760},
    {"end": 0, "packet": 700, "play": 900},
    {"end": 0, "packet": 900, "play": 3900},
]
first_play = [x["play"] - x["end"] for x in traces]
print({"p50": percentile(first_play, .5), "p95": percentile(first_play, .95)})

这组数据是教学用模拟 trace，不代表任何云服务或闪电智能 Voice Agent 的线上性能。它只展示：一个长尾样本会让首播 P95 与平均值呈现完全不同的问题轮廓。

优化顺序与测量边界

先定位最长的一段：端点、编排、TTS、传输还是播放器。不要为了压低首播而过早截断用户，也不要为了提高首字而把未经确认的文本直接播出去。延迟优化的目标是减少可感知空白，同时不牺牲理解、打断和取消的正确性。