利用多代理框架构建人工智能工作流程

代理在系统中注册为可调用组件

在代理做任何事情之前，框架需要知道它的存在。这意味着要告诉系统代理的名称、负责的工作以及可以访问的工具或信息。

在大多数框架中，这种设置都是通过配置文件或一些代码进行的，您可以在其中定义每个代理的角色以及如何激活它。例如，你可以告诉系统

"这是计划器。它读取用户输入并决定下一步行动。
""这是验证器。它获取用户信息，并返回 booking_id 和用户信息。"

一旦注册成功，框架就可以 "调用 "这些代理的名称，这意味着当工作流程轮到每个代理时，它知道如何运行它们。

路由代理决定下一个运行的代理

规划器代理或控制器功能负责处理人工智能代理路由。它查看机器人的最新输出、当前对话历史，有时还查看用户的原始输入，以决定下一步需要做什么。

有些计划程序是基于提示的--它们接收系统信息并输出下一个要运行的代理的名称。

其他人则使用硬编码逻辑或流程图，这取决于你正在使用的人工智能代理框架。

框架会获取该输出并用于调用下一个代理。路由器决定由谁来执行任务，而不是执行任务。

代理之间通过信息传递数据

代理不直接共享内存。一个代理运行结束后，其输出会打包成一条消息（通常是字典或 JSON 对象），并作为输入传递给下一个代理。

框架负责处理传输。它要么将信息存储在共享内存空间中，要么将其直接传入下一个代理的输入接口，具体取决于系统的结构。

信息通常不仅仅包括内容：

• 谁发送的（代理或用户）
• 工作流程从何而来
• 如何使用（如触发、输入、决策）
• 令牌计数或时间戳等可选指标

这种上下文有助于系统干净利落地路由任务，并保持代理之间的解耦。

使用工作流状态和触发器跟踪执行情况

该框架会记录迄今为止发生的事情--运行了哪些代理、它们返回了什么，以及还需要发生什么。这些信息存储在一个状态对象中，每一步之后都会更新。

触发器决定下一步。它们使用输出值或条件来分支流程。

这样，系统就能向前推进，而无需将逻辑硬编码到每个代理中。驱动工作流程的是状态，而不是代理本身。

扩展逻辑而不会使单个代理超载

单个人工智能代理只能做这么多，然后就会变成一堆乱七八糟的提示、工具和不明确的责任。多代理框架可让你将逻辑分割成若干个专注的代理，每个代理处理一项明确的任务。

您可以将特定的步骤（如检索、验证或执行）分配给不同的代理，然后逐个扩展系统，而不是让单个代理捉襟见肘。

调试代理协作，完全可视

当人工智能代理协同工作时，问题可能难以追踪。框架可以显示每个代理得到了什么、返回了什么以及在哪里停滞不前。

你不需要猜测是哪里出了问题，只需检查交接过程并直接修复。这种可视性使人工智能代理协作变得易于管理。

跨工作流程重复使用代理

如果代理有效，就重复使用。框架可让您将同一个代理插入不同的流程中，而无需重写。这样可以保持一致性，加快测试速度。

例如，检查用户输入或身份验证的验证代理可用于客户服务聊天机器人和预订聊天机器人，只要逻辑相同即可。

自动处理故障和重试

当代理失败时，框架可以重试、跳过或继续。您不需要自己编写这些逻辑。  

内置回退功能无需额外工作即可提高工作流程的可靠性，而这种可靠性正是现实世界系统的动力所在。

建立易于更改的代理流程

如果将任务分配给不同的代理，就不必在每次发生变化时都重新设计整个系统。

您可以更新计划器，而无需触及执行，或者改变一个代理的响应方式，而无需重写其他代理。

访问的便捷性带来了回报--Salesforce 的报告显示，使用代理人工智能的团队每周为每位员工节省 11 个小时，这部分归功于工作流程的适应性。

1.Botpress

Botpress 是一个可视化开发平台，用于构建能够跨步骤、跨角色和跨渠道协调的人工智能代理。

你可以使用流程、内存、条件和工具调用来定义代理的行为方式，而不是在代码中编写逻辑。

多代理行为是围绕指令、工作流程和外部工具构建的。Botpress 流程中的每个节点都是一个重点单元，有自己的指令和范围。

