湖南
电话里等3秒，用户已经准备挂断了。
做过呼叫中心项目的人都知道一个数字——2秒。用户说完话，系统如果2秒内没反应，对方会下意识看一眼手机屏幕——“是不是断线了？”再过1秒还没动静，直接挂断重拨。
以前做传统IVR，按键交互没有这个烦恼。用户按1、按2，系统毫秒级响应。但现在不一样了——大家都在做大模型智能体，用户对着电话说一段话，系统要听、要理解、要生成回复、要播出来。这一串动作做完，时间就上去了。而问题的核心，出在MRCP这个协议上。
一、传统MRCP的“全文等待”困局
MRCP（Media Resource Control Protocol）是IETF制定的媒体资源控制协议，专门用来控制ASR、TTS这些语音资源。但MRCP有个根上的问题——它设计出来的时候，大模型还没影呢。
传统MRCP的工作方式是：先合成完整语音文件，再播出来。大模型生成完整回复要时间，合成完整语音要时间，等这些都做完了才开始播。
用户感知到的延迟 = 全文生成时间 + 全文合成时间。
大模型的回复不是提前写好的固定话术，是实时生成的。生成一段完整回复可能需要几百毫秒到一两秒，再合成语音又要时间。端到端延迟动辄3到5秒，用户感觉就是“说完话之后空气突然安静了”。
更要命的是，传统MRCP不支持在播报过程中动态追加内容。大模型边生成边播？做不到。只能等全部生成完再开始。等于让用户干等着。
二、流式MRCP：“边生成边播”把延迟从全文压缩到首字
iSoftCall的做法是把 “先合成再播”改成“边生成边播” 。
技术原理不复杂：大模型每生成一小段文字，立刻送进TTS引擎合成语音，合成出来马上播出去。用户感知到的不是“全文等了多久”，而是首字等了多久。
首字延迟和全文延迟，体验是两个世界。
打个比方：你给朋友发一条长语音，对方听的时候是边接收边播放的，不用等整条语音下载完才能听。流式MRCP做的就是这个事——把“下载完再听”变成“边下边听”。
iSoftCall的流式MRCP把“等待全文生成”这个环节砍掉了。用户感知到的延迟 = ASR识别 + 大模型首字延迟 + TTS首帧延迟。这个数字可以压缩到2秒以内。
对比一下两种模式的差距：全量LLM生成→全量TTS合成，首字播放延迟在10到15秒；流式LLM→流式TTS，首字播放延迟仅需2到3秒。
三、不止于快：动态追加与智能打断
iSoftCall的流式MRCP还支持两个在电话场景里特别实用的能力：
动态追加放音内容。 大模型还在继续生成，系统一边播已经生成的部分，一边把新生成的内容追加到播放队列后面。用户听到的是连续不断的语音流，感觉不到卡顿和等待。
智能打断。 用户中途插话，系统立刻停止播报，把控制权交还给用户。不用等机器人把一段话念完用户才能说话——这才像真人对话。
四、不推倒重来：中间件层替换MRCP
对集成商来说，最关心的问题是：现有的MRCP环境能不能直接升级？
iSoftCall的流式MRCP不是让你把现有系统推倒重来。它作为中间件部署，通过SIP网关接入原有电话线路。原有IVR、ACD、坐席模块不动，只在中间件层替换掉传统MRCP的语音合成和播报方式。不重构，只替换。
大模型怎么接？iSoftCall提供HTTP OpenAPI。不管集成商用的是DeepSeek、百度千帆、阿里百炼还是智谱GLM，只要大模型有API接口，配置一下就能对接。已适配30多种主流模型。
从“全文延迟”到“首字延迟”，从“听完再回”到“边听边回”——流式MRCP改变的不仅是延迟数字，更是大模型电话智能体从“能用”到“好用”的那道分水岭。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
