當AI Agent遇上消息“煙囪”：要么融合，要么掉隊！

想象這樣一個場景：
你的IoT設備用MQTT說話，你的微服務用Kafka聽令，你的任務調度依賴RabbitMQ。它們各司其職，仿佛一個三權分立的數字王國。

但問題是，一旦數據需要跨越這些系統流動，噩夢就開始了：
設備上報的數據要進入分析管道，業務告警要觸達千萬設備，AI Agent 還要同時感知和決策，以至于這些“語言不通”的系統之間，只能靠一層層脆弱的橋接程序來勉強溝通。

于是，工程團隊的時間不再花在業務創新上，而是在為這些“翻譯官”的故障、延遲和運維問題疲于奔命。

可以斷言，這不僅是技術架構的煙囪化，更是企業效率與成本的黑洞。
那么，當大模型和AI Agent正在涌入這個復雜體系時，一個問題變得愈發迫切：

下一代消息基礎設施，究竟應該是什么樣子？

而這，正是 EMQ 映云科技即將給出的答案。（文末有驚喜哦）

消息系統煙囪化

當我們回顧大多數企業的消息基礎設施演進歷程，大概率會看到一個熟悉的模式：

• 需要接入 IoT 設備，增加了 MQTT Broker——因為 MQTT 是 IoT 領域的事實標準，輕量、省電、支持海量長連接。

• 需要構建事件流與日志管道，增加了 Kafka——因為 Kafka 的分區模型和持久化能力是大規模流處理的最佳選擇。

• 需要做業務異步與任務分發，增加了 RabbitMQ——因為 AMQP 協議的靈活路由和消息確認機制天然適合工作隊列場景。

這些選擇在做出的時候都是合理的。不同場景、不同時期、不同團隊，基于各自的需求做出了各自最優的技術選型。

問題在于：隨著業務規模增長和系統復雜度上升，這些「各自最優」的選擇疊加在一起，逐漸演變成了一座座技術煙囪——各團隊自建、各自運維、各自監控、各自一套權限體系。

煙囪化帶來的四重痛點

當消息系統煙囪化成為既成事實，一系列深層問題開始浮現。

數據孤島，跨系統互通困難

不同消息系統之間難以互通，跨系統的數據打通往往依賴復雜的配置和脆弱的同步管道。

最典型的場景：IoT 設備通過 MQTT 上報遙測數據，數據分析團隊需要用 Kafka 消費這些數據做分析處理。中間怎么辦？寫一個橋接程序，從 MQTT Broker 訂閱消息，轉發到 Kafka Topic。反過來，如果 Kafka 側產生了告警需要推送到設備端，又得再建一條反向鏈路。

每一條橋接鏈路都是一個需要開發、測試、部署、監控、維護的程序。它們不創造業務價值，卻往往是很多問題之源，消耗著工程團隊大量的時間和精力。

成本飆升

多套消息系統意味著多套集群、多套存儲、多倍跨可用區流量。

每套系統都需要獨立做高可用部署，都需要獨立的容量預留。尤其是 Kafka 這樣基于分區副本的系統，在多可用區部署場景下，跨 AZ 的數據復制流量本身就是一筆可觀的開支。再加上為應對流量尖峰預留的冗余容量，實際的資源利用率往往遠低于理想水平。

三套系統的成本，絕不只是一套系統的三倍——因為每增加一套系統，還會帶來額外的網絡互聯、數據同步和運維人力成本。

交付速度變慢

當一個新業務需要使用消息能力時，它面臨的不僅僅是「調一個 API」這么簡單。

它需要先完成技術選型（用哪套消息系統？），然后打通網絡、申請權限、配置監控告警，最后才能開始寫業務代碼。如果涉及跨系統數據消費，還要加上橋接程序的開發與聯調時間。

「發送和接收消息」這件本應簡單的事情，被基礎設施的復雜度嚴重拖慢。

可靠性風險增大

系統越多，故障域越多。鏈路越長，排障越難。

