传统呼叫中心怎么升级AI能力？

手头还在跑板卡和E1硬交换的集成商都知道那种滋味：设备老旧，厂家技术支持早就断了；扩容要加板卡，采购周期长，还得找懂硬件的师傅；客户想上AI，但一听说要换交换机就摇头——“我们系统还能用，别推倒重来。”

这个局怎么破？答案是“叠加式”升级：不拆旧的，只加新的。下面从硬件接入、API对接、话术设计三个环节，拆解iSoftCall的处理方式。

一、硬件接入：用软交换“骑”在硬交换上面

传统硬交换的核心问题是语音走TDM时隙，AI引擎听不懂。iSoftCall的做法是在原设备前端加一个SIP软交换中间件——说白了就是一个小型的VoIP代理，一边跟老交换机用E1或板卡通信，另一边把语音流封装成SIP包送给AI模块。

实际操作中，有两种常见的接入方式：

串接模式：把中间件串在中继线和原有PBX之间。所有来电先经过中间件，中间件复制一份语音流给ASR，同时把原样转发给原PBX。这种方式适合对延迟不敏感的场景，部署简单。

并接模式：通过高阻录音板卡或镜像端口，旁路监听语音流。中间件只收不发，不介入呼叫控制。这种方式对原系统零影响，但无法做双向的机器人对话（因为不能放音）。

对于大多数只需要AI质检和坐席辅助的客户，并接模式就够了；如果要上电话机器人，需要串接模式。iSoftCall两种都支持，配置时根据现场情况选就行。

关键点：原交换机的路由表、中继群、IVR菜单统统不用改。中间件对原系统是透明的，哪天你不想用AI了，把中间件摘掉，电话恢复原状。

二、API对接：给旧系统开一扇窗，不砸墙

AI跑出来的结果——转译文本、情绪标签、实体词——得送到旧系统里去用。但旧系统的源代码可能早没了，数据库也不敢随便写。

iSoftCall的API设计思路是“只读推送，可配置回调”。具体来说：

坐席辅助弹屏：中间件通过HTTP POST，把实时识别的实体词（比如客户账号、地址）发给旧系统的一个新接口。旧系统只需要新写一个几十行的接收脚本，收到后调用原有的查询模块，在座席桌面弹出窗口。旧系统的核心业务代码一根手指都不碰。

质检结果入库：通话结束后，中间件把完整的质检报告（得分、命中规则、情绪曲线）打包成JSON，推送到集成商指定的地址。你可以把它存入单独的数据库，也可以写脚本同步到旧系统的报表表里。旧系统不用改表结构，多一张外部表就行。

这种“接口在外面，数据送进来”的模式，比硬要改造旧系统SQL要安全得多。我们遇到过数据库密码都不知道的项目，照样把AI结果对接进去了。

三、话术设计：让业务人员自己动手

电话机器人的话术，最怕交给程序员写代码——改一句话要提需求、排期、测试、上线，折腾一周。iSoftCall带了一个图形化的话术编辑器，拖拖拽拽就能搭流程。

设计一个简单的“智能转接”话术：

节点1：机器人放音“请问您要办理什么业务？”

节点2：ASR识别用户回答，匹配关键词（比如“查账单”“投诉”“人工”）

节点3：根据匹配结果跳转——查账单去查数据库接口，投诉转人工队列，说“人工”直接转

整个配置过程，鼠标点一点，下拉框选一选，不用写一行代码。运营人员自己试两次就能上手。如果业务逻辑复杂，比如要调用大模型动态生成回答，iSoftCall也支持在话术节点里配置HTTP接口，指向你自己的大模型代理服务。

实际项目中，第一次配一个基础话术，熟练的话一到两个小时就能完成从零到测试。后面迭代就是改几个节点的问题。

总结：三条路径，按需选择

传统呼叫中心升级AI，根据客户预算和原系统状况，有三条路：

最核心的原则就一个：能不动的坚决不动。传统呼叫中心最大的资产是已经跑通多年的业务逻辑和坐席习惯。iSoftCall这类中间件存在的意义，就是让AI能力像插件一样“卡”上去，而不是把整个房子拆了重建。

如果你的客户还在用板卡、还在被E1绑定、还在羡慕别人的AI客服——告诉他们，不需要换系统，加一层中间件就够了。