一次面向真实场景的交互升级

豆包视频通话功能升级后，AI 不再只是等用户提问再回答，而是在摄像头、麦克风和文本输入同时存在的场景中持续理解环境。官方给出的典型画面是：用户在陌生景点举着手机，豆包能看到路牌、建筑入口等视觉信息，也能听到用户提问，同时过滤旁边路人的闲聊和街边叫卖。

这次升级的核心，是模型层接入原生音视频全双工大模型 SeedRealtime，并由火山引擎多模态传输系统 MMT 提供底层传输支撑。全双工可以简单理解为双方能同时“说”和“听”，不必像传统对讲那样轮流占用通道；放到 AI 视频通话里，就是用户可以边看、边说、边打断，模型也能边接收、边判断、边回应。

从一问一答到双向协作

升级后的体验主要体现在三方面。第一，豆包可同时处理音频、视频和文本三路输入。例如用户指着航班牌询问路线，系统需要结合画面中的指向对象和语音内容判断其真实意图。第二，AI 可以主动开口：当画面中出现关键标识，或任务需要查询、整理信息时，它不必等待下一句指令。第三，对话节奏更接近人与人交流，既要避免用户没说完就抢答，也要避免模型突然停顿造成冷场。

官方评测称，相比传统级联方案，对话节奏违和问题减少约 50%。这里的“级联方案”通常指语音识别、视觉理解、语言模型、语音合成等模块按顺序串接，任何一环延迟或状态不同步，都可能放大到用户侧，表现为抢话、漏听或答非所问。

MMT把传输层从管道变成调度层

过去实时音视频多依赖 RTC 技术。RTC 即实时通信，重点是把音视频低延迟送到对端。但 AI 通话比人与人通话更复杂：传输层不仅要传声音和画面，还要让模型知道会话是否就绪、首帧是否完整、音画是否对齐。

火山引擎 MMT 的变化在于统一多模态会话。客户端底层基于 QUIC，这是一种面向低延迟连接的网络传输协议，可支持连接复用和多路复用；传输层则基于 MoQ 协议进行统一会话控制，将媒体流、信令和模型状态放在同一会话中协同调度。官方称，这使建联耗时从秒级压缩到数百毫秒，用户点开视频通话后更接近“秒接通”。

解决“丢字”和看不清的问题

在传统架构中，音频通道和模型推理通道可能异步建立：用户已经开始说话，但模型会话还没准备好；或者模型已就绪，首帧音频尚未同步。这样就可能出现开头几个字丢失，导致回答偏题。MMT 通过统一链路调度音视频流和模型状态，并在网关层引入 MediaKit 同源处理算法，判断首帧完整性、音画同步和模型就绪状态，只有多模态状态同步后才触发推理。

另一个关键点是按需传输。用户指着屏幕上一行小字提问时，低码率视频可能不足以让模型识别细节。MMT 的服务侧网关可判断是否抽帧、是否需要高清图，以及哪一路音频或哪一帧视频更值得优先送入模型。换言之，传输系统开始理解模型需要什么数据，而不是机械搬运所有数据。

行业点评：模型之外的体验竞争

豆包这次升级说明，实时多模态 AI 的竞争不只取决于模型“聪不聪明”，也取决于端到云之间能否稳定、同步、低延迟地交付数据。模型决定能力上限，传输系统则决定普通用户能感受到多少能力。

随着同传、外语陪练、博物馆讲解等场景继续落地，“边看边听边说”会成为 AI 应用的重要交互形态。但这类体验对网络、会话控制和多模态同步要求更高。未来一段时间，行业关注点很可能从单纯比拼模型参数和效果，扩展到模型、传输、终端协同优化；谁能把复杂系统压缩成自然对话，谁就更接近真正可用的 AI 助手。