为何 AI 智能体需要事件驱动架构？

据 IDC 预测，到 2029 年，全球部署的 AI 智能体数量将达到 11.5 亿，是 2025 年部署量的 40 多倍。¹随着企业将未来押注于代理式 AI，如果实施不当，这将成为业务领导者的一场噩梦般的风险。而这种风险确实存在，尤其是当企业仅仅把代理式 AI 视为又一项技术时。

由于具备自主决策能力，AI 智能体对系统的要求与其他商业智能系统截然不同。在传统企业架构中，业务事件（例如客户订单、供应商发货延迟）通常以瀑布式方式从一个系统传递到下一个系统。然而，AI 智能体需要能够即时、独立地处理这些事件，这就要求采用一种不同的架构方式来共享和处理事件，即所谓的事件驱动架构。

AI 智能体通常参与复杂的闭环决策过程。它们需要实时获知事件，交叉比对其他业务数据源以获取更多背景信息，做出决策，并启动操作或其他由智能体驱动的业务流程。例如，一笔大额客户订单可能触发库存智能体检查库存水平，若发现库存不足，则自动补货，同时可能结合需求预测数据和物流数据，以缩短发货时间。

这类信息的处理必须实时进行。与此同时，AI 智能体需要有选择性地获取信息，并能够便捷访问广泛的资源。事件驱动架构（EDA）平台正是为满足代理式 AI 系统这些需求而设计的。

在传统架构中，一个工作流或业务流程可能横跨多个紧密耦合的系统，以达成特定结果。以客户在线购物为例：

客户购买（事件）→ 订单系统 → 支付系统 → 库存系统 → 发货系统 → 邮件系统

流程中的每一步，都需要相应系统或智能体感知到变化并采取行动：生成发票、向客户收费、更新库存系统、安排发货以及发送确认邮件。

在这种通常被称为“轮询”的架构模式下，AI 智能体必须主动查询各个系统，才能发现新事件。例如，负责补货的 AI 智能体可能每五分钟轮询一次库存系统，检查库存水平是否已低于某个阈值。如果库存在上一次轮询后一秒内就跌破了该阈值，该 AI 智能体仍需等到下一次轮询才能得知。这种机制限制了代理式 AI 的有效性，具体表现为：

• 增加决策延迟。
• 使用可能已经过时的数据。
• 即使没有变化，也持续消耗基础设施资源。
• 随着 AI 智能体数量增加，系统复杂性进一步上升。
• 难以清晰掌握企业运营的真实状况。

在事件驱动架构（EDA）中，AI 智能体不会主动轮询系统来获取事件信息。相反，事件会被发布到网络中，智能体则订阅这些事件，从而启动一个包含订阅、决策与执行的多阶段流程。

在订阅阶段，智能体只关注自己感兴趣的事件类型。当相关事件发布后，智能体会立即收到通知。随后，智能体决定如何应对该事件。通常情况下，智能体在做出决策前，可能需要从其他系统获取额外的上下文信息。最后，智能体执行相应操作。这一操作本身可能生成新的事件，进而由其他事件驱动的 AI 智能体处理。

这类事件驱动的交互，需要具备大规模企业级能力的基础设施，能够对业务事件进行路由、过滤与分发。诸如 SAP Integration Suite 等解决方案，可提供此类事件基础架构，使智能体、应用程序和业务流程通过实时事件进行交互，而不是依赖点对点连接或重复轮询。

情境感知对智能体 AI 的决策至关重要。例如，一个负责完成客户订单的 AI 智能体，在收到货物运输将延迟的事件后，可能需要更多上下文信息——是否有库存余量？是否有备用供应商？该客户是否为优先客户？——才能确定最佳应对方案。事件驱动架构（EDA）通过以下方式为 AI 智能体提供实时上下文：

• 提供最新信息，而非上次轮询留下的过时数据。
• 在恰当时机添加相关上下文。
• 通过整合多个事件流，提升态势感知能力。
• 加速决策流程。

在紧密耦合的架构中，相互依赖的网络意味着，一旦某个系统发生故障，很可能波及其他系统。即使故障系统恢复后，更新和同步其他依赖系统仍可能是一项巨大的工作。

事件驱动架构（EDA）采用松耦合方式，避免了这种多米诺骨牌效应。由于事件会被缓冲而不会丢失，当系统重新可用时，只需消费这些事件即可，因此恢复过程更加平滑。

事件代理（event brokers）专为大规模、低延迟运行而设计。通过缓冲机制，可以吸收业务运营中的突发高峰（例如黑色星期五的购物流量），确保系统和智能体不会因负载过重而崩溃。

