<mark id="oztn4"></mark>
0
| 本文作者： Nemo | 2026-07-15 12:32 |
對通用 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應用的基礎設施位置。
