豆包視頻通話背後，火山引擎重構 Agent 時代多模態傳輸底座

豆包推出視頻通話功能後，使用者體驗出現顯著變化——家長可以直接將鏡頭對準孩子的作業題目，讓AI一步步引導解題；在穿搭建議、視障人士語音導航這類場景中，AI不再是「一問一答」的靜態互動，而是能在整個任務過程中持續傾聽、即時回應。這種多模態交互正在成為通用Agent的關鍵基礎技術，它不僅增加了功能豐富度，也大幅提升了使用者與AI建立連結的頻率與深度。火山引擎智能視頻技術負責人裴志偉指出，視頻通話等多模態場景「極大拓寬了技術方案的普適性，帶來更多想像力」，同時也讓豆包獲得大量流量——「幾乎沒有做太多投放，業務規模就翻了10倍，從千萬級DAU變成億級DAU」。

然而，這種多模態體驗並非僅靠模型能力就能達成。當使用者打開攝像頭與麥克風後，真正影響感受的關鍵在於傳輸品質：連線是否夠快、弱網下是否穩定、音畫是否同步、使用者打斷能否被即時響應，以及模型能否在正確時間拿到正確資訊。正因如此，國內的豆包與海外的ChatGPT都在積極建構一套能讓AI與人自然溝通的成熟技術底座。OpenAI在7月8日推出全新的GPT-Live，將連續對話與更深層的搜尋、推理和智能體任務解耦，打造出一個獨立、低延遲、可打斷、可持續的多模態資訊交互層。而在稍早舉辦的2026火山引擎FORCE原動力大會上，火山引擎也介紹了支撐豆包即時多模態交互的「多模態傳輸系統」（MMT）。

雙方想要解決的不只是單純的音視頻性能問題，而是為Agent時代搭建一套能支撐大規模、多場景、低延遲、可打斷、可同步的多模態傳輸底座。傳統的音視頻傳輸技術在面對Agent時代的多模態需求時，已經明顯不夠用。豆包最開始從語音交互切入，選擇了WebSocket作為連接方案——它簡單、標準、支援全雙工與長連接，穿透性也不錯。對當時聚焦語音驗證的豆包來說，先用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協議實現更好的會話控制——判斷不同模態之間的關係：哪一路音頻要優先、哪一幀影片更值得送給模型、哪些內容需要可靠傳輸、哪些可以為了低延遲做取捨，這些都不是單純的網路問題，而是會話控制問題。MoQ信令上會有分層的邏輯單元支援更精細的會話控制。在服務側，網關扮演更關鍵的角色。

使用者傳來一句話，網關可以選擇是否直接送往模型；使用者打開攝像頭，網關需判斷是否需要抽幀、是否需要高清圖、是否要結合模型反饋改變處理策略。火山引擎在這裡引入了MediaKit同源的處理算法，服務於即時傳輸場景。目前這套系統已開始在豆包中落地，近期更新過豆包的用戶已有相當比例使用新的多模態傳輸鏈路，意味著它已進入真實的C端高併發場景，而非僅在內部測試。

火山引擎會繼續將這套在豆包內部跑通的新系統輸出給更多客戶：需要一站式服務的客戶可直接獲得完整的多模態交互Agent；希望保留Agent定製空間的客戶，可獲得前後處理能力；自身有較強音視頻處理能力且高度定製化需求的客戶，則可直接採購多模態傳輸與基礎處理能力。這不是簡單把豆包的視頻通話能力外溢，而是把一套被真實高併發場景驗證過的多模態傳輸能力，拆成即時傳輸網路、傳輸SDK、傳輸網關、處理網關等不同模組，讓不同開發深度的AI應用都能按需接入。

豆包的視頻通話只是前臺入口，背後是火山引擎在超大規模C端流量與自身產品化能力之間快速沉澱的多模態傳輸系統，並透過豆包真實驗證了這套系統能否在真實流量、複雜網路、高頻交互中跑通。長遠來看，多模態傳輸很可能從通信管道變成Agent時代的人機交互技術底座。過去兩年，大模型競爭圍繞參數、推理、上下文、多模態理解能力，行業評價AI能力的座標往往是誰能回答更準確、推理更複雜、理解更長上下文。但當AI從聊天框走向更多真實場景，保證體驗下限就變得同樣重要。沒有穩定、低延遲、低成本的多模態傳輸，再強的模型也很難進入高頻、長時、移動化、硬體化的真實場景。用戶不會關心底層協議，但能感知到模型是否真的「跟上了自己」。

模型決定智能上限，傳輸決定體驗下限，這是AI產品化的硬約束。正因如此，火山引擎與OpenAI都在建構新的多模態傳輸技術底座。OpenAI的GPT-Live可以把任務交給另一個模型，同時自己繼續維持對話，本質上是將「自然交互」與「深度智能」拆成兩個協作層：前者負責低延遲、持續、可打斷；後者負責複雜任務與更強推理。儘管GPT-Live初期尚未把語音與影片或螢幕分享完全結合，但下一步顯然是要將語音、視覺、螢幕與工具呼叫納入同一個即時會話系統。使用者與AI的關係，將從任務式查詢變成更連續的陪伴式交互。

豆包的視頻通話之所以深受喜愛，不是因為簡單「增加了攝像頭」，而是因為多模態傳輸讓AI從工具變成了更接近「在場者」的角色。隨著Agent競爭從模型能力延伸到工程能力，行業需要一套完善的AI原生基礎設施。火山引擎在多模態傳輸上的投入，不只是為豆包補齊一條技術鏈路，而是在為Agent時代進行底層基建。當AI開始即時進入真實世界，誰能長期、穩定、低成本地支撐這種交互，誰就更接近下一代AI應用的基礎設施位置。