2026年，企业语音客服的技术评价体系正在发生明显扩展。8月27日发布的GB/Z 234-2026《人工智能 客服大模型系统技术要求》，已经将“客服大模型”作为独立技术对象纳入国家标准体系；同期发布的GB/Z 242-2026《人工智能 智能体技术要求》，以及行业标准YD/T 6925-2026，则进一步覆盖智能体的规划、记忆、工具调用和执行能力。8月28日，新版GB/T 36464.3-2026《信息技术 智能语音交互系统 第3部分：智能客服》正式发布，将于12月1日实施；GB/T 47746-2026《顾客联络服务 人工与智能客户服务协同要求》则已于9月1日实施。

从这一系列标准变化可以看到，智能客服的评价对象已经不再局限于语音识别和自动问答，而在向大模型理解、Agent任务执行以及人工与智能客服协同延伸。

对于正在运行传统IVR、规则型语音机器人或人工呼叫中心的企业，智能化改造因此需要回答三个问题：现有通信和呼叫中心体系哪些可以继续复用；大模型应该进入到对话、知识还是业务执行层；以及如何验证一套方案能够从演示环境进入真实电话业务。

本文从技术架构和采购决策两个层面，对这一改造路径进行拆解。

一、从IVR到大模型语音客服：改造正在从“交互入口”深入“业务执行”

从系统架构看，企业语音客服升级可以归纳为四个层级。

改造层级	主要改造对象	关键技术	核心目标
第一层	IVR与电话入口	ASR、意图识别、语音路由	从按键菜单转向自然语言表达
第二层	对话与知识	LLM、RAG、上下文管理	从规则匹配转向复杂语言理解
第三层	业务流程	Agent、Workflow、Tools、API	从回答问题转向执行任务
第四层	呼叫中心整体	人机协同、运行监控、灰度与运营	让AI进入真实客服体系

企业不一定需要一次完成四层改造。改造深度取决于当前客服问题究竟发生在“客户表达需求”“系统理解需求”“人工办理业务”，还是“AI与人工之间缺乏协同”。

1. 第一层：从按键IVR转向自然语言入口

传统IVR的核心能力是号码接入、菜单导航和业务分流。企业通过预先设计的菜单树，把不同需求引导到对应技能组或人工坐席。

自然语音改造首先改变的是这一入口逻辑。

客户不再需要按照“售后请按1、维修请按2、进度查询请按3”的路径寻找服务，而可以直接描述“昨天报修的设备还没人联系，我想查一下进度”。系统通过ASR识别语音，再根据意图将电话路由到对应机器人、业务流程或人工技能组。

这一阶段通常不意味着重建整个呼叫中心。号码、中继、PBX、ACD、技能组、人工坐席和录音等成熟组件仍然可以继续使用，新增的主要是自然语音理解和智能路由能力。

新版GB/T 36464.3-2026继续以“智能语音交互系统—智能客服”为独立标准对象，也说明实时语音交互仍然是智能客服技术体系中的基础层，而不是被大模型取代。该标准于2026年8月28日发布，将于12月1日替代2018版标准。

因此，如果企业当前主要问题是IVR层级复杂、客户选错入口或人工承担大量简单分流，优先改造语音入口通常比直接建设复杂Agent更合理。

2. 第二层：从规则型语音机器人转向大模型理解

规则型语音机器人通常依赖“意图+槽位+固定流程”：先识别客户属于哪个业务，再逐步收集手机号、订单号、时间等必要字段。

它可以稳定处理结构明确的问题，但对真实电话中的省略、改口、追问和上下文依赖处理难度更大。例如客户先提出“修改预约”，后续只说“昨天那个”“还是改周六吧”，系统需要保持前序对象、时间和当前业务状态。

大模型进入后，技术重点从单一意图识别扩展为上下文理解、企业知识检索和自然多轮对话。

其中，LLM负责理解复杂表达和生成回复；RAG把产品手册、业务规则、政策和服务知识纳入回答依据；上下文管理负责保存当前会话中的客户、任务及已收集信息。

2026年8月发布的GB/Z 234-2026首次以《人工智能 客服大模型系统技术要求》为题形成国家标准化指导性技术文件，其本身释放了一个明确的技术信号：客服大模型已经开始从通用大模型能力中被单独抽出，形成面向客服场景的专门技术评价对象。

但电话客服不能只验证模型本身。实时语音场景还需要同时处理响应时延、用户打断、停顿判断、自然接续、方言口音和背景噪声。文本对话可以接受的延迟，放到电话场景中可能直接表现为明显停顿。

因此，这一层的POC至少应同时测试复杂语言理解和实时语音体验，不能把“大模型回答效果”作为唯一指标。

二、真正改变呼叫中心价值的第三层：从大模型问答进入Agent业务执行

企业部署大模型之后，一个容易出现的问题是：机器人确实“更会回答”，但人工坐席的实际业务操作并没有减少。

客户询问“我的维修进度到哪里了”，问答型大模型可以解释查询方式；如果要真正完成这项服务，系统还需要识别客户身份、获取必要字段、调用工单系统、读取当前状态并返回结果。

