智能客服Agent多模型调度的场景映射与降级路径

ByondLabs在优化一个印度语音Agent的生产延迟时，打出了一条逐轮延迟日志。

turn latencies: VAD=45ms, EOU=120ms/890ms, STT=950ms,LLM=1200ms (TTFT=450ms), TTS=650ms (TTFB=120ms)

大模型推理占了一轮延迟中最大的一块——1200ms。其中TTFT（首token到达时间）是450ms，用户感受到的等待就是这个数加上TTS首字节延迟，而不是1200ms。把TTFT从450ms压到轻量模型的300ms以内，每轮省150ms，十轮电话省下一秒半。

但轻量模型处理不了多条件跨步骤的复杂推理。90%的客服来电是FAQ和单条件查询——轻量模型够用。10%是投诉、跨订单比对、条款判断——需要强推理。全量用强模型，简单问题多付了延迟和成本。全量用轻量模型，复杂问题答不好，最终转人工或重复来电。多模型调度的需求从这里产生。

但这只是动机。下面的问题都在实现方式里。

一、只有级联架构才支持多模型调度

多模型调度的前提容易被当成默认条件，但它不是。Softcery在2026年语音Agent架构对比中明确指出三种架构的灵活性差异：端到端语音模型（Voice→Unified Model→Voice）是"不透明的推理层"，LLM作为一个黑盒内嵌在统一模型中，无法被外部替换。半级联（语音输入→文本LLM推理→语音输出）的LLM层虽然可独立替换，但组件间需要紧密的流式协调。

链式管线（STT→LLM→TTS）才是真正支持LLM层自由替换的架构。Softcery的原话是"high flexibility – easy to swap out STT, TTS, and LLM independently"。代价是链式架构的延迟高于端到端方案——每个组件等前一个完成——但多模型调度只能在有这个灵活性的前提下讨论。

合力亿捷的通话Agent本身就是链式管线架构。ASR→大模型推理→TTS的级联方式意味着LLM层是一个可以独立选择和替换的组件。MPaaS在此基础上支持按场景接入豆包、通义千问、DeepSeek等不同模型，不绑定单一供应商。多模型调度的工程基础——LLM层的可替换性——在通话Agent的链式架构中是一个既成事实，不是额外的集成工作。

二、首句话不完全等于场景复杂度

多模型调度的第一个直觉方案是按首句话做分配。用户说"我想查一下订单"→简单查询→轻量模型。但同一个开头可能发展成完全不同的复杂度。

"我想查一下订单"——六个字，单条件查询，轻量模型处理。"我想查一下上个月退的那笔钱，当时客服说分两次退，到了今天我只收到一笔，中间还改过一次收货地址，另一笔到底退不退"——同一个开头，第三个分句之后已经是跨时间跨步骤跨系统的多条件推理。从"我想查一下订单"到系统判定"简单查询"，中间可能只有一两秒——这个时间点，模型已经分配完了。

ByondLabs的生产数据表明约70%的客服咨询在首轮就能确定复杂度。但剩下30%的误判中，大部分不是"选错了模型"，而是"选的时候用户还没说完"。

合力亿捷MPaaS在业务流程设计中的处理方式是把流程状态引入分配逻辑。一个已经在"订单查询"流程中走了三轮的用户，和刚接通就说"问个问题"的用户，后续触发跨系统查询的概率完全不同。Flow的状态跟踪机制意味着系统知道用户当前处于哪个业务流程节点——处于流程中间的用户，即使本轮表达简洁，后续复杂化的概率也远高于独立来电的开头场景。这个状态信息比首句话的文本特征更能预测该场景需要什么级别的模型推理。

三、渐进式确认与掩盖效应

切换模型本身的延迟在百毫秒级，不是问题。问题是切换发生在对话的什么位置。

渐进式确认的策略是：首轮统一用轻量模型回答（延迟最低），同时后台评估复杂度。需要升级时，第二轮开始前切到目标模型。此时用户正在听首轮回答，音频在播放，切换间隙被掩盖。这个"掩盖效应"成立的前提是用户耳边有声音——人对听到第一句话之前的静默容忍度远低于对话中途的短暂间隙。

掩盖效应是单向的。反过来——首轮用强模型、发现过于高配、第二轮降级——降级后的轻量模型回答质量明显低于强模型的首轮回答。用户被首轮拉高了预期，降级后的落差即使回答内容没问题也会被感知为质量下降。降级路径比升级路径更难处理，因为差距不在延迟而在回答质量。

ByondLabs的日志还揭示了一个附加约束：如果轻量模型的首轮回答质量太差，连掩盖效应本身都会失效——用户听到不满意的回答后，对后续切换间隙的容忍度也同步下降。首轮轻量模型仍然需要达到一个最低的回答质量标准，才能让掩盖效应有效运作。

四、降级深度不超过两层

多模型调度的降级路径容易设计成多层链表：轻→中→强，一层处理不了就降下一层。每层降级在逻辑上成立——是，换更强的模型就行了——但每多一层降级，用户在那通电话里已经被"转手"了一次。

一层降级：等了首轮回答，AI换了个模型又答一轮。两层降级：等了第二轮，AI又换了。第三层降级时，对话已经偏离正常轨道三四轮，用户感知到的不是"AI在处理我的问题"，而是"AI在反复试"。降级深度超过两层后，继续切换模型是在用推理成本充抵应该触发转人工的判断，用户体验已经在前两层降级中丢失。

合力亿捷的通话Agent在Flow状态节点的设计中包含了降级深度的上限约束——不是所有场景都允许无限制降级，也不是所有模型组合都允许串联切换。这套约束的设计目标不是让"所有路径都可以走"，而是让每条路径的终点明确——要么在两轮内回到可接受的回答质量，要么触发转人工。

五、ByondLabs的STT优化启示

多模型调度不只在LLM层。ByondLabs在同一篇调优记录中描述了对STT层的优化：他们在评估后发现telephony专用STT模型对印地语的识别提升不显著，于是切回了通用STT以换取更低延迟。同时关掉了所有STT后处理标记——标点符号、填充词检测、智能格式化、语言检测、脏话过滤、数字转换——每一项只增加个位数毫秒，但六项叠加后累加出一个可感知的延迟增量。ByondLabs的结论直白："让STT做最少的事：音频到文字，快。你的LLM才是理解层。"

这个逻辑也同样适用于TTS层的模型选择——链式架构允许每个环节做独立的模型评估和替换，灵活性是整个管道共享的。多模型调度不只是LLM的事情。