AI 应用从 Demo 走向生产的过程中，一个越来越普遍的判断正在形成：模型选型不再是主要瓶颈，另一个同样关键的变量，是那条把业务事件送进模型的数据链路。
这个判断有三重含义。负载特征变了：Agent 任务、模型推理调用、工具执行普遍呈现长耗时、耗时高度不均的特征，跟传统消息负载的短平快模式不匹配。时效要求变了：RAG 和实时推荐要求上下文在秒级内可用，离线批处理供给不了 Agent 的决策现场，上下文时延就是决策质量。信任边界变了：数据流向越来越多的模型、Agent 和第三方工具，敏感字段一旦进入模型上下文就不可撤回；仅靠网络边界拦得住谁能连，拦不住敏感字段被合法读走后去了哪里。
8 月 28 日，由极客传媒 InfoQ、阿里云和 IBM 联合举办的「AI 实时数据沙龙 · 上海站」上，三位来自阿里云和 IBM 的一线工程师围绕这条链路做了分享：一场讲数据流平台面向 AI 的整体演进，另两场分别落到阿里云消息队列 Confluent 版（ApsaraMQ for Confluent）和云消息队列 Kafka 版（ApsaraMQ for Kafka）两款产品的演进与实践。三场分享层层承接，给出的判断是一致的：当模型能力趋于充裕，AI 生产化的瓶颈正移向实时数据链路。
关注「阿里云云原生」公众号，后台回复：0828
免费获得上海站讲师 PPT 合集
事件驱动 AI：Agent 生产化的范式转变
吴敏达，IBM 中国科技事业部客户工程团队资深架构师
IBM 中国科技事业部客户工程团队资深架构师吴敏达在现场分享中提到，AI 应用的一个关键跃迁，是从“回答问题”转向“实现目标” —— 从“用户提问、模型回答”的交互模式，转向“业务事件发生、Agent 实时感知并采取受治理的行动”的事件驱动模式。他把这一转变总结为 “事件驱动 AI”（Event-Driven AI）：Agent 不再由人类唤起，而是嵌入企业基础设施、在变化发生的那一刻即时监控并做出反应；AI 的使用重点也从“关注输出”转向“以结果为导向”。
「Confluent AI 能力参考架构」 · 感知 / 供数 / 行动 三大支柱
支撑这个范式转变的技术底座，吴敏达用一张架构图总结成 Confluent Intelligence 的三大支柱加一层支撑层：
- 感知把异常检测、情感分析、PII 脱敏等能力内置为流处理函数，从海量事件中筛出真正需要 Agent 决策的信号；
- 供数用实时上下文引擎把 Kafka Topic 物化为低延迟的只读服务表，Agent 通过 MCP 协议直接查询订单、库存、设备状态等业务事实，把“批处理供给”变成“事件到达即可查”；
- 行动让 Agent 以事件为触发器持续跑在 Kafka Topic 上并调用外部工具，Agent 生命周期与数据流生命周期在同一平面内管理。
- 底层还有模型推理、实时 Embedding、外部表检索、安全连接、RBAC 与审计作为支撑。
三大支柱如何组合成闭环，吴敏达在现场用一个信用卡欺诈调查用例做了具象说明。
Day 1，实时决策： 信用卡交易流实时接入 Kafka，流处理任务做异常检测和有状态富化（例如识别“30 分钟内两个不同地点金额激增”这类模式），Agent 结合规则、商家观察名单和用户历史标记记录实时判定风险，并驱动推送通知、冻结卡、生成工单等补救动作。
Day 2，历史复盘： 另一个调查 Agent 通过 MCP 读取 Day 1 的决策数据流，结合人工处置结果和用户争议做跨系统推理，产出规则变更建议 —— 优化后的规则回流到 Day 1 的执行链路，形成事件驱动的规则闭环，不再依赖离线批处理定期更新。案例背后的判断是：Agent 要在生产环境里承担业务职责，就必须让它站在“业务事件发生的那一刻”，不是回答用户的问题，而是响应世界的变化。
在整个范式中，Confluent Connect 充当着实时数据总线与集成枢纽的核心角色，为 AI Agent 提供稳定、安全的上下文数据流。它通过无代码预置连接器与分布式架构，实时打通传统数据库、云存储及向量数据库等异构系统，不仅能在大规模高并发场景下保障数据流的不间断与故障自动恢复，还可以利用私有网络打通混合云环境，将企业内部数据安全输送至 AI 系统。
在实际应用中，Connect 可以在数据流转过程中进行轻量级的实时清洗与安全防护。例如，当企业将包含客户交易记录的数据库实时同步给 Agent 时，Connect 能够直接在传输链路中利用单条消息变换（SMT）将身份证或银行卡等敏感数据自动掩码脱敏，既无需额外套设数据清洗服务，又能防止敏感信息直接暴露给大模型，加速 Agent 从实验走向生产落地的过程。
消费模型、数据新鲜度、信任边界——AI 时代重新定义了数据流平台
刘尧，阿里云 · Kafka 产品负责人
感知、供数、行动这三大支柱，每一层都对底层数据流平台提出了跟传统 Kafka 不一样的要求。阿里云 Kafka 产品负责人刘尧在分享中给出的判断是：AI 应用的规模化落地正在重新定义“什么样的数据流平台才够用”，具体体现为消费模型、数据新鲜度、信任边界三条变化。他把这次 ApsaraMQ for Confluent 的版本升级定位为 “一次平台代际跃迁，而不是一次补丁升级” —— 三条变化在内核跨代、Queues for Kafka GA、CSFLE + 阿里云 KMS 这三项重要特性中同时落地。
「ApsaraMQ for Confluent 重要特性」 · 内核跨代 / Queues for Kafka GA / CSFLE + 阿里云 KMS
消费模型：从“分区消费”到“任务处理”
传统 Kafka 消费组的分区分配语义匹配的是“事件流”负载 —— 消息量大、单条处理快、顺序敏感。但 Agent 时代的负载完全不同：Agent 任务、模型推理调用、工具执行都是长耗时、耗时高度不均的任务型负载，一个慢任务会阻塞整个分区里的后续消息。这次升级 GA 了 Queues for Kafka（KIP-932 共享组），让多个消费者可以同时消费同一个分区、逐条确认与重投，消费者数量不再受分区数限制。“要顺序选消费组，要并发选共享消费组，两者可以在同一集群、同一 Topic 上并存。” 这也意味着一套 Kafka 可以同时承载事件流与任务队列。—— 对正在落地 Agent 与推理调度的团队，等于把“消息 + 队列”两套架构合并成一套。
数据新鲜度：从“分钟级”到“秒级”
RAG 与实时推荐要求上下文在秒级内可用；而“秒级”不只是流处理跑得快，还要求元数据、控制面、故障恢复整体匹配。这次升级完成了内核跨代 —— KRaft 成为唯一元数据平面，Apache Kafka 4.2 内核，ZooKeeper 完全退场，直接效果是故障恢复更快、控制面切换更平滑、元数据规模上限更大。对客户而言，少一套分布式协调系统，就少一类故障域、少一份运维与许可成本 —— 对数据新鲜度敏感的 AI 场景来说，这是“能不能秒级供数”的前提。
信任边界：从“网络边界”到“字段边界”
当数据流向越来越多的模型、Agent 和第三方工具，网络边界只解决“谁能连”，无法约束“敏感字段流到了哪里”。这次升级 GA 了 CSFLE（Client-Side Field Level Encryption），把加密边界前移到客户端：加解密在 SDK 内完成，基于 Schema 字段标签自动生效，密文在服务端、磁盘、备份、跨地域复制全链路始终是密文，服务端无解密能力；字段级粒度让身份证、手机号等敏感字段单独加密，其他字段仍可正常检索与计算。“CSFLE 让‘数据可流动’与‘敏感字段不泄露’不再互斥 —— 加密跟着数据走，而不是靠边界防护把数据锁死。”
中国大陆场景的一个关键能力，是 CSFLE 原生对接阿里云 KMS —— KEK 常驻阿里云 KMS，密钥不出境、不出云，与阿里云 RAM 权限体系和操作审计打通。对金融、政务、医疗等对密钥属地与自主可控有强要求的行业，这条能力是“能不能上云用 Confluent”的前置条件。
三条变化不是孤立的技术升级，而是 AI 时代对企业数据流平台的三条重新定义。同一次升级带来的收益，可以还原到三类客户视角：合规敏感型行业（等保与行业审计场景有据可依）、高并发在线业务（长尾任务不再整批拖慢）、正在落地 AI 应用的团队（数据脱敏与并发弹性同时具备）。
流接入、流计算、数据入湖，正在收敛进同一个平台
张美平，阿里云 · Kafka 技术负责人
平台层的三条重新定义要真正落到生产可用，还有最后一层挑战：底层 Kafka 集群本身的架构需要重构。阿里云 Kafka 技术负责人张美平在分享中给出的判断是：过去要跑通一条“实时采集 → 计算 → 入湖”链路，通常需要拼装 Kafka + 独立计算引擎 + 入湖工具 + 元数据系统，每多一个系统，就多一组连接、一套状态、一个故障边界。他给出的答案，是让 Kafka 这个“实时数据的第一跳”承担更多职责 —— 数据进来即算、算完即入湖，一个平台把流、算、湖三层能力收敛到同一个产品体系。这里的“一体化”不是把所有事情塞进一个进程，而是共享入口、共享底座；计算和入湖各自形成独立、可组合的闭环。
「整体架构 · 一份数据，流转算存一体」 · 从数据源经流·算·湖到 AI 生态的完整数据链路
产品形态：一个平台，三层“算”能力并行输出
“算”这一层拆成三种能力：流计算 SQL（过滤、窗口聚合、多流 Join，结果多路输出）、实时 Embedding（数据流经 Kafka 即完成向量化，对接通义 DashScope 系列模型，写入 DashVector / OpenSearch）、Streaming Agent（数据流上运行智能体，实时调用通义千问 / 百炼做内容理解、分类、路由与连续决策）。三层能力并行叠加，让吴敏达提到的三大支柱（感知、供数、行动）落到具体的产品形态上。这三层能力也不是必须依次串联 —— 只做合规留存的团队可以让原始 Topic 直接持续成表；只做实时风控的团队可以只运行 SQL；需要“清洗聚合后再沉淀”的场景，则把 SQL 结果 Topic 继续启用成表。
底座：存算分离，让故障切换与扩缩容不再搬数据
传统 Kafka 架构下，节点故障需要在副本之间搬运历史数据，切换又慢又费带宽。团队采用共享存储 + IO Fence 重构了 HA 路径 —— 分区数据持久化到共享存储，副本只维护接管所需的少量状态；主从切换和扩缩容时新节点直接复用共享数据，切换目标秒级，不再触发全量数据迁移。 传统架构下的分区再平衡和数据搬运，正是 AI 流量峰谷下弹性能力的隐形上限。放到 Kafka 生态的坐标系里看，社区演进方向是从“本地副本复制”走向“分层 / 共享存储”（Kafka 3.9 Tiered Storage 生产可用、KIP-1150 已 Accepted），共享存储底座相当于把这条方向工程化落地。
入湖：从“外置任务”收敛为“托管关系”
传统链路下，即使不做窗口和 Join，把 Kafka 数据持续写成开放表，也要跑一套 ETL 任务，管理位点、Schema、事务提交与故障恢复。“Table Topic”把这一套外部运行时收敛为 Topic 与表之间的托管关系 —— 用户在原 Topic 上一键启用，平台承接消息到 Iceberg 表的映射、Schema 演进、事务提交与失败恢复；下游通过 Iceberg Catalog 读取，Spark / Flink / Trino / MaxCompute / Hologres 可复用同一份数据资产。用户视角的关键变化是：实时入湖不再是一条要自建自维的独立链路，而是 Topic 上一份可配置、可托管的能力。
实时入湖还有一层容易被低估的长期成本：小文件、快照与元数据会持续膨胀。小文件合并（Compaction）、快照过期、未引用文件清理这些长期动作由服务后台自动执行，无需客户侧维护常驻任务 —— 把治理成本从用户任务移到存储内核，是实时入湖能否长期跑下去的隐性门槛。
流计算：SQL 开发体验，独立计算运行时
平台提供统一的流计算入口，用户通过 SQL 完成实时数据处理任务的开发、部署与运维。流计算任务运行于独立的计算资源与运行时，与 Kafka Broker 的核心消息服务解耦；复杂 Join、聚合、大状态计算或任务反压等计算侧压力被隔离在流计算域内，避免计算负载直接影响消息服务的稳定性。团队围绕单机效率和规模效率对 SQL 引擎做了多轮优化，落到用户可感的层面：实时任务吞吐更高、大状态场景扫描延迟显著下降、恢复更平稳 —— 状态型算子和大流量场景从“状态受本地内存约束”跨越到“状态与计算容量解耦”。用张美平的话说：“前两层是把单机性能做到极致；后两层决定了系统在大状态、高流量场景下，能不能存得下、跑得快、扩得动、恢复得稳。”
把底座、入湖、流计算这三层放在一起看，收敛路径的门槛不在“功能组合”，而在四个工程闭环同时成立 —— HA 正确性（切换不丢、不乱、不搬数据）、Table 资产（位点与 Snapshot 一致推进）、流计算隔离（计算故障不打扰核心消息流链路）、AI 治理（模型调用与消息热路径解耦）。对客户而言，这意味着一份实时数据不再需要为不同用途重复搭建链路，同时不用为一体化牺牲运行边界的清晰。“可复制的是功能清单，难复制的是正确性、隔离性与长期运营闭环。”
数据侧能力，正在成为 AI 应用能否规模化的分水岭
综合上述三条观察 —— 从事件驱动 AI 提出的应用范式诉求，到数据流平台的三条重新定义，再到底层 Kafka 集群的架构级重构 —— 一个更宏观的趋势正在浮现：AI 应用从 Demo 到生产的距离，越来越取决于数据侧的工程能力，而不是模型侧的选型能力。 这意味着评价一个 AI 应用团队的技术成熟度，除了看它对模型的理解，同样要看它对数据链路的掌控 —— 对上下文时效性的处理能力、对多源数据的融合能力、对流批一体架构的驾驭能力。这些能力过去分散在数据工程、消息中间件、流计算等多个技术领域，AI 应用的规模化正在推动它们融合到同一个平台上，指向一个共同的技术目标：让 Agent 始终基于最新的业务状态作出判断。 围绕这条链路的工程实践和技术判断，正在快速成型。
本文根据 2026 年 8 月 28 日「AI 实时数据沙龙 · 上海站」（由极客传媒 InfoQ、阿里云与 IBM 联合举办）现场分享整理，观点归属讲师本人。分享嘉宾：吴敏达（IBM 中国科技事业部客户工程团队资深架构师）、刘尧（阿里云 · Kafka 产品负责人）、张美平（阿里云 · Kafka 技术负责人）。
沙龙直播回放已上线，点击此处即可查看完整内容。
