Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

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

Last reviewed 2026-05-28 UTC

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

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

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

如需查看代理模式指南的摘要，请参阅本文档后面的比较设计模式部分。

设计过程概览

以下是为智能体 AI 系统选择设计模式的高级步骤。本文档后面部分详细介绍了这些步骤。

确定您的需求：评估工作负载的特征，包括任务复杂性、延迟和性能预期、费用预算以及是否需要人工参与。
查看常见的智能体设计模式：在本指南中了解常见的设计模式，包括单智能体系统和多智能体系统。
选择模式：根据工作负载特征选择合适的设计模式。

此过程并非一次性决定。您应定期重新审视这些步骤，以便在工作负载特征发生变化、要求不断演变或有新的 Google Cloud 功能可用时，优化您的架构。

定义您的要求

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

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

如果您的工作负载是可预测的或高度结构化的，或者可以通过对 AI 模型进行单次调用来执行，那么探索非智能体解决方案来完成任务可能更具成本效益。例如，对于汇总文档、翻译文本或对客户反馈进行分类等任务，您可能不需要智能体工作流。如需了解如何为不需要智能体基础设施的生成式 AI 应用选择架构组件，请参阅为您的生成式 AI 应用选择模型和基础设施。

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

单智能体系统

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

下图高度概括地显示了单代理模式：

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

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

如果您刚开始开发代理，建议您从单个代理开始。当您从单智能体系统开始开发智能体时，可以先专注于完善智能体的核心逻辑、提示和工具定义，然后再添加更复杂的架构组件。

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

多智能体系统

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

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

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

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

顺序模式

多智能体依序模式会按照预定义的线性顺序执行一系列专用智能体，其中一个智能体的输出会作为下一个智能体的直接输入。此模式使用顺序工作流代理，该代理根据预定义的逻辑运行，无需咨询 AI 模型来编排其子代理。

下图高度概括地展示了多代理顺序模式：

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

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

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

并行模式

多智能体并行模式也称为并发模式，是指多个专业子智能体同时独立执行一项任务或多项子任务。然后，系统会综合子智能体的输出，生成最终的整合回答。与顺序模式类似，并行模式使用并行工作流智能体来管理其他智能体的运行方式和时间，而无需咨询 AI 模型来编排其子智能体。

下图高度概括地展示了多代理并行模式：

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

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

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

循环模式

多智能体循环智能体模式会重复执行一系列专用子智能体，直到满足特定终止条件。此模式使用循环工作流代理，与其他工作流代理一样，它基于预定义的逻辑运行，而无需咨询 AI 模型进行编排。在所有子智能体完成任务后，循环智能体会评估是否满足退出条件。该条件可以是迭代次数上限或自定义状态。如果未满足退出条件，则循环智能体会再次启动子智能体序列。您可以实现一个循环模式，其中在流中的任何点评估退出条件。对于需要迭代优化或自我修正的任务，请使用循环模式，例如生成内容并让评论家代理检查该内容，直到其达到质量标准。

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

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

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

审阅和评判模式

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

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

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

多智能体评论-批判设计模式的架构。

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

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

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

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

下图高度概括地展示了多代理迭代优化模式：

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

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

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

协作者模式

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

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

下图高度概括地展示了多智能体协调器模式：

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

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

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

分层任务分解模式

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

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

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

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

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

蜂群模式

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

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

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

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

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

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

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

推理与行动 (ReAct) 模式

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

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

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

下图简要展示了 ReAct 模式：

ReAct 设计模式的架构。

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

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

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

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

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

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

下图高度概括地展示了人工在环模式：

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

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

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

自定义逻辑模式

自定义逻辑模式在工作流设计中提供了最大的灵活性。此方法可让您使用代码（例如条件语句）实现特定的编排逻辑，以创建具有多个分支路径的复杂工作流。

下图展示了使用自定义逻辑模式捕获退款流程的示例：

多智能体自定义设计模式的架构。

在上图中，以下是示例客户退款智能体的工作流：

用户向充当协调器智能体的客户退款智能体发送查询。
协调器的自定义逻辑首先会调用并行验证器代理，该代理会同时调度两个子代理：购买者验证器代理和退款资格代理。
收集结果后，协调器代理会执行一个工具，检查请求是否符合退款条件。
1. 如果用户符合条件，协调器会将任务路由到退款处理方智能体，后者会调用 process_refund 工具。
2. 如果用户不符合条件，协调器会将任务路由到单独的顺序流程，从商店抵用金代理和处理抵用金决策代理开始。
无论采用哪条路径，结果都会发送到最终回答代理，以便为用户编制回答。

客户退款代理示例需要一种独特的解决方案来实现其逻辑级编排，这超出了其他模式提供的结构化方法。此工作流混合了多种模式，因为它会运行并行检查，然后执行自定义条件分支，该分支会路由到两个完全不同的下游流程。这种复杂的混合模式工作流是自定义逻辑模式的理想应用场景。

如果您需要对智能体的执行进行精细控制，或者您的工作流不适合本文档中介绍的其他模式，请使用自定义逻辑模式。但是，这种方法会增加开发和维护的复杂性。您需要负责设计、实现和调试整个编排流程，这需要更多开发工作，并且与使用智能体开发套件 (ADK) 等工具支持的预定义模式相比，更容易出错。

如需了解自定义代理以及如何使用 ADK 实现自定义逻辑，请参阅自定义代理。