为您的智能体 AI 系统选择设计模式

Last reviewed 2026-11-13 UTC

本文档提供了指导，可帮助您为智能体 AI 系统选择设计模式。智能体设计模式是构建智能体应用的常见架构方法。智能体设计模式提供了一个独特的框架，用于组织系统组件、集成模型以及编排单个智能体或多个智能体来完成工作流。

AI 智能体适用于解决开放式问题的应用，这些应用可能需要自主决策和复杂的多步骤工作流管理。智能体擅长利用外部数据实时解决问题，也擅长自动化知识密集型任务。当您需要 AI 以一定程度的自主性完成以目标为导向的任务时，AI 智能体非常适用。对于其他应用场景，您可以使用辅助和生成式 AI 应用。如需了解 AI 智能体与非智能体 AI 应用之间的区别，请参阅“AI 智能体、AI 助理和聊天机器人有什么区别？”。

本指南假定您已具备智能体 AI 系统的基础知识，并了解其架构与非智能体系统（例如使用直接模型推理或检索增强生成 [RAG] 的系统）有何不同。

定义您的要求

以下问题并非用于规划的详尽核对清单。从回答以下问题着手，确定智能体系统的主要目标，并选择最佳设计模式。

  • 任务特征：您的任务是否可以在预定义的工作流步骤中完成，还是开放式任务？您的任务是否需要使用 AI 模型来编排工作流？
  • 延迟时间和性能：您是否需要优先考虑快速或互动式回答，即使牺牲准确性或高质量回答？或者，您的应用是否可以容忍延迟以获得更准确或更全面的结果？
  • 费用：您的推理费用预算是多少？您能否支持需要针对单个请求多次调用模型的模式？
  • 人工参与：您的任务是否涉及需要人工判断的高风险决策、安全关键型操作或主观审批？

如果您的工作负载可预测或高度结构化，或者可以通过对 AI 模型的单次调用来执行，那么探索非智能体解决方案来完成任务可能会更具成本效益。例如，对于总结文档、翻译文本或对客户反馈进行分类等任务，您可能不需要智能体工作流。

以下部分介绍了常见的智能体设计模式，可用于构建可靠且高效的智能体 AI 系统。

单智能体系统

单智能体系统使用 AI 模型、一组定义的工具和全面的系统提示来自动处理用户请求或完成特定任务。在这种基本模式中，智能体依靠模型的推理能力来解读用户请求、规划一系列步骤，并从定义的集合中决定要使用的工具。系统提示通过定义智能体的核心任务、角色和操作，以及使用每种工具的具体条件，来塑造智能体的行为。

下图简要展示了单智能体模式：

单智能体设计模式的架构。

单代理系统非常适合需要多个步骤和访问外部数据的任务。例如，客户服务代理必须查询数据库才能找到订单状态，或者研究助理需要调用 API 才能总结近期新闻。非智能体系统无法执行这些任务，因为它无法自主使用工具或执行多步骤计划来合成最终答案。

如果您处于代理开发的早期阶段，我们建议您从单个代理开始。在开始使用单智能体系统开发智能体时，您可以专注于优化智能体的核心逻辑、提示和工具定义，然后再添加更复杂的架构组件。

当单个智能体使用更多工具且任务复杂度增加时，其性能可能会降低。您可能会观察到延迟时间增加、工具选择或使用不正确，或者无法完成任务。您通常可以通过推理和行动 (ReAct) 模式等技术来优化智能体的推理过程，从而缓解这些问题。但是，如果您的工作流需要一个智能体来管理多项不同的职责，这些方法可能还不够。对于这些情况，请考虑使用多智能体系统，该系统可以通过将特定技能委托给专业智能体来提高弹性和性能。

多智能体系统

多智能体系统会编排多个专业智能体，以解决单个智能体无法轻松管理的复杂问题。核心原则是将一个大目标分解为较小的子任务，并将每个子任务分配给具有特定技能的专用智能体。然后，这些智能体通过协作或分层工作流进行交互，以实现最终目标。与具有单体式提示的单个代理相比，多代理模式提供了一种模块化设计，可以提高整个系统的可伸缩性、可靠性和可维护性。

