使用多智能体框架构建AI工作流

大多数开发者在尝试构建 AI 智能体时，通常从一个大型语言模型循环开始——一个系统提示，可能再加上一两个工具——对于小任务来说，这已经足够。

但一旦你需要更有结构的系统，问题就会出现。输出变得不可预测，工作流难以调试，你会因为重复而浪费大量 tokens，而不是推动进展。

多智能体工作流让你可以构建 AI 智能体，它们的行为更像一个有明确分工的团队，能够清晰了解决策过程，并朝着同一个目标努力。

什么是多智能体框架？

多智能体框架是你用来协调构建、运行和管理多个AI 智能体的基础设施。

它负责处理智能体之间的通信方式以及任务如何在它们之间流转。

如果你在使用多智能体系统，框架就是让它们能够正常运作的关键。

本质上，它将原始的大语言模型（LLM）转变为有明确角色和可预测操作方式的智能体。

你无需从零编写编排逻辑，框架为你提供结构、控制和可复用性。

多智能体框架：核心概念

多智能体框架如何工作？

多智能体框架为智能体的触发方式、数据传递方式以及系统如何跟踪进度提供了结构。

它们为协调智能体提供了构建模块，能够随着复杂度扩展，并支持实际部署。

一个例子是用多智能体架构驱动WhatsApp 聊天机器人。在这种情况下，不同的智能体可以分别处理预订、退款处理或身份验证等任务，在后台协同工作，而无需依赖单一的机器人。

智能体作为可调用组件注册到系统中

在智能体能够执行任何操作之前，框架需要知道它的存在。这意味着要告知系统智能体的名称、职责以及它可以访问的工具或信息。

在大多数框架中，这一设置通过配置文件或部分代码完成，你可以在其中定义每个智能体的角色以及如何激活它。例如，你可以告诉系统：

“这是规划者。它读取用户输入并决定下一步做什么。”
“这是验证者。它接收用户信息并返回 booking_id 和用户信息。”

注册后，框架可以通过名称“调用”这些智能体，也就是说它知道在工作流中轮到哪个智能体时如何运行它。

路由智能体决定下一个运行的智能体

规划者智能体或控制器函数负责AI 智能体路由。它会查看最新的机器人输出、当前的对话历史，有时还会参考原始用户输入，以决定接下来需要做什么。

有些规划者基于提示——它们接收系统消息并输出下一个要运行的智能体名称。

其他则根据你使用的AI 智能体框架，采用硬编码逻辑或流程图。

框架接收该输出，并用它来调用下一个智能体。路由器决定由谁来执行任务，而不是自己执行任务。

数据通过消息在智能体之间传递

智能体之间不会直接共享内存。当一个智能体运行结束时，它的输出会被打包成一条消息——通常是字典或 JSON 对象——并作为输入传递给下一个智能体。

框架负责传递过程。它要么将消息存储在共享内存空间，要么直接传递到下一个智能体的输入接口，具体取决于系统结构。

消息通常不仅包含内容：

• 发送者是谁（智能体或用户）
• 在工作流中的来源
• 如何使用（如触发、输入、决策）
• 可选指标，如 token 数量或时间戳

这些上下文信息有助于系统清晰地路由任务，并保持智能体之间的解耦。

通过工作流状态和触发器跟踪执行进度

框架会跟踪到目前为止发生的事情——哪些智能体已运行、它们返回了什么、还需要做什么。这些信息存储在状态对象中，每一步都会更新。

触发器决定接下来做什么。它们根据输出值或条件分支流程。

这样系统就能继续推进，而无需在每个智能体中硬编码逻辑。状态驱动工作流，而不是智能体本身。

使用多智能体框架的主要优势

扩展逻辑而不让单一智能体超负荷

单个 AI 智能体的能力有限，过度扩展会导致提示、工具和职责混乱。多智能体框架让你可以将逻辑拆分为专注的智能体，每个只处理一个明确的任务。

你无需让一个智能体承担所有任务，可以将检索、验证或执行等具体步骤分配给不同智能体，逐步扩展系统。

通过全程可见性调试智能体协作

当 AI 智能体协作时，问题往往难以追踪。框架会显示每个智能体收到什么、返回了什么、卡在了哪里。

你无需猜测哪里出错——可以直接检查交接环节并修复。这种可见性让 AI 智能体协作变得可控。

在不同工作流中复用智能体

如果某个智能体有效，就复用它。框架允许你将同一个智能体插入不同流程，无需重写代码。这样可以保持一致性，也加快测试速度。

例如，一个用于检查用户输入或身份验证的验证智能体，可以同时用于客服聊天机器人和预订聊天机器人，只要逻辑相同即可。

自动处理失败和重试

当智能体失败时，框架可以自动重试、跳过或继续。你无需自己编写这些逻辑。

内置的回退机制让工作流更可靠，无需额外工作，这种可靠性正是实际系统所需。