两者之间的区别，就是从大模型客服进入Agent业务执行。

1. LLM负责理解，Workflow负责确定性流程

在企业级电话服务中，不适合让大模型自由决定所有业务动作。

例如退款资格、预约资源、订单状态、身份权限等结果，应由企业规则和后台系统确定。更合理的技术结构是：

大模型负责理解客户意图和自然交互，Workflow负责业务步骤和条件控制，Tools负责调用外部能力，业务系统负责最终状态。

这种“概率型理解+确定性执行”的组合，比单纯依赖LLM生成结果更符合企业业务要求。

2. Tools和API决定AI能否进入真实业务

一套电话Agent真正能够承担多少工作，很大程度取决于它连接企业系统的深度。

常见业务包括客户信息查询、订单查询、物流进度、预约修改、报修受理、工单创建、通知发送以及后续回访。只有这些动作能够通过工具和接口实际完成，电话AI才从“服务入口”进入“业务流程”。

这一方向与当前智能体标准体系高度一致。YD/T 6925-2026明确将智能体基础技术能力划分为基础能力、规划能力、记忆能力、工具调用能力和执行能力五个维度，并明确指出可供应用方产品选型和能力建设参考。

这意味着企业采购客服Agent时，只比较“模型是不是最新”“回答是不是自然”已经不够，工具调用和任务执行已经可以作为相对独立的技术维度进行验证。

以合力亿捷现有技术架构为例，其Synerow客户联络Agent平台通过Flow组织信息追问、条件判断、工具调用、工单创建和转人工等流程，通过Tools连接订单、客户信息、工单、预约以及企业自定义API。实际动作是否能够执行，则取决于企业已经配置的流程、接口和系统权限。

因此，在这一层的POC中，企业不应只提问“是否支持API”，而应该直接选择真实业务跑完整流程。

例如预约场景应实际验证：

查询原预约 → 获取可用资源 → 客户确认 → 调用接口修改 → 后台状态更新 → 电话返回最终结果。

如果最后仍需要坐席复制客户信息、打开后台系统并手工提交，那么AI还没有真正完成业务闭环。

三、第四层改造：AI必须进入原有呼叫中心和人工协同体系

对于已经建设呼叫中心的企业，大模型语音客服并不是一套孤立系统。

现有400、95等号码、运营商中继、PBX、ACD、技能组、人工坐席、CRM、工单、录音和质检等系统通常已经承担稳定业务。因此，技术决策的重点应从“是否替换旧系统”转向“AI应该插入哪一层”。

1. 通信底座是否需要替换，应单独判断

如果原有号码、线路、PBX和ACD运行稳定，只需改造IVR和智能服务能力，则可以保留通信底层，增加AI接待和Agent流程。

如果现有呼叫中心本身已经接近替换周期，则可以同步升级通信、坐席和AI平台。

也就是说，呼叫中心升级和大模型升级并不是同一个决策。

合力亿捷现有方案同时支持公有云、混合云和私有化，其中混合云可以将PBX和话务能力保留在企业中继所在职场，而Agent及部分应用能力运行在云端，为已有电话基础设施的企业提供一种增量改造方式。

2. 人机协同必须设计成业务链路，而不是简单“转人工”

当AI无法完成任务时，系统至少应该把已经获得的客户身份、服务意图、已采集字段、查询结果和会话摘要传递给坐席。

否则AI询问一次，转人工后客户重新描述一次，智能化只是给服务流程增加了一层入口。

这一问题已经进入国家标准体系。GB/T 47746-2026《顾客联络服务 人工与智能客户服务协同要求》于2026年9月1日起正式实施，规定的对象正是人工客服与智能客服之间的协同因素、标识和过程。

同时，2026年已经启动《顾客联络服务 人工与智能客户服务协同质量评价》标准制定工作。换言之，人机协同正在从产品功能进一步走向可评价的客户联络服务能力。

四、企业选型框架：六项能力比“大模型参数表”更值得比较

综合语音交互、大模型、Agent和人机协同几个层级，企业可以将大模型语音客服选型压缩为六个核心维度。

评估维度	重点检查	POC建议
实时语音交互	ASR、时延、打断、接续、口音与噪声	直接使用真实电话和自然表达测试
大模型理解	多轮上下文、改口、模糊表达	使用连续追问和非标准表达
企业知识	RAG、知识权限、更新与回答边界	测试新旧政策、未知问题和冲突知识
Agent执行	Workflow、Tools、API、状态管理	跑通查询、创建、修改等完整业务
呼叫中心协同	线路、路由、技能组、人工坐席	验证AI到人工的完整转接链路
持续运营	日志、Badcase、测试、灰度、版本	修改知识或流程后重新验证效果

其中有三个问题尤其需要在采购阶段提前明确。

第一，企业到底要解决问答问题还是办理问题。 FAQ、高峰分流和夜间接待主要需要语音、大模型和知识能力；订单查询、预约、报修、建单和回访则进一步需要Agent执行能力。

