实时语音 AI 怎么测：轮流说话、打断延迟和音频质量不能只听一遍

语音 Agent 看起来像“把文字聊天换成声音”，但实时交互多了几类新的失败：用户还没说完就被抢答，用户打断后系统仍继续播放，识别结果漏掉否定词，工具调用等待太久导致长时间沉默。测评时不能只把录音转成文字再比较答案。

记录完整的时间线

至少记录用户开始说话、语音活动检测、最终转写、模型开始响应、首个音频包、用户打断、播放停止和工具返回这几个时间点。首个音频包反映系统是否及时给出反馈；端到端完成时间则反映任务效率。两者都要看 P50、P95 和异常长尾。

打断测试要覆盖句中打断、说完立即打断、连续打断和网络抖动。系统应在确认用户接管后及时停止旧播放，并把未完成的模型输出标成取消。若旧请求仍然占用上游资源，账单和并发控制也会出现偏差。

不要把音频质量等同于语音自然

自然度只是一个维度。还要测数字、专有名词、否定句、多人名和中英混说的识别准确率；测不同麦克风、噪声和网络条件下的表现；测声音过快、停顿不自然和重复片段。对客服类场景，信息是否听清比“像不像真人”更重要。

实时语音框架如 LiveKit Agents 强调构建实时语音 Agent，但框架能力不等于业务效果。选型时要把音频传输、语音识别、模型响应、语音合成和工具服务拆开评估，不能只看演示视频。

如果文本模型和工具服务需要在多个上游之间切换，可以用 top-api.cc 统一管理文本调用、回退和成本记录；音频链路则应单独保存首音频、打断和转写指标，避免把不同阶段混成一个平均延迟。

一份可执行的场景集

• 安静环境、噪声环境和网络丢包；
• 用户说到一半打断，系统正在调用工具；
• 工具耗时 1 秒、5 秒和超时；
• 数字、日期、否定和混合语言；
• 用户连续追问、改口和撤回上一句；
• 取消后是否停止播放并停止计费。

最终报告应同时给出交互延迟、识别错误、打断成功率、音频质量和单位分钟成本。实时产品的“好用”不是音色漂亮，而是用户可以自然地开始、暂停、纠正和结束一次任务。

参考资料：LiveKit Agents 项目、各语音模型的流式音频与计费文档。模型、编码格式和网络条件要在报告中注明。

如果需要统一测试文本模型和工具调用的上游差异，可以从 top-api.cc 固定请求和路由，再把语音前后端指标接入自己的测试仪表盘。