李维伊晚上十一点四十，告警电话把我从沙发上拽起来。接通率曲线在晚高峰之后没有回落，反而一路往下探，转人工率飙升了快二十个百分点。那是我们新版智能路由上线第三天，还没来得及把“接通率创历史新高”的海报发出去，就迎来了今年最狼狈的一次回滚。这一年，我和“融合通信”“智能”这两个词纠缠了三百多天，最大的体会是：让通信变智能这件事，难点从来不在把大模型接进去，而在于让AI在通信这个极度挑剔延迟、挑剔确定性、挑剔容错率的场景里，真正站得住脚。这篇年度总结，我想把这条路上的背景、方案、踩坑和复盘，原原本本记录下来。
1. 先交代背景：我们的融合通信网关在2025年初是什么状态
1.1 网关承载了什么，痛在哪里
我们做的是一套企业级融合通信网关，线下线上全渠道接入：传统电话通过PSTN/SIP进来，VoIP软电话、短信、微信公众号、App内消息、视频通话，全部统一接入一套网关，再按业务路由到各个技能组和业务系统。表面上，渠道是“通”的，但“融”得很浅。最典型的场景是：用户打电话进来问完套餐，挂断之后又去App上问一句“刚才那个套餐能办吗”，App端的座席完全看不到电话记录，用户得把身份、问题、诉求重新说一遍。这种割裂在2025年已经不是体验问题，而是成本问题——座席大量时间花在重复确认和重复解释上。
从业务侧看，痛点更具体。传统IVR菜单是按层级点选的，用户想投诉、想改套餐、想查余额，得先听一段语音广告再按一长串数字。用户的耐心越来越差，白天上班没空点，晚上有空了又嫌菜单太绕。运营同学也很为难，静态路由规则写了上百条，按主叫号码、按时段、按VIP等级、按技能组，规则之间偶尔还冲突，改一条常常牵一发动全身。说白了，规则是人写的，但用户的真实诉求是不能穷举的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
1.2 “智能”从哪条线撕开口子的
2025年上半年，公司给了我们明确的预算方向：在网关的智能化上做文章。之前团队不是没碰过AI——智能外呼做过、智能质检做过、智能客服机器人也做过，但都是单点接入，外呼一组选A模型，质检一组选B模型，客服一组用C模型，每个项目各接各的AI能力，互不相通。就像一个房子里装了一堆智能家电，但每台都要用各自的App控制，用户感受不到智能，只感受到麻烦。
认真讨论后，我们提出了一个判断：融合通信网关本身就是天然的AI Agent入口。它有渠道接入能力，有业务系统对接能力（查余额、查订单、开工单、预约、支付这些API都在网关后面），还有实时会话上下文。把大模型接进来，不是只做一个“会聊天的机器人”，而是让网关具备统一的“意图识别—任务规划—工具调用—回复生成”能力，才能真正解决“融而不智”的问题。我们内部把这个方向叫“智能网关”，切入点选的是最容易见效也最容易翻车的一条线：智能路由。
2. 智能路由：把话务分发从“配规则”变成“看意图”
2.1 旧方案为什么越来越不够用
老路由方案的核心是“按键+条件”。用户在IVR里按1查余额、按2办业务、按0转人工，系统再根据主叫号码、来话时间、会员等级这些标签做一个静态分配。这套模式在业务简单、渠道单一的时候还凑合，但到了2025年已经完全跟不上。
原因不复杂：用户表达诉求的方式，从来不是一个按键能承载的。很多人打电话不会说“我要查余额”，而是说“我这个月话费怎么扣了这么多，是不是哪里有问题”，这背后可能是投诉、是资费咨询、是想退订某个业务。系统如果只按“按键”来分发，用户只能一级级菜单往下找，找到最后往往直接按0转人工。我见过最夸张的例子，一个用户为了办理“携号转网+退订套餐+查余额”三个诉求，在IVR里来回转了三圈，最终才被踢到人工。这不是路由，这是障碍赛。
静态规则还有一个问题：写规则的人离用户太远。业务部门提需求、运营部门写规则、技术部门维护数据，一条规则上线往往要一两周。而这期间用户的话术早就变了。规则系统的维护成本越来越高，线上几百条策略，更新频率却低得可怜，真正在跑的业务场景和规则之间早就出现了明显的错位。
2.2 新方案骨架：ASR转写、意图识别、工具调用、动态路由
我们设计的智能路由，核心链路是这样的：
用户来电后，网关先做接入，ASR语音转写模块把用户的语音实时转成文本。这一步是流式的，用户说话的同时就在转写，不需要等整段话说完。转写结果进入意图识别模块，这里跑的是大模型，输入不仅包括当前这段转写文本，还包括会话的历史摘要、用户画像标签、当前渠道信息，比如“用户是App渠道来的VIP客户，近一周打过三次电话投诉话费，当前会话情绪检测为负面”。大模型输出一个结构化的意图标签，例如“投诉话费扣费”，附带一个置信度分数。
紧接着路由决策模块介入。置信度高，直接按意图标签分到对应技能组，或者更进一步——如果这个诉求属于高频简单业务，Agent直接调用业务接口自动办理。比如“查余额”这种，压根不需要转人工，Agent查完计费系统，直接把结果用语音播报给用户，一步到位。置信度中等，系统播报确认：“您是想办理余额查询吗？”用户确认后再执行。置信度太低或者连续两次确认失败，直接转人工，绝不硬猜。
技术上有一个关键设计：意图标签体系必须和下游系统对齐。大模型输出的是自然语言，但技能组、CRM、工单系统只认结构化标签。所以我们提前定义了一套意图标签树，覆盖线上的高频业务场景，大模型的输出被约束在这棵标签树上。这一步很重要，它保证了“AI听懂人类话术”之后，还能被现有业务系统消费。
2.3 上线初测的数据
智能路由试运行两周后，我们统计了首批数据：
| 指标 | 改造前 | 改造后 |
|---|---|---|
| 意图识别准确率（内部测试集） | 87.2% | 92.3% |
| 路由到正确技能组的比例 | 81% | 89% |
| 平均接通前等待时长 | 23秒 | 14秒 |
| 转人工率 | 38% | 24% |
数据看起来很不错，尤其是平均接通前等待时长从23秒降到14秒，用户体感是质的提升。但我一直提醒团队：在线下指标再漂亮，都要过线上复核这关。试运行期间我们每天随机抽200通录音，人工复核路由结果是否正确。这个环节帮我们发现了不少隐患，也为第三天晚上的翻车做了铺垫。
3. 一路踩过来的坑：AI调度的三次“翻车”和补救
3.1 “我要投诉”被识别成“我要办理”：一次语义歧义的教训
上线第三天傍晚，我接到第一个线上投诉：一个用户气冲冲地说“我要投诉你们的套餐扣费问题，我要办理退订，顺便把我的余额查一下”，结果系统把这句话识别成了“办理退订”，话务被分到普通业务组。用户被普通业务组接了之后，发现不是投诉通道，又重复了一遍，情绪彻底爆发。
那天晚上我们拉了三层日志来查这个问题。先听录音，确认用户原话；再拉ASR转写文本，发现转写结果里保留了“我要办理退订”这一段，模型就截取了“办理退订”这个片段，忽略了更靠前的“我要投诉”；最后翻大模型的prompt，发现当时的设计只让模型做“诉求分类”，压根没让模型做“情绪判断”。也就是说，“投诉”这种带有强烈负面情绪的信号，根本没有被单独建模。
修复方案是在意图识别链路前增加一道“情绪闸门”：先用一个独立的、更短的大模型prompt做情绪检测，一旦识别到愤怒、失望等强负面情绪，直接走投诉绿色通道，不再参与常规意图分类。这个改动上线后，投诉类会话的平均接入时间从五分钟压缩到一分钟以内。
这个坑让我彻底记住一件事：通信场景里的AI识别，不能只看“用户说了什么”，还要看“用户怎么说”。语气、情绪、节奏，都是路由要素。
3.2 大模型并发延迟拖垮呼叫建立：一次性能事故
就在同一天的晚高峰，更大的坑来了。智能路由上线第三天，晚高峰并发一上来，大模型接口的P95延迟从800毫秒飙到4秒多。用户打电话进来，听到的是“嘟——嘟——”之后漫长的静音，很多人等不到座席就挂了。这就是开头那个告警的真相。
排查链路是这样的：先看网关侧的呼叫时间线，发现大量呼叫的等待时间都卡在“调用识别服务”这个环节；再看模型服务监控，GPU利用率逼近上限，排队请求堆积严重；最后查token消耗，发现根子在于两处浪费。一是语音转写出来的文本太长，几十秒的录音转成文字有近千字，全部塞给大模型；二是提示词里塞了整份业务知识文档，导致每次推理都要处理大量无关token。本质上是拿一辆卡车运一件小快递，把算力全耗在运输本身上了。
修复分三步走。第一步，上线两级识别架构：先跑一个轻量分类器，对高频简单意图直接返回标签，不经过大模型；只有模糊、复杂、多意图的会话才进入大模型精排。这个改动直接把大模型调用量砍掉了约六成。第二步，提示词瘦身：把业务知识从“全量塞进prompt”改成向量检索，每次只注入和当前会话相关的片段。第三步，也是我认为最重要的兜底：给大模型调用加超时降级开关，超过1.5秒未返回就自动回退到规则路由，宁可回到传统方式，也不能让AI成为通信链路上的单点故障。
3.3 低置信度时怎么选：把选择权交还给用户
这两次事故之后，我们仔细复盘了置信度分布和错误类型，发现一个规律：当模型对意图识别的置信度在60%到75%之间时，硬着头皮自动判断的准确率只有七成左右，但恰恰是这类会话被大量自动转接，导致错分率很高。
怎么处理？我们设计了两档阈值加一个确认机制。高置信度阈值设在85%，高于它直接自动处理；低置信度阈值设在60%，低于它不猜了，直接转人工；60%到85%之间的中间区间，系统播报一句确认话术：“您是想办理余额查询吗？”让用户确认之后再执行。这里有个细节：确认话术不要用“系统识别到您的意图是……吗”这种机器人腔，用户会懵。
确认次数还必须设上限。我们限定最多确认两次，第三次无论置信度多少都直接转人工，避免把用户困在循环里。这套机制上线后，转人工率从最初的24%回升到31%，但整体用户投诉率持续下降，体验分从4.1升到4.4。用一点自动化率换实实在在的用户满意度，这笔账是划算的。
这条经验后来成了我们团队的一个共识：AI路由不要追求“全自动”，要追求“在合适的时候把选择权交还给用户”。人机协作的边界，用置信度来划，比用规则来划靠谱得多。
4. 从“接入AI”到“长出一个AI底座”：下半年我们重构了平台
4.1 为什么不能每个业务都单独调大模型接口
上半年的智能化属于“散装AI”，外呼组接A模型做话术，质检组接B模型做审核，客服组用C模型做问答。到七月份我们做了一次系统盘点，发现重复建设已经到了不可忽视的程度：每个组都在写鉴权、限流、敏感内容过滤、数据脱敏、超时重试，写的代码逻辑几乎一样，只是接的模型供应商不同。更麻烦的是，各组之间会话记录互不相通，用户在一侧产生的会话上下文，另一侧完全拿不到。
我们算了笔账：与其继续让各业务组各自接模型，不如把AI能力沉淀成平台能力，就像当年把语音、消息、视频融合成一套通信网关一样，再把AI能力融合成一套智能底座。这个判断让下半年的研发方向清晰了很多。
4.2 智能底座沉淀的四个能力模块
这个底座最终沉淀成四个能力模块，现在已经成为所有智能化业务的地基。
第一个是统一模型接入层。对接多家模型供应商，上层业务不再关心具体接的是哪家，由接入层根据模型能力、成本、延迟做自动路由。某一家出故障时自动切换，业务无感。我们初期也调研过Dify这类现成的智能体平台，最终选择自研轻量层，核心原因有两个：一是延迟要求太苛刻，部分模块需要毫秒级返回，外部平台不好定制；二是会话记忆和业务系统深度绑定，自研更容易做到“开箱即用”。
第二个是统一会话记忆。按用户ID、渠道、会话维度统一存储摘要和上下文，跨渠道能继承意图。这是融合通信真正区别于普通智能客服的地方。
第三个是工具调用网关。把业务系统API方法化，让Agent能通过“意图识别—工具调用”直接完成业务办理。用户说“查余额”，Agent就能查计费系统并播报结果，不需要转人工。
第四个是策略与可观测。所有AI决策都记录置信度、模型版本、提示词版本、耗时、最终路由结果，形成全链路trace。没有这个，前两次事故就不可能快速定位。
举个例子，现在一条实时路由日志长这样：
json复制{
"query": "我要投诉上月扣费",
"first_pass": "fasttext: 投诉(0.72)",
"emotion_gate": "high_anger",
"final_decision": "priority_group: complaint_channel",
"model_used": "emotion-gate-v2",
"latency_ms": 320
}
4.3 融合通信里“会话记忆”为什么最值钱
很多人问我，“融合通信”和“多渠道客服”到底有什么本质区别？我的回答是：多渠道客服是把渠道铺开来，让用户随处能找到你；融合通信是把渠道背后的上下文粘起来，让用户在任何一个渠道开口时，系统都记得他在别的渠道说过什么。
举一个我们线上天天在发生的场景。用户先打电话进来说“我上个月账单有问题”，客服帮他排查到一半，电话断了。用户转头打开App，把账单截图传给了在线客服。在旧的架构里，App座席看到的是一个全新的会话，用户得重新解释一遍身份和问题。但现在，统一会话记忆自动把App会话关联到半小时前的那通电话上，座席工作台直接弹出“该用户30分钟前咨询过账单问题，已上传截图”，座席开口第一句是“您刚才电话里说的账单问题，我看到您传的截图了”。这就是融合，用户会明显感觉到“这个客服好像认识我”。
实现这个能力有几个容易被忽略的细节。会话ID不能只靠渠道自己的会话ID，要按照用户身份归一化，手机号、微信号、客户ID都要映射到统一用户ID。会话记忆优先存储结构化摘要，而不是把每通电话全文存进去，这样更省token，也更安全。最后是数据保留策略，语音原文最多保留30天，结构化摘要保留更久，兼顾合规和业务需要。
5. 数据复盘：哪些指标真变了，哪些只是自我感动
5.1 关键指标对照：全年数据摆出来说话
年底复盘，我把全年核心指标拉了一张表：
| 指标 | 改造前 | 改造后 |
|---|---|---|
| 意图识别准确率（内部测试集） | 87.2% | 92.3% |
| 路由到正确技能组比例 | 81% | 89% |
| 平均接通前等待时长 | 23秒 | 14秒 |
| 转人工率 | 38% | 31% |
| 一次解决率 | 61% | 73% |
| 投诉率（每万通） | 3.8起 | 2.1起 |
| CSAT（5分制） | 4.1 | 4.4 |
注意转人工率这一行，最终稳定在31%，不是最初测试时的24%。因为回退策略和确认机制上线后，一部分低置信度会话被有意引导回人工。从“省人力”的角度看，这个数字不是最优解；但从“用户体验”和“投诉率”看，31%比24%健康得多。自动化率少一点，满意率高一点，这个交换我们认为是值得的。
5.2 不够好的地方：自动化率没有达到预期
年初我们立了一个“60%自助完结率”的目标，年底实际只有37%。这个差距得诚实面对。卡点主要在三个地方。
一是复杂业务。涉及多系统协作的诉求，比如“改套餐+退订增值业务+迁移号码”这种组合操作，Agent经常做到一半卡住。因为每个系统都要求不同的身份核验信息，信息缺失一环，整个流程就推进不下去。二是ASR确实是最大瓶颈。口音重、背景噪音大的场景，语音转写准确率明显下滑，文本不准，下游的意图识别再强也白搭。年中我们试过接增强语音模型，效果好一些，但成本涨了将近三倍，最后只覆盖了VIP线路。三是渠道差异造成的智能化断层。App文字渠道识别准确率高、体验稳定，电话语音渠道差不少，两个渠道的用户体验不齐，业务部门对此也有意见。
5.3 复盘结论：智能化的价值不在“替代”而在“兜底”
说句实在话，现在一谈AI客服，很多人的第一反应就是“又要裁员了”。但我们的数据讲了一个完全不同的故事。
AI全量做初筛，人工只处理高风险和复杂case，座席人均日处理量从90通降到55通，看起来“处理量”下降了，但工单解决率从68%升到了81%。投诉渠道的座席也不再是“受气包”，因为系统在电话接入时就把上下文和可能的解决方案推送到了工作台，座席开口之前就知道用户是谁、遇到了什么问题、之前处理到哪一步。座席从“倾听者”变成了“解决者”。
这个转变的价值，比单纯压低成本重要得多。智能化真正的收益是把人工从低质量的重复劳动里兜出来，让人的价值往高处走，而不是简单地把人替换掉。
6. 下一年的大方向：从“识别意图”走向“主动服务”
6.1 从被动响应到主动触发
现在这套系统，本质上是“用户来找我们，我们听懂他要什么”。下一年我想做的第一件事，是从被动响应转向主动服务。通过用户的行为特征识别潜在需求，在用户开口之前先动起来。
举一个已经小范围验证过的例子：一个用户连续一周每天都打电话查余额，大概率是对话费异常有疑虑。系统识别到这个模式后，可以主动推一条短信，告知月结日、当前消费明细、以及一个自助查询入口。我们做了三周试点，推送组用户的次日话量比对照组下降了约8%，这个方向明年会扩大范围继续做。
6.2 实时语音交互与全链路可观测
目前大部分环节还是“先ASR转写，再交给大模型，再返回结果”，延迟和自然度都有损耗。明年计划在部分线路上试验实时语音流式交互，让AI边听边回应，更接近人与人之间的对话节奏。
另一条线是继续强化可观测。目标是让每一个AI决策都能复盘：路由结果、置信度、prompt版本、模型版本、耗时、最终用户反馈，一个都不能缺。AI决策不像传统规则那样确定性很强，出了问题必须能回溯、能验证、能收敛。这一点在我们做融合通信这种对稳定性要求极高的场景里，比模型效果本身还要重要。
写到这里，回想这一年，最大的感受是：融合通信的“融合”，从来不是把几个渠道塞进一个网关就完事，真正的融合是让用户的诉求在渠道之间无缝流动；而“智能”也不是接一个大模型就万事大吉，它是让系统在用户还没说出口的时候，就已经做好准备。明年我不期待什么颠覆性的突破，只希望把这些事情再做扎实一点，让服务真正跟着人走，而不是让人跟着系统走。