AI 智能体为什么让来电客户干等
来电客户说完话后的那段停顿，是六个环节耗时的总和。逐轮测量，盯住最慢的轮次，先修最耗时的那个环节。
先说结论
来电客户说完话，听到的却是一片静音。这段停顿很少只是某一处慢了，而是六个环节耗时的总和：话轮结束、语音转写、模型回复、系统查询、语音起播和线路。系统查询只出现在查询轮次，也就是智能体需要查一下系统的那几轮，比如查订单状态。其余轮次都是普通轮次。
本文把这段停顿称为响应延迟：从来电客户停止说话，到客户听到智能体首次发声为止。响应延迟的平均值，会把客户真正记住的那几轮掩盖掉。所以要逐轮测量，把普通轮次和查询轮次分开，看中位数和 P90（第 90 百分位数）。
然后，在每个最慢轮次里找出最耗时环节。最常成为最耗时环节的那个，就是您要先修的。一次只改一个环节，同时盯住反向信号：智能体开口前等得短了，就可能开始抢话。实在省不掉的等待，可以加一句进度提示，把首次发声提前，但答复并不会因此提前。
目标值不要从别处照搬。找出响应延迟长到多少时，您自己的来电客户会开始对着静音问一声“喂？”，这就是您的阈值。
我们在客户在 AI 通话的哪一步挂断一文中，找的是客户离开的那个阶段。本文再往下深挖一层：静音为什么这么长，该修哪个环节。下文所有数字都是示例，既不是 DRING 的数据，也不是行业数据。
响应延迟的六个环节
从来电客户说完最后一个字，到智能体首次发声，这段时间分成六个环节。本文始终按以下顺序列出：
| 环节 | 做什么 | 常见的拖慢原因 | 怎么测量 |
|---|---|---|---|
| 话轮结束 | 系统判定来电客户已经说完。 | 要等到一段很长的静音，才做出判定。 | 从录音中客户的话音结束，到系统做出判定 |
| 语音转写 | 语音识别的文字定稿。 | 整句话处理完，最终文字才出来。 | 从系统做出判定，到最终文字出来 |
| 模型回复 | 模型决定下一步做什么，并生成回复。 | 第一句话太长、提示词过长、开口前的推理链太长。 | 从最终文字出来，到回复生成。查询轮次分两段：到发出系统查询请求为止，以及从系统查询返回结果到回复生成 |
| 系统查询 | 查一下系统，比如订单状态。只出现在查询轮次。 | 系统响应慢、多项查询依次排队执行、没有设置超时上限。 | 从发出请求，到系统返回结果 |
| 语音起播 | 语音合成输出回复的第一段音频。 | 语音合成要等整段回复文字都出来，才开始发声。 | 从回复文字送达语音合成，到第一段音频离开您的系统 |
| 线路 | 电话线路和网络双向传送音频。 | 通话路由过长、所在区域相隔太远、移动网络信号弱。 | 用普通手机拨打测试电话，在来电方一侧录音 |
有两个环节分成两段。在查询轮次，模型在系统查询之前工作一次，决定要查什么；查询之后再工作一次，组织答复的措辞。两段都算模型回复。线路在每一轮都分两段：客户的声音传到您的系统，智能体的声音传到客户耳边。两段都算线路。
如何逐轮测量
要按轮次测，不要按通话测：按整通电话取平均，一个很慢的查询轮次，可能就淹没在七个很快的轮次里。每一轮记一行，字段都一样。示例值来自本文后面展示的那个慢轮次。示例，并非真实数据。
| 字段 | 记录内容 | 示例值 |
|---|---|---|
| 通话 ID | 通话录音和系统日志共用的同一个 ID | C1047 |
| 轮次序号 | 智能体的这次回复是通话中的第几轮 | 4 |
| 轮次类型 | 普通轮次或查询轮次 | 查询轮次 |
| 响应延迟 | 从客户说完最后一个字，到智能体首次发声，含线路耗时 | 3.9 秒 |
| 话轮结束 | 您的录音和系统时间戳 | 0.7 秒 |
| 语音转写 | 系统时间戳 | 0.2 秒 |
| 模型回复 | 系统时间戳，查询轮次记两段 | 0.6 秒（系统查询前 0.3 秒，查询后 0.3 秒） |
| 系统查询 | 系统时间戳，普通轮次留空 | 1.9 秒 |
| 语音起播 | 系统时间戳 | 0.3 秒 |
| 线路 | 在客户使用的网络上拨打测试电话 | 0.2 秒 |
| 未归因时间 | 系统侧录音上的响应延迟，减去已记录的各环节耗时 | 0.0 秒 |
| 客户在静音中开口 | 响应延迟期间，客户问了“喂？”或把话重复了一遍，记为“是” | 是 |
| 抢话 | 客户还在说话或只是停顿了一下，智能体就开始回复，记为“是” | 否 |
| 任务完成 | 按通话记：客户要办的事办成了，记为“是” | 是 |
先在系统侧的通话录音上测量响应延迟。借助共用的通话 ID，录音里的每一轮都能对上相应的系统时间戳，由此得出话轮结束、语音转写、模型回复、系统查询和语音起播的耗时。线路耗时在下一步再加上。
您的录音里没有线路耗时。在您的系统上，计时从客户的音频到达时开始，到您的音频发出时停止。所以，要在客户使用的网络上用普通手机拨打测试电话，并在来电方一侧录音。同一轮对话，这份录音上的响应延迟减去系统侧录音上的响应延迟，就是线路耗时。把它加到真实通话的响应延迟上。
接着核对总和。未归因时间等于系统侧录音上的响应延迟，减去已记录的各环节耗时。如果这个数很大，说明漏了某个时间戳。在示例轮次中，系统侧录音显示 3.7 秒，已记录的各环节加起来也是 3.7 秒，所以未归因时间为零。再加上 0.2 秒的线路耗时，客户听到的就是 3.9 秒。
平均值为什么会掩盖问题
示例，并非真实数据：同一条线路上 50 通录音通话，共 400 个智能体轮次，其中普通轮次 300 个，查询轮次 100 个。每个响应延迟都含线路耗时，即测试电话测得的 0.2 秒。
| 轮次类型 | 轮次数 | 中位数 | 平均值 | P90 |
|---|---|---|---|---|
| 普通轮次 | 300 | 1.1 秒 | 1.2 秒 | 1.8 秒 |
| 查询轮次 | 100 | 2.9 秒 | 3.2 秒 | 4.6 秒 |
| 全部轮次 | 400 | 1.3 秒 | 1.7 秒 | 3.4 秒 |
全部轮次的平均值是 1.7 秒，高于 1.3 秒的中位数，因为慢轮次把它拉高了。但这两个数都看不出客户记住的那几轮。P90（第 90 百分位数）看得出：每十轮中有一轮的响应延迟达到或超过这个值，这里是 3.4 秒。达到或超过 P90 的轮次，就是最慢轮次。
还要按轮次类型拆开看。普通轮次的中位数是 1.1 秒，查询轮次是 2.9 秒。某一周查询轮次多了，全部轮次的数字就会上升，哪怕没有任何环节变慢。
再把这 400 轮按响应延迟分成四档：1.0 秒以下 130 轮，1.0 至 2.0 秒 180 轮，2.0 至 3.4 秒 50 轮，3.4 秒及以上 40 轮。然后标出客户在静音中开口的轮次，也就是客户问了“喂？”或把话重复了一遍。最慢的 40 轮里有 31 轮出现这种情况，其余 360 轮里有 7 轮：2.0 秒以下的 310 轮中有 3 轮，2.0 至 3.4 秒的 50 轮中有 4 轮。
所以在这条线路上，响应延迟在 2.0 秒以下时，客户很少在静音中开口；2.0 至 3.4 秒时仍不多见；到了 3.4 秒及以上就很常见。这条线路的阈值在 3.4 秒附近，并不是通用目标。您的阈值也用同样的方法找：把自己的轮次分档，看客户在静音中开口从少见变成常见，发生在哪一档。在这个位置附近把档位分得更细，就能定得更准。
在最慢轮次中找出最耗时环节
P90 告诉您最慢轮次有多慢，却不告诉您为什么慢。要找原因，就逐个打开慢轮次，找出它的最耗时环节，也就是这一轮中用时最长的那个环节。
示例，并非真实数据：最慢的 40 轮之一。客户询问订单状态，所以这是一个查询轮次。计时从客户停止说话的那一刻开始，以来电方一侧听到的为准。
各环节耗时：话轮结束 0.7 秒，语音转写 0.2 秒，模型回复 0.6 秒，系统查询 1.9 秒，语音起播 0.3 秒，线路 0.2 秒。模型回复分两段，各 0.3 秒：一段决定去查订单，一段组织答复。线路每个方向各 0.1 秒。各环节加起来，响应延迟是 3.9 秒。系统查询是最耗时环节，几乎占了响应延迟的一半。
只有在同一轮之内，各环节耗时才能这样相加。中位数和 P90 不能这样加：六个环节的中位数加在一起，并不等于响应延迟的中位数。所以要逐轮找出最耗时环节，再做统计。
示例，并非真实数据：最慢的 40 轮中，每一轮的最耗时环节。
| 最耗时环节 | 最慢轮次 |
|---|---|
| 话轮结束 | 8 |
| 语音转写 | 0 |
| 模型回复 | 5 |
| 系统查询 | 27 |
| 语音起播 | 0 |
| 线路 | 0 |
| 合计 | 40 |
系统查询最常成为最耗时环节，40 轮中占 27 轮。这和轮次类型对得上：最慢轮次中，36 个是查询轮次，4 个是普通轮次。话轮结束是 8 轮的最耗时环节，其中大多数是客户在报号码时停顿了一下，系统多等了一会儿，才判定客户已经说完。模型回复是 5 轮的最耗时环节。
在这个示例里，线路从来不是最耗时环节，因为这条线路稳定在 0.2 秒。换一条线路，就可能不一样。我们在演示顺利、真实通话出错一文中给过一个快速判断方法：每一轮都有停顿，指向线路；只有查询轮次才停顿，指向工具。
一次只修一个环节，同时盯住反向信号
从最慢轮次中最常成为最耗时环节的那个环节开始，这里是系统查询。只改一处，然后对同样的轮次类型重新测量。同时改两处，就分不清是哪一处让 P90 变了。
每项修复都有代价，所以每一行也写明了要盯住的信号：
| 环节 | 可以尝试 | 要盯住的信号 |
|---|---|---|
| 话轮结束 | 等待时长随客户说的内容而变：客户只答“是”“不是”或报个名字时，等得短一些；客户在报号码，或者在说明某个字怎么写时，等得长一些。 | 抢话 |
| 语音转写 | 改用流式语音转文字，话轮结束时，大部分文字已经出来了。 | 听错的字词和数字 |
| 模型回复 | 第一句话说短一点。常见问题用简单的回复方案。 | 答复的质量和完整性 |
| 系统查询 | 互不依赖的查询同时执行。设置超时上限并准备兜底：转人工，或者提出回电。查询之前先给一句进度提示。 | 答复过时或不完整。每一轮都重复进度提示。 |
| 语音起播 | 第一句话写好就开始发声，其余部分边生成边播放。 | 回复说到一半出现不自然的停顿 |
| 线路 | 从客户使用的网络拨打测试电话。和您的电话线路服务商一起检查通话路由。 | 音质，而不只是延迟 |
每一行列出的都是备选做法。先试一个，测量后再决定下一步。
缩短话轮结束的代价：抢话
抢话是和响应延迟过长相反的失误：客户还在说话，或者只是停顿了一下，智能体就开始回复。示例，并非真实数据：同样这 400 轮中出现了 6 次抢话，其中 5 次发生在客户报订单号或手机号的时候。两种失误都和报号码有关：最慢轮次中有 8 轮的最耗时环节是话轮结束，其中大多数也是客户在报号码。如果每一轮都缩短等待，抢话就会变多。所以上表中话轮结束那一行给了长短两种等待。不过，报号码时等得再久，也不会让这 8 个慢轮次变快。真正有用的是一个“号码已报完”的信号：系统如果知道订单号是五位数，客户报完第五位数字时就能判定话轮结束，不必再等静音。
等待省不掉时，给一句进度提示
有些查询就是慢，背后的系统也不一定由您说了算。这时，就把首次发声提前到系统查询之前，用的是进度提示：在耗时的步骤之前说一句简短的话。在上面那个慢轮次中，这句话会紧接在模型回复的第一段之后：
- 客户：“订单号是 4 8 1 7 2。”
- 智能体（系统查询前）：“好的，我帮您查一下这个订单，您稍等。”
- 智能体（系统查询后）：“您的订单已经在路上了，周四能送到。”
响应延迟缩短了，因为首次发声提前到了系统查询之前。答复等待时间是从客户停止说话，到真正开始答复为止的时间。它基本不变，因为答复仍然要等系统查询结束。在这类轮次上，也要记录答复等待时间，免得进度提示掩盖了越来越慢的系统查询。
进度提示要简短，只用在耗时的步骤之前，绝不放在道歉、数字或结束语中。每一轮都说也有代价：客户会一遍又一遍地听到同一句话。
每周要跟踪什么
每周把普通轮次和查询轮次分开，看三个信号：
- 响应延迟：中位数和 P90；有进度提示的轮次，还要看答复等待时间。
- 客户在静音中开口：出现这种情况的轮次占比。
- 抢话：次数，以及抢话时客户正在说什么。
第四个信号按通话看：任务有没有完成。如果完成任务的通话变少了，响应延迟缩短也没多大意义。如果您在做试点，就按试点评估卡对已解决通话的定义，来判断任务是否完成。
每次改动前后，都要拿同样的轮次类型做比较。在几百轮上测得的占比，可能只是偶然波动。比率的误差范围怎么算，请看我们关于语音 AI 试点成功标准的文章。
DRING 能帮上什么
精选的语音转文字、文字转语音和推理模型，以及电话线路、测试和监控，都属于每个 DRING 套餐共用的基础能力。在 DRING 上，六个环节中的三个，以及进度提示，是这样运作的：
- 话轮结束：由一个专门的模型负责插话处理和话轮结束检测，让智能体既不在停顿时抢话，也不在对方说完后干等。
- 语音转写：采用流式语音转文字，通话被实时转写。
- 线路：按号码跟踪音质和延迟信号，线路一变差就能尽早发现。
- 进度提示：工具或模型耗时较长时，一句取自 DRING 审批集合的简短自然的过渡语，让对话继续推进。过渡语就是 DRING 实现进度提示的方式，绝不出现在道歉、数字或结束语中。
我们的语音核心页面介绍了语音转文字、话轮管理和文字转语音如何作为一条链路运行，电话系统页面则讲解线路健康。
每个 DRING 智能体在接第一通真实电话之前，都会跑 1,000 至 10,000 次专为您企业生成的模拟对话。模拟对话在上线前测试话轮管理和进度提示，但测不出真实通话的线路耗时。线路耗时要靠在客户所用网络上拨打的测试电话来测。
如果您线路上有客户对着静音问“喂？”，可以申请 AI 回电。提前准备几通这样的通话，在公司规定允许的前提下附上录音。我们的团队可以和您一起，逐个环节梳理最慢的轮次。