在多智能体系统中，每个智能体都需要特定的上下文才能有效执行其任务。上下文可以包括文档、历史偏好、相关链接、对话历史记录或任何操作限制。管理此信息流的过程称为上下文工程。上下文工程包括隔离特定代理的上下文、在多个步骤中保留信息或压缩大量数据以提高效率等策略。

AI 智能体带来了一些独特且关键的安全风险，传统的确定性安全实践可能无法充分缓解这些风险。使用 Agent Gateway 进行入站和出站流量路由和安全控制，使用 Agent Identity 进行工作负载绑定身份验证和最小权限访问权限控制，并使用 Agent Registry 帮助确保使用经过验证的工具和子智能体。

本部分中的指导并非详尽无遗。如需详细了解设计因素和最佳实践，以及有关构建和部署多智能体 AI 系统的建议，请参阅 Google Cloud中的多智能体 AI 系统。

顺序模式

多智能体依序模式会按照预定义的线性顺序执行一系列专用智能体，其中一个智能体的输出会作为下一个智能体的直接输入。

下图简要展示了多智能体依序模式：

多智能体顺序设计模式的架构。

对于操作顺序不会改变的高度结构化、可重复的流程，请使用顺序模式。例如，数据处理流水线可能会使用此模式，首先让数据提取智能体拉取原始数据，然后将该数据传递给数据清理智能体进行格式设置，后者再将清理后的数据传递给数据加载智能体，以将其保存在数据库中。

与使用 AI 模型编排任务工作流的模式相比，依序模式可以降低延迟时间和运营成本。不过，这种效率是以牺牲灵活性为代价的。流水线的刚性预定义结构使其难以适应动态条件或跳过不必要的步骤，这可能会导致处理效率低下，或者如果不需要的步骤很慢，则会导致更高的累积延迟。

并行模式

在多智能体并行模式（也称为并发模式）中，多个专业子智能体同时独立执行一项任务或多项子任务。然后，系统会综合子智能体的输出，生成最终的整合回答。此模式基于预定义逻辑运行，无需咨询 AI 模型进行编排。

下图简要展示了多智能体并行模式：

多智能体并行设计模式的架构。

当子任务可以并发执行时，请使用并行模式，以缩短延迟时间或收集不同的观点，例如从不同来源收集数据或同时评估多个选项。例如，为了分析客户反馈，并行智能体可能会同时将单个反馈条目分发给四个专用智能体：情感分析智能体、关键词提取智能体、分类智能体和紧急程度检测智能体。最后一个智能体将这四个输出汇总到对该反馈的单个综合分析中。

与顺序方法相比，并行模式可以减少总体延迟时间，因为它可以同时从多个来源收集各种信息。不过，这种方法在成本和复杂性方面存在一些权衡。 并行运行多个智能体可能会增加即时资源利用率和 token 消耗，从而导致运营成本增加。此外，收集步骤需要复杂的逻辑来合成可能存在冲突的结果，这增加了系统的开发和维护开销。

循环模式

多智能体循环智能体模式会重复执行预定义的专业子智能体序列，直到满足特定终止条件。所有子代理完成任务后，循环代理会评估是否满足退出条件。该条件可以是迭代次数上限或自定义状态。如果未满足退出条件，循环代理会再次启动子代理序列。您可以实现一种循环模式，其中退出条件在流中的任何位置进行评估。对于需要迭代优化或自我纠正的任务，请使用循环模式，例如生成内容并让批评者代理对其进行审核，直到达到质量标准。

下图简要展示了多智能体循环模式：

多智能体循环设计模式的架构。

循环智能体模式提供了一种构建复杂迭代工作流的方法。它使智能体能够优化自己的工作并继续处理，直到达到特定的质量或状态。不过，此模式的主要缺点是存在无限循环的风险。如果终止条件定义不正确，或者子智能体未能生成停止所需的状态，则循环可能会无限期运行。这可能会导致运营成本过高、资源消耗过高以及潜在的系统挂起。

