新智元報道

【新智元導讀】只會聊天的Agent要下崗了！AI盯直播自己解說世界杯，懂戰(zhàn)術還會切粵語，背后竟藏著一個流式Agent引擎。

2026世界杯，正打得火熱！

全球幾億人盯著同一顆滾動的足球，等一個進球，等一句吶喊。

41歲的C羅第六次踏上世界杯賽場，38歲的梅西帶著衛(wèi)冕冠軍阿根廷繼續(xù)追夢，哈蘭德第一次站上世界杯就殺紅了眼，姆巴佩則劍指世界杯歷史射手王。

綠茵場上每個瞬間都在發(fā)生故事，每個進球都讓世界屏住呼吸。

但你有沒有想過，要是讓一個AI來實時解說這場比賽，它得同時干成幾件事？

它得看懂此刻畫面里「誰在頭球」，得記住「幾十分鐘前誰踢丟了一腳」，還得調出「上一場比賽、甚至這個球星近幾年的數(shù)據(jù)」。

把這三層信息：現(xiàn)在、剛才、過去，對齊到同一根時間軸上，再用一種你喜歡的方言、喜歡的風格講出來。

這種極限背后，到底是一套什么樣的系統(tǒng)在運轉？

把直播現(xiàn)場，煉成實時智能

答案，就在今天召開的Flink Forward Asia (FFA) 2026大會上。

阿里云正式宣布，Apache Flink 3.0全面進入Agentic Streaming For AI時代，并推出全模態(tài)數(shù)據(jù)流處理能力。

這是業(yè)界第一次，把視頻、音頻、圖像、文本這四類數(shù)據(jù)，統(tǒng)一放進同一條流式pipeline里調度，讓AI能夠實時感知、實時理解、實時回應。

可以讓AI實時解說世界杯的demo，正是這套能力的注腳。

一場直播畫面，是怎么在Flink這條流水線上，一步步變成實時解說的。

第一步，實時抓幀、實時看懂。

Flink實時抓取直播畫面里正在發(fā)生的信息，做實時多模態(tài)數(shù)據(jù)處理，理解此刻屏幕上發(fā)生了什么。

誰接了球？誰完成了傳球？這腳打沒打進？

這一步既可以調用大模型API，也可以跑GPU本地部署的全模態(tài)模型，把「看畫面」這件吃算力的活兒，壓在GPU上高效完成。

第二步，喂給大模型、生成解說詞。

理解完的信息被實時喂進大模型，由它推理出一句完整的解說——

誰、在什么時刻、做了什么、造成了什么結果。

解說詞一旦成型，輸出的音色還能隨手切換。

嫌普通話解說不帶勁？它下一秒就能換成一段地道的粵語；亦或是，換上「猴哥」的音色，實時評價C羅等球員的表現(xiàn)。

第三步，沉淀成上下文、隨時回看。

所有這些信息，都會在Flink里沉淀為實時上下文，彼此之間做交叉分析。

于是「半場總結」、「精彩鏡頭集錦」這類需要跨時間回溯的能力，第一次有了水到渠成的實現(xiàn)路徑——因為該記住的，系統(tǒng)一直都在記。

視頻里，那句「兩回合都是大場面先生」的跨場次分析，則同時調動了兩層記憶。

大模型把兩層記憶一融合，才說得出那句讓人起雞皮疙瘩的話。

如果你在現(xiàn)場看，唯一能察覺到它「在工作」的痕跡，是大概25秒的延遲。不是說流式，那這個延時又是哪里來的？

其中的15秒花在「攢幀」上，視頻流得一秒抽一幀，把關鍵幀攢夠一段才能給模型。

剩下10秒是大模型自己琢磨：VL模型先看懂視頻，LLM再寫解說詞，接著做風格轉換（比如切粵語），中間還卡著一道合規(guī)檢查。

而當前大部分的VL模型的處理延遲都相對較大，這才導致了整條鏈路上的部分延時，如果是流音頻模型這部分的延時就會少很多。

好幾個小Agent串成一條鏈，各干各的，一個干完遞給下一個。等鏈子跑順了，開頭那十幾秒的延遲就沒了。

回頭再看這個AI。它在看球，在解說，在回憶，在切粵語——全程沒有一個人戳它一下、問它一句。事件流到了，它就動。

這跟過去三年我們以為的「Agent」，已經(jīng)不是一個東西了。

這跟會聊天的AI，不是一個東西