橋接程序和同步任務本身就是脆弱的環節——它們通常不像核心消息系統那樣有經過詳盡測試的高可用保證，卻承載著關鍵的數據流轉。一旦橋接程序出現延遲或故障，上下游系統都會受到影響，而排查問題時要在多套系統之間來回切換，定位根因的成本極高。

行業趨勢：從「專用系統」到「融合平臺」

消息系統正在經歷的變化，并不是孤例。回顧其它基礎設施領域的演進，我們會發現一個共同的規律：從專用到融合統一，是基礎設施成熟化的必然方向。

• 數據庫領域：從早期的 OLTP 和 OLAP 嚴格分離，到 HTAP（混合事務與分析處理）數據庫的興起，一套系統同時承載事務處理和分析查詢已經成為可能。

• 可觀測性領域：從日志系統（ELK）、指標系統（Prometheus）、鏈路追蹤（Jaeger）各自獨立，到統一可觀測性平臺將三者整合，一套平臺覆蓋所有可觀測性需求正在成為主流。

• AI 領域：早期的文本、圖像、語音模型各自獨立發展，而如今前沿的基礎模型已經走向多模態融合，一個模型同時具備文本、圖像、視頻、音頻的理解與生成能力。

消息系統也在經歷同樣的演進：從 MQTT、Kafka、RabbitMQ 等多種專用系統共存，走向一個融合平臺統一承載多種消息范式。

融合消息平臺應該長什么樣？

如果我們從第一性原理出發，重新設計一個面向當下和未來的消息平臺，它應該具備哪些關鍵特質？

它不僅要解決已有的 IoT、微服務、事件流等需求，還要能夠自然地接納 AI Agent 這類新型參與者。AI Agent 需要實時訂閱設備和業務數據來感知環境、做出決策，也需要將指令和結果投遞到設備和下游系統。如果為此再引入一套新的消息系統，只會讓煙囪化問題雪上加霜。這進一步要求消息平臺具備統一的多模型、多協議能力。

多模消息引擎：一套系統，多種范式

統一平臺的核心前提是在一個系統內同時支持多種消息范式，例如：

• Pub/Sub：多訂閱者廣播，實時分發，適合實時通知、事件廣播等場景。

• Stream：事件流與日志管道，支持持久化存儲與回放消費，適合數據管道、審計日志、事件溯源。

• Queue：競爭消費，支持 ACK、重試與死信隊列，適合任務分發、削峰填谷。

更重要的是，平臺的消息引擎應該是可擴展的——隨著業務場景的演進和 AI 等新需求的出現，能夠靈活引入新的消息范式，而不是固定在幾種模型上。

要實現這種多模型與可擴展性，協議與消息模型必須解耦。用戶可以用自己熟悉的協議接入（無論是 MQTT、Kafka 還是 AMQP），平臺內部按業務語義選擇最合適的消息模型。同一套治理能力——權限、配額、監控、審計——覆蓋所有模式。

原生跨模型/協議互通

在當前的多系統架構下，要讓 MQTT 的數據流入 Kafka，或者讓 Kafka 的事件推送到 MQTT 設備，往往需要部署專門的橋接程序或同步管道，配置復雜、鏈路脆弱。

統一消息平臺應該從根本上消除這種割裂：不同協議接入的消息，天然就能互通。MQTT 設備發布的數據，Kafka Consumer 可以直接消費；Kafka 寫入的告警，MQTT 訂閱者可以實時接收；AI Agent 可以直接訂閱設備數據流進行實時分析，并將決策結果推送到業務系統——無需橋接程序，無需同步任務，無需額外配置。

云原生彈性架構

傳統消息系統大多采用有狀態分區架構，擴容或節點故障恢復時往往需要經歷漫長的分區再平衡（Rebalance），運維復雜度高，故障恢復不可預測。

面向云原生時代的統一消息平臺，計算層與存儲層應該徹底分離、獨立擴縮容。計算節點應該是無狀態的，可以隨時增減和替換，做到秒級彈性伸縮和快速自愈，不再受限于分區遷移和數據再平衡。

