对通用型Agent而言，多模态交互正逐渐成为一项决定用户体验上限的关键基础技术。
过去，用户与AI的互动，大多停留在输入文字、上传图片、等待回复的回合制模式。而今天，家长希望直接将镜头对准孩子的习题，让AI一步步讲解；穿搭建议、视障人群视频导航等场景中，用户也期望AI不再是机械的一问一答，而是在完整任务流程中持续倾听、动态对话。
这种演进，不仅拓展了功能的丰富度，更显著提升了用户与AI建立连接的频率和深度。
火山引擎智能视频技术负责人裴志伟指出，视频通话等多模态场景“极大拓宽了技术方案的普适性，带来更多想象空间”，同时也为豆包带来了显著的流量增长：“几乎未做大规模投放，业务规模便从千万级DAU跃升至亿级DAU，翻了10倍。”
不过，多模态体验并非仅由模型能力决定。当用户开启摄像头和麦克风，真正影响体验的反而是传输链路的质量——连接速度是否足够快，弱网环境是否稳定，音画是否同步，用户打断能否被即时响应，以及模型能否在准确的时机获得正确的信息。
正因如此，国内豆包与海外ChatGPT，都在加速构建支撑人与AI自然交流的技术底座。
OpenAI于7月8日推出全新GPT-Live，将连续对话与深层搜索、推理及智能体任务解耦，打造出一个相对独立、低延迟、可打断、可持续的多模态信息交互层。更早的2026火山引擎FORCE原动力大会上，火山引擎也介绍了支撑豆包实时多模态交互的多模态传输系统（MMT）。
归根结底，火山引擎与OpenAI所要解决的不只是音视频性能指标，而是如何为Agent时代构建一套覆盖大规模、多场景、低延迟、可打断、可同步的多模态传输基础架构。
音视频传输技术已捉襟见肘
火山引擎与OpenAI在阐述各自多模态交互技术时，均提及传统音视频传输方案与Agent时代需求之间存在的鸿沟。
就豆包而言，其并未从一开始就主攻复杂的视频通话，而是从相对简单的语音交互起步。WebSocket作为早期选择，简单、标准、支持全双工长连接，且穿透性良好，便于快速验证语音交互的方向有效性。但随着业务推进，WebSocket很快暴露出短板：弱网下体验糟糕，视频丢包、延迟不可控等问题直接影响模型接收信息的质量，甚至导致回答失真或中断。裴志伟介绍，日常使用中，延迟抖动一旦超过1秒，模型收到的信息便会变形，最终输出失准或无效。
针对弱网优化，豆包引入了QUIC方案。与WebSocket相比，QUIC在弱网恢复、多路复用和连接迁移方面更适配移动端场景，使豆包在耳机、车载、机器人、智能眼镜等更复杂环境下仍能保持稳定高效的传输。
当视频通话成为重点能力后，QUIC同样显得力不从心，于是豆包转向WebRTC。WebRTC可实现超低时延，端到端延迟较QUIC优化约10%，且具备完备的视频链路能力，内置音视频编解码、回声消除，并获浏览器原生支持，最终带来直观体验：豆包反应更快、可被自然打断、音画更接近真人对话。
但WebRTC仍非面向AI交互的多模态传输的最优解。火山引擎判断，这类多模态传输系统可能是当前最复杂、规模最大的RTC系统之一，服务体量预计可达传统RTC需求的100至500倍。亿级用户、长时间在线、高频调用的AI场景，持续放大成本和稳定性压力。
此外，人与人通话中，音视频内容按时间线性生成，系统主要任务是稳定转发；而AI交互中，模型可能在短时间内集中产生大量内容，用户也可能随时打断、追问或切换画面。多模态传输链路必须实现“实时中的异步”，提前缓存、减少加载时间。
更核心的差异在于传输目标的变化：人与Agent交互追求的是让模型在正确时机拿到最有价值的信息。当用户询问屏幕上一行小字时，继续传输低码率视频未必最优，更合理的做法是触发高清图、抽帧或局部增强，让模型先看清问题本身。
WebSocket、QUIC、WebRTC虽在不同阶段解决了豆包的现实问题，但单独任一方案都难以承载未来规模更大、场景更复杂的实时多模态交互需求。
重构实时多模态传输链路
豆包需要一条专为AI交互设计的多模态传输链路。该链路须将建联时间从秒级压缩至数百毫秒；端到端延迟对齐RTC水平，不因系统改造牺牲体验；弱网表现更加稳定，适应移动、出境、地铁、电梯等复杂环境；同时支撑亿级并发，并将长期成本控制在合理范围。
为此，火山引擎选择基于C/S架构搭建系统，以支持复杂网络传输策略、传控策略、播控策略，构建面向多模态传输的多模态会话系统，并进一步扩展交互能力。
具体实践中，火山引擎并未在客户端全盘替换已有音视频能力，而是保留成熟的采集、编码、回声消除等模块，同时将底层网络库替换为QUIC库，增强弱网恢复、多路复用和连接迁移能力，使用户侧的音画数据能更快、更稳地传送出去。
传输层则基于MoQ协议实现更精细的会话控制。面向AI的多模态传输还需判别不同模态间的优先级：哪路音频优先，哪帧视频更值得送模型，哪些内容需可靠传输，哪些可因低延迟而舍弃——这些都不再纯属网络问题，而是会话控制问题。MoQ信令上配置分层逻辑单元，以支撑更细粒度的控制。
服务侧，网关开始发挥关键作用。用户的一句话，网关可判断是否直接送往模型；用户打开摄像头，网关决定是否抽帧、是否需要高清图、是否结合模型反馈动态调整处理策略。在这一环节，火山引擎引入MediaKit同源处理算法，使其服务于实时传输场景。
目前，这套系统已在豆包中逐步落地。近期更新豆包的用户中，相当比例已开始使用新的多模态传输链路，意味着该链路已进入真实C端高并发场景，而不仅停留在内部测试阶段。
火山引擎还将继续把豆包内跑通的新系统输出给更广泛的客户：需要一站式服务的客户可直接获取多模态交互Agent；希望保留定制空间的客户可获得Agent前后处理能力；具备较强音视频处理能力和高度定制化需求的客户，则可直接采购多模态传输及基础处理能力。
火山引擎并非简单外溢豆包的视频通话能力，而是将一套经过真实高并发场景验证的多模态传输能力，拆分为实时传输网络、传输SDK、传输网关、处理网关等模块。对内，支撑豆包多模态体验；对外，让不同开发深度的AI应用均可按需接入实时多模态能力。
多模态传输成为Agent时代新底座
这意味着，豆包的视频通话仅仅是前台入口。火山引擎在豆包超大规模C端流量与自身产品化能力之间，迅速沉淀出一套自有多模态传输系统，并通过豆包在真实流量、复杂网络和高频交互中验证其可行性。
这套系统的意义不仅限于体验提升。长远来看，多模态传输很可能从通信管道演进为Agent时代人机交互的技术基座。
过去两年，大模型竞争多聚焦于参数、推理、上下文、多模态理解等维度，行业对AI能力的评判往往落在“谁能回答更准确”“谁能推理更复杂”“谁能理解更长上下文”。然而，当AI从聊天框走向更多真实场景，保障体验下限便同等重要。
没有稳定、低延迟、低成本的多模态传输能力，再强大的模型也难以深入高频、长时、移动化、硬件化的现实环境。用户不会关心底层协议，但能敏锐感知模型是否真正“跟上了自己”。如果一个AI能理解世界，却总慢半拍进入现场，便难以成为高频入口；若一次连续会话成本过高，也无法成为随时可用的基础能力。
模型决定智能上限，传输决定体验下限——这是AI产品化的硬约束。正因如此，火山引擎、OpenAI等公司都在积极构建新的多模态传输技术底座。
OpenAI最新推出的GPT-Live，可将任务交由另一个模型处理，同时自身维持连续对话。这种架构的本质，是将“自然交互”与“深度智能”拆分为两个协作层：前者负责低延迟、持续、可打断；后者负责复杂任务与强推理。
尽管GPT-Live发布初期尚未将语音与视频或屏幕共享完全结合，但下一步显然会将语音、视觉、屏幕及工具调用纳入同一实时会话体系。用户与AI的关系，也将从任务式查询，转向更连续的陪伴式交互。
这种连接频率与深度的提升，是豆包和ChatGPT共同追逐的方向。豆包视频通话之所以广受欢迎，不是因为简单“增加摄像头”，而是多模态传输让AI从工具蜕变为更接近“在场者”的角色。
随着Agent竞争从模型能力延伸至工程能力，行业将越发需要一套完善的AI原生基础设施。从这个角度看，火山引擎在多模态传输上的持续投入，不仅是为豆包补齐一条技术链路，更是在为Agent时代铺设底层基建。
当AI开始实时介入真实世界，谁能长期、稳定、低成本地支撑这种交互，谁就更接近下一代AI应用的基础设施位置。
评论(0)