为什么多模式代理需要与纯语音不同的架构

语音代理具有线性管道：音频输入 → ASR → LLM → TTS → 音频输出。多模式代理运行并行流：音频输入+视频帧→ASR+视觉模型→统一的LLM推理→TTS+可选的视觉输出。差异不是相加的——而是架构上的。系统必须随时决定优先考虑哪种模式、如何融合来自不同感官的输入以及如何跨流分配计算。

模态融合，而非模态切换

一个简单的多模式系统在模式之间切换：要么听，要么看。适当的多模式系统会融合输入：客服人员会听到客户说“这个坏了”，同时看到他们指向屏幕上的特定项目。 “这个”这个词只能通过视觉上下文来解析。这种跨模式解决方案需要一个同时获取两个输入（而不是顺序）的推理模型。

无缝模态转换

代理以语音呼叫启动。客户需要帮助浏览其帐户，因此客服人员提供屏幕共享。现在是语音+屏幕共享。客户在摄像机上展示文档——现在是语音+视觉。从用户的角度和代理的角度来看，这些转换应该是无缝的。对话状态、上下文和角色会在无需重新启动的情况下进行模态更改。这需要统一的会话运行时，而不是将单独的语音和视频服务缝合在一起。