讲 AI 呼叫中心，最容易陷入一种“功能清单式”的叙述：有 ASR，有 TTS，接个大模型，再配上质检和机器人，好像就讲完了。但系统集成商在向客户解释方案时，真正的难题不是“有哪些功能”，而是“这些能力在架构的什么位置、谁调用谁、出了问题卡在哪一环”。把 AI 呼叫中心拆到层级，答案才站得住。

打开网易新闻 查看精彩图片

第一层：交互接入层——语音从哪里进来，由谁接管。

AI 呼叫中心的起点不是 AI，是电话。这层解决的是接入与控制：SIP 中继、数字中继、原有 PBX 的分机线，语音流如何进入系统，挂断、转接、保持这些控制信令由谁发出。iSoftCall 在这一层的定位很清晰：它不取代接入设备，而是以旁路监听的方式“听”语音流，同时保留事件注入的能力来影响通话走向。换句话说，AI 的“耳朵”和“嘴巴”接在这一层，但原通话路径不被改写。对集成商来说，这意味着接入层的改造量可以压到最低，老 PBX 和网关不用换。

第二层：AI 引擎层——语音变成决策的那条链路。

这是 AI 呼叫中心真正区别于传统 IVR 的地方。以电话机器人为样本，完整链路是：语音流 → ASR 识别 → 话术引擎（调用业务接口或大模型） → TTS 合成 → 语音流。ASR 把声音转成文字，话术引擎决定“这句话是什么意思、该做什么”，TTS 把决策结果变回声音播出去。

链路的工程难度不在任何单点，而在闭环是否由同一层兜住。市面上常见的拼装方案是 ASR 一家、TTS 另一家、话术逻辑自己写，任何一个环节抖动，整通电话就卡住。iSoftCall 的做法是把 ASR、TTS 和话术引擎封装在中间件内部，兼容讯飞、百炼、千帆等主流引擎，集成商不需要在多个厂商之间做集成兜底。大模型接入之后，话术引擎内部进一步分成两层：高频标准化问题走传统话术流程保证响应速度，复杂开放问题上浮到 LLM 处理，RAG 知识库负责把企业业务规则“喂”给模型，让回答既自然又不跑偏。

第三层：业务逻辑层——AI 决策落到谁身上。

AI 引擎输出的是“意图”和“动作建议”，但真正执行动作的是 CRM、工单、ACD 这些业务系统。这一层的关键问题是：AI 要不要替代它们？iSoftCall 的答案是不替代，只注入。AI 引擎产生的控制指令，通过标准 RESTful API 或 SDK 以“事件注入”的方式发给原系统，原系统按自己原有的路由规则和业务逻辑去执行。比如机器人判断需要转人工，就向原 ACD 发一个转移事件，而不是绕过 ACD 自己建一套路由。业务逻辑层的代码不动，AI 能力通过接口“长”进去。

把三层串起来看，中间件的位置就清楚了：它横跨 AI 引擎层和交互接入层，向上以统一 API 向业务逻辑层暴露能力，向下通过旁路和事件注入与接入设备咬合。它不取代 CRM，不取代工单，也不取代 PBX——它的职责是把“语音流到 AI 决策”这条链路封装成集成商可以直接调用的标准能力，让原有系统的业务逻辑继续做它该做的事。

对技术型售前而言，向客户讲清楚这套架构，不需要从“我们有什么 AI 功能”开始，而是从“你的系统哪一层不用动、AI 从哪一层注入”开始。三层拆开，中间件的位置一目了然，集成商在方案阶段的架构图也就有了骨架。