您可以在多个自主节点和静态节点之间拆分推理，添加验证层，或通过基于工具的决策逻辑来处理用户输入，而不是一步到位。

内存适用于每个流程，因此代理只需使用所需的内存。输入和输出定义明确，可通过内置集成直接添加工具调用。

主要功能

• 使用流和节点进行可视化代理协调
• 节点之间的内存作用域和变量控制
• 多圈记忆、回退逻辑和重试
• 通过 API 调用、网络钩子和函数输入使用工具

2.LangChain

LangChain 是一个开发人员优先的框架，通过将提示、工具和内存链连接起来，构建由LLM应用程序。

一开始，它只是一种利用搜索和计算器等工具来组织LLM 电话的方式，但后来逐渐扩展成为一个庞大的生态系统。

一个版本优先考虑 "代理"，然后是 "助手"，最后是 "可运行程序"。这就是一个功能强大的工具包，它几乎可以做任何事情，但往往需要花时间去浏览。

您可以分配工具包，在代理之间建立路由逻辑。它的亮点在于模块化--组件可重复使用、混合搭配，并与外部 API 完美集成。

不过，你要写的胶水代码会比预期的多。而且随着抽象概念的快速变化，值得检查一下你正在使用的方法是否仍是首选。

主要功能

• 提示、工具和记忆的模块化链条
• 与LLMs、向量存储和 API 集成
• 可选择使用 LangSmith 进行跟踪和评估

3.CrewAI

CrewAI 可以轻松构建多代理工作流程，其中每个代理都有明确的角色和任务。您可以创建一个团队，分配目标，然后代理通过共享管理器进行协调。

这是无需从头开始编写协调逻辑就能对代理协作进行建模的最快方法之一。

非常适合计划执行者配对、研究审查者流程等设置，或任何团队任务中的责任划分。

但是，一旦开始增加复杂性，抽象就会变得很严格。代理运行方式和时间的灵活性降低，修改行为往往意味着要跳出框架的默认设置。

主要功能

• 基于角色的代理设置，包括名称、目标和记忆
• 支持顺序和并行代理执行
• 船员共享记忆，促进代理协作
• 与工具、功能和自定义提示轻松集成

4.AutoGPT

AutoGPT 是第一个展示给GPT 聊天机器人一个目标并让它运行的项目--计划、思考、研究和执行，而无需持续的人工输入。

您确定目标后，AutoGPT 会循环推理步骤、创建子目标、调用工具并调整策略。

这是一个巨大的飞跃，让代理行为具有自主性和动态感。但它并不是为精确而生的。

任务循环很脆弱，代理往往会陷入重写相同计划或追逐无关子任务的困境。

您可以将内存、工具和应用程序接口连接在一起，但将所有东西拼接在一起往往会导致难以预测的流程，难以调试或引导。

主要功能

• 具有自我提示和任务规划功能的目标驱动型代理
• 自动生成子任务并循环执行
• 支持通过插件和 API 调用使用工具
• 可通过自定义脚本、功能和集成进行扩展

5.自动生成

Autogen 是微软公司推出的一个开源框架，主要用于多代理对话，代理通过结构化、基于回合的信息进行交互。

当你想控制每一次交换时，比如在计划-执行循环或人在循环系统中，它就特别有用。

Autogen 在透明度方面大放异彩。您可以在对话过程中注入功能，通过自定义逻辑进行决策路由，并准确跟踪每个代理的发言内容和原因。

但扩展它需要大量工作。消息协调虽然灵活，但并不抽象--你仍然需要自己管理历史记录、代理配置和步骤逻辑。

对于研究设置、受控测试或可重现的代理行为而言，它是最精确的框架之一。

主要功能

• 基于回合的多代理通信框架
• 支持人在回路中和功能调用代理
• 透明信息跟踪和自定义逻辑注入

步骤 1：找出单一代理逻辑的漏洞所在

在你的机器人或系统中寻找一个开始杂乱无章的地方--冗长的提示或连锁的工具调用，让人感觉是临时拼凑起来的。这就是你的切入点。以下是一些容易发现的常见例子：