审阅和评判模式

多智能体审核和评判模式（也称为生成器和评判器模式）通过使用两个专用智能体（通常在依序工作流中）来提高生成内容的质量和可靠性。审核和批评模式是循环智能体模式的一种实现。

在审核和评论模式中，生成器智能体会创建初始输出，例如代码块或文档摘要。接下来，评估者智能体会根据一组预定义的标准（例如事实准确性、是否遵守格式规则或安全准则）评估此输出。根据评估结果，评判器可以批准内容、拒绝内容，或将内容退回给生成器并提供修改反馈。

下图简要展示了多智能体审核和批评模式：

多智能体审核-批评设计模式的架构。

此模式适用于以下任务：在向用户呈现输出或在下游流程中使用输出之前，输出必须高度准确或必须符合严格的限制。例如，在代码生成工作流中，生成器代理可能会编写一个函数来满足用户的请求。然后，此生成的代码会传递给充当安全审核员的批评者智能体。批评者智能体的职责是根据一组约束条件检查代码，例如扫描安全漏洞或验证代码是否通过了所有单元测试，然后才能批准使用该代码。

审核和批评模式可以提高输出质量、准确性和可靠性，因为它添加了专门的验证步骤。不过，这种质量保证会直接导致延迟时间和运营费用增加。该工作流至少需要一次额外的模型调用，以便进行批评者评估。如果流程中包含修订循环（即内容被发回进行优化），则每次迭代都会增加延迟时间和费用。

迭代优化模式

迭代优化模式使用循环机制，通过多个周期逐步改进输出。迭代优化模式是循环智能体模式的一种实现。

在此模式中，一个或多个代理在循环中工作，以修改每次迭代期间存储在会话状态中的结果。此过程会持续进行，直到输出达到预定义的质量阈值或达到最大迭代次数（以防止无限循环）。

下图简要展示了多智能体迭代优化模式：

多智能体迭代优化设计模式的架构。

此模式适用于复杂的生成任务，这些任务的输出很难通过一个步骤完成。此类任务的示例包括编写和调试一段代码、制定详细的多部分计划，或起草和修改长篇文档。例如，在创意写作工作流中，智能体可能会生成博文草稿，对草稿的流畅度和语气进行评判，然后根据该评判重写草稿。此过程会循环重复，直到智能体的输出符合预定义的质量标准，或达到最大迭代次数。

迭代优化模式可以生成高度复杂或精细的输出，而这些输出很难通过单一步骤实现。不过，循环机制会直接增加每个周期的延迟时间和运营成本。此模式还会增加架构复杂性，因为它需要精心设计的退出条件（例如质量评估或最大迭代限制），以防止费用过高或执行不受控制。

协调器模式

多智能体协调器模式使用一个中央智能体（即协调器）来指导工作流。协调器会分析用户的请求，并将其分解为子任务，然后将每个子任务分派给专门的智能体执行。每个专用智能体都是特定功能（例如查询数据库或调用 API）方面的专家。

协调器模式的一个特点是，它使用 AI 模型来编排和动态路由任务。相比之下，并行模式依赖于硬编码工作流来分派任务以同时执行，而无需 AI 模型编排。

下图简要展示了多智能体协调器模式：

多智能体协调器设计模式的架构。

使用协调器模式自动执行需要自适应路由的结构化业务流程。例如，客服人员可以充当协调者。协调器代理会分析请求，以确定它是订单状态请求、商品退货还是退款请求。根据请求类型，协调器会将任务路由到适当的专业智能体。

与更严格、预定义的工作流相比，协调器模式提供了灵活性。通过使用模型来路由任务，协调器可以处理更多种类的输入，并在运行时调整工作流。不过，这种方法也需要做出权衡。由于协调器和每个专用智能体都依赖模型进行推理，因此这种模式会比单智能体系统产生更多的模型调用。虽然协调器模式可以提高推理质量，但与单智能体系统相比，它也会增加词元吞吐量、运营成本和总体延迟时间。

层级任务分解模式