此外，在企业环境中添加新的系统或智能体时，事件驱动架构（EDA）也更具灵活性和安全性。过去，新增系统或智能体必须直接连接到其他系统，这往往需要额外的更新或配置，甚至可能导致停机，并带来一定的业务风险。而在事件驱动架构（EDA）中，新系统或智能体能以更独立的方式运行，只需订阅与其相关的事件即可。

事件驱动模式提供了一种灵活且可扩展的工作流表达方式，其中事件会触发、协调或控制 AI 智能体执行的任务。一种适用于代理式 AI 的通用模式如下：

事件发生 → 智能体被触发 → 智能体推理 → 智能体行动 → 新事件发生

将该模式应用于一笔大额客户订单时，流程可能如下所示：

1. 事件：CRM 系统发布收到大额订单的事件。
2. 触发：订阅该事件的库存智能体被激活。
3. 推理：智能体检查可用库存、现有承诺以及补货计划。
4. 行动：智能体判断需要补充库存，并发起补货订单。
5. 新事件：发布库存补货事件。

发布/订阅（pub/sub）是一种事件驱动的模式，能在业务事件发生时立即通知已订阅的 AI 智能体。该模式非常适合代理式 AI，因为它：

• 支持向智能体实时、异步地传递数据。
• 消除了重复且低效的轮询操作。
• 避免了直接或点对点集成带来的复杂性。
• 防止对发布系统进行修改和变更所带来的风险。
• 随着添加更多智能体，可实现无缝扩展。
• 允许多个智能体同时响应同一事件。

事件代理在 AI 智能体与产生事件的应用程序（如 ERP、CRM、供应链、人力资源、财务和电子商务系统）之间架起了一层连接。从宏观层面看，事件代理确保 AI 智能体能够可靠且一致地消费这些应用程序中的事件信息。在更具体的层面上，事件代理支持以下能力：

• 实时、低延迟地访问事件信息
• 将正确的事件传递给合适的智能体
• 通过构建由多个智能体组成的事件网格，实现地理分布式扩展（同时有助于满足数据主权合规要求）
• 支持监控与追踪
• 通过新事件触发后续智能体的处理流程

到目前为止，为 AI 智能体实施事件驱动架构的优势应当已经十分明确。但为了让商业论证更具说服力，你需要提出三个关键问题：

1. Token 成本是多少？

企业若要采用代理式 AI，就需考虑因自主式 AI 处理而可能产生的高额大语言模型（LLM） Token 成本。在传统的轮询架构中，AI 智能体会持续轮询应用程序以检查事件更新，其中许多事件甚至与智能体无关，导致 Token 成本迅速累积。而像 SAP Integration Suite 高级事件网格模块这样的事件驱动架构（EDA）平台，通过以下两种重要方式减少了下游处理开销：

• 一是用选择性订阅取代持续轮询，使智能体仅在有值得处理的内容时才消耗 Token。
• 二是提供动态过滤功能，利用事件上下文进一步精简 Token 流量，仅将相关事件路由至相应智能体。

2. 添加新的智能体会影响我们现有的系统吗？

正如我们之前提到的，当新增智能体或系统时，紧密耦合的系统会带来固有的复杂性。而像 SAP Integration Suite 高级事件网格模块这样的松耦合事件驱动架构（EDA）系统，使企业能够轻松添加新的智能体，几乎无需额外的集成工作。其结果是降低了集成成本，提升了灵活性，并实现了 AI 智能体的无缝扩展。

3. 它们是否支持动态路由/过滤以及多云/混合部署？

企业通常会在一个云服务商中运行 SAP 应用，在另一个云中部署 AI 智能体，在第三个位置使用多供应商的软件即服务（SaaS）应用，同时还有部分应用部署在本地或网络边缘。如果平台无法无缝跨越这些环境，就会导致更多数据孤岛和额外的集成复杂性。SAP Integration Suite 高级事件网格模块具有分布式事件代理、动态路由和细粒度过滤功能，可支持跨多云、本地和边缘环境中的 SAP 与非 SAP 应用实现事件驱动的工作流。

随着企业越来越多地采用 AI 智能体来自动化日益复杂的决策，挑战在于如何在恰当时机提供正确的业务上下文。当 AI 智能体能够识别有意义的事件、理解其影响并实时采取行动时，效果最为显著。事件驱动架构为此模式提供了基础，它通过以及时、相关的事件分发取代低效的轮询机制，使智能体能够在整个企业范围内做出更快、更明智、更协调的决策。

SAP Integration Suite 高级事件网格模块通过可扩展的事件骨干网络连接应用程序、系统和 AI 智能体，帮助组织构建这一基础。凭借发布/订阅消息、动态路由与过滤、分布式事件代理以及对混合云和多云环境的支持等功能，组织可以创建与代理式 AI 计划同步发展的事件驱动自动化体系。