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

    随着生成式 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 与 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 的智能体工作流，核心能力可以归纳为感知、供数和行动三个层次。

    1. 感知：内置机器学习函数

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

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

    2. 供数：实时上下文引擎

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

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

    3. 行动：流式智能体

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

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

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

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

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

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

    写在最后

    随着IBM 完成对 Confluent 的正式收购，实时数据流与 IBM 的数据管理、集成和企业基础设施能力进一步结合，流式数据在企业 AI 战略中的位置更加突出。其主要组件（如Confluent Intelligence 和 Confluent Connector）结合 Kafka + Flink 的强大底座，可以帮助企业从被动的"问数分析"走向主动的"实时行动"，让 AI 真正融入持续变化的业务过程。

    关于IBM

    IBM 是全球领先的混合云、人工智能及企业服务提供商，帮助超过 175 个国家和地区的客户，从其拥有的数据中获取商业洞察，简化业务流程，降低成本，并获得行业竞争优势。金融服务、电信和医疗健康等关键基础设施领域的超过 4000 家政府和企业实体依靠 IBM 混合云平台和红帽 OpenShift 快速、高效、安全地实现数字化转型。IBM 在人工智能、量子计算、行业云解决方案和企业服务方面的突破性创新为我们的客户提供了开放和灵活的选择。对企业诚信、透明治理、社会责任、包容文化和服务精神的长期承诺是 IBM 业务发展的基石。了解更多信息，请访问：https://www.ibm.com/cn-zh