基于對象存儲的低成本持久化

傳統消息系統通常依賴本地磁盤或塊存儲做消息持久化，容量需要提前規劃，單價較高，長期保留和歷史回放的成本壓力尤為突出。

隨著對象存儲技術的成熟和成本的持續下降，消息持久化應該轉向對象存儲。對象存儲容量按需擴展、單價遠低于塊存儲，天然適合消息數據的長期保留與歷史回放，能夠大幅降低存儲成本。

原生多租戶

企業級消息平臺通常需要服務多個團隊和業務線。多租戶能力應該是平臺的內建特性，而非事后附加——每個租戶擁有獨立的資源空間、訪問控制和配額管理。平臺團隊統一治理，業務團隊按需自助使用，既保證安全隔離，又降低使用門檻。

隨著 AI Agent 大規模涌現，未來消息系統的使用者將不僅僅是當前的人和應用，還有大量自主運行的 Agent，這讓多租戶隔離與治理能力變得尤為重要。

融合之后，能帶來什么？

當消息基礎設施從多套技術煙囪整合為一個統一平臺，企業將在四個維度獲得顯著收益。

• 更低的 TCO：降本來自三個方面的協同——彈性架構減少容量預留（架構降本）；低成本存儲降低持久化開支（存儲降本）；一套平臺替代多套集群，統一治理（運維降本）。

• 更簡單的架構：一套平臺覆蓋 Pub/Sub、Queue、Stream 等多種消息需求。團隊用熟悉的協議接入，跨協議互通無需膠水代碼和橋接程序。新業務對接消息能力的路徑從「選型 - 打通 - 運維」縮短為「接入即用」。

• 更強的彈性與可靠性：云原生架構帶來秒級擴縮容能力，節點故障快速自愈，故障恢復路徑更短、更可預測。

• 打破數據孤島：IoT 數據可以直接進入事件流處理管道，不再需要中間的搬運環節。業務事件可以被分析系統、告警系統、審計系統直接訂閱消費。跨系統集成從「搬運數據」變為「直接訂閱」。

消息基礎設施的下一個十年

隨著 IoT、微服務、實時數據處理等場景的爆發，以及 AI Agent 作為新一類消息參與者的快速崛起，企業對消息系統的依賴越來越深，場景越來越多樣。而在這個過程中，我們也積累了大量的技術債——多套系統并存、數據孤島林立、運維成本居高不下。

好消息是，云原生架構的成熟、存儲技術的演進、以及行業對平臺化治理的共識，讓統一消息平臺從愿景變為現實。消息基礎設施正在迎來一次范式躍遷：從「多套工具各司其職」走向「一個平臺統一承載」。

這不僅僅是技術架構的演進，更是企業數據流通與智能化能力的質變——讓團隊把時間用在業務創新上，而不是「打通消息系統」上；讓 AI Agent 能夠直接接入統一的數據流，實時感知、自主決策、即時行動。

3 月 20 日，見證一次關鍵發布

如果說過去十年，消息系統解決的是「連接萬物」的問題；那么下一個十年，真正的挑戰是：如何在一個融合的平臺上，讓萬物、應用與 AI 協同流動。

我們在前文討論的多模消息引擎、原生跨協議互通、云原生彈性架構、對象存儲持久化以及多租戶治理，并不是停留在概念層面的架構設想，而是一套已經完整落地、面向未來十年的消息平臺能力。

3 月 20 日，在杭州舉辦的 EMQ Tech Day 上，我們將首次對外完整展示這一全新消息平臺的設計理念、核心架構與關鍵能力。如果你正在面臨多套消息系統并存的復雜架構，如果你正在為跨協議數據流轉和橋接鏈路所困擾，或者你正在思考如何讓 AI 能力更自然地融入實時數據體系，這場活動值得你到場參與。

融合消息平臺的時代，正在開啟。

歡迎報名，掃描下面二維碼，與我們一起，見證消息基礎設施的下一次躍遷。

完整嘉賓陣容與最新議程：