AI 代理有望通过自主问题解决、自适应工作流和可扩展性改变企业运营。但真正的挑战并非构建更优的模型。
代理需要能够访问数据、工具，并有能力跨系统共享信息，且其输出要能被多个服务（包括其他代理）使用。这并非 AI 问题，而是基础设施和数据互操作性问题。这不仅需要将一系列命令拼接起来，还需要由数据流驱动的事件驱动架构（EDA）。
正如 HubSpot 首席技术官 Dharmesh Shah 所说：“智能代理是新的应用程序。” 要实现这一潜力，从一开始就需要投入到正确的设计模式中。本文将探讨为何 EDA 是实现代理规模化并在现代企业系统中释放其全部潜力的关键。
要充分理解为何 EDA 对下一波 AI 至关重要，我们必须首先回顾 AI 的发展历程。
AI 的演进
AI 经历了两个截然不同的发展阶段，如今正进入第三个阶段。前两个阶段带来了新的可能，但也存在关键局限。
第一波 AI：预测模型
第一波 AI 围绕传统机器学习展开，聚焦于为明确定义的任务提供预测能力。
传统机器学习工作流
构建这些模型需要深厚的专业知识，因为它们是为特定用例量身打造的。它们具有领域特异性，其领域特性嵌入在训练数据中，这使得它们僵化且难以重新利用。要让模型适应新领域，往往意味着要从头开始 —— 这种方法缺乏可扩展性，也延缓了普及速度。
第二波 AI：生成式模型
由深度学习驱动的生成式 AI 标志着一个转折点。
与局限于单一领域不同，这些生成式模型在海量、多样化的数据集上训练，使其能够在各种场景中进行泛化。它们可以生成文本、图像甚至视频，带来了令人兴奋的新应用。然而，这一波 AI 也面临着自身的挑战。
生成式模型受时间限制，无法纳入新的或动态的信息且难以调整。微调可以满足特定领域的需求，但成本高昂且容易出错。微调需要海量数据、大量计算资源和机器学习专业知识，这使得在许多情况下都不切实际。此外，由于大型语言模型（LLMs）是基于公开可用数据训练的，它们无法获取特定领域的信息，这限制了它们准确回答需要上下文的问题的能力，例如，在你让生成式模型根据用户的个人健康史、所在地和财务目标推荐一份适合的保险政策的场景下。
LLM 的简单提示与响应
在这种情况下，你向 LLM 发出提示，它会生成一个响应。显然，该模型无法提供准确的推荐，因为它无法获取相关的用户数据。没有这些数据，其响应要么泛泛而谈，要么完全错误。
复合 AI 填补空白
为了克服这些局限，复合 AI 系统将生成式模型与其他组件（如程序化逻辑、数据检索机制和验证层）相结合。这种模块化设计使 AI 能够整合工具、获取相关数据，并以静态模型无法实现的方式定制输出。
例如，在保险推荐的例子中：
-
检索机制从安全数据库中提取用户的健康数据和财务数据。
-
这些数据被添加到构建提示时提供给 LLM 的上下文中。
-
LLM 利用构建好的提示生成准确的响应。
简单的 RAG 架构
这一过程被称为检索增强生成（RAG），它通过将相关数据动态纳入模型的工作流，填补了静态 AI 与现实需求之间的差距。
尽管 RAG 能有效处理此类任务，但它依赖于固定的工作流，这意味着每一次交互和执行路径都必须预先定义。这种刚性使其难以处理更复杂或动态的任务 —— 在这些任务中，工作流无法被详尽编码。手动编码所有可能的执行路径既费力又具有局限性。
固定流架构的局限性催生了第三波 AI：智能代理系统。
智能代理型AI的崛起
尽管AI已经取得了长足进步，但我们正触及固定系统乃至大型语言模型（LLMs）的极限。
据报道，谷歌的Gemini尽管在更大的数据集上训练，却未能达到内部预期。OpenAI及其下一代Orion模型也传出了类似的结果。
Salesforce首席执行官马克·贝尼奥夫最近在《华尔街日报》的“万物的未来”播客中表示，我们已经触及了大型语言模型能力的上限。他认为，未来属于自主代理——即能够独立思考、适应和行动的系统，而非像GPT-4这样的模型。
智能代理带来了全新的东西：动态的、上下文驱动的工作流。与固定路径不同，智能代理系统能实时确定下一步行动，适应当前情境。这使它们成为解决当今企业面临的各类不可预测、相互关联问题的理想选择。
控制逻辑：程序化与智能代理化
智能代理颠覆了传统的控制逻辑。
智能代理不再是僵化的程序，它支配每一个动作利用大型语言模型来驱动决策。它们能够推理、使用工具、访问记忆——所有这些都是动态进行的。这种灵活性使工作流能够实时演进，让智能代理比任何基于固定逻辑构建的系统都强大得多。
智能代理架构
设计模式如何塑造更智能的代理
AI代理的优势不仅来自其核心能力，还来自构建其工作流和交互的设计模式。这些模式使代理能够解决复杂问题、适应不断变化的环境并有效协作。
下面我们介绍一些使高效代理成为可能的常见设计模式。
反思：通过自我评估实现改进
反思能力使代理能够在采取行动或提供最终响应之前，评估自身决策并改进输出。这种能力让代理能够发现并纠正错误、完善推理过程，从而确保更高质量的结果。
代理的反思设计模式
工具的使用扩展了代理能力
与外部工具交互能扩展代理的功能，使其能够执行诸如数据检索、流程自动化或确定性工作流执行等任务。这在需要严格准确性的操作中尤其有价值，例如数学计算或数据库查询——在这些场景中，精确性至关重要。工具使用填补了灵活决策与可预测、可靠执行之间的差距。
代理的工具使用设计模式
规划：将目标转化为行动
具备规划能力的代理能够将高层次目标分解为可执行的步骤，并按逻辑顺序组织任务。这种设计模式对于解决多步骤问题或管理具有依赖关系的工作流至关重要。
代理的规划设计模式
多代理协作：模块化思维
多代理系统采用模块化方法解决问题，将特定任务分配给专门的代理。这种方法具有灵活性：可以为特定任务的代理使用小型语言模型（SLMs），以提高效率并简化内存管理。模块化设计通过让单个代理的上下文聚焦于其特定任务，降低了它们的复杂性。
一种相关技术是混合专家模型（Mixture-of-Experts，MoE），它在单一框架中采用专门的子模型（即“专家”）。与多代理协作类似，MoE会动态地将任务路由到最相关的专家，从而优化计算资源并提升性能。这两种方法都强调模块化和专业化——无论是通过多个独立工作的代理，还是通过统一模型中特定于任务的路由。
就像在传统系统设计中一样，将问题分解为模块化组件会使其更易于维护、扩展和调整。通过协作，这些专门的代理能够共享信息、划分职责并协调行动，从而更有效地应对复杂挑战。
代理的多代理协作设计模式
简言之，代理不仅能执行工作流，还能重塑我们对工作流的认知。它们是构建可扩展、自适应AI系统的下一步，超越了传统架构的限制以及当前大型语言模型的局限性。
智能代理型RAG：自适应且上下文感知的检索
智能代理型RAG（Agentic RAG）对RAG进行了演进，使其更具动态性和上下文驱动性。不同于依赖固定工作流，智能代理能够实时确定所需数据、数据位置以及如何根据当前任务优化查询。这种灵活性使智能代理型RAG非常适合处理需要响应性和适应性的复杂多步骤工作流。
例如，一个制定营销策略的智能代理可能会先从客户关系管理系统（CRM）中提取客户数据，使用API收集市场趋势，并随着新信息的出现调整其方法。通过记忆保留上下文并迭代查询，该代理能够生成更准确、更相关的输出。智能代理型RAG将检索、推理和行动融为一体。
智能代理型RAG设计模式
智能代理规模化面临的挑战
无论是单个代理还是协作系统，智能代理的规模化都取决于它们轻松访问和共享数据的能力。智能代理需要从多个来源（包括其他代理、工具和外部系统）收集信息，以制定决策和采取行动。
单个代理的依赖关系
将智能代理与其所需的工具和数据相连，本质上是一个分布式系统问题。这种复杂性与微服务设计中面临的挑战相似——在微服务中，组件必须高效通信，同时避免产生瓶颈或僵化的依赖关系。
与微服务一样，智能代理必须高效通信，并确保其输出在更广泛的系统中有用。而且，与任何服务一样，它们的输出不应只回流到AI应用中，而应流入其他关键系统，如数据仓库、CRM、客户数据平台（CDP）和客户成功平台。
当然，你可以通过远程过程调用（RPC）和API来连接智能代理和工具，但这会导致紧耦合系统。紧耦合会使系统更难扩展、调整或支持同一数据的多个消费者。智能代理需要灵活性。它们的输出必须无缝地流入其他代理、服务和平台，而不会将所有东西锁定在僵化的依赖关系中。
解决方案是什么？
通过事件驱动架构实现松耦合。这是使智能代理能够共享信息、实时行动并与更广泛的生态系统集成的基础——同时避免紧耦合带来的麻烦。
事件驱动架构入门
早期，软件系统都是单体架构。所有功能都存在于一个紧密集成的代码库中。虽然构建简单，但随着规模扩大，单体架构变成了噩梦。
扩展方式很粗糙：即使只有一部分需要扩展，你也得扩展整个应用。这种低效导致系统臃肿、架构脆弱，无法应对增长需求。
微服务改变了这一点。
通过将应用拆分为更小的、可独立部署的组件，团队可以只扩展和更新特定部分，而无需改动整个系统。但这带来了新的挑战：这些小型服务如何有效通信？
如果我们通过直接的RPC（远程过程调用）或API调用连接服务，会造成一堆错综复杂的依赖关系。如果一个服务宕机，会影响到连接路径上的所有节点。
紧耦合微服务
EDA（事件驱动架构）解决了这个问题。
不同于紧耦合的同步通信，EDA使组件能够通过事件进行异步通信。服务之间无需相互等待——它们会实时对正在发生的事情做出反应。
事件驱动架构
这种方式让系统更具弹性和适应性，能够应对现代工作流的复杂性。这不仅是一项技术突破，更是高压下系统的生存策略。
早期社交巨头的兴衰
像Friendster这样的早期社交网络的兴衰，凸显了可扩展架构的重要性。Friendster早期吸引了大量用户，但他们的系统无法应对需求。性能问题导致用户流失，平台最终失败。
另一方面，Facebook的成功不仅源于其功能，还在于它对可扩展基础设施的投入。它没有在成功的重压下崩溃，反而崛起并占据主导地位。
如今，我们可能会在AI代理身上看到类似的故事。
和早期社交网络一样，代理将经历快速增长和普及。构建代理还不够。真正的问题是，你的架构能否应对分布式数据、工具集成和多代理协作的复杂性。没有合适的基础，你的代理架构可能会像早期社交媒体的失败者一样崩塌。
未来属于事件驱动代理
AI的未来不仅在于构建更智能的代理，更在于创建能随着技术进步而演进和扩展的系统。随着AI技术栈和底层模型的快速变化，僵化的设计会迅速成为创新的障碍。为了跟上步伐，我们需要优先考虑灵活性、适应性和无缝集成的架构。事件驱动架构（EDA）是这一未来的基础，它能让代理在动态环境中蓬勃发展，同时保持韧性和可扩展性。
作为具有信息依赖的微服务的代理
代理与微服务相似：它们具有自主性、解耦性，能够独立处理任务。但代理更进一步。
微服务通常处理离散的操作，而代理依赖共享的、富含上下文的信息来推理、决策和协作。这对依赖管理和确保实时数据流提出了独特需求。
例如，一个代理可能从CRM中提取客户数据、分析实时统计信息、使用外部工具，同时与其他代理共享更新。这些交互需要一个系统，让代理既能独立工作，又能流畅地交换关键信息。
EDA通过充当数据的“中枢神经系统”解决了这一挑战。它允许代理异步广播事件，确保信息动态流动，而不会产生僵化的依赖。这种解耦使代理能够自主运行，同时无缝集成到更广泛的工作流和系统中。
事件驱动的AI代理架构
解耦的同时保持上下文完整
构建灵活的系统并不意味着要牺牲上下文。传统的紧耦合设计通常将工作流绑定到特定的管道或技术上，迫使团队应对瓶颈和依赖关系。技术栈中某一部分的变更会波及整个系统，减缓创新和扩展的进度。
EDA消除了这些限制。通过解耦工作流并支持异步通信，EDA使技术栈的不同部分（代理、数据源、工具和应用层）能够独立运行。
以当今的AI技术栈为例。机器学习运维（MLOps）团队管理RAG等管道，数据科学家选择模型，应用开发者构建界面和后端。紧耦合设计会迫使所有这些团队陷入不必要的相互依赖中，减缓交付速度，且难以适应新工具和技术的出现。
相反，事件驱动系统确保工作流保持松耦合，让每个团队都能独立创新。
应用层无需了解AI的内部机制——它们只需在需要时使用结果即可。这种解耦还确保AI洞察不会局限于单一系统。代理的输出可以无缝集成到CRM、客户数据平台（CDP）、分析工具等中，形成一个统一、可适应的生态系统。
通过事件驱动架构扩展代理
EDA是向代理型系统过渡的支柱。
它能够解耦工作流同时支持实时通信，确保代理能够高效地大规模运行。正如前文所讨论的，像Kafka这样的平台体现了EDA在代理驱动系统中的优势：
-
水平可扩展性：Kafka的分布式设计支持添加新代理或消费者而不会产生瓶颈，确保系统轻松扩展。
-
低延迟：实时事件处理使代理能够即时响应变化，确保工作流快速且可靠。
-
松耦合：通过Kafka主题而非直接依赖进行通信，代理保持独立性和可扩展性。
-
事件持久性：耐用的消息存储保证数据在传输过程中不会丢失，这对高可靠性工作流至关重要。
实时流平台上作为事件生产者和消费者的代理
数据流使数据能够在企业中持续流动。中枢神经系统作为实时数据流的统一支柱，无缝连接不同的系统、应用和数据源，实现高效的代理通信和决策。
这种架构天然适合Anthropic的模型上下文协议（MCP）等框架。
MCP提供了一个通用标准，用于将AI系统与外部工具、数据源和应用集成，确保安全且无缝地访问最新信息。通过简化这些连接，MCP减少了开发工作量，同时支持基于上下文的决策。
EDA解决了MCP旨在应对的许多挑战。MCP需要无缝访问多样化的数据源、实时响应能力以及支持复杂多代理工作流的可扩展性。通过解耦系统并支持异步通信，EDA简化了集成，确保代理能够无僵化依赖地消费和生成事件。
事件驱动代理将定义AI的未来
AI领域正快速演进，架构也必须随之发展。
企业已做好准备。Forum Ventures的一项调查显示，48%的高级IT领导者已准备好将AI代理集成到运营中，其中33%表示已做好充分准备。这表明，对于能够扩展并处理复杂性的系统存在明确需求。
事件驱动架构（EDA）是构建灵活、有韧性且可扩展的代理系统的关键。它实现了组件解耦，支持实时工作流，并确保代理能够无缝集成到更广泛的生态系统中。
采用EDA的企业不仅能立足，还将在这波新的AI创新浪潮中获得竞争优势。而其余企业呢？它们可能会被甩在后面，成为自身无法扩展的牺牲品。
