一通电话里，用户最容易感知到的，不一定是AI模型是否足够聪明，而是声音是不是连续。如果用户听到的AI播报断断续续，或者AI听到的用户语音出现卡顿、吞字、延迟、重叠，再强的ASR、大模型和TTS能力都会被通信体验拖累。
在实时语音系统中，这类问题经常来自网络本身。真实网络不会像实验室一样稳定。音频数据包可能早到、晚到、乱序到达，也可能直接丢失。对于普通文件传输来说，数据晚一点到还能重传；但对于实时通话来说，声音必须按时间连续播放。等太久，电话会产生明显延迟；不等，又可能出现断音和卡顿。
这就是Jitter Buffer，也就是抖动缓冲要解决的问题。在WebRTC实时音频体系里，NetEQ是一个典型的音频抖动缓冲实现。它的核心目标不是让网络变好，而是在网络不稳定时，尽量让用户听到连续、平滑、低延迟的声音。
一、弱网下的“卡”，本质上是音频包没有按节奏到达
实时语音并不是一整段音频一次性传输。在通话过程中，声音会被切成一小段一小段的音频帧，编码后通过网络连续发送。接收端再按时间顺序解码、播放，用户才会听到连续声音。
理想情况下，音频包应该像节拍器一样稳定到达。但真实网络中，接收端可能遇到几类问题：有的包晚到了，有的包乱序到了，有的包直接丢了，有的包到得太密集，有的包间隔突然变长。这就是网络抖动和丢包。
对人耳来说，实时语音最怕两件事。第一，播放时间不连续，声音会出现断裂、爆音、卡顿、吞字。第二，为了等迟到的包，系统不断增加等待时间，声音虽然连续了，但通话延迟变大，用户和AI更容易互相抢话。所以，实时音频系统一直在做一个取舍：多等一点，可以让声音更平滑；少等一点，可以让延迟更低。
二、Jitter Buffer：在“不卡”和“不慢”之间找平衡
Jitter Buffer可以理解为接收端的一小段音频缓冲区。它不会立刻播放刚收到的每个音频包，而是先把收到的包暂存起来，根据时间戳、序列号和网络状态重新排序，再按照稳定节奏送去播放。
网络到达的音频包
↓
接收端缓存
↓
乱序重排 / 丢包检测 / 播放时间判断
↓
平滑输出音频
↓
用户听到连续声音
真正难的是缓冲区大小如何控制。如果缓冲太小，延迟低，但网络稍微波动就容易断音。如果缓冲太大，声音更稳，但通话延迟会变高。电话对话不是听音乐，用户需要实时互动。一旦延迟过大，就容易出现两边同时说话、AI接话慢、用户误以为系统没反应等问题。
NetEQ这类自适应抖动缓冲机制，不只是“放一个缓存”，而是持续判断当前网络抖动是否变大、是否有音频包迟到、是否有音频包丢失、当前播放队列是否快耗尽、是否要拉长缓冲、网络恢复后是否要缩短缓冲、缺失音频能否通过算法补偿、是否要轻微拉伸或压缩音频时间。
三、NetEQ这类机制，解决的是实时音频里的三个问题
以WebRTC中的NetEQ为例，它通常围绕三个目标工作：抗抖动、抗丢包、控延迟。
抗抖动，是让不稳定到达的包稳定播放。网络抖动的表现是音频包不是按均匀节奏到达。抖动缓冲会先收住这些包，然后按照更稳定的播放节奏输出。它像一个“节拍整理器”，把网络侧不规律的输入，变成播放侧相对规律的输出。
抗丢包，是包丢了也尽量别让声音突然断掉。实时语音通常不能像文件下载一样反复等待重传。一个音频包错过播放时间，就算后来到了，也可能已经没有意义。这时系统需要Packet Loss Concealment，也就是丢包隐藏。它会根据前后音频，生成一小段“尽量自然”的替代声音，避免用户听到明显断裂。
控延迟，是网络差时变稳、网络好时变快。抖动缓冲不能一直变大。如果为了追求平滑而不断增加缓冲，通话会越来越慢。自适应抖动缓冲需要在网络变差时适当扩大，在网络稳定后逐步收缩。这就是实时音频的典型工程取舍：稳定性和低延迟必须同时考虑。
四、WSOLA和时间伸缩：弱网下的声音为什么还能“接上”
弱网音频补偿里，还有一个值得理解的机制：时间伸缩。在一些实时音频处理中，系统会对音频做轻微拉伸或压缩，让播放节奏更平滑。WSOLA可以理解为一种时间尺度调整方法。它的目标是在不明显改变音高和语音自然度的前提下，对音频时间长度做细微调整。
当缓冲区快要空了，但下一个包还没到，系统可能需要“拖一拖”当前音频，让播放不要立刻断掉。当缓冲区积累太多，为了降低延迟，系统又可能需要“赶一赶”，轻微压缩播放时间，把积累的延迟慢慢消化掉。
这类操作用户通常不会明显感知，但它对实时通话很重要。因为它避免了两种极端：直接断音和一味增加延迟。对通话Agent来说，这类机制的价值在于：弱网并不会立刻让服务崩掉，系统可以通过音频补偿、缓冲调整和播放节奏控制，把短时网络波动对用户体验的影响降到更低。
五、弱网音频问题，会沿着链路影响ASR、VAD和打断
弱网问题 | 对音频的影响 | 对通话Agent的影响 |
抖动 | 音频包到达不稳定 | ASR输入断续，识别结果不稳定 |
丢包 | 部分音频缺失 | 关键词、数字、短句可能被漏掉 |
延迟波动 | 声音播放节奏不一致 | AI接话时机异常，容易抢话或慢半拍 |
音频补偿过多 | 声音轻微失真 | 可能影响语音识别和情绪判断 |
缓冲过大 | 声音更平滑但延迟更高 | 双方更容易重叠发言 |
缓冲过小 | 延迟低但容易卡顿 | 用户觉得AI不稳定或听不清 |
通信链路问题会一路传导到AI能力。ASR需要稳定音频输入，VAD需要判断用户是否在说话，打断机制需要识别用户是否插话，TTS播报需要连续输出，转人工需要保持通话不中断，质检需要完整录音和服务记录。如果底层音频链路不稳，上层AI能力就会出现连锁波动。
六、网页语音和电话热线，面对的弱网问题并不完全一样
入口类型 | 常见链路 | 弱网问题重点 |
网页 / APP语音 | WebRTC、移动网络、浏览器音频 | 网络抖动、丢包、浏览器采集质量、耳机/麦克风差异 |
小程序语音 | 小程序运行环境、移动网络 | 端侧权限、音频采集稳定性、网络波动 |
400热线 | PSTN、运营商线路、呼叫中心 | 电话音频压缩、线路质量、排队转接、坐席接管 |
外呼电话 | 外呼线路、运营商网络、用户终端 | 接通质量、用户环境噪声、线路延迟 |
远程售后 | 电话或APP语音、现场环境 | 弱网、设备噪声、免提回声、多人说话 |
合力亿捷通话Agent面对的是企业真实客户联络场景，不是单一入口的语音Demo。因此，服务稳定性不能只从某一个协议或某一个模型看，而要从通信底座、线路接入、音频质量、坐席协同和业务流转整体考虑。
七、服务稳定性，是企业级通话Agent走向生产环境的前提
弱网、抖动、丢包、延迟、音频压缩、线路质量和转人工链路，都会影响用户最终体验。NetEQ这类抖动缓冲机制说明，实时音频系统本质上一直在和不稳定网络做动态博弈：既要尽量平滑声音，也要尽量控制延迟。
合力亿捷通话Agent面向真实客服电话、400热线、外呼、网页语音和多渠道客户联络场景，需要从通信底座、线路接入、通话质量、坐席协同、录音质检和服务流程等多个层面保障稳定性。当AI语音不仅能在理想网络里顺畅对话，也能在弱网、丢包、抖动和真实电话链路中保持服务连续，通话Agent才具备进入企业生产环境的可靠基础。