tldr: 大规模语言模型（LLMs）和人工智能（AI）代理的快速发展激发了一系列复杂的代理工作流程模式的开发，这些模式增强了AI系统的功能。本指南全面探讨了高级代理工作流程模式，分析了它们的技术方面、关键特性、变体以及彼此之间的关系。从自我修正机制到利用有向无环图（DAGs）进行动态任务调度，我们将提供深入分析，为希望在实际应用中利用这些模式的研究人员和从业者提供指导。
本文整理了8个重要的代理工作流模式，探讨了人工智能工作流中常见的、直观的和新兴的方法或技巧。例如，我们以Gemini为主要例子，这些模式同样可以轻松地应用于其他模型。此外，文中提到的所有模式都有配套的GitHub仓库，方便进一步探索和实现。
代理工作流模式是强有力的框架，指导涉及智能代理和大型语言模型的AI系统的开发。这些模式解决了应对各种用例所需的特定功能——一些模式可以独立运作，而另一些则在特定阶段整合人类输入。例如，自我修正使代理能够自主改进输出，而知识扩展则提供了实时访问超出预训练数据的信息。同时，任务协调确保了专门代理之间无缝协作以完成复杂任务，并行处理则提高了效率。可扩展性使系统能够处理大规模数据集，而动态适应性则使工作流能够根据上下文实时调整，确保了这些解决方案既复杂又灵活，能够应对不断变化的挑战和需求。
之前的 work 回顾在我们之前的文章中，我们探讨了 文本到 SQL 的架构模式 和 ReACT 代理，包括深入研究如何从零开始构建一个 ReACT 代理。在我们对自然语言到 SQL（NL2SQL）的架构模式进行分析的过程中，我们强调了自我校正机制在验证 LLM 生成的 SQL 查询有效性的过程中所起的重要作用。这一迭代过程通过执行查询、识别错误并将这些信息反馈给 LLM，从而形成一个强大的反馈回路。这种做法增强了提示信息，让 LLM 更好地理解具体问题，并提供了有针对性的指导来优化查询，最终显著提升了查询的准确性和可靠性。
在我们之前关于此主题的文章中提到的 ReACT 框架内， 并行策略同样证明了有效性。在这样的背景下，我们将工具使用（Wiki 和 Google 搜索）过程中产生的想法、行动和结果整合到代理的工作记忆和反馈循环里。这种方法使代理在复杂、多步骤的任务中能够做出更明智的决策和更具适应性的行为。
虽然熟悉这些先前的文章可以提供宝贵背景，但这并不是理解本文中讨论的概念的前提条件。反馈回路、自我纠正和在AI系统中反复调整的原则具有广泛的应用性，并构成了我们接下来要探讨的先进技术的基础。
现在，让我们逐一深入探索我们构建的每个代理工作流。包含所有模式的整个仓库可以在这里找到here。
模式 1：反思
多智能体反思框架（Actor-评价框架）
反射模式让AI代理能够通过内置的自我评估和纠错机制来批评和改进其输出，从而提高可靠性和输出质量。这种模式可以通过不同的设置来实现。一种设置可以是单一代理的反思，其中单个AI模型执行任务并批评其输出，利用其内部能力发现并纠正问题。我们也可以采用多代理反思设置，其中Actor代理生成输出，Critic代理进行审查和改进，提高分析的深度和质量。另一种常见的方式是使用集成到流程中的外部工具来验证输出的特定方面。例如，在我们之前的NLtoSQL 文章中，通过执行生成的SQL查询来验证其正确性。最后，人机交互的反思允许纳入主观判断任务中的人类反馈，确保改进过程的平衡和全面。
我们的实现遵循多代理反思路线。Actor 针对给定的主题生成初始草稿，并根据 Critic 提供的详细反馈来优化这些草稿，同时维护版本历史。这一迭代过程在每次前一轮的基础上逐步推进，逐步完善内容。Actor 使用专门的组件，例如 DraftGenerator 用于生成初始版本，RevisionGenerator 用于根据反馈来优化草稿。Critic 则充当内容审查员，评估草稿，提出改进建议，并通过查看整个内容历史来确保一致性和跟踪进度。
我们也有一项中央运行器Runner，它负责整个Actor和Critic之间的交互，管理多个生成和评审周期中的状态变化。这个运行器协调整个工作流程，确保系统性进展，同时保留所有草案和评审的完整历史。通过管理生成、评审和修订的循环，运行器使持续改进直至最终输出达到所需质量。
以下是一个从高处俯瞰的工作流概览。反射模式展示了代理驱动的工作流如何通过协作反馈推动迭代改善，使其成为需要逐步优化和自我优化系统的应用程序的强大框架。反射模式的完整实现可以在这里找到 here。
现在让我们来看看这三个重要的模块： [actor](https://github.com/arunpshankar/Agentic-Workflow-Patterns/blob/main/src/patterns/reflection/actor.py)， [critic](https://github.com/arunpshankar/Agentic-Workflow-Patterns/blob/main/src/patterns/reflection/critic.py)，和 [pipeline](https://github.com/arunpshankar/Agentic-Workflow-Patterns/blob/main/src/patterns/reflection/pipeline.py)。actor 模块封装了生成任何选定主题的博客草稿所需的所有逻辑。同样，critic 模块会评估生成的草稿，并提供关于其优缺点和问题的反馈，并提出改进建议。pipeline 模块负责管理这个反馈循环，根据用户设定的循环次数来运作。
你可以试试这种设置方式。根据用户提供的话题的复杂性和长度——这个话题可以是一个词或短语——我们可以发现改进不仅仅局限于三个循环。对于简短常见的话题，我们通常在大约三个循环内就能轻易达成一致。下面你可以看到针对话题的三个循环过程，轮流扮演执行者和评论者的角色，以及我们如何最终完成完整的草稿。
演员生成的初稿 — 第1轮
更清晰的可视化效果显示了v1和v2之间的区别。
v2和v3最终版本的对比
网页访问模式是一种代理工作流，旨在简化从网页中检索、处理和生成摘要的过程。该模式利用专门的代理，每个代理专门负责管道中的特定任务。它高效地协调整个搜索、抓取和总结网页内容的流程，依赖外部API（应用程序接口）进行网页搜索，并利用高级语言模型来生成查询和摘要。
工作流由一个 [WebSearchAgent](https://github.com/arunpshankar/Agentic-Workflow-Patterns/blob/main/src/patterns/web_access/search.py) 启动，该代理获取用户输入，并使用语言模型来生成优化的搜索查询。通过SERP API执行这些查询以检索Google搜索结果。代理确保将结果以结构化的格式存储，从而准备好供管道的下一阶段使用。它还使用Gemini进行函数调用来确定调用SERP API所需的适当参数，进而获取Google搜索结果。
搜索阶段完成后，[WebScrapeAgent](https://github.com/arunpshankar/Agentic-Workflow-Patterns/blob/main/src/patterns/web_access/scrape.py) 就会接管。这个代理负责从检索到的搜索结果中提取内容，同时还能处理多个请求。它实现了限速抓取协议，遵守服务器限制，同时避免给服务器带来压力。提取的内容经过处理和清理，最终形成结构化的数据，作为摘要的输入。
在这个阶段，[WebContentSummarizeAgent](https://github.com/arunpshankar/Agentic-Workflow-Patterns/blob/main/src/patterns/web_access/summarize.py)开始介入。该代理使用模板提示和语言模型，从提取的内容生成简洁一致的摘要。将生成的摘要保存为最终结果，标志着流程的结束。
整个系统由一个 [pipeline](https://github.com/arunpshankar/Agentic-Workflow-Patterns/blob/main/src/patterns/web_access/pipeline.py) 控制，该管道协调所有代理的运作，并确保组件间的数据流动顺畅。管道还处理清理任务、管理错误恢复，并提供一个简单的接口来启动工作流。这种良好的结构抽象了网络内容处理的复杂性，允许用户通过一个简单的函数调用即可执行整个管道。
这种全面设计的Web访问模式能够高效可靠地获取和处理网页内容，使其成为从网络浩瀚资源中生成结构化、简洁内容的理想方案。核心思想是创建一个由三个代理协调工作的统一串行管道，处理从用户提供的查询到网络搜索全面摘要的过程。此管道可以作为后续代理和模式（管道）使用的工具。您可以在这里找到该模式的完整实现。
现在让我们检查从设置代理开始的管道中每个阶段的输出。我们将要测试的初始搜索查询是“Fresno, California的最佳酒店”。
这是WebSearchAgent找到的一些关于Google的搜索结果。
接下来，WebScrapeAgent 从之前的代理中获取前 k 个结果并抓取这些网页。然后，它清理 HTML 并使用 Gemini 清理和整合 HTML，形成整洁的标记格式。这些网页的内容无法被抓取的将被忽略。以下是抓取并整理后的一部分 Markdown 内容：
...
WebContentSummarizeAgent 将先前代理生成的 Markdown 输出重写为更易于用户阅读的格式。
模式3：基于语义的路由
根据用户的意图进行路由
语义路由 模式实现了一种智能的路由工作流程，根据用户意图将用户查询智能地路由到专门的代理。这个模式使用一个 协调器-委托者 架构，其中包含一个条件路由器。主要的 TravelPlannerAgent 会识别用户的意图，并将请求转交给专门的子代理，以处理特定的旅行相关任务，如预订航班、酒店搜索和租车。通过利用语言模型进行意图检测和查询处理，该模式确保每个请求都由最相关的专门代理处理。
模式的核心在于这个代理 [TravelPlannerAgent](https://github.com/arunpshankar/Agentic-Workflow-Patterns/blob/main/src/patterns/semantic_router/coordinator.py)，它作为中央协调器。该代理对用户的传入查询进行语义分析，以识别意图，并将其分类为预定义的类别，例如 FLIGHT、HOTEL、CAR_RENTAL 或 UNKNOWN。根据此分类，计划将查询路由给相应的专业子代理。它还负责协调各子代理间的通讯，将他们的回复整合成一个连贯且易于用户理解的最终结果。
工作流涉及几个专门的子代理，每个子代理都专注于特定的旅行任务。[FlightSearchAgent](https://github.com/arunpshankar/Agentic-Workflow-Patterns/blob/main/src/patterns/semantic_router/delegates/flight_search.py)负责处理所有与航班相关的查询，通过生成优化的航班搜索条件并返回简要的航班信息。同样，[HotelSearchAgent](https://github.com/arunpshankar/Agentic-Workflow-Patterns/blob/main/src/patterns/semantic_router/delegates/hotel_search.py)处理酒店预订请求，并提供相关的住宿详情，而[CarRentalSearchAgent](https://github.com/arunpshankar/Agentic-Workflow-Patterns/blob/main/src/patterns/semantic_router/delegates/car_rental_search.py)管理汽车租赁查询，提供车辆租赁的相关信息。每个子代理都专门高效地处理特定的旅行任务，并提供准确的结果。这些子代理利用我们在模式2中建立的网络访问管道来获取和总结网页搜索结果。
这个 [pipeline](https://github.com/arunpshankar/Agentic-Workflow-Patterns/blob/main/src/patterns/semantic_router/pipeline.py) 负责协调整个工作流。它初始化所有代理并管理消息的整体流程。流程从查询接收开始，用户提交旅行相关的查询，管道将查询转换成消息对象并转发给 TravelPlannerAgent。在意图检测阶段，TravelPlannerAgent 分析查询的语义内容以确定具体的旅行意图。随后将查询路由给最适合的专门子代理。在专门处理阶段，选定的子代理（仅根据条件匹配选择一个）处理路由查询，生成优化的网页搜索查询，并汇总网页搜索结果以提供详细响应。当子代理返回响应后，规划者接管响应整合任务，合并子代理的信息并格式化最终的用户友好型响应。所有子代理（即代理）和协调者使用大型语言模型 (LLM) 作为其认知组件来解决提供的自然语言理解 (NLU) 任务。
除了这里讨论的旅行规划场景之外，基于语义意图的条件路由在其他多种用例中也非常有用。例如，在客户支持中，可以根据客户消息的内容将咨询转接到相应的部门，例如账单、技术支持或销售部门。在电子商务中，可以根据提到的产品类型的查询将产品相关询问定向到特定的产品专家或推荐系统。医疗保健系统也可以通过这种方式让患者的咨询根据症状或关心的问题转接到合适的医疗专家。实现此模式的完整代码可以在这里找到。
我们现在来看一看下面这个示例查询的工作流的结果，如下所示：
最初，TravelPlannerAgent 正确识别了寻找酒店的意图，如下所示，然后将控制交给 HotelSearchAgent。
然后，代理将原始查询重新措辞为更适合搜索引擎的查询。
下属代理然后通过模式2的网页访问管道进行API调用，来生成我们正在寻找的酒店搜索摘要，如下所示。
HotelSearchAgent将这些结果返回给TravelPlannerAgent，它是一个协调代理，随后将最终结果整合成更易于理解和阅读的格式（如下），然后返回给用户。
并行委派模式是一种通过将任务分解为多个独立的子任务来提高效率的代理工作流设计，旨在通过大型语言模型驱动的自然语言理解（NLU）识别出独立的实体或见解，并根据这些识别结果将其分配给专门的代理进行并行处理，从而处理复杂的查询。这种模式在需要同时处理多个独立任务的情况下特别有效。例如，我们可以在模式3中讨论的旅行规划场景中应用该模式——航班、酒店和租车的搜索可以并行进行，例如。通过利用异步处理方式，此模式优化了性能并提高了效率，同时通过一个中心协调代理保持协调和结构化的流程。
与之前的模式类似，该模式的核心是 TravelPlannerAgent，它充当主要协调者。它会对用户的查询执行命名实体识别技术（NER），以识别关键元素，如航班、酒店和租车。然后，代理将这些实体分类，并分配给专门的子代理进行并行处理。计划者监督这一异步委派过程，并将结果汇总成一个全面的最终答复。这种方法通过将复杂的旅行规划请求分解为可管理的并行任务，实现了高效的处理。
这里的特定代理被设计成独立处理特定类型的实体。FlightSearchAgent 处理与航班相关的实体，生成优化的航班搜索查询并获取相关信息。同样，HotelSearchAgent 管理与酒店相关的实体，处理住宿请求并提供所需信息。CarRentalSearchAgent 独立处理车辆租赁请求，提供相关的汽车租赁选择。
异步管道协调整个并行工作流。它初始化所有代理，并管理它们之间的异步消息通信。通过启用并发处理，管道允许每个专门的子代理独立并行地完成任务，从而大大提高效率。因此，这种模式为处理包含多个独立任务的复杂工作流提供了一种可扩展的解决方案。在动态环境如旅行规划中，任务可以拆分为并行组件以实现优化执行，这种模式特别有用。该模式的完整代码可以在以下位置找到：location。
现在让我们来检查一下我们之前输入到管道中的一个示例用户查询的结果。请注意，下面的查询不能归因于单一意图——它包含了涉及所有三个子代理的意图。然而，在触发这些代理之前，我们首先需要将该查询分解成可以传递给相应代理的实体部分。
第一步由协调器（TravelPlannerAgent）执行。它接收查询内容，并利用Gemini工具来确定哪些合适的实体需要传递给各个子代理。
这条信息随后会被传递给各个子代理，以便并行异步地执行三次搜索。每个子代理首先会将原始查询转化成更适合谷歌搜索的形式。我们通过在模式2中建立的网络访问管道使用工具来利用谷歌搜索。搜索结果的摘要随后会被传递回协调器（TravelPlannerAgent）。最终，当TravelPlannerAgent从每个子代理接收到所有摘要后，它将进行汇总，生成供用户查看的最终摘要。
- 问题重述
- 搜索结果概览
- 重新表述的查询请求
- 搜索结果：概览
- 重新措辞的请求
- 搜索结果概览.
TravelPlannerAgent 的整合计划
- 最后的总结（返回用户）
动态分片模式代表一种从传统软件设计演变而来的架构方法，该方法拥抱了以代理为基础的系统。在这种情况下，工作负载被智能且动态地分割成更小的单元，称为“分片”。虽然这种模式在通过并行处理管理大型数据集方面一直表现出色，但在适应代理式环境时，它引入了更为复杂的任务分配层次。通过智能地在代理之间分配任务，系统实现了增强的可扩展性和最佳资源利用。
在中心位置的是Coordinator代理，它负责整个数据处理流程的协调。为了演示，我们将在网络搜索的场景中使用名人姓名，以及指定的分片大小。它的主要任务是将列表分割成更小、更易管理的部分。例如，如果列表包含100个名人姓名，而分片大小为10，Coordinator代理将创建10个分片。一旦分片建立，Coordinator会为每个分片动态创建专门的Delegate代理，并启动这些代理的并行处理，让它们各自独立处理分片。
注意，尽管我们称 Coordinator 为代理，在当前实现中，我们并没有使用 LLM 来预处理用户提供的原始列表。这可以在分片之前轻松实现一些我们可能需要的功能。例如，可以更好地组织或甚至提供一段自由文本内容，提取实体，例如名人名字，作为代理协调过程中的第一步。这是你可以尝试实现的一个功能。
碎片处理 Delegate 代理是专门设计用于处理单个碎片的专用组件。这些代理从 Coordinator 代理接收一部分数据，并独立处理分配给它们的碎片内的每个项目。例如，在一个获取名人传记的项目里，每个碎片处理代理会专注于获取分配给它的名人信息。这些代理并行运行，执行每个项目的处理以提高效率。这种细粒度的并行处理不仅提高了处理速度，还简化了碎片级的错误处理和重试机制，从而更好地实现资源隔离和管理。
当每个 Delegate 代理完成它的任务时，它们的结果会被收集并返回给 Coordinator 代理。然后，Coordinator 会将所有代理的结果整合成一个统一且连贯的响应。这一步确保了所有处理过的数据被汇总成一个全面的输出，然后交付给最初的请求方。无论是用户还是系统中的其他组件，都会收到这个最终的综合输出。
动态分片模式展示了一种可扩展的数据处理方法，能够根据工作负载的动态变化进行调整。通过将任务分成多个分片并利用专门的代理并发处理，这种模式在系统响应性、吞吐量和资源利用率上带来了显著提升。它特别适合处理大规模数据集或高流量请求的应用场景，其中高效的可扩展处理尤为重要。该模式的代码可以在这里找到：here。
如下所示，展示了工作流程的整体概览：
现在让我们来检查工作流的成果。这个模式的输入基本上是一个扁平化的名单，这个名单被提供给Coordinator代理以启动分片和信息搜集过程。
协调器会使用我们设置的网页访问管道来分片处理并执行网络搜索，以收集所有单独的搜索摘要。之后，这些摘要将传回协调器代理。协调器不会使用LLM来对子代理的响应进行后处理或汇总。然而，如果有需要，这一功能可以轻松添加。
最终汇总如下：
任务分解模式是一种设计方法，通过将复杂任务分解为多个独立的子任务来管理任务，这些子任务可以并行处理。此模式依赖于一个中央协调器代理来监督任务的分解与执行。与其他模式不同，任务不是自动识别的，在这里用户需要定义具体的子任务并提供相应的输入。协调器将这些子任务分配给专业的代理并行处理。通过高效地分配任务负载，任务分解模式增强了可扩展性并优化了资源的使用，使其适用于复杂且多部分任务的场景。
在这个模式的核心是Coordinator，它在接收复杂的任务输入并处理用户定义的子任务方面扮演着核心角色。它将主要任务分解成更小的独立可执行单元。它通过为每个子任务创建单独的Delegate代理来启动工作流。Coordinator还会将每个子任务的信息发送给相应的Delegate代理，并协调它们的并行执行。一旦所有子代理完成它们的任务，Coordinator代理将结果整合成一个结构化和统一的输出。
每个 Delegate 代理独立运行并处理由 Coordinator 代理分配的特定子任务。当 Delegate 接收到一个子任务时，它会提取必要的细节，并在有必要时准备输入供大型语言模型（LLM）处理。然后该代理通过与LLM或任何其他所需服务交互来处理子任务，并生成结果。完成任务后，Delegate 将结果回传给 Coordinator 代理。
通过将复杂任务拆分成更小的、可以独立执行的单元并同时处理它们，任务拆分模式让任务管理变得更加模块化，允许每个子任务都可以并行处理，同时保持流程的连贯性和组织性。该模式特别有益于那些可以逻辑地分成更小的自包含组件的复杂任务，这些组件可以同时运行。支持该模式的代码库可以在这里找到链接：here。
注意： 在我们的实现中，Coordinator 代理没有使用 LLM（Gemini）进行任何预处理逻辑或后处理汇总。但是，这些功能也可以根据具体需求轻松添加。
现在让我们来看看将一份公共法律案件文档输入到这个工作流程中的结果。该工作流程有用户提供的5个明确的任务作为子任务。Coordinator代理同时接收法律文件和用户提供的任务列表。根据用户提供的任务列表中的任务数量，它会根据任务数量生成相应的子代理来执行这些任务。由于所有任务都是独立设计的，因此这些任务会并行处理。输入的文档和用户提供的任务列表如下。
以下展示了最终输出的截图。Coordinator接收来自各个子代理的各自的输出，然后将这些输出简单地整合成最终输出。请注意一下，当前版本中我们还没有使用LLM来整合，但这很容易实现这一功能。
动态分解模式（DDP） 是一种高级设计模式，其中中央的 Coordinator 代理自主地将复杂的任务分解为多个子任务，而不依赖于预定义的子任务结构。此模式利用 LLM 动态生成子任务，然后将其委派给不同的 Delegate 代理进行处理。在所有子任务完成后，Coordinator 收集并整合结果，生成结构化的综合摘要，提供一个连贯且全面的输出结果。此模式与之前的模式之间的主要区别在于，这里的协调器可以使用 LLM（如 Gemini）自动分解子任务，而在之前的模式中，子任务列表是由人为提供给协调者的。
在这个模式中，核心组件是Coordinator代理，它在分析和管理整个任务分解过程中扮演着关键角色。它首先接收复杂的任务输入，并使用大型语言模型（LLM）来识别所需的子任务。Coordinator根据输入的上下文动态确定这些子任务，从而能够处理结构各异或未明确定义的任务。在分解完成后，Coordinator创建单独的Delegate代理，并将每个子任务分配给相应的代理。这些子任务代理随后并行执行，处理各自的任务并将结果返回给Coordinator。最后，Coordinator将这些结果整合成一个结构化的摘要，为原始任务提供一个全面的输出结果。
Delegate Delegate 负责执行由 Coordinator 分配的各个子任务。每个 Delegate 在收到子任务后，准备相应的输入数据并与 LLM 交互，以进行分析或提取信息。通过将子任务的执行委托给独立的 Delegate，该模式实现了并发处理，从而提高了效率并缩短了任务的整体执行时间。每个子任务代理在其任务完成后将其结果返回给 Coordinator。这一工作流程段落与我们之前在模式 6 中探讨的内容类似。模式 7 的完整代码位于共享代码库中的此 位置。
我们现在来分析通过类似在模式6中用户引导的任务拆分传递文档所得到的结果。在这里，我们不再像之前那样，直接给Coordinator代理提供一个子任务列表来辅助输入文档，而是让Coordinator代理自己从文档中提取子任务，让Gemini分析提供的短故事输入，从而提取子任务。
我们的工作流程的输入文件是古腾堡计划提供的《海上的老人》的数字文本形式。
下面是由Coordinator提取的子任务
鉴于Coordinator代理提取了10个子任务，提取了这些任务之后，它还会创建10个Delegate代理（每个代理分配一个任务）。这些子任务随后由这些代理同时执行。最后，Coordinator将所有代理的输出汇总生成一个最终的汇总结果。
我们将要看到的最后一个模式是 DAG 调度模式。这是一套高级的设计方法，用于通过将任务结构化为有向无环图（DAG）结构来管理复杂的工作流程。此模式允许灵活高效地执行多个任务，支持根据依赖关系进行并行或顺序执行。该模式利用一个 Coordinator 代理，正如之前提到的模式一样，根据定义的DAG动态管理任务执行，并使用基于 YAML 的配置文件来指定任务间的关系、执行顺序及相关代理。
就像之前一样，这个模式的核心组件是称为Coordinator的代理，它监督整个执行过程。Coordinator代理从读取和解析包含DAG定义的YAML文件开始，将任务、依赖关系及其相关的子代理加载到内存中。这种灵活的结构使工作流易于定制、更新和扩展，而无需修改底层代码，使其适用于各种复杂的工作流程。
工作流程的关键在于这些专业化子代理，如 CollectAgent、PreprocessAgent、ExtractAgent、SummarizeAgent 和 CompileAgent，每个子代理负责工作流程中的特定任务。CollectAgent 负责从指定文件夹中收集文档并为后续处理做好准备。一旦文档被收集，PreprocessAgent 就会介入，使用大语言模型（LLM）来清理和规范化文档内容。然后，ExtractAgent 从预处理过的文档中提取关键信息，例如人物、主题或情节点。然后 SummarizeAgent 生成简洁的摘要。最后，CompileAgent 编制一份详尽的报告，基于提取的关键信息和生成的摘要。
编排模式遵循一个结构化的流程，从加载DAG定义开始。在此初始步骤中，Coordinator代理读取并解析 YAML 文件，将 DAG 结构加载到内存中，并识别所有任务、依赖及相关代理。加载完成后，任务执行准备阶段开始时，Coordinator 初始化任务状态并准备待处理任务列表。
在最后的迭代任务执行阶段，Coordinator 代理会一直循环直到所有任务都完成了。在每次迭代中，Coordinator 识别所有满足条件的任务，并将其标为可执行。对于每个可执行的任务，根据任务定义动态创建相应子代理，并从之前已完成的任务结果中收集输入数据。子代理随后异步处理这些任务。在等待任务完成时，Coordinator 监控进度并收集结果，更新状态以反映当前任务情况。
DAG 任务编排模式是一种强大的解决方案，适用于需要灵活且结构化任务执行的场景，其中依赖关系需要动态管理，并且任务可以并行或顺序地执行。与此高级模式相关的所有代码和支持文件可以在此链接 这里 查看。
下面展示的是工作流在实际运作中的100英尺视角。
现在让我们通过一个实际的例子来看看，编排流程在我们之前提到的工作流模式中是如何工作的。
我们的输入是一些短故事。DAG管道的目的是以分步骤的方式消费这些故事，并通过定义的Delegate代理来执行之前定义的各个子任务。Coordinator代理负责整个流程的驱动。下面是一些示例短故事的输入。
我们将为此示例设置的DAG流程的声明性YAML如下所示：
这里，每个任务都依赖于前一个任务，除了一个例外：任务5（编译任务）依赖于任务3和任务4（抽取和总结任务）。这意味着我们可以独立并行地执行任务3和任务4，然后将它们的结果输入到任务5中。下面，我们将分享来自子任务（委派）代理的中间输出。
任务一
最终输出（来自任务5）是一份文学分析报告，该报告以非常特定的方式总结了我们最初处理的短篇故事，并符合初始请求中提出的要求，如下所示。
最后的感想
人工智能（AI）和大型语言模型（LLMs）的快速演变带来了设计具有代理功能的工作流程的新挑战和机遇。反射、网络访问、语义路由和并行委托等模式提供了构建复杂且适应性强的AI系统的强大框架。这些模式不仅提高了效率，还增强了AI应用的可扩展性、动态适应性和自主改进的能力。通过理解和应用这些代理工作流程模式，从业者可以释放AI的全部潜力，为各种现实世界问题提供智能解决方案。
本指南仅是关于代理工作流更广泛讨论的起点。我们鼓励AI研究人员和从业者探索这些模式，根据自身需求调整并为这一不断发展的领域做出贡献。本文提出了一种实现代理工作流的方法，但并非唯一途径。还有许多其他方法可以构建和组合基于代理的工作流。本文的目标是展示一些简单的实现方式，这些方式纯粹，让您完全掌控，自由定制和实验，无需依赖专门为此设计的外部框架。讨论的八个模式可以结合创造出更高级的变体。我们甚至可以让简单的代理变得类似于ReAct的形式，这在之前的某篇文章中有探讨过。如果您有新的模式想法或觉得有些内容缺失，请随时联系我们。让我们合作，共同推动这一领域的发展。
感谢你阅读这篇文章并积极参与。你的关注和支持对我来说非常重要。如果你对内容或共享的笔记有任何疑问或顾虑，欢迎通过邮件联系我：arunpshankar@google.com 或 shankar.arunp@gmail.com。或者你也可以在我的领英（LinkedIn）上找到我：https://www.linkedin.com/in/arunprasath-shankar/。
我很乐意接受您的任何反馈和建议。如果您对大规模机器学习、自然语言处理或自然语言理解（NLP/NLU）感兴趣，并希望合作，我非常乐意与您合作。同时，如果您是个人、初创公司或企业，想了解谷歌云、VertexAI以及各种生成式AI组件及其在NLP/ML中的应用，我随时可以提供帮助和指导。请随时联系我。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
