如何搭建高效AI应用？从单智能体到多智能体

想要构建一个智能体应用，最重要的是什么？可能很多人首先会想到要选择一个性能强大的大模型。这个回答没错，毕竟当前的LLM Based Agent哪能缺少LLM的支撑。但事实却是，很多基于先进大模型构建的智能体没能体现出应用效果，反而一些使用性能一般大模型的智能体表现更加亮眼。这是什么原因呢？答案在于，大模型本身的能力并不能决定智能体性能与应用效果。基于性能不是那么强大的模型所构建的智能体，在与之契合的应用环境中发挥了更好的效果。在企业充斥大量复杂流程的生产环境中构建智能体，往往需要考虑所构建的智能体如何与企业系统协同应用，需要考虑智能体如何更好地融入到企业原有的生产环境中。因此，智能体的架构类型、集成能力以及系统整体的设计决定了智能体的应用表现。最近看到一篇名为《A practical guide to the architectures of agentic applications》的文章，很好的阐述了这一点。文章认为，在构建智能体应用时，选择强大的AI模型并非最重要的决定，架构设计、集成和系统整体设计才是成功的关键。糟糕的架构会导致预算浪费、技术债务和性能不佳。这篇文章详细探讨了单智能体和多智能体两种核心架构模型，并深入分析了工作流设计、自主性、协调性等要素，提供了常见的设计模式、实际案例以及一个决策框架，帮助开发者根据具体用例选择合适的架构方法。

很多人以为，构建AI产品最重要的是在GPT-4、Claude等商业模型或者开源模型之间做出选择，其实这是一个误区。更多成功案例和失败案例告诉我们，大模型的能力并不能决定真正应用于生成环境的智能体应用。

即便这些智能体应用基于最先进的大模型，如果架构、集成和整体系统设计没能针对现实应用环境的复杂性进行设计与构建，一般也不会有多好的表现。

一个架构薄弱的强大AI模型，可能会耗尽预算、浪费GPU时间和造成技术债务，甚至其性能还不如一个基于坚实架构基础构建的能力较弱的模型。

所以想要构建一个高效可用的智能体应用，不但要了解智能体应用的常见架构类型，还要了解他们的架构与设计模式。

这篇文章，将揭秘智能体应用的两大核心架构类型单智能体和多智能体，介绍如何考量工作流设计、自主性与协调性。也将提及构建两种智能体应用的9种常用设计模式、实际案例和决策框架，帮助大家具体应用时选择合适的方法。

明确系统需完成的任务

在选择智能体应用的架构及模式之前，首先需要定义系统需要支持的端到端工作流。无论采用什么样的实现方式，系统从接收初始输入到产生最终输出，必须完成哪些步骤？工作流是简短线性的，还是步骤繁多？某些步骤能否并行运行，或者阶段间存在严格的依赖关系？流程是否涉及多个角色、服务或数据类型？整个过程是否需要协调、重试或适应能力？

系统的工作流决定智能体采用的架构，可以帮助大家判断单智能体设置是否足够，抑或需要分布式的多智能体设计来实现目标。

单智能体架构Single-agent architectures

单智能体架构依赖一个智能体从头至尾处理整个工作流，因此非常适合简单、线性且需极少协调的工作流。该智能体负责推理（评估输入并决定行动）、规划（将目标分解为步骤）、执行（调用函数或API）以及与工具交互（运用模型之外的功能，如数据库或搜索）。

单智能体流程高层示意图

通过精心设计，单智能体架构在适当条件下也能管理更复杂的工作流。例如，透明、开源的SWE-agent通过单一控制循环，自主使用工具来修复GitHub仓库中的问题、检测安全漏洞并执行其他由脚本定义的工作流，无需任务委托或并行处理。

下面我们来看看单智能体架构中的一些常见模式，以及即使基础工作流如何因正确的结构选择而受益。

 单智能体模式The single-agent pattern

