消息队列巨头的 AI 战略：StreamNative、Confluent、Redpanda 都在做什么
最近在研究 AI 基础设施时，发现一个有意思的现象：几乎所有主流的消息队列厂商都在强调自己的 AI 能力。StreamNative、Confluent、Redpanda，不约而同地在官网首页突出 AI 相关特性，在技术大会上重点讲 AI 应用案例。
作为行业人员，我很好奇：消息队列和 AI 到底应该怎么结合，能做什么？这些厂商在 AI 方向都做了什么？是真有价值还是市场营销？本文梳理一下三家的 AI 战略，看看能有什么启发。
StreamNative：押注 Agentic AI
StreamNative 是 Apache Pulsar 背后的商业公司，由 Pulsar 的核心开发者创立。在 AI 方向上，StreamNative 的动作最激进，而且路线很清晰：押注 Agentic AI（AI Agent）。
今年 9 月，StreamNative 发布了 Orca Agent Engine，这是专门为生产环境 AI Agent 设计的事件驱动运行时。Orca 将 AI Agent 从无状态的请求-响应函数转变为持续在线的事件驱动服务，具有持久化流式内存和内置可观测性。它使用 Pulsar 或 Kafka 作为共享事件总线，通过 Model Context Protocol（MCP）实现 Agent 之间的协作和工具发现，创建所谓的"Agent 网格"。
配合 Orca，StreamNative 还推出了 MCP Server。这是一个标准化接口，让 AI Agent（比如 Claude、ChatGPT）可以用自然语言管理 Kafka 和 Pulsar 集群。你可以对 Agent 说"将 topic 'user-signups' 的保留时间增加到 3 天"，Agent 会自动执行对应的管理命令。MCP 是 Anthropic 推出的开放协议，被称为"AI 的 USB-C"，StreamNative 是最早支持这个协议的消息队列厂商。
除了 Agent 方向，StreamNative 还有 Ursa 引擎。这是一个 Lakehouse-Native 的流式引擎，直接将流数据写入 Apache Iceberg 和 Delta Lake 等开放表格式，消除了单独的 ETL 管道。流数据立即可以通过 SQL 和分析工具查询，无需额外的批处理。StreamNative 宣称这种架构可以降低 90-95% 的成本。
StreamNative 的策略很清晰：不只是"支持 AI"，而是"为 AI 重新设计"。Orca 是专门的 Agent 运行时，MCP Server 是专门的 Agent 接口，Ursa 是专门的实时分析引擎。这些都是新产品，不是在原有产品上打补丁。
Confluent：强调 RAG 和实时上下文
Confluent 是 Kafka 背后的商业公司，由 Kafka 的创始人创立。在 AI 方向上，Confluent 的重点是 RAG（检索增强生成）和实时上下文。
Confluent 的核心产品是 Flink AI Model Inference，这是集成在 Apache Flink 中的功能，可以在流处理中直接调用 LLM API。比如用户的客服咨询流经 Flink，Flink 实时关联用户的历史数据、订单信息，然后通过 Flink SQL UDF 调用 OpenAI API 生成回答。整个过程在流处理中完成，不需要单独的系统。
Confluent 还重点强调向量搜索集成。在 Flink 中可以直接查询外部的向量数据库（MongoDB、Pinecone、Elasticsearch），实现 RAG 场景。流数据进来，实时生成向量 embedding，存入向量数据库，然后在查询时做语义搜索。
此外，Confluent 提供了 120 多个连接器，可以方便地连接各种 AI 服务（OpenAI、AWS Bedrock、Google Vertex AI）和向量数据库。官网上大量的案例都在讲如何用 Confluent 构建实时 RAG 应用、如何持续更新向量数据库、如何为 LLM 提供实时上下文。
Confluent 的策略是"让消息队列更好地服务 AI 应用"。不开发新产品，而是通过集成（Flink + LLM + 向量数据库）和连接器，把 Kafka 定位为 AI 基础设施的数据流转中枢。
Redpanda：Agentic Data Plane
Redpanda 是 Kafka 的竞品，用 C++ 重写了 Kafka，性能更好。在 AI 方向上，Redpanda 最近推出了 Agentic Data Plane。
Agentic Data Plane 的定位是"AI Agent 的数据访问层"。核心功能包括连接能力（300 多个连接器，连接各种数据源）、治理能力（访问控制、审计、策略管理）、实时查询能力（最近收购了 SQL 引擎公司 Oxla）。Redpanda 强调的是：企业 AI Agent 的最大挑战不是模型，而是如何安全地访问分散在各处的数据。
Redpanda 还支持实时 RAG，宣传可以快速集成 OpenAI、AWS Bedrock、Google Vertex AI 等 AI 服务，持续更新向量数据库。另外还有 Data Transforms 功能，基于 WebAssembly 进行实时数据转换，用于机器学习的特征工程。
Redpanda 的策略介于 StreamNative 和 Confluent 之间。既推出了新产品（Agentic Data Plane），又强调集成和数据治理。但 Agentic Data Plane 本质上还是数据连接 + 治理 + 查询，和消息队列的核心功能关系不大，更像是在消息队列上叠加数据平台的能力。
共同点：都在做集成
虽然三家的具体产品不同，但有个共同点：核心都是数据集成和流转。
StreamNative 的 MCP Server 是集成 AI Agent 和消息队列，Orca 是把消息队列作为 Agent 的事件总线。Confluent 的 Flink AI Model Inference 是集成流处理和 LLM API，向量搜索是集成 Flink 和向量数据库。Redpanda 的 Agentic Data Plane 是集成各种数据源和 AI Agent。
他们做的不是 AI 的核心技术（模型训练、向量搜索、Agent 推理），而是把消息队列定位为 AI 应用的数据基础设施。帮助 AI 应用获取实时数据、持续更新向量数据库、收集用户反馈、协调多个服务。
这也印证了一个观察：消息队列在 AI 领域的价值主要在应用层，而非训练层。用于实时数据流转、用户交互、系统协调，而不是模型训练本身。OpenAI 的 30 多个 Kafka 集群也是这个用途。
一些观察和思考
看完这三家的 AI 战略，我有几个观察。
第一，大家都在蹭 AI 热度，但能做的确实不多。消息队列的核心能力是数据流转，AI 的核心能力是模型和算法，两者的交集主要就是"实时数据"。所以无论怎么包装，本质上都是在强调"为 AI 应用提供实时数据流"。
第二，集成和包装多于创新。Confluent 的向量搜索是集成 Flink 和向量数据库，Redpanda 的 Agentic Data Plane 是集成连接器和治理工具，这些都是把现有技术组合包装。真正原创的只有 StreamNative 的 Orca，但 Orca 也还在私有预览，实际效果未知。
第三，StreamNative 最激进。推出专门的 Agent 运行时（Orca）、MCP Server、Lakehouse-Native 引擎（Ursa），甚至收购公司（Oxla）。相比之下，Confluent 和 Redpanda 更保守，主要是在现有产品上做集成。StreamNative 是真的在押注 AI，还是过度激进？时间会给答案。
第四，市场需求不明确。AI Agent 真的需要专门的"事件驱动运行时"吗？还是说通用的消息队列就够了？企业真的愿意为"Agentic Data Plane"付费吗？这些产品看起来很酷，但真实需求有多大，还需要市场验证。
第五，消息队列的定位仍然是基础设施。不管怎么强调 AI，消息队列做的仍然是数据流转、系统集成、事件驱动这些基础设施的事。AI 的核心（模型、推理、向量搜索）在其他系统，消息队列是配角，不是主角。
总结
StreamNative、Confluent、Redpanda 都在积极拥抱 AI,但本质上做的是数据集成和流转。StreamNative 最激进,推出了专门的 Agent 产品。Confluent 最保守,主要是集成现有技术。Redpanda 居中,有新产品但不太激进。
客观讲,消息队列在 AI 领域能做的确实有限。需要明确的是:消息队列更多是在 AI 基础设施的应用层,而不是模型训练层。
在模型训练层,AI 系统的数据模式和消息队列的设计是不匹配的。训练需要批量读取、反复遍历数据(多个 epoch)、随机采样,这些特征更适合对象存储(S3、OSS)或分布式文件系统(HDFS)。消息队列的流式、顺序、一次消费的特点在这里并无优势。
但在应用层,消息队列的价值就非常明显了。OpenAI 运行 30 多个 Kafka 集群,用途包括:实时处理用户请求、收集用户反馈构建数据飞轮、多区域部署的数据同步、流处理管道(配合 Flink)。这些都是应用层的事——用户交互、数据流转、系统协调,而不是模型训练本身。
所以消息队列厂商强调的 RAG、实时上下文、Agent 协作,本质上都是在应用层提供数据流转基础设施。帮助 AI 应用获取实时数据、持续更新向量数据库、收集用户反馈、协调多个服务。这些 AI 功能更多是市场定位和场景包装,而非技术突破。但这也不是坏事,因为 AI 应用确实需要可靠的数据流转,这正是消息队列的强项。
关于 RobustMQ
RobustMQ 是一个用 Rust 编写的消息队列，专注核心能力，不追逐热点。我们相信把基础做好，比做很多花哨的功能更重要。欢迎关注我们的 GitHub。