从数据流到 AI 上下文： IBM Confluent 面向 AI 场景的能力演进

AI 时代的数据挑战：从历史洞察走向事件驱动

越来越多的企业正在利用 AI 加速业务流程并推动业务创新。传统路径通常包括两类：一类是建设数据湖仓，从历史结构化数据中提取业务洞察；另一类是通过检索增强生成（RAG）构建知识库，为智能体提供非结构化知识。前者回答经营数据发生了什么以及为什么发生，后者帮助智能体理解制度、文档和经验知识。

IBM 提出的“智慧经营”理念，与业界常说的“问数”路径相近，即从指标查询出发，进一步分析变化原因、观察业务动态、定位根因并采取行动。这仍是当前企业智能化应用的重要模式。

AI 应用的一个关键跃迁，是从“回答问题”转向“实现目标” —— 从“用户提问、模型回答”的交互模式，转向“业务事件发生、智能体实时感知并采取受治理的行动”的“事件驱动 AI”（Event-Driven AI）模式。其核心是让持续流动的业务数据直接成为智能体的实时上下文，使智能体能够感知业务变化并及时响应。在这一闭环中，智能体不再只依赖静态知识，而是直接获取经过筛选和关联的实时事件。

作为 IBM 近年的重磅收购之一，IBM Confluent 可结合规则、复杂事件处理、机器学习和大模型能力，从海量数据中识别值得关注的信号，而不是把全部原始数据交给智能体。关键信号交由智能体研判后，智能体可以触发相应行动，处置结果再写回事件流，用于后续反馈、复盘和规则优化。由此形成“实时感知、上下文供给、智能决策、业务行动、反馈优化”的完整闭环。

这一模式带来两项关键转变。其一，智能体由实时流数据触发，而不是等待用户提问；其二，AI 的价值从“回答问题”延伸到“执行操作”。

IBM 如何重塑实时智能：贯通实时数据、智能体与 AI 辅助开发

在支撑上述转变的技术架构中，Confluent 作为数据流平台，确保账户、客户、采购、交易、点击流等业务数据通过基于 Kafka Connect 的连接能力持续接入。平台在事件之间维护可关联的业务上下文，并以事件驱动方式将经过处理的数据推送至右侧的智能体平台。IBM watsonx Orchestrate 则负责接收实时上下文，完成推理、编排和行动，并对智能体运行过程进行可观测、可控制和可优化的闭环管理。

架构的底座是 AI 辅助开发能力。随着 AI Coding 逐步进入企业研发体系，数据处理逻辑和智能体应用都可以通过 AI 辅助方式构建。IBM Bob 可辅助贯通从 Confluent 流处理到智能体开发的流程，支持数据处理逻辑、应用代码和智能体能力的端到端开发。

DAY 1 与 DAY 2：构建实时处置和持续优化闭环

以银行信用卡欺诈检测为例，信用卡交易数据以流式方式接入 Confluent。整个业务闭环可以划分为 DAY 1 和 DAY 2 两个相互衔接的阶段。

• DAY 1：实时调查与行动

实时交易数据进入 Confluent 后，由流处理逻辑识别异常信号并触发智能体。智能体对异常交易进行实时研判和处置，处理结果再写回 Confluent。该流程持续运行，实现流数据与智能体协同下的大规模自动化处置。

• DAY 2：综合分析与规则优化

由于原始事件、智能体判断和处置结果均被记录在流式数据体系中，调查智能体可以回顾前一周期的交易、决策和后续结果，判断处置是否准确并提出优化建议。建议可用于调整智能体逻辑和流处理规则，从而形成持续改进闭环。涉及代码和逻辑调整的部分，也可以借助 IBM Bob 等开发辅助工具提高开发效率。

信用卡欺诈检测：从实时筛查到决策反思

信用卡交易持续写入 Kafka Topic，数据规模巨大，不适合直接全量交由大模型处理。更合理的方式是先使用 Apache Flink 结合已知业务规则进行流式筛查。例如，当同一账户在短时间内出现在不同地点且交易金额明显增长时，系统可将其标记为异常候选。通过规则和流式分析，可以将千万级交易压缩为数千条高价值信号，再交由交易研究智能体进一步判断。

智能体获得异常数据后，可结合商户观察名单、客户交易历史和账户关系进行综合研判，并按风险等级采取处置措施。高风险交易可触发冻结或止付并向客户发送通知；较低风险交易可进入二次确认流程；所有触发规则的交易和处置动作均保留审计日志，以确保全流程可追溯。这构成了 DAY 1 的完整链路，即从事件流、规则过滤到智能行动。

DAY 2 的核心是反思与优化。智能体的决策结果写回 Confluent 后，调查智能体可以借助基于模型上下文协议（MCP）的工具，读取前一周期的交易数据、规则命中情况、争议工单以及客户沟通记录，综合判断既有处置是否合理。