其最简形式为：单智能体系统响应触发器，处理任务，并返回输出。不涉及记忆、规划或外部交互，仅包含：输入、推理和响应。此模式适用于简单自动化或原型验证，并有助于在构建智能体应用时检验工作流和想法。

开源自动化智能体bumpgen是单智能体架构的一个实例，它展示了即使是基础自动化任务也能从精心设计的架构中获益。该智能体监控项目中的新软件包发布，获取最新版本信息，并创建自动化拉取请求以完成更新。工作流直截了当：检测、获取、更新。无需协调或并行处理，单个智能体即可独立处理全流程。

 记忆增强智能体模式The memory-augmented agent pattern

当系统需要记住过往上下文（如先前的用户交互、历史数据或外部状态）以做出更佳决策时，此模式很有用。例如，假设您正在构建一个自动提醒系统，用于向用户发送个性化提示。

一个基于cron的触发器每日运行，智能体从向量记忆库中查询过往消息或操作，并利用该上下文生成个性化的提醒。这种设置使得智能体能够基于对过去事件的认知进行响应。

 工具使用智能体模式The tool-using agent pattern

假设您正在构建一个处理发票请求的客户支持智能体。当用户提交支持工单时，智能体需获取账单数据、进行格式化并返回摘要——这些步骤它无法独自完成。它会调用计费API（Billing API）、处理响应并自动完成任务。

您不会希望通过硬编码每个API交互的方式，来确保此过程在智能体内可靠运行。相反，您可以引入一个MCP（模型上下文协议）层——MCP是一种用于标准化访问外部工具和服务的协议。MCP层代表了工具接口层，所有外部交互（主要是API）在此抽象和维护。如此一来，核心逻辑保留在智能体内部，而繁重的工作则委托给工具处理。

 规划智能体模式The planning-agent pattern

规划智能体基于初始输入生成一个多步骤计划，按顺序执行每个步骤，并通过理解任务依赖关系和跟踪执行状态来灵活调整。

规划智能体模式的一个典型用例是SaaS产品的AI入职助手：用户注册后，系统必须安排欢迎邮件、设置产品引导、三天后跟进检查，若一周后仍无互动则转接人工支持。这些步骤并非自动完成，而是需要按正确顺序进行规划和执行。

规划智能体模式适用于无法一步完成、且需要一系列协调操作的任务。

 反思智能体模式The reflection-agent pattern

反思智能体模式适用于那些除了执行，还需要随时间推移不断改进的任务。在完成某项操作后，反思智能体会存储结果，将其与目标或指标进行比对，并据此更新策略。随着时间的推移，这种反馈循环能使智能体愈发高效，即便没有人工干预。

假设您构建了一个基于市场信号执行每日交易的交易助手。在每个交易日结束时，智能体会评估哪些交易表现良好、哪些不佳，以及未来如何调整策略。

当您的系统需要从既往结果中学习以提升未来性能时，此模式尤为有用。

多智能体架构Multi-agent architectures

现实生成环境的工作流程往往比较复杂。一旦你构建了最小可行产品（MVP）或用单智能体架构验证了流程，很可能需要进一步扩展，以增加更多推理、并行性、精确性或专业化。这时，多智能体架构就派上了用场。

在多智能体架构中，多个智能体协作完成一个复杂的工作流程。每个智能体承担特定的职责：规划、检索、分析或执行，并与其他智能体沟通以推动流程前进。

微软的开源项目TaskWeaver遵循多智能体模式：目标被分解为子任务——例如检索文档、总结文档和起草输出——并分配给各个智能体。一个中央协调器管理智能体间的协作与结果传递。这种设置很常见：大多数有效的多智能体系统都包含一个协调智能体，负责监督任务委派。无论它被称为主导智能体、监督者还是管理者，这个智能体都确保工作流程保持有序。

在多智能体设置中，每个智能体通常被设计为一个单智能体系统，拥有自己的记忆、工具和决策逻辑。例如，在一个AI交易系统中，你可能拥有负责以下任务的独立智能体：

