 |
从被动问数到实时行动，构建事件驱动的企业级智能体
作者：吴敏达，IBM 中国科技事业部数据与人工智能资深技术专家
北京2026年9月7日 /美通社/ — 随着生成式 AI 和智能体加速进入企业核心流程，数据基础正在发生深刻变化。企业不仅需要从历史数据和知识库中获取洞察，更需要让智能体及时理解正在发生的业务事件，并在治理边界内采取行动。围绕这一目标，IBM Confluent 正从实时数据流平台进一步演进为面向 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 真正融入持续变化的业务过程。