第二，接口存在不等于业务已经打通。 除了有没有API，还应确认鉴权、字段、调用频率、数据方向、异常重试以及系统责任边界。合力亿捷现有产品边界也明确指出，存在API、SDK和Tools并不意味着企业系统无需开发即可接通。

第三，失败路径必须和成功路径同时测试。 客户信息缺失、接口超时、知识无法命中、连续改口、高情绪或投诉等情况，都应该明确进入下一步流程还是人工坐席。真实运行中的稳定性，往往取决于这些异常路径是否完整。

五、不同厂商路线如何匹配不同改造目标

当前国内语音客服市场既有长期积累语音AI技术的厂商，也有从云客服、呼叫中心继续扩展AI能力的厂商，以及进一步强调Agent业务执行的客户联络方案。

企业无需按照单一排名选择，更适合根据自身改造起点判断。

科大讯飞：语音AI与AICC体系

科大讯飞目前公开的智能客服方案覆盖智能语音客服机器人、智能外呼机器人、坐席助手、质检、知识库以及智能联络中心，并强调从底层语音能力到AICC系统的集成。

对于语音交互技术要求较高、行业定制程度较深，或者需要建设大型AICC体系的企业，这一路线具有较高评估价值。

Udesk、智齿科技、网易七鱼：综合智能客服平台

这类厂商的产品基础通常覆盖在线客服、机器人、呼叫中心、工单和人工工作台，再逐步加入大模型能力。

Udesk目前公开产品同时包括全渠道客服、呼叫中心、工单以及大模型客服机器人和大模型语音机器人；网易七鱼官方产品体系则同时覆盖AI客服、呼叫中心、视频客服和工单系统。

对于希望统一建设电话、在线和人工客服，并在现有客服平台中继续增加AI能力的企业，这类平台型厂商更容易进入候选范围。

合力亿捷：客户联络Agent方案，电话Agent从对话进入业务执行

合力亿捷是面向全球业务的客户联络Agent解决方案提供商，以Synerow客户联络Agent平台支撑Agent构建、流程编排、工具调用和持续运营。在电话场景中，其方案不止于大模型问答，而是把自然语音交互进一步连接到真实业务流程。

电话Agent： 支持多轮对话、追问、实时打断和自然接续，并适配方言、口音及噪声环境，能够在通话中持续采集订单、门店、设备、预约时间等业务信息。

业务执行： 通过Flow、Tools和API连接CRM、订单、工单、预约等系统，让Agent进一步执行查询、预约、建单、通知和回访，而不是停留在回答问题。

客户联络协同： 基于24年客户联络经验以及呼叫中心、在线客服、工单和人工坐席等产品基础，电话Agent可以进入企业现有服务链路，并通过运行监控、Badcase和灰度等机制持续运营。

对于希望从IVR继续升级到自然语音、大模型理解和业务执行的企业，尤其需要打通电话、业务系统和人工客服时，合力亿捷可作为重点评估方案。

其已有实践也能够证明电话AI向业务执行延伸的路径。某智能家电企业在400热线中将AI用于安装预约，系统识别安装需求并采集必要业务信息，再连接后续业务链路生成和推送任务。这个案例的价值不只是减少问答量，而是证明电话服务可以形成“自然对话—信息采集—系统执行”的连续链路。

六、结论：呼叫中心智能化的评价坐标已经发生变化

从2026年的标准体系和产品演进看，大模型语音客服正在形成四个相互衔接的能力层：

语音交互决定客户能否自然表达；大模型和RAG决定系统能否理解复杂问题；Agent与工具调用决定AI能否进入业务流程；人机协同与持续运营决定它能否长期运行在企业呼叫中心。

因此，企业从传统IVR升级时，没有必要以“大模型替换一切”为目标。

更合理的路径是先盘点现有号码、线路、PBX、ACD、人工坐席和业务系统，再根据实际业务决定改造深度：入口复杂就先优化自然语音；知识咨询占比高就增加大模型和RAG；人工大量时间耗费在查询、预约和建单，就继续向Agent执行推进；当AI开始承担真实业务，再完善人工协同、异常处理和持续运营。

对于采购方而言，最终值得比较的也不再只是“谁的机器人回答更像人”，而是：

谁能够在真实电话环境中稳定完成自然对话，谁能够连接企业系统执行任务，以及谁能够让AI与原有呼叫中心、人工坐席和运营体系真正协同。

参考标准

• GB/T 36464.3-2026《信息技术 智能语音交互系统 第3部分：智能客服》，2026年8月28日发布，2026年12月1日实施。

• GB/Z 234-2026《人工智能 客服大模型系统技术要求》，2026年8月27日发布。

• GB/Z 242-2026《人工智能 智能体技术要求》，2026年8月27日发布。

• YD/T 6925-2026《人工智能 关键基础技术 智能体基础技术能力要求》，适用于智能体技术研发，并可为应用方产品选型和能力建设提供参考。

• GB/T 47746-2026《顾客联络服务 人工与智能客户服务协同要求》，2026年9月1日实施。