• 获取实时市场数据。
• 执行技术和情感分析。
• 反思过去表现以调整策略。
• 通过经纪商API执行交易。
• 在多智能体架构中，焦点从每个智能体做什么转移到它们如何协作。
•  监督者模式The supervisor pattern
• 监督者模式是较常用的多智能体架构之一，其核心理念很简单：一个智能体担任主导。监督者智能体接收触发指令，将任务分解为子任务，并将每个子任务委托给专用智能体，然后确保智能体以正确的顺序、在正确的上下文中运行，并且输出能够正确回流。

这种架构的一个实际应用可能是医院的专家预约系统。当患者发起请求时，监督者智能体控制整个工作流程：

首先，它通过调度器智能体检查可用性。

接着，它通过记录智能体检索患者的医疗记录。

然后，它将记录发送给总结器智能体，以生成简洁的概述。

最后，它将最终摘要转发给负责通知专家的邮件智能体。

医院专家预约系统的监督者模式示意图

 层级模式The hierarchical pattern

作为监督者模式的扩展，当任务过于复杂或范围过广，无法由单个监督者管理时，会使用层级模式。它引入了协调层：一个顶层智能体处理高层目标，并将其部分委托给中层智能体，中层智能体进一步分解工作并将任务分配给低层智能体。这种方法在职责必须跨专门团队或领域划分的系统中很有用。

例如，在企业文档处理系统中，一个顶层智能体可能监督整个流程，将总结任务委托给一个中层智能体，将数据提取委托给另一个中层智能体，每个中层智能体管理自己的工作组。

层级模式示意图

 竞争模式The competitive pattern

竞争模式涉及多个智能体独立处理同一问题，每个智能体提出自己的解决方案。一个单独的评估器智能体审查所有提交的方案，并根据预定义的标准（如速度、准确性、创造性和成本效益）选择最合适的方案。

当思想的多样性或冗余机制可以带来更好的结果时，这种方法很有用。它还增加了鲁棒性：如果一个智能体失败或表现不佳，其他智能体可能仍然成功。

竞争模式的一个典型用例是生成营销文案：多个智能体生成不同的标题或内容片段，评估器根据A/B测试标准选择最符合品牌指南的方案。

 网络模式The network pattern

网络模式不存在主导智能体。每个智能体都有自己的工具，并直接与其他智能体通信以协调任务。像OpenAI Agents和Crew AI这样的框架就是围绕这种模型设计的。

虽然网络模式提供了灵活性，但在实际应用中往往不切实际。没有清晰的流程，智能体之间的通信是非结构化的，使得系统难以调试、不可靠且运行成本高。每个步骤都可能触发额外的大语言模型（LLM）调用，增加延迟。由于这些原因，网络模式通常不适合生产使用，除非你特别需要去中心化设置，例如在研究或模拟环境中。

网络模式示意图

后记：几个建议提升智能体应用效果

理解了构建智能体系统的机构类型和模式，下一步就是选择适合你生产环境的构建方案。为了让你的智能体应用表现的更好，这里有几个建议：

1、如果应用程序采用多智能体架构，可以考虑加入一个反思智能体。虽然多智能体系统受益于提高的精确性、推理能力、并行性和任务专业化，但添加反思智能体引入了一个反馈循环，使系统能够随着时间的推移学习和改进。这是利用AI自适应潜力的最有效方法之一。

2、如果你正在构建一个简单的MVP或原型，可以从工具调用型智能体入手。这类智能体适用性强、实现快速，并且已经支持记忆和工具。添加一个模型上下文协议（MCP）层用于外部API访问，就可以快速推进。

3、如果你的应用程序需要多智能体设置，监督者模式通常是最好的起点。其他多智能体模式（如网络、层级和竞争）可能有用，但仅适用于特定场景：

• 当你希望多个智能体提出不同解决方案并比较结果时，选择竞争模式。
• 当任务复杂且需要在子监督者下跨工作组划分时，选择层级模式。
• 下面这个参考表格，帮助帮助大家快速选择合理的的架构。