构建易于修改的智能体流程

当你将任务拆分到不同智能体时，每次需求变更都无需重构整个系统。

你可以只更新规划者而不影响执行，或者只更改某个智能体的响应方式，无需重写其他部分。

这种灵活性带来了回报——Salesforce 报告称，使用智能体 AI 的团队每位员工每周可节省 11 小时，部分得益于工作流的可适应性。

五大主流多智能体框架

选择多智能体框架取决于你的构建目标，以及你希望对智能体行为、通信和故障恢复有多大控制权。

最好的框架各有取舍——有的适合结构化工作流，有的则提供更多灵活性，但可能牺牲清晰度。

你需要选择最符合团队需求和系统发展规划的框架。

1. Botpress

Botpress 是一个可视化开发平台，用于构建能够跨步骤、角色和渠道协作的 AI 智能体。

你无需在代码中编写逻辑，而是通过流程、内存、条件和工具调用来定义智能体的行为。

多智能体行为围绕指令、工作流和外部工具构建。Botpress 流程中的每个节点都是一个专注的单元，拥有自己的指令和作用域。

你可以将推理分散到多个自主节点和静态节点，添加验证层，或通过基于工具的决策逻辑路由用户输入，而不是在一个步骤中处理所有内容。

内存限定在每个流程范围内，智能体只使用所需信息。输入和输出定义清晰，工具调用可通过内置集成直接添加。

主要功能

• 通过流程和节点实现可视化智能体编排
• 节点间的作用域内存和变量控制
• 多轮对话记忆、回退逻辑和重试机制
• 通过 API 调用、Webhook 和函数输入使用工具

2. LangChain

LangChain 是一个面向开发者的框架，通过将提示、工具和内存串联起来，构建由 LLM 驱动的应用。

它最初用于用搜索、计算器等工具结构化 LLM 调用，但逐渐扩展为庞大的生态系统。

有的版本主打“智能体”，有的主打“助手”，还有的主打“可运行对象”。最终形成了一个功能强大的工具包，几乎可以实现任何需求，但通常需要花时间熟悉。

你可以分配工具包并在智能体间构建路由逻辑。它的优势在于模块化——组件可复用、可混搭，并且与外部 API 集成良好。

但你可能需要编写比预期更多的粘合代码。随着抽象层快速变化，建议随时确认你用的方法是否仍为推荐方式。

主要功能

• 模块化串联提示、工具和内存
• 可与 LLM、向量存储和 API 集成
• 可选的 LangSmith 跟踪和评估功能

3. CrewAI

CrewAI 让你可以轻松构建多智能体工作流，每个智能体都有明确的角色和任务。你创建团队，分配目标，智能体通过共享管理者进行协调。

这是无需从零编写编排逻辑即可建模智能体协作的最快方式之一。

非常适合规划者-执行者组合、调研-审核流程或任何职责分工明确的团队任务。

但一旦你开始增加复杂度，抽象层就会变得紧凑。对于智能体的运行方式和时机灵活性较低，修改行为往往需要跳出框架默认设置。

主要功能

• 基于角色的智能体设置，包含名称、目标和内存
• 支持顺序和并行的智能体执行
• 团队共享内存，支持智能体协作
• 可轻松集成工具、函数和自定义提示

4. AutoGPT

AutoGPT 是第一个展示GPT 聊天机器人在设定目标后自主运行——规划、思考、调研和执行，无需持续人工输入的项目。

你只需定义目标，AutoGPT 就会循环推理步骤，创建子目标，调用工具，并在过程中调整策略。

它极大推动了智能体行为的自主性和动态性。但它并不以精确著称。

任务循环较为脆弱，智能体容易陷入反复重写同一计划或追逐无关子任务的困境。

你可以接入内存、工具和 API——但将所有内容拼接在一起，往往会导致流程不可预测，难以调试或引导。

主要功能

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

5. Autogen

Autogen 是微软推出的开源框架，专注于多智能体对话，智能体通过结构化、回合制消息进行交互。

当你需要对每一次交互都进行控制时（如规划-执行循环或人类参与系统），它尤其适用。

Autogen 的透明性表现突出。你可以在对话中注入函数，通过自定义逻辑路由决策，并精确追踪每个智能体说了什么以及原因。

但要实现扩展还需要付出努力。消息编排非常灵活，但并未完全抽象化——你仍然需要自己管理历史记录、智能体配置和步骤逻辑。

对于研究环境、受控测试或需要可复现代理行为的场景来说，这是目前最精确的框架之一。

主要功能

• 回合制多代理通信框架
• 支持人工参与和函数调用代理
• 透明的消息追踪与自定义逻辑注入

如何使用多智能体框架进行开发

最简单的入门方式是选择一个真实的工作流程——那种已经复杂到单一代理难以胜任的流程——并将其拆分为几个简单部分。

