Agent架构解析及分布式Agent协作方案

最新推荐文章于 2025-05-05 14:07:50 发布

大模型入门教程

最新推荐文章于 2025-05-05 14:07:50 发布

阅读量778

点赞数 15

文章标签： Agent AI大模型人工智能程序员 AI 大模型学习大模型入门

本文链接：https://blog.csdn.net/2401_85343303/article/details/147702339

版权

AI Agent（智能体）系统发展迅猛，且关注点已经不再局限在Agent的规划推理等基本能力，智能体系统在扩展性、互操作、安全性等工程化方面的挑战也越来越引起重视，比如最近的MCP和A2A。上一篇我们介绍了A2A，今天接着再聊聊分布式Agent系统的话题。

Agent 模式架构解析

Agent 有效减少人类工作总量，人与 AI 协作才是最终形态。人类与 AI 交互可大致分为三种模式。Embedding 模式中大模型可以填补一些信息缺失，完成少量子任务，例如总结信息等等。用户最终会整合挑选 AI 提供的信息，并自主完成任务。Copilot 模式则更加智能化，AI 可根据用户设定的流程去执行任务。例如让 AI 根据写一段稿件或者根据需求编程，但其对 Prompt 的要求也更高。在 AI 完成流程后，用户需要对内容结果进行调整并自主结束工作。Agent 智能体模式的 AI 参与度更高，但也不是完全由 AI 代理。用户需要给 AI 设计一个目标和身份，以及需要使用的工具。配上更为复杂的 Prompt， AI 能自主进行任务拆分，使用工具并结束任务。用户只负责设立目标、提供资源、监督结果。

以 LLM 为核心，四模块铸造AI Agent。从 OpenAI 的定义来看，智能体以大语言模型为核心，其拥有长期和短期记忆、自主规划能力、能自动化执行复杂任务、能够使用工具等四个特点。

1）记忆模块：智能体像人类一样，能留存学到的知识以及交互习惯等，这样的机制能让智能体在处理重复工作时调用以前的经验，从而避免用户进行大量重复交互。短期记忆适用于所有上下文的学习，类似平常我们与ChatGPT 沟通的模式；长期记忆则保留知识和交互回忆，例如智能体在特定行业积累的大量数据和经验，则能提供更专业、更具深度和个性化的回答，提升用户体验。

2）规划模块：将复杂任务分解成子目标并逐一解决，完成任务后进行反思总结。例如反思自己大量输出重复内容或在单一子目标耗时过长等问题，将经验存入长期记忆以规避类似错误。

3）工具模块：智能体可利用工具来弥补自身短板，通过调用外部 API 来实现功能拓展。例如调用连接互联网的 API 去搜索实时信息。

4）行动模块：智能体会形成完整的计划流程。例如先读取以前工作的经验和记忆，之后规划子目标并使用相应工具去处理问题，最后输出给用户并完成反思。

单智能体 vs 多智能体

单智能体与多智能体各具优势，适配于不同垂直领域。单智能体的强化学习原理是基于马尔可夫决策来完成的，简单来说可以分为状态集 S、行动集 A、奖励 R，下一时刻的状态和奖励只与上一时刻的行动有关，与更早之前的状态无关。其模型原理就是让智能体用试错的方式来学习，若某个策略能得到奖赏，则智能体产生该行为的策略就会加强。其目的就是在单一环境中行动，尽可能得到最大的奖励。应用领域目前也较为广泛，例如赛车游戏中连续动作的训练：控制方向盘、油门、刹车等动作，可由 DDPG、 A3C、PPO 算法来决策。一些离散动作的训练例如围棋智能体 AlphaGo，可通过 Q-Learning 等算法决策。多智能体的决策不仅与自身行动相关，还与系统内其他智能体的行动所关联。一个多智能体系统中会有两个以上的智能体，他们一般存在着合作或竞争关系。这样模型称为马尔科夫博弈，其状态转换符合马尔可夫决策，关系符合博弈。在多智能体模型中，每个智能体的目标是找到最优策略来使它在任意状态下获得最大的长期累积奖励。由于其模型更为复杂，干扰因素较多等原因，目前多智能体模型商业化产品较少。

CrewAI 是世界领先的多智能体框架之一，在多智能体领域用于协调角色扮演型自主 AI 智能体。通过促进协作智能，CrewAI 使智能体能够无缝协作并处理复杂任务。在编写程序时，用户需要赋予每一位 Agent 角色、任务、以及背景故事。

Agent系统如何扩展？

相对于在单个进程空间运行的Agent系统，分布式智能体系统则是将这些智能体分布运行在不同的进程、主机甚至不同的平台上，它们需要通过网络通信协同工作，共同完成复杂任务。

