公积金中心这种单位，选呼叫中心中间件有三道绕不过去的坎：数据不能出内网、系统不能停、国产化验收必须过。你要跟客户推方案，光喊“我们支持信创”没用，得拿出真能在麒麟上跑、能对接达梦、能让市民在电话里查余额不泄露隐私的东西。

       
关于数据安全：语音和文本都不出域

       公积金用户打电话进来，最敏感的场景是查余额、查贷款进度、修改还款账户。很多厂商的方案会把ASR送到公有云去识别，美其名曰“识别率高”，但客户一听就摇头——用户报出身份证号的那一刻，数据已经出去了，等保三级就别想了。

      iSoftCall在这个项目里的做法是纯本地化部署。中间件对接客户内网已有的ASR/TTS服务器，用的是标准MRCP协议，语音流在整个处理过程中不经过任何外网链路。所有的语音转译文本、大模型生成的话术，都只在内网的服务器之间流动。

      至于大模型，客户要求不能用公有云API。iSoftCall的方案是在一台国产服务器上部署量化后的大模型（比如GLM系列的本地版本），挂载公积金中心自己的政策文档库。市民问“租房提取需要什么材料”，机器人实时检索文档、组织回答，整个过程模型推理和文本生成都跑在客户机房里。有人担心大模型胡说八道？他们把回答范围限定在RAG检索到的文档片段内，超过文档的内容不回答，直接转人工。


 关于保留原有系统：只做加法

      公积金中心的原系统往往是老牌大厂很多年前建的，源码不完整，文档也过时了。你不可能去动它的ACD逻辑、IVR菜单、数据库表结构。iSoftCall的部署方案很简单：在语音中继和原PBX之间串一个SIP代理层，或者并联一个高阻监听口。原系统该怎么跑还怎么跑，中间件只是把语音流复制一份去做ASR和意图识别。
 
       具体到业务场景：用户打进来，原系统的IVR仍然放音“查余额请按1，提取业务请按2…”，同时中间件在后台做实时转译。如果用户直接说“我要查余额”，中间件识别后，通过一个预先协商好的HTTP接口，去调用原系统的余额查询存储过程（原系统不需要改，只是暴露一个只读接口），拿到结果后由TTS播报给用户。整个过程原系统没有任何感知，座席端甚至不知道这通电话已经被AI处理过。

      如果用户选择按键操作，原IVR继续走老流程；如果说自然语言，中间件截胡处理。两者井水不犯河水，互不干扰。


 关于国产化适配：不是换皮

       国产化适配这件事，很多厂商的做法是在麒麟系统上跑一个Wine兼容层，或者把Windows版的exe直接拷过来碰运气。iSoftCall在这个项目里干了三件实在的事：

第一，中间件的SIP协议栈和音频编解码模块（C/C++写的）拿到鲲鹏服务器上重新编译，解决了字节序和内存对齐的问题，不是靠模拟运行。

第二，原系统用Oracle，但中间件自己也要写话单和录音索引。iSoftCall改写了这部分SQL，适配了达梦的语法和分页规则，同时在连接池里做了方言判断——如果检测到是达梦，就用达梦的方式读写；如果是金仓，换一套写法。集成商在配置界面里选一下数据库类型就行，不用改代码。

第三，管理后台部署在东方通TongWeb上，没有出现常见的classloader冲突或jar包缺失。他们提前把依赖的第三方库都重新打包过，适配工作做得很细。
客户验收的时候，第三方测评机构拿扫描工具跑了一遍，没有发现因国产化迁移引入的高危漏洞。这一点已经超过很多匆忙适配的厂商。
 
 
市民体验：不刷存在感的升级

       项目上线后，市民打电话进来最直观的感受是：不用按很多层菜单了，直接说“我要预约提取业务”，机器人会确认“您是预约明天上午还是下午”，然后自动在原系统里创建预约记录并播报预约号。以前要转人工才能办的事，现在大部分在自助语音环节就解决了。
 
     夜间和周末时段，原系统本来只有值班座席，电话多了接不过来。现在机器人7×24小时在线，回答高频的“贷款额度怎么算”“提取多久到账”等问题。只有机器人无法处理或者用户连续说“转人工”的时候，才会把通话转到人工座席队列。座席上班后看到未接记录和机器人转过来的上下文，回拨时已经知道用户要办什么，不用从头问一遍。
 

     整个升级过程，原系统的座席界面、工单流程、数据库表结构，一行都没动。信息中心主任说了一句很实在的话：“我要的就是这种——后台你随便折腾，前台别让市民感觉系统换过。”
 
     选中间件这件事，公积金中心的底线不是“功能多强”，而是“不出事”。在这个前提下，iSoftCall至少把该做的事都做到了：本地化、国产化、不改原系统。别的花里胡哨的功能，等验收完了再慢慢加。