例如，一笔交易最初被判定为欺诈，后续调查却发现客户持有多张附属卡，因此同一时段在不同地点出现多笔大额交易。调查智能体可以识别这一关联，建议把“附属卡与主卡关系”纳入规则例外，从而减少误报并改善客户体验。

复盘还可以发现新的风险维度。传统规则可能只关注单一客户和单笔交易，但某些风险集中于商户侧。若同一商户在短时间内处理大量异常交易，系统就应增加以商户为主体的风险检测规则。DAY 2 通过持续回溯，帮助企业同时降低误报与漏报。

这一复盘强调对事件发生时业务上下文的还原。湖仓仍然适合长期历史分析、合规留存和跨域分析，但对于需要重现实时决策过程的场景，保留事件流中的时间顺序、状态变化和决策轨迹尤为重要。流式数据与湖仓并非替代关系，而是分别服务于实时行动和长期分析。

Confluent Intelligence 三大核心能力：感知、供数与行动

作为Confluent平台的关键组件，Confluent Intelligence 面向基于 Flink SQL 的智能体工作流，核心能力可以归纳为感知、供数和行动三个层次。

• 感知：内置机器学习函数

Confluent 将多类机器学习能力集成到 Confluent Cloud for Apache Flink 中，使开发者能够通过 Flink SQL 完成异常检测、趋势预测、情感分析和个人可识别信息检测等任务。相关函数包括ML_DETECT_ANOMALIES（异常检测）、ML_FORECAST（预测）、AI_SENTIMENT（情感分析）、AI_DETECT_PII（敏感信息识别）。

这些能力可以与规则及复杂事件处理结合，作为实时感知层从大规模事件流中提取高价值信号。先利用确定性规则和机器学习缩小数据范围，再调用大模型进行复杂研判，可以兼顾效率、成本和准确性。由于大模型通常按 Token 或推理资源计费，这种分层处理方式也有助于显著控制成本。

• 供数：实时上下文引擎

实时上下文引擎通过 MCP（模型上下文协议）接口将 Kafka Topic 中的业务数据提供给外部智能体。启用后，Topic 数据可被物化为面向低延迟查询的表，智能体无需直接消费 Kafka 消息，即可通过 MCP 工具查询订单、库存、设备状态等实时业务信息，并在授权范围内关联多个数据主题。

对于生产数据，应遵循最小权限和职责分离原则。面向外部智能体的上下文查询通常采用只读方式，并结合身份认证、授权和治理策略，避免智能体直接改写关键业务数据。订单、供应商、交易和库存等多个 Topic 可以被关联为完整业务上下文，从而提升智能体决策质量。

• 行动：流式智能体

Streaming Agents 使智能体能够持续运行在事件流之上，并连接模型、工具与业务系统。通过 CREATE TOOL、CREATE AGENT、AI_RUN_AGENT 等能力，企业可以在流式工作流中定义工具、构建智能体并触发执行。平台还可以调用大模型对持续到来的数据进行总结、分类、翻译或文本生成，再将结果交给下游系统。

例如，工单内容进入事件流后，可以先由大模型生成简洁摘要，再交由运维流程处理。将三类能力串联起来，就形成了“感知异常、提供实时上下文、触发智能行动”的完整路径，使 Confluent 成为企业实时运营的感知与响应基础。

三类参考架构：从行业信号到业务行动

• 场景一：电信网络异常检测

用户设备遥测数据和蜂窝基站指标实时流入 Confluent 后，Flink 可通过规则识别掉话等事件，再利用机器学习算法对掉话率进行异常评分，筛选出需要关注的信号。智能体进一步开展根因分析，判断问题来自基站故障、施工干扰还是覆盖不足，并在授权范围内自动触发处置。该模式也适用于制造、物联网和设备运维等异常检测场景。

• 场景二：实时产品个性化推荐

网页端和移动端的实时点击行为，与购物车、购买记录和产品目录在 Confluent 中汇聚后，可以形成持续更新的用户偏好视图。该视图在用户浏览过程中实时生成，并通过实时上下文引擎提供给外部智能体。大模型结合当前行为和历史偏好生成个性化推荐，限时优惠也可以在分钟级窗口内触发，从而把事后分析转化为当下行动。

• 场景三：AI 驱动的 IT 运维数据增强

Kubernetes 日志、Jira 工单以及存储、操作系统和网络日志可以持续进入 Confluent。大模型对日志和工单描述进行实时总结与增强，将关键信息直接推送给运维人员；在明确授权和安全控制下，智能体还可以执行扩容磁盘等标准化操作。理想状态下，问题在工单创建前即可被识别和处理，从而减少重复工单并缩短平均修复时间。