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

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

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

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

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

设计过程概览

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

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

此过程并非一次性决定。随着工作负载特征的变化、要求的演变或新 Google Cloud 功能的推出，您应定期重新审视这些步骤，以优化架构。

定义您的要求

以下问题不是用于规划的详尽核对清单。您可以先回答以下问题，确定智能体系统的主要目标，然后选择最合适的设计模式。

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

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

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

单智能体系统

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

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

单代理设计模式的架构。

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

如果您刚开始开发代理，建议您先从单个代理入手。如果您从单智能体系统开始开发智能体，则可以在添加更复杂的架构组件之前，专注于优化智能体的核心逻辑、提示和工具定义。

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

多代理系统

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

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

与单智能体系统相比，构建多智能体系统需要额外考虑评估、安全性、可靠性和成本。例如，多代理系统必须为每个专业代理实现精确的访问控制，设计强大的编排系统以确保可靠的代理间通信，并管理因运行多个代理而产生的计算开销所带来的运营成本增加。如需查看用于构建多代理系统的参考架构示例，请参阅 Google Cloud中的多代理 AI 系统。

顺序模式

多智能体顺序模式以预定义的线性顺序执行一系列专业化智能体，其中一个智能体的输出直接作为下一个智能体的输入。此模式使用一个顺序工作流代理，该代理按照预定义的逻辑运行，无需咨询 AI 模型即可协调其子代理。

下图展示了多代理顺序模式的概要视图：

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

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

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

平行模式

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

下图展示了多代理并行模式的概要视图：

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

当子任务可以并发执行以减少延迟或收集不同的视角时，请使用并行模式，例如从不同的来源收集数据或同时评估多个选项。例如，为了分析客户反馈，并行智能体可能会同时将单个反馈条目分发给四个专业智能体：情感分析智能体、关键字提取智能体、分类智能体和紧急程度检测智能体。最终代理会将这四种输出内容整合为对相应反馈的全面分析。

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

循环模式

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

下图展示了多代理循环模式的概要视图：

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

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

查看和评判模式

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

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

下图展示了多代理审核和评判模式的简要视图：

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

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

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

迭代优化模式

迭代优化模式使用循环机制在多个周期内逐步改进输出。迭代细化模式是循环代理模式的一种实现。

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

下图展示了多代理迭代细化模式的高度概括视图：

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

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

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

协调器模式

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

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

下图展示了多代理协调器模式的高度概括视图：

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

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

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

分层任务分解模式

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

下图展示了多代理分层任务分解模式的高度概括视图：

多代理分层任务分解设计模式的架构。

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

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

集群模式

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

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

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

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

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

对于模棱两可或高度复杂的问题，可使用集群模式，因为这类问题可通过辩论和迭代改进来解决。例如，设计新产品可能需要市场研究智能体、工程智能体和财务建模智能体。代理会分享初步想法，讨论功能和成本之间的权衡，并共同确定最终设计规范，以平衡所有相互冲突的要求。

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

推理和行动 (ReAct) 模式

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

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

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

下图简要展示了 ReAct 模式：

ReAct 设计模式的架构。

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

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

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

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

人机协同模式

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

下图简要展示了人工在环模式：

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

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

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

自定义逻辑模式

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

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

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

在上图中，示例客户退款代理的代理工作流程如下：

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

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

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

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

比较设计模式

选择代理模式是一项基础性的架构决策。每种模式在灵活性、复杂性和性能方面都有不同的权衡取舍。如需确定适合您工作负载的模式，请考虑以下部分中的设计模式。

确定性 Workflows

确定性工作流包含可预测的顺序任务，并且从开始到结束具有明确定义的工作流路径。任务中的步骤是预先已知的，并且流程在每次运行之间不会发生太大变化。以下是确定性工作流的代理设计模式：

工作负载特性 代理设计模式
  • 遵循预定义、严格工作流程的多步任务。
  • 不需要模型编排。
  • 固定的操作顺序。一个代理的输出是序列中下一个代理的直接输入。
 多代理顺序模式
  • 可以同时执行的独立任务。
  • 不需要模型编排。
  • 通过同时运行子任务来缩短总体延迟时间。
 多代理并行模式
  • 难以一次性完成的开放式或复杂的生成任务。
  • 要求代理在多个周期内逐步改进输出。
  • 不需要模型编排。
  • 优先考虑输出质量，而不是延迟时间。
 多代理迭代优化模式

需要动态编排的 Workflows

需要动态编排的 Workflows 包括复杂问题，在这种情况下，代理必须确定最佳处理方式。智能体 AI 系统需要动态规划、委派和协调任务，而无需预定义的脚本。以下是需要自主动态编排的工作流的智能体设计模式：

工作负载特性 代理设计模式
  • 需要使用外部工具的结构化多步骤任务。
  • 需要快速开发解决方案原型，以进行概念验证。
 单代理模式
  • 需要动态路由到适当的专业子代理，以处理具有不同输入的结构化任务。
  • 由于多次调用协调器 AI 模型，导致延迟时间较长，以便协调器 AI 模型可以将任务定向到相应的子代理。
  • 由于多次调用协调器代理，可能会产生高昂的费用。
 多代理协调器模式
  • 需要多级模型编排来处理复杂、开放式和模糊的任务。
  • 需要全面、高质量的结果，其中分解歧义是主要挑战。
  • 由于嵌套的多级分解导致多次调用 AI 模型进行推理，因此延迟时间较长。
 多智能体分层任务分解模式
  • 需要多个专业代理进行协作辩论和迭代优化，以处理高度复杂、开放式或模糊不清的任务。
  • 优先考虑综合运用多种视角来制定全面或富有创意的解决方案。
  • 由于代理之间的动态全到全通信，导致延迟时间和运营成本较高。
 多代理群模式

涉及迭代的 Workflows

涉及迭代的 Workflows 包含的任务需要通过不断完善、反馈和改进才能获得最终输出。以下是涉及迭代的工作流的代理设计模式：

工作负载特性 代理设计模式
  • 需要智能体通过迭代推理、行动和观察来制定或调整复杂、开放式和动态任务的计划。
  • 优先考虑更准确、更全面的结果，而不是延迟时间。
 ReAct 模式
  • 需要执行监控或轮询任务，重复执行预定义的操作（例如自动检查），直到代理满足退出条件。
  • 等待满足退出条件时出现不可预测或长时间的延迟。
 多代理循环模式
  • 任务需要在完成之前进行明确的验证步骤。
 多代理评价和评论模式
  • 难以一次性完成的开放式或复杂的生成任务。
  • 要求代理在多个周期内逐步改进输出。
  • 不需要模型编排。
  • 优先考虑输出质量，而不是延迟时间。
 多代理迭代优化模式

有特殊要求的 Workflows

有特殊要求的 Workflows 包含不遵循常见 agentic 模式的任务。您的任务可以包含独特的业务逻辑，也可以在关键点需要人工判断和干预。代理型 AI 系统是一种专门为单一特定用途而构建的自定义机器。以下是具有特殊要求的工作流的代理设计模式：

工作负载特性 代理设计模式
  • 由于任务涉及高风险或主观性强，可能包含安全性、可靠性和合规性要求，因此需要人工监督。
 人机协同模式
  • 超出直接线性序列的复杂分支逻辑。
  • 需要最大限度地控制，才能将预定义规则与模型推理相结合。
  • 需要对不适合标准模板的工作流进行精细的流程控制。
 自定义逻辑模式

后续步骤

贡献者

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

其他贡献者：