豆包视频通话背后，火山引擎重构 Agent 时代多模态传输底座

发布时间：2026-07-17 10:32:16 来源：安智兰德资讯网 作者：探索

对于通用 Agent 而言，豆包代多底座多模态交互已演变为提升用户体验的视频关键基石。

传统的通话人机交互模式局限于“文字输入+图片上传+等待回复”，而当下的背后用户需求已发生质变：家长希望直接拍摄孩子作业，由 AI 进行分步讲解；在穿搭建议、火山视障人士导航等场景中，引擎用户期待 AI 具备持续倾听与对话的重构能力，而非简单的模态问答机器。

这种转变不仅丰富了功能维度，传输更显著提升了用户与 AI 建立连接的豆包代多底座频率与深度。

火山引擎智能视频技术负责人裴志伟指出，视频视频通话等多模态场景“极大地拓宽了技术方案的通话普适性，带来了更多的背后想象力”。这一技术突破也直接推动了豆包业务的火山爆发式增长——在极少投放的情况下，其业务规模翻了 10 倍，引擎日活跃用户数（DAU）从千万级跃升至亿级。

多模态体验的优劣并非仅由模型能力决定。当用户开启摄像头和麦克风后，传输质量成为影响体验的核心变量：连接速度、弱网稳定性、音画同步率、打断响应及时性，以及模型获取信息的准确性，共同构成了用户体验的底线。

因此，国内豆包与海外 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同源处理算法，服务于实时传输场景。

目前，该系统已在豆包落地。近期更新豆包的用户中，相当一部分已开始使用新的多模态传输链路。这意味着该面向 AI 交互的多模态传输链路已进入真实的 C 端高并发场景，而非仅停留在内部测试阶段。

火山引擎计划将这套经豆包验证的新系统输出给更多客户：
* 需要一站式服务的客户，可直接获得多模态交互 Agent；
* 希望保留 Agent 定制空间的客户，可获得 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 应用的基础设施位置。

相关文章