分布式的需求来自于Agent能力扩展的需要，本质上有两个维度：

横向扩展：单个 Agent 实例部署在多台服务器上，从而提高其处理性能和吞吐能力，这类似于传统 Web 服务的水平扩展。例如：当某个 Agent 需要维护大量长连接会话、处理大规模并发请求，或执行耗时的任务时，可以通过负载均衡将请求分散到多个实例，实现更高的容量和可靠性。

纵向扩展：多个不同职责的 Agent，将它们部署在不同服务器上协同工作，形成一个多 Agent 系统，类似于将单一智能体的功能按模块解耦为多个服务。例如：可以用一个 Agent 专门负责数据检索，另一个负责推理决策，再另一个负责执行操作，通过彼此通信来完成一个综合任务。这种方式提升了系统的模块化和灵活性，使各Agent各司其职，协同解决复杂问题。

所以：

横向扩展关注同质的扩容（更多实例），以解决并发与吞吐的问题；
纵向扩展关注异质的协作（更多类型），解决合作与协同的问题；

分布式Agent系统的挑战

对于横向的水平扩展，其面临的最主要挑战是，由于Agent任务的特点，简单的无状态服务形式对其是不够的（长时间任务、多轮对话、流输出等）；但有状态的服务又会带来扩展能力的下降，面临新的挑战：

任务状态一致性：如何保证Agent任务状态和上下文在多个实例间的一致性是难题。可能需要借助会话粘连（保证同一会话总是由同一实例处理）或状态持久化等手段，来实现状态同步。这对分布式会话管理有较高要求。

任务调度与容错：需要有效的负载均衡和任务调度策略来优化资源利用，是简单的轮询还是根据实例响应时间或资源使用的动态分配等。此外，还需要考虑实例故障的容错，通常需要借助成熟的负载均衡与容器编排策略。

而对于更复杂的多Agent系统跨网络的协作，还会面临更多问题：

Agent 协同协议

如果每对Agent都用各自私有接口对话，随着Agent数量增加，连接关系将变得错综复杂，维护成本高且易出错，会导致极高的耦合度。
消息传递效率

Agent 间需要频繁交换消息，如果通信机制低效，多 Agent 协作的整体速度将受限。特别在涉及长时间任务时，如何让Agent间异步并行工作、及时通知任务状态变化，避免因为轮询等机制浪费资源，都是需要考虑的问题。
上下文共享

多个 Agent 合作时，每个 Agent 只掌握局部信息，如何在它们之间共享上下文尤为关键。需要机制让Agent能够方便地共享知识和中间结果（例如通过公共内存、黑板系统甚至数据库）。
能力复用

当不同Agent具备互补的技能时，应该允许互相调用对方的能力，而不是各自重复实现同样的功能。这要求在 Agent 之间建立服务发现与调用机制。

几种分布式Agent协作方案

我们重点探讨分布式环境下，多Agent之间的协作与互操作的方案。

【方案一：AutoGen 框架的分布式运行时】

AutoGen在最新0.4版本后引入了实验性的分布式 Agent Runtime。其架构包含一个中央的主机服务（Host Service）和若干工作节点（Worker Runtime）：

主机服务通过 gRPC 协议（不同于JSON-RPC）连接所有活跃的 Worker，负责在 Agent 之间路由消息、维护会话状态等。
每个 Worker 在某台服务器上运行，托管一个或多个具体的 Agent，并向主机注册自己有哪些 Agent 可以处理哪些消息。
当某 Agent 需要给另一个 Agent 发消息时，主机服务会将消息转发给目标 Agent 的对应 Worker，实现不同机器上 Agent 间的透明通信。

通过 AutoGen 分布式运行时， Agent 系统可以方便地部署在多台服务器上，并实现消息通信与上下文同步，而开发者无需关心底层消息传递细节。

AutoGen 提供的方案侧重于框架层的集成：优势在于开箱即用，但局限是协作的 Agent 需要在同一 AutoGen 框架内，跨不同框架和语言的 Agent 互通需另行考虑。

【方案二：Agent 远程服务化（RPC/MCP）】

这种方法是将每个 Agent 作为独立服务来部署，通过远程调用的方式实现协作。这是一种经典的 RPC方案：每个 Agent 提供一组远程可调用的 API 接口，其他 Agent 可以像调用远程服务那样请求其执行某项任务并获取结果。

经典 RPC 方法的优点在于：利用成熟的分布式技术栈。同时，每个 Agent 服务可以独立扩展和部署（当然横向扩展也会面临上面提到的问题），天然具有模块边界清晰、故障隔离好的特点。

然而，纯粹的 RPC 式协作也有明显的局限：