比如一个线索收集聊天机器人、预订流程，或任何逻辑、验证和操作交织在一起的场景。

为每个步骤分配一个代理，然后用框架的路由和消息工具将它们连接起来。

第1步：找出单代理逻辑失效的地方

在你的机器人或系统中寻找已经变得杂乱无章的地方——比如冗长的提示词或强行拼接的工具调用链。这就是你的切入点。以下是一些常见且容易发现的例子：

1. 一个退款流程，既要解析用户输入、检查资格、发起退款，还要发送确认信息——全部集中在一个循环里
2. 一个入职流程，既要收集数据、验证表单、分配用户类型，还要在一个提示链中触发邮件

你无需重构整个系统，只需把已经出现问题的工作流单独隔离出来。

第2步：在动手前先定义各自角色

找到混乱的逻辑后，将其拆解为实际的职责。

如果某部分负责验证输入，那就是一个代理。如果某部分负责外部操作，那就是另一个代理。

用通俗的语言写下来——只需足够清晰地标明各环节的交接点。

当所有内容都摆在你面前时，你会清楚哪些需要拆分，哪些可以合并。这也有助于你判断需要什么样的框架。

每个角色都应该是可以单独测试的。

第3步：选择合适的框架

选择一个适合你工作流风格的平台。

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

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

第4步：搭建第一个工作流

现在把这些角色转化为代理。在你的框架中定义它们——为每个代理命名、分配职责，并配置所需的工具或API访问权限。

代理就位后，将它们连接起来。利用框架提供的路由机制，让流程从一个代理顺畅流转到下一个。

目标是让一个完整的工作流从头到尾顺利运行，每个代理各司其职。

第5步：运行系统并检查每一次交接

触发完整的工作流——从头到尾——并追踪每一步。你需要观察每个代理收到什么、返回什么，以及流程是否顺畅地在它们之间切换。

如果某个代理收到混乱的输入，说明你的作用域划分有问题。如果逻辑出现意外跳转，说明路由需要调整。

一旦交接顺畅，你就拥有了一个可用的系统。

多智能体框架使用最佳实践

选择框架只是起点，更重要的是你如何设计、测试和管理基于该框架构建的工作流。

随着AI系统变得更加模块化和自主化，可追溯性也变得更难。

将核心逻辑集中管理

避免将关键决策分散到多个代理中。将核心推理集中在一个地方，更易于维护和测试，而不是分散在松散连接的各个部分。

提前定义代理的输入和输出

每个代理都应有明确的输入输出约定——接收什么、返回什么。这样可以方便地替换代理或将其接入新工作流，而不会破坏流程逻辑。

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

如果你无法看到代理之间的交流内容，就无法排查任何问题。确保每次输入和输出都被详细记录，便于回溯整个流程。

使用作用域内存以减少噪音和成本

只为每个代理提供所需的上下文。全局内存访问会导致提示词冗长、令牌消耗增加，以及本应专注的代理出现不可预测的行为。

开始构建能够协作的人工智能

大多数系统在需要真正协作时就会崩溃。Botpress让你可以控制代理之间的任务交接——通过明确的角色和逻辑，你可以进行测试和理解。

它还支持在不同流程间顺畅传递数据。你可以通过多轮日志追踪每一步，了解调用了哪个工具、为何运行、以及它在工作流中的具体用途。

你无需再专注于提示词调优和幻觉控制，而是关注真正的功能——打造像软件一样可靠的代理。

立即开始构建——永久免费。

常见问题

我怎么判断我的AI项目是否真的需要多代理框架，还是单一代理就够了？

如果你的单代理提示词或工作流已经变得冗长或难以调试，尤其是在处理多个不同任务时，你的AI项目很可能需要多代理框架；而对于简单的问答或单一用途机器人，通常只用一个代理就足够了。

用多代理框架开发只适合大型企业项目吗，小型初创公司也适用吗？

多代理框架不仅适用于大型企业，小型初创公司同样受益，因为即使是中小型项目，将复杂任务拆分到专门代理中，也能让调试更简单，避免所有逻辑堆积在一个难以维护的大循环里。

使用多代理系统是否意味着必须把所有内容都拆分成独立代理，还是可以混合使用单代理和多代理逻辑？

使用多代理系统并不意味着必须把所有内容都拆分成独立代理；你可以对简单任务采用单代理逻辑，而将复杂工作流交给多代理编排。

多代理系统与在应用中简单调用多个API或微服务有何不同？

多代理系统与调用多个API或微服务不同，它协调的是具备独立角色和推理能力的AI代理，这些代理之间传递结构化消息和状态；而API和微服务只处理单一功能，并不会自主编排复杂工作流。

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

运行多代理系统的成本可能低于单个大型LLM，因为小型、专用代理能高效处理特定任务，无需在冗长提示或重复上下文上浪费令牌，但多代理也会带来编排和代理间通信的额外开销，因此节省多少取决于你的用例复杂度。