多智能体分层任务分解模式将智能体组织成多级层次结构，以解决需要大量规划的复杂问题。分层任务分解模式是协调器模式的一种实现。顶级父级（或根）智能体会收到一项复杂的任务，并负责将该任务分解为多个更小、更易于管理的子任务。根智能体将每个子任务委托给较低级别的专业子智能体。此过程可以重复多个层级，智能体逐步分解其分配的任务，直到这些任务可以由最低层级的工作器智能体直接执行。

下图简要展示了多智能体分层任务分解模式：

多智能体层级任务分解设计模式的架构。

对于需要多步推理的模糊、开放式问题，例如涉及研究、规划和综合的任务，请使用分层任务分解模式。例如，为了完成一个复杂的研究项目，协调器智能体会将高级目标分解为多个任务，例如收集信息、分析发现结果和合成最终报告。然后，协调器智能体会将这些任务委托给专门的子智能体（例如数据收集智能体、分析智能体和报告撰写智能体）来执行或进一步分解。

层级任务分解模式非常适合解决高度复杂和模糊的问题，因为它能将这些问题系统地分解为可管理的子任务。与更简单的模式相比，此模式可以产生更全面、更高质量的结果。不过，这种高级功能也带来了重大权衡。多级结构会增加架构的复杂性，从而使系统更难设计、调试和维护。多层委托和推理还会导致大量模型调用，与其他模式相比，这会显著增加总体延迟时间和运营成本。

蜂群模式

多智能体集群模式采用协作式全对全通信方法。在此模式中，多个专业智能体协同工作，以迭代方式优化复杂问题的解决方案。

下图简要展示了多智能体集群模式：

多智能体集群设计模式的架构。

群集模式使用调度器智能体将用户请求路由到由专业智能体组成的协作群组。调度器智能体解读请求，并确定集群中的哪个智能体最适合开始执行任务。在此模式中，每个智能体都可以与其他所有智能体通信，从而分享发现、批评提案，并基于彼此的工作成果迭代优化解决方案。集群中的任何智能体都可以将任务移交给它认为更适合处理下一步的另一个智能体，也可以通过协调器智能体将最终回答传达给用户。

集群通常缺乏中央监督者或协调者智能体来确保流程按计划进行。与协调器模式不同，调度器智能体不会编排智能体工作流。相反，调度器智能体负责促进集群子智能体与用户之间的通信。为确保群集最终停止并返回结果，您必须定义明确的退出条件。此条件通常是迭代次数上限、时间限制或实现特定目标（例如达成共识）。

对于需要通过辩论和迭代优化来解决的模糊或高度复杂的问题，请使用群集模式。例如，设计新产品可能需要市场研究员智能体、工程智能体和财务建模智能体。这些智能体会分享初步想法，讨论功能与成本之间的权衡，并最终共同确定一个平衡所有竞争需求的最终设计规范。

群集模式模拟了一个协作专家团队，因此可以产生极高质量和创造性的解决方案。不过，这也是最复杂、实现成本最高的多智能体模式。如果缺少使用 AI 模型进行编排的智能体，可能会导致出现无效循环或无法收敛到解决方案的风险。因此，您必须设计复杂的逻辑来管理错综复杂的智能体间通信、控制迭代工作流，并处理与在多个智能体之间运行动态多轮对话相关的重大运营成本和延迟。

推理和行动 (ReAct) 模式

ReAct 模式是一种使用 AI 模型将其思考过程和操作构建为一系列自然语言互动的方法。在此模式中，智能体在思考、行动和观察的迭代循环中运行，直到满足退出条件。

  • 思考：模型对任务进行推理，并决定下一步该做什么。模型会评估其收集的所有信息，以确定用户的请求是否已得到完整回答。
  • 操作：根据其思考过程，模型会执行以下两项操作之一：
    • 如果任务未完成，它会选择一个工具，然后形成一个查询来收集更多信息。
    • 如果任务已完成，它会制定最终答案发送给用户，从而结束循环。
  • 观察：模型接收来自工具的输出，并将相关信息保存在其记忆中。由于模型会保存相关输出，因此它可以基于之前的观察结果进行构建，这有助于防止模型重复自身或丢失上下文。