1. 退款流程可在一个循环中解析用户输入、检查资格、发放退款并发送确认信息
2. 入职序列可在单个提示链中收集数据、验证表单、分配用户类型并触发电子邮件

与其重新设计整个系统，不如将已经出现裂痕的工作流程隔离开来。

步骤 2：在接触框架之前确定角色

找到混乱的逻辑后，将其分解为真正的责任。

如果有东西在验证输入，那是一个代理。如果有东西在处理外部操作，那就是另一个代理。

用通俗易懂的语言写出来--足以暴露交接点的位置。

一旦所有内容都呈现在你面前，你就会发现哪些是真正需要分离的，哪些是可以折叠的。这也会让你感觉到你需要什么样的框架。

每个角色都应该听起来像是你可以单独测试的。

第 3 步：选择框架

选择适合自己工作流程风格的平台。

• 可视化：Botpress，如果你想要基于节点的流量和作用域内存。
• 代码优先：如果你喜欢用 Python 编写逻辑，可以使用 LangChain 或 CrewAI。

该框架决定代理如何注册、触发和连接。

步骤 4：建立第一个工作流程

现在，将这些角色转化为代理。在你的框架内定义它们--给每个代理一个名字、它的工作以及它需要的任何工具或 API 访问权限。

就位后，将它们连接起来。使用框架提供的任何路由，从一个代理移动到下一个代理。

这样做的目的是让一个完整的工作流程从头到尾运行，让代理人员各司其职。

步骤 5：运行系统并检查每次切换

从头到尾触发整个工作流程，并跟踪所发生的一切。您应该观察每个代理接收到什么、返回什么，以及它们之间的流程是否顺畅。

如果代理收到混乱的输入，很可能是你的范围设置出了问题。如果逻辑出现意外跳转，则需要修复路由。 

一旦交接干净利落，你就拥有了一个有效的系统。

保持核心逻辑集中化

避免将关键决策分散到多个代理中。如果关键推理是在一个地方进行，而不是分散在连接松散的各个部分，那么维护和测试就会更容易。

预先定义代理输入和输出

每个代理都应该有一个定义明确的合同--它接收什么，返回什么。这样，代理就更容易更换或插入新的工作流程，而不会破坏流程逻辑。

记录代理之间传递的每一条信息

如果看不到代理之间在说什么，就无法进行任何调试。确保每个输入和输出都有足够的上下文记录，以便回溯整个流程。

使用范围内存，降低噪音和成本

只为每个代理提供所需的上下文。全内存访问会导致臃肿的提示、更高的令牌使用率，以及本应专注的代理出现不可预测的行为。

如何知道我的人工智能项目是否真的需要多代理框架，还是单个代理就足够了？

如果单个代理的提示或工作流程变得过长或难以调试，尤其是在处理多个不同任务时，您的人工智能项目就可能需要一个多代理框架，而基本问答或单一用途机器人等简单用例通常只需一个代理即可正常工作。

使用多代理框架是否只适用于大型企业项目，还是也适用于小型初创企业？

使用多代理框架构建项目不仅适用于大型企业，小型初创企业也能从中受益，因为如果将复杂的任务分拆给专门的代理，而不是将所有任务都堆在一个难以管理的大循环中，那么即使是规模不大的项目也能更容易地进行调试。

使用多代理系统是否意味着我必须把所有东西都分成不同的代理，还是说我可以混合使用单代理和多代理逻辑？ 

使用多代理系统并不意味着你必须把所有事情都分拆成不同的代理；你可以在简单任务中混合使用单代理逻辑，而在复杂工作流中保留多代理协调。

多代理系统与简单地在应用程序中使用多个应用程序接口或微服务有何不同？

多代理系统不同于使用多个应用程序接口或微服务，因为它能协调具有不同角色和推理能力的专门人工智能代理，传递结构化的信息和状态，而应用程序接口和微服务只能处理离散的功能，不能独立地协调复杂的工作流程。

运行多代理系统的成本与运行单个大型LLM 的成本相比如何？

运行多代理系统的成本可能低于运行单个大型LLM ，因为较小的、专业化的代理可以高效地处理特定任务，而不会在冗长的提示或重复的上下文上浪费令牌，但它也会为管理协调和代理间通信带来额外的开销，因此节省的成本取决于用例的复杂程度。