AI 语音客服听起来卡顿，原因不一定在模型。电话网络、语音活动侦测、轮次判断、模型推理、企业 API 和语音合成都会累积等待；调快其中一段，也可能把使用者尚未说完的内容截断。正确测法不是只记一个「回覆几秒」，而是把延迟、插话与任务结果一起观察。
来电先经过电信与 SIP／PBX 路由，音讯送进语音处理后，系统要判断使用者是否说完，再由模型理解、呼叫企业工具，最后把回覆转成语音送回电话。若查询 CRM 或建立工单需要等待，工具时间也会进入体感延迟。只量模型首 token，会忽略来电者真正感受到的整条路径。
| 阶段 | 量测起讫 | 常见风险 |
|---|---|---|
| 电话传输 | 来电音讯进入与离开语音平台 | 电信路由、编解码、网络抖动与封包遗失 |
| 轮次判断 | 使用者停止说话到系统确认结束 | 等待过久或太早截断 |
| 模型回应 | 送出有效输入到产生可播放内容 | 上下文过长、模型选择与复杂推理 |
| 工具呼叫 | 发出 API 到取得可用结果 | 企业系统逾时、重试与排队 |
| 语音播放 | 文字或音讯产生到电话端开始播放 | 合成缓冲、首包等待与播放取消 |
Server VAD 通常依音量与沉默时间判断语音开始及停止；Semantic VAD 会进一步估计语意是否尚未完成。等待较久可降低截断，却会增加停顿；反应太快则可能把「嗯……我想改成」切成两轮。参数不能全站共用一个答案，姓名、长地址、代码与开放式描述需要的停顿容忍度不同。
Barge-in 让来电者在 AI 播放期间插话并停止原本回覆，适合更正资讯、跳过已知内容与缩短选单。它和系统因沉默判断使用者已说完是两件事。一般对话通常应允许插话；录音告知、必要揭露或重要栏位确认是否允许打断，则要依企业流程与法务要求个别决定。把 Barge-in 全域关闭会让对话迟钝，把它全域开启也可能让必要内容没播完。
平均值容易被少数极慢或大量极快样本扭曲。p50 用来看一般通话体感，p95 用来看较差但仍常遇到的尾端；另外记录使用者停止说话到首段回覆、工具完成时间、错误截断、错误等待及插话未生效。每笔样本还要标记任务、网络、语言和是否呼叫企业 API，否则不同情境混在一起无法定位问题。
| 观察项目 | 事件定义 | 判读用途 |
|---|---|---|
| 首段回应延迟 | 确认轮次结束到使用者听见回覆 | 区分轮次、模型与合成等待 |
| 工具等待 | API 发出到结果可用 | 找出企业系统或第三方瓶颈 |
| 错误截断 | 使用者未说完就开始回覆 | 调整 VAD、轮次与栏位策略 |
| 错误等待 | 使用者已说完但系统持续沉默 | 检查结束判断、逾时与工具状态 |
| 插话成功 | 使用者开口后原回覆停止并保留新输入 | 验证取消播放与上下文一致性 |
网页麦克风在安静办公室的结果，不能代表手机、车内、免持、蓝牙耳机或市话。测试至少要涵盖背景人声、回音、讯号不稳、快慢语速、常见口音、数字、英数代码与长地址。对重要栏位，目标不只是逐字正确，而是系统能否重述、让使用者修正，并在仍不确定时停止执行。
CRM、ERP 或派单 API 可能需要数秒甚至进入非同步流程。系统可以用简短进度语句降低死寂，但不能在结果返回前说「已完成」。超过通话内可接受时间时，应建立待确认状态、人工待办或后续通知，并用唯一识别避免重复执行。延迟优化若牺牲结果真实性，只是把错误更快地说出口。
GoGoCha 的公开案例证明电话入口与即时派单工作流，但没有公开端到端延迟分布、电信环境、通话样本或 SLA。未经相同事件定义与真实量测，不应把产品设计目标写成已达成服务水准。企业专案要在自己的 PBX／SIP、API 与尖峰条件下重新建立 p50、p95 和失败样本。
公开案例与可验证证据
GoGoCha AI 电话与即时派单技术案例