之前，ChatGPT、Gemini等聊天AI，底層都是一套：你問一句，它答一句。

最近上線的Claude Tag，則往「更主動」走了一大步，把AI嵌進人的工作流。可它終究還是得有人 @ 那么一下。

而Flink要做的，是把這層「等人開口」的殼整個掀掉，轉向了「流式Agent」新路。

Flink這次給流式Agent下的定義很清楚，叫Event-Driven Agent（事件驅動型Agent）。

它和對話式Agent的根本差別，可以拆成四點：事件觸發(fā)對人發(fā)問響應、7×24永遠在線對一問一答即停、自主決策對被動響應、記憶自維護對靠人喂上下文。

如果問哪一種方式，更接近「AI真正替代人干活」的終局，答案應該是后者。

真正撐起一個產(chǎn)業(yè)的，從來不是會聊天的助手，是會自己上班的員工。

干這件事的主角，是Apache Flink。如果你不在技術圈，可能沒聽過這個名字。但全球流計算這一塊，它就是事實標準。

Netflix的實時推薦、Uber的行程調度、阿里雙11零點的洪峰——背后跑的都是Flink。國內你叫得上名字的互聯(lián)網(wǎng)大廠，字節(jié)、美團、快手，它的實時數(shù)據(jù)管道里大概率躺著同一個引擎。

還有一層背景。這么一個統(tǒng)治全球的Apache頂級項目，背后最核心的貢獻者和推動者，是中國團隊——阿里云實時計算Flink團隊。

Apache基金會里，由中國團隊主導、還做到了全球第一梯隊的基礎軟件項目，F(xiàn)link是鳳毛麟角的一個。每年一度的Flink Forward Asia大會，是亞太流計算圈的旗艦盛會。

就是這樣一個已經(jīng)在全球跑了十幾年、被驗證過無數(shù)次的工業(yè)級引擎，這次把自己徹底重做了一遍。從「算報表的實時計算框架」，跳到了「養(yǎng)Agent的流式智能體基座」。

卡了三年，這次一次解開

流式Agent這個想法，其實并不新。

「讓AI持續(xù)運轉、持續(xù)感知、自主決策」——這幾乎是所有人最早對Agent的想象。問題從來不是「想不想做」，而是「做不出來」。它卡在一個非常具體的、又非常底層的地方：數(shù)據(jù)。

在這套AI-Driven的新邏輯面前，現(xiàn)有主流方案暴露出三道硬傷。

第一，全模態(tài)數(shù)據(jù)散落一地。

Agent要感知的世界，早就不是表格和數(shù)字，是文本、圖像、音頻、視頻的混合流。可它們躺在完全不同的管道里，對不齊時間——AI拿到手的，是一堆「拼圖碎片」。

第二，批處理撐不住「永遠在線」。

一次性打包7天數(shù)據(jù)喂模型，這套離線訓練的老辦法沒問題。可面對7×24源源不斷的事件流，「攢一批、跑一批」立刻力不從心——等數(shù)據(jù)攢夠、模型跑完，該發(fā)生的早發(fā)生了。

第三，關鍵信號被淹沒。

數(shù)據(jù)攢成一大坨一起喂，AI的注意力就被稀釋了。一次異常交易、一個突然的進球、一臺機器的異常心跳，淹沒在海量數(shù)據(jù)里。系統(tǒng)用得越久，反應越慢，越笨重。

結果就是：大模型再強，也白搭。

Flink 3.0徹底告別「打補丁」式的妥協(xié)，從底層完成重構。

對應第一道，全模態(tài)數(shù)據(jù)對不齊/Flink 3.0給的是全模態(tài)Agentic Streaming Engine。

它把視頻、音頻、圖像、文本第一次統(tǒng)一進了同一條流式pipeline。不是各自處理后拼起來，是從一開始就在同一根時間軸上調度。

事件時間、狀態(tài)管理、精確一次這些流計算的老本行，和多模態(tài)理解、大模型推理這些新需求，對齊到同一根軸上。

AI拿到的不再是拼圖碎片，是完整、連貫、對齊的世界。CPU和GPU混合調度，把整條流水線的資源打滿。

對應第二道，批處理撐不住永遠在線。這本來就是Flink的主場。

Flink是純流式引擎，從第一天起處理的就是「無限流」，不是攢成批的存量數(shù)據(jù)。同樣是pipeline架構，Spark、Ray處理的是躺在對象存儲里的批量數(shù)據(jù)，而Flink處理的是攝像頭視頻流、直播流、消息隊列里永不停止的流。