需要开发者自行设计请求/响应的数据格式和流程。
Agent 之间没有共享的“会话”概念或上下文维护机制。
随着协作Agent数量增加，开发者可能需要处理繁琐的编排逻辑。
很快会陷入会话管理、内存管理和协调同步的复杂细节中。

不过，你可以利用新近出现的 MCP（Model Context Protocol） 与RPC方法结合。虽然 MCP 更侧重于工具接入和上下文提供，但我们也可以将每个 Agent 看作一个“MCP服务模块”，对外暴露自己的能力，即把Agent转化为工具，在一定程度上缓解了“每对Agent单独定制接口”的问题。

即便如此，这种方法总体上仍需要开发者规划好哪个Agent调用哪个、何时调用，并处理数据格式转换和错误恢复，其适用场景通常是固定的流程编排或工具调用型的Agent协作，即任务流程相对确定，Agent 之间主要是服务调用关系而非自由对话。对于需要灵活对话协商、多轮交互的场景，RPC方式会变得力不从心。

【方案二：Google 的 Agent-to-Agent 协议】

Google A2A 协议的目标是在不同厂商、不同框架的 Agent 之间建立统一的通信语言，让它们能够直接对话、交换信息并协同行动。

A2A 协议定义了一套面向 Agent 协作的通信机制，主要特点包括：

服务发现机制：每个支持 A2A 的 Agent 对外暴露一个Agent Card（JSON 文档），描述该 Agent 的元信息。解决了异构 Agent 之间如何互相发现和了解彼此功能的问题。
标准化的消息与任务结构：A2A 将 Agent 之间交互抽象为一个个任务（Task）。任务由协议统一定义生命周期，Agent 间通过发送消息来协商和更新任务状态，每条消息都有明确的结构，确保不同实现的Agent都能正确理解彼此发送的内容。
多样的通信模式：考虑到不同任务对交互实时性的要求，A2A 支持多种通信方式，支持短周期的请求/响应或者异步通知的任务形式。
安全与跨平台：作为企业级协议，A2A 特别强调了通信的安全性和跨平台兼容

A2A 协议提供的是跨平台、跨不同开发框架的Agent的通信与互操作协议，规定了Agent对外如何描述自己、如何发消息、如何协同完成任务，有望成为 Agent 协同的统一解决方案，但A2A目前仍在演进与草案阶段。

引入Multi-Agent架构

我们调研了：LangManus、OpenManus、OWL、Tars等完整产品形态的开源框架。同时也调研了一些更轻量的后台框架，比如eino 。这些框架在这些框架有一些共同点：引入了多Agent动态协同、上下文管理、任务流编排与执行等能力。核心逻辑都采用了ReAct模式进行循环迭代。都引入一套处理特定任务的工具集（如搜索、文档处理），同时支持MCP扩展。

这里基于调研的结论及对开源框架的理解画了一下 Multi-Agent的架构示意图：

这里不展开说。后续会发专项文章。敬请期待。

解决大模型应用开发的痛点

大模型给应用开发带来了很大的便利：

基于语义的文本处理能力：能够理解和生成人类语言，处理非结构化的内容语义关系
动态决策能力：能够基于上下文进行推理和判断，做出相应的行为决策

但大模型提供良好泛化能力的同时也引入了一些痛点，那就是准确性和稳定性

准确性 ：用户希望使用AI Agent的P图功能，在发送图片给Agent后，又说"卡通风格"。而AI Agent 出戏了回复了一段文字解释了卡通风格。大模型没有理解到用户处于画图的流程中。

稳定性：用户输入"我明天去第比利斯旅行，请帮我制定一个4天旅行计划"。可能存在大模型第一次规划的任务流程和第二次不一致的情况，比如：第一次"调用工具查询天气 -> 调用工具制定行程计划"，第二次"询问用户当地的天气情况- > 调用工具制定行程计划"。

可以从算法和工程两个维度来改进。这里主要探讨工程化的提升手段/措施：

提升意图识别准确性的工程化手段

1.1 精细化提示词管理、上下文管理，为大模型提供必要准确的信息。

1.2 通过任务质量Agent 收集低置信度意图识别结果。完成反馈与修正流程。

2.提升任务流规划稳定性的工程化手段

2.1. （参考eino框架的思路）开发者预先定义执行图的结构和可能的路径，固化某些业务的处理流程，而大模型在运行时根据任务内容动态决定具体走哪条路径。这种设计既保证了系统的结构化和可控性，又提供了足够的灵活性来处理各种复杂任务。

2.2. 复杂流程处理上：增加按照用户响应判断是否跳出任务的处理过程的逻辑或步骤。

如何学习AI大模型？

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。