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

对通用 Agent 来说，多模态交互正在成为一项能大幅提升用户体验的关键基础技术。

过去，用户和 AI 的交互更多是输入文字、上传图片，然后等待回答。现在，家长希望可以直接把镜头对准孩子正在做的题目，让 AI 一步步讲解；在穿搭建议、视障人群视频导航等场景里，用户也希望 AI 不再是一问一答，而是在整个任务过程中持续倾听、对话。

这种变化提高的不只是功能丰富度，还有用户与 AI 建立连接的频率和深度。

火山引擎智能视频技术负责人裴志伟在分享中提到，视频通话等多模态场景“极大地拓宽了技术方案的普适性，带来了更多的想象力”，同时也帮助豆包获得了更多流量，“几乎是在没有做太多投放的情况下，业务规模翻了10倍，从千万级DAU变成了亿级DAU”。

这种多模态体验不是模型能力单独决定的。用户打开摄像头和麦克风后，真正影响体验的还有传输质量——连接是否足够快，弱网下是否稳定，音画是否同步，用户打断能否被及时响应，以及模型能否在正确时间拿到正确的信息。

也因此，国内的豆包和海外的 ChatGPT，都在构建让 AI 与人自然沟通的更成熟技术底座。

OpenAI 在7月8日推出了新的 GPT-Live，将连续对话与更深入的搜索、推理和智能体任务解耦，打造了一个相对独立的、低延迟、可打断、可持续的多模态信息交互层。更早举办的2026火山引擎 FORCE 原动力大会上，火山引擎也介绍了背后支撑豆包进行实时多模态交互的多模态传输系统（MMT）。

最终，火山引擎和 OpenAI 要解决的，都不是单纯的音视频性能问题，而是如何为 Agent 时代搭建一套支撑大规模、多场景、低延迟、可打断、可同步的多模态传输系统。

音视频传输技术不够用了

火山引擎和 OpenAI 在介绍自己的多模态交互技术时，都提到了传统音视频传输技术与 Agent 时代的多模态交互需求存在落差。

具体来看，豆包不是一开始就选择攻关复杂的视频通话问题，而是从相对简单的语音交互开始进行探索。

WebSocket 是最先被选择的技术方案。它简单、标准、支持全双工和长连接，也有不错的穿透性。对于当时聚焦语音交互体验的豆包来说，先用这个技术把用户和模型连接起来，验证方向的有效性，比直接搭建一套复杂音视频系统更重要。

但 WebSocket 很快就不够用了。WebSocket 的弱网体验差，会出现视频丢包、延迟不可控等问题，直接影响了模型的反应和回答效果。裴志伟介绍，在日常应用中，延迟抖动超过1秒，模型接收到的信息就会变形，造成回答失真或直接不回答。

为了解决弱网优化问题，豆包引入了 QUIC 方案。相比 WebSocket ，QUIC 在弱网恢复、多路复用和连接迁移上更适合移动端场景。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应用的基础设施位置。

对通用 Agent 来说，多模态交互正在成为一项能大幅提升用户体验的关键基础技术。

过去，用户和 AI 的交互更多是输入文字、上传图片，然后等待回答。现在，家长希望可以直接把镜头对准孩子正在做的题目，让 AI 一步步讲解；在穿搭建议、视障人群视频导航等场景里，用户也希望 AI 不再是一问一答，而是在整个任务过程中持续倾听、对话。

这种变化提高的不只是功能丰富度，还有用户与 AI 建立连接的频率和深度。

火山引擎智能视频技术负责人裴志伟在分享中提到，视频通话等多模态场景“极大地拓宽了技术方案的普适性，带来了更多的想象力”，同时也帮助豆包获得了更多流量，“几乎是在没有做太多投放的情况下，业务规模翻了10倍，从千万级DAU变成了亿级DAU”。

这种多模态体验不是模型能力单独决定的。用户打开摄像头和麦克风后，真正影响体验的还有传输质量——连接是否足够快，弱网下是否稳定，音画是否同步，用户打断能否被及时响应，以及模型能否在正确时间拿到正确的信息。

也因此，国内的豆包和海外的 ChatGPT，都在构建让 AI 与人自然沟通的更成熟技术底座。

OpenAI 在7月8日推出了新的 GPT-Live，将连续对话与更深入的搜索、推理和智能体任务解耦，打造了一个相对独立的、低延迟、可打断、可持续的多模态信息交互层。更早举办的2026火山引擎 FORCE 原动力大会上，火山引擎也介绍了背后支撑豆包进行实时多模态交互的多模态传输系统（MMT）。

最终，火山引擎和 OpenAI 要解决的，都不是单纯的音视频性能问题，而是如何为 Agent 时代搭建一套支撑大规模、多场景、低延迟、可打断、可同步的多模态传输系统。

音视频传输技术不够用了

火山引擎和 OpenAI 在介绍自己的多模态交互技术时，都提到了传统音视频传输技术与 Agent 时代的多模态交互需求存在落差。

具体来看，豆包不是一开始就选择攻关复杂的视频通话问题，而是从相对简单的语音交互开始进行探索。

WebSocket 是最先被选择的技术方案。它简单、标准、支持全双工和长连接，也有不错的穿透性。对于当时聚焦语音交互体验的豆包来说，先用这个技术把用户和模型连接起来，验证方向的有效性，比直接搭建一套复杂音视频系统更重要。

但 WebSocket 很快就不够用了。WebSocket 的弱网体验差，会出现视频丢包、延迟不可控等问题，直接影响了模型的反应和回答效果。裴志伟介绍，在日常应用中，延迟抖动超过1秒，模型接收到的信息就会变形，造成回答失真或直接不回答。

为了解决弱网优化问题，豆包引入了 QUIC 方案。相比 WebSocket ，QUIC 在弱网恢复、多路复用和连接迁移上更适合移动端场景。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应用的基础设施位置。