当智能体找到最终答案、达到预设的最大迭代次数或遇到导致其无法继续的错误时，迭代循环就会终止。 通过这一迭代循环，智能体可以动态制定计划、收集证据并调整方法，从而逐步得出最终答案。

下图简要展示了 ReAct 模式：

ReAct 设计模式的架构。

对于需要持续规划和调整的复杂动态任务，请使用 ReAct 模式。例如，假设有一个机器人智能体，它必须生成一条从初始状态过渡到目标状态的路径：

  • 思考：模型会推理从当前状态过渡到目标状态的最佳路径。在思考过程中，模型会针对时间或能量等指标进行优化。
  • 操作：模型通过沿计算出的路径段移动来执行其计划中的下一步。
  • 观察：模型观察并保存环境的新状态。模型会保存其新位置以及它感知到的环境变化。

通过此循环，智能体可以根据新的观察结果不断更新其计划，从而遵守动态约束条件，例如避开新的障碍物或遵守交通法规。智能体会继续执行迭代循环，直到实现目标或遇到错误。

与复杂的多智能体系统相比，单个 ReAct 智能体可能更简单，实现和维护成本更低。 模型思考会提供模型推理的转写，这有助于调试。不过，这种灵活性也带来了一些取舍。与单次查询相比，该循环的迭代式多步骤特性可能会导致更高的端到端延迟。此外，智能体的有效性在很大程度上取决于 AI 模型的推理质量。因此，如果某个工具在某个观察步骤中出现错误或产生误导性结果，该错误或结果可能会传播并导致最终答案不正确。

人机协同 (human-in-the-loop) 模式

人机协同模式将人工干预点直接集成到智能体的工作流中。在预定义的检查点，智能体会暂停执行并调用外部系统，以等待人工审核其工作。此模式允许用户在智能体继续操作之前批准决策、更正错误或提供必要的输入。

下图简要展示了人机协同模式：

多智能体人机协同设计模式的架构。

对于需要人工监督、主观判断或对关键操作进行最终审批的任务，请使用人机协同 (human-in-the-loop) 模式。此类操作包括批准大额金融交易、验证敏感文档的摘要，或对生成的创意内容提供主观反馈。例如，智能体可能需要对患者数据集进行匿名化处理，以用于研究。智能体会自动识别并隐去所有受保护健康信息，但在最终检查点会暂停。然后，它会等待人工合规官员手动验证数据集并批准其发布，这有助于确保不会泄露任何敏感数据。

人机协同 (human-in-the-loop) 模式通过在工作流中的关键决策点引入人工判断，提高了安全性和可靠性。此模式可能会显著增加架构复杂性，因为它要求您构建和维护用于用户互动的外部系统。

使用 ADK 进行多智能体编排

ADK 是一个开源框架，用于开发和编排单智能体和多智能体系统。为了实现本文档中介绍的设计模式，ADK 允许您将智能体、工具和确定性代码函数组合成结构化的Agentic Workflows。

ADK 支持使用以下工作流类型进行智能体编排：

  • 基于图的工作流：将应用逻辑定义为执行节点和边的声明式图。通过这种方法，您可以构建灵活的执行路径，在 AI 智能体、工具、确定性代码函数和嵌套工作流之间编排和路由数据。
  • 动态工作流：使用标准编程结构（例如 if 和 else 语句、while 和 for 循环以及并发任务执行）以命令式方式定义工作流逻辑。动态工作流可让您在节点调用之间直接传递类型化输出，而 ADK 会自动跟踪和检查每个子节点的执行情况。
  • 协作协调工作流：将工作流逻辑定义为多智能体团队，这些智能体可以相互沟通和协作来解决问题。在这种方法中，协调器智能体使用 AI 模型来解读请求、分解问题，并动态地将子任务委托给专门的子智能体。ADK 会为每个声明的子代理自动生成委派工具，以便协调器在运行时路由任务。

后续步骤

贡献者

作者：Samantha He | 技术文档工程师

其他贡献者：