客服语音 Agent 上线前：4 项硬指标压测清单

语音客服 Agent 最容易被低估的成本不是 token 费，而是「沉默」。文本 Bot 卡两秒没人察觉，语音里两秒就是尴尬，用户会重复说话，系统再识别一遍，反而更慢。上线前先把下面四项压测做完，比反复调 prompt 更能决定成败。

一、延迟预算：先拆段，再谈模型选型

端到端延迟 = 静音检测 + STT + 编排 + LLM 首字节 + TTS 首字节 + 网络。别只测「平均响应时间」，那会把长尾问题盖掉，要测 P95。

• 建议把首字延迟（用户说完到听到第一声）的 P95 控制在 1.2 秒内；超过 1.8 秒，用户大概率会补话或重说。

• 逐段埋点：如果 LLM 首字节 400ms、TTS 首字节 700ms，问题在语音合成，不必换更大的模型。

• 流式是默认解：LLM 边出边送 TTS，按逗号级切句播报，通常比等整段生成快几百毫秒。

测法：固定脚本在真实网络（4G、弱网）下各跑 50 通，记录每段耗时，输出 P50/P95 对照表，达标线写进上线 checklist。

二、打断压测：最容易翻车的一项

用户会插话、会「嗯嗯」、会在你播报时咳嗽。barge-in 做不好，体验直接崩。

建议至少覆盖五类脚本：

1. 播报第 1 秒插话，看 TTS 是否立刻停止；

1. 播报第 3 秒说「等一下」，看上下文是否保留；

1. 半句后停顿 1.5 秒再说，考验静音阈值，设太短会误打断；

1. 叠加背景人声或电视声，考验 VAD 与说话人区分；

1. 连续两次打断后仍要能问清意图，不能「忘掉」前一句。

评判标准很朴素：打断后 TTS 停止时间小于 300ms，且助手不会把用户的插话当成一个全新问题重新开场。

三、工具调用失败链路：兜底比聪明重要

语音场景里「查订单」「改地址」「约回访」这类调用最常出问题：超时、返回多条、参数缺失。建议定三条硬规则：

• 任何写操作（改地址、取消订单）必须口头复述关键字段，二次确认后再执行；

• 工具超时 2 秒就切兜底话术并转人工，不要让模型自己「编一个答案」；

• 返回多条时最多口播 3 条并按时间排序，其余引导用户报订单号。

测试时故意注入 500 错误、超时和空结果三种故障，重点看 Agent 会不会把失败说成成功——这是投诉率最大的来源。

四、回归集与并发：上线后的守门人

从真实通话里挑 30～50 条（含口音、方言、嘈杂环境）转写成回归集。每次改 prompt、换模型、调 TTS 都跑一遍，盯两个数：意图识别准确率、任务完成率是否回退。别拿自己录的「标准普通话」当唯一基准，那只会得到虚高的分数。

并发方面，按峰值通话数 ×1.5 压测，重点看两件事：排队带来的额外延迟，以及每通成本。语音的 token 消耗通常远高于文本（转写 + 上下文 + 播报都要算钱），先把「每通多少钱」算清楚，再谈规模化。

上线决策门槛

四项全过再灰度：P95 首字延迟 ≤1.2 秒；打断停止 <300ms；故障注入零次「假成功」；回归集任务完成率不低于上一版。语音 Agent 的护城河不在模型多强，而在这些看起来无聊的工程指标上。