语音机器人接进企业电话网：七处工程细节决定它能不能长期跑

小杨手记

先说结论：把一个语音机器人接进企业现有的电话网，让它接通、能听懂，通常两周就能做完；让它连续跑一年不出事，靠的是另外七件事。这七件事跟模型关系不大，跟电话网本身关系很大。

见过一个典型现场。系统上线后接通率一直不错，第三个月开始，陆续有人反馈"打过去说我这边很吵""按 1 没反应""传真收不到"。三个现象看起来无关，查下来是同一个方向的问题：接入层的参数是按最理想的网络条件配的，一旦真实环境里有丢包、有免提、有老式传真机，链路就开始失配。

一、并发不是坐席数，是收敛比

先说容量。很多方案在报价阶段给的是"支持 N 路并发"，但 N 是按什么算出来的，很少有人追问。

电话网的并发要分三段看：中继侧、媒体处理侧、业务侧。中继侧由运营商给的话务量决定，用爱尔兰公式反推，通常按忙时话务量和阻塞率定；媒体处理侧看的是同时进行的语音编解码与识别，一路占多少 CPU 取决于采样率、编码格式和是否开启回声消除；业务侧才是业务系统能同时处理的请求数。

三段里最容易被忽略的是收敛比。企业实际的话务是峰谷分明的，如果按峰值配足并发，其余时间全是闲置；如果按均值配，忙时就会溢出。常见做法是按峰值的一定比例配，再留一条溢出策略——超出部分回落为排队或回拨，而不是直接失败。这个比例写进合同比写进 PPT 有意义。

二、编解码协商，同一路语音两端听到的不一样

第三个容易出问题的地方不在算法，在协商。两端的编解码不一致时，网关会做一次转码，转码本身不复杂，但它会带来两个后果：音质下降和额外时延。

常见组合是：运营商侧给 G.711（PCMA/PCMU，64 kbps 固定码率），终端侧为了省带宽用 G.729（8 kbps）或者 Opus。G.711 转 G.729 是有损转码，语音里的高频成分会被削掉，识别引擎在安静环境下感觉不出来，一旦有背景噪声，字错率会明显上升。所以做语音识别接入时，能协商成 G.711 就别绕到低码率编码上，带宽省下来的那点钱，通常不够补识别率的损失。

时延也要算清楚。一路转码增加十几到几十毫秒，加上网络抖动缓冲、识别首包、模型推理，整条链路的端到端时延会累加。人对这个的容忍阈值大约在一秒上下，超过之后对话就开始互相抢话——用户以为没听见，于是重复一遍，系统又把重复当成新问题。

这里有个务实的建议：把编解码、抖动缓冲、识别首包这三段时延分别压测出数值，写进验收指标，而不是只看"总时延小于多少"。总时延一旦不达标，拆开看才知道该动哪一段。

三、回声与双讲，免提场景最先崩

第二个细节是回声。手机贴着耳朵打，回声不是问题；一旦对方开免提、或者在车里、或者在会议室，扬声器的声音被麦克风收回去，识别就会被自己的声音带偏。

工程上有两层处理。终端侧用 AEC（回声消除）把参考信号减掉，这一层取决于终端做得好不好，服务端控制不了。服务端能做的是双讲检测：判断当前是"只有对方在说"还是"两边同时说"，双讲期间暂停打断逻辑，避免把用户的话当成噪声滤掉。

这里有个反直觉的点：回声消除做得越激进，双讲期间越容易把真人语音一起削掉，表现就是"用户说了一半，系统没听见"。这类问题在实验室测不出来，必须用真实免提录音回放才能复现。

四、DTMF 与转人工，按键丢了导航就断了

第三个细节是按键。语音导航里的"按 1 转人工、按 2 查进度"，靠的是 DTMF 信号。DTMF 在 VoIP 链路里有三种传法：带内音频、RFC2833、SIP INFO。三种方式在不同设备上的兼容性差别很大，一端发带内、另一端只认 RFC2833，就会出现"用户按了没反应"。

排查方法很简单：抓包看有没有对应的 RTP 事件包。如果没有，就是传法不匹配，改配置即可；如果有但业务侧没收到，问题在解析层。这类故障的特征是"部分用户按得动、部分按不动"——按得动的是手机，按不动的是某些固话或企业交换机下面的话机。

转人工还有一层。语音机器人把上下文交给坐席时，如果只交了一句话摘要，坐席还得重新问一遍；如果能交过去通话主题、已确认的信息、用户情绪，坐席的首次解决率会明显不同。这一层的工程量在数据打通，不在语音。

五、传真与断电旁路，老业务不能因为升级消失

第四个细节最不体面，但最容易出事。企业电话网里往往还挂着一台传真机、一台老式报警主机、或者一个只支持模拟线路的 POS。改造时如果整条链路都换成 IP，这些设备会直接失效。

常规做法是保留旁路：核心设备断电或升级时，外线自动切到模拟直通，让最基本的呼入呼出不中断。这件事在方案里通常只占一行字，但它决定了升级当天会不会有人打不进电话。

六、录音与留存，可追溯和最小化是一对矛盾

第五个细节是留存。通话录音既是质量管理的依据，也是需要严格管控的数据。工程上要同时满足两件事：需要的时候能查到，不需要的时候不扩散。

落地通常是三条：录音文件加密存储、访问走审批并留痕、按业务类型设不同的留存期限。技术上不难，难在边界画清楚——哪些角色能听、能听多久、导出要不要二次审批，这些是流程问题，不是代码问题。

七、联调清单，比功能演示有用

最后给一份上线前的联调清单，都是现场真正会卡住的项目：

· 忙时并发压测，按实际话务模型跑，不用平均值
· 编解码、抖动缓冲、识别首包三段时延分别压测，不只看总时延
· 免提、车载、会议室三种场景的真实录音回放
· 三种 DTMF 传法逐一验证，覆盖手机与固话
· 断电与升级时段的旁路切换演练
· 传真、报警主机、老式终端的保活验证
· 录音调取流程走一遍，看审批链是否通

这七项跑完，系统才谈得上"能长期跑"。前面那些功能演示，只证明了它今天能用。

电话网是一个已经稳定运行了几十年的系统，语音机器人是新加进来的一层。新的一层要迁就旧的一层，而不是反过来。把这个顺序搞反，问题会以各种意想不到的形式冒出来——接通率、按键、传真、回声，看着是四个故障，根子上是同一件事。