關鍵就在這：在線計算、實時把大模型能力集成進去，才是能釋放更高業(yè)務價值的所在。離線批量也能用AI，但只有實時在線，才能讓AI真正嵌進生產(chǎn)流程。

對應第三個道，關鍵信號被淹沒。Flink用Streaming Agent-OS來解。

它不只讓Agent看到數(shù)據(jù)，還給Agent配了一套「操作系統(tǒng)」Flink孵化了Flink Agens項目，包含Agent DSL、Agentic算子，外加Flink原生的流處理、狀態(tài)管理、故障容錯。

Agent不用每次都重新理解一遍世界。它的短期記憶和長期記憶由這套系統(tǒng)維護。

7x24h，永遠在線的Agent

Agent要永遠在線，它背后的數(shù)據(jù)底座也得永遠在線。

這就是FFA2026上同時發(fā)布的Agentic Lake。

Apache Paimon 2.0負責全模態(tài)數(shù)據(jù)的沉淀和統(tǒng)一管理，Apache Fluss 1.0負責實時數(shù)據(jù)的流轉和Agent上下文供給，兩者雙向自動互通，構成湖流一體。

至此，一個能7×24自轉的流式Agent，第一次有了完整的工程化路徑。

全模態(tài)引擎讓它「看得清」，Streaming Agent-OS讓它「記得住、想得通」，Agentic Lake讓它「餓不著」。

要理解這次升級的分量，得先看清楚一件事：在AI時代，數(shù)據(jù)處理這件事本身的命題，已經(jīng)換了。

過去十幾年，數(shù)據(jù)基礎設施服務的是BI——做報表、跑分析、算指標。它處理的對象，是訂單、點擊、日志這類結構化數(shù)據(jù)，整整齊齊躺在數(shù)據(jù)庫里。

驅動這一切的邏輯，是BI-Driven：人來提問，系統(tǒng)給出圖表。

但今天，喂給AI的「燃料」變了。

在AI Agent時代，進來的數(shù)據(jù)變成了圖像、語音、PDF文檔、攝像頭信號、車聯(lián)網(wǎng)等全模態(tài)數(shù)據(jù)。

這意味著數(shù)據(jù)計算的驅動力，已經(jīng)從BI-Driven轉向了AI-Driven。

若數(shù)據(jù)底座如果還停留在「為報表服務」的舊范式里，AI就只能困在Demo階段。

這恰恰是Flink 3.0升級之后，所重塑的底層邏輯。

它會在哪里先上崗

流式Agent不是空中樓閣，已經(jīng)有具體場景在跑。

最先跑出生產(chǎn)力的，是智能運維。

企業(yè)的IT系統(tǒng)里，機器心跳、底層日志、應用信息、業(yè)務事件每秒鐘都在海量涌出，天然就是事件密集的戰(zhàn)場。

過去靠運維專家盯，現(xiàn)在嵌入AI能力之后，系統(tǒng)可以自己看matrix、看log，判斷要不要做負載均衡、換機器、提前預警。

直播監(jiān)控是另一個天然場景。海量直播流涌進來，系統(tǒng)不僅能做內容監(jiān)控，甚至能給導播實時提供智能化建議。

還有廣告實時定價。用戶點擊、商品瀏覽、競價波動，每一個事件都在實時產(chǎn)生。

把它們實時捕獲、分類，沉淀成短期與長期上下文，模型就能實時判斷廣告要不要重新定價、怎么投放。

這里還藏著一個被很多人誤解的點：AI來了，規(guī)則就該被推倒？

模型驅動和規(guī)則驅動，是融合模式，不是完全替換把歷史推倒。

數(shù)據(jù)量太大，全交給大模型不現(xiàn)實；更聰明的做法，是用規(guī)則做預處理與初篩，再讓AI對剩下的部分做加權式的增強判斷。

甚至，規(guī)則本身都可以由大模型動態(tài)生成、持續(xù)迭代。

這也是流式Agent能比對話式Agent更快走進生產(chǎn)場景的原因之一。它不要求你推翻現(xiàn)有的規(guī)則系統(tǒng)，它要求的是把你現(xiàn)有的事件流，接進一條能讓AI實時介入的管道。

以前我們以為，Agent就是ChatGPT那樣會聊天的東西。Flink 3.0提示的是另一種可能——一個不靠人發(fā)問、靠自己運轉起來的AI。

它不是更強的工具。它是第一次，自己活了起來。