AIGC系列之二-"Plan-and-Execute" 一种省钱高效解决复杂任务的Agent架构设计

Original ruby ruby的数据漫谈

2024-09-27

摘要：使用AIGC的智能体（Agent)进行问题解决时，有时候即使对prompt进行优化，结果仍然不理想。这可能是因为在问题解决过程中需要涉及多个外部工具的组合和协调，单一的Action agents无法满足需求。在这种情况下，可以考虑使用Plan-and-execute agents架构。该架构允许智能体不仅仅关注单个行动，而是将问题解决过程分为更高级别的计划和执行阶段。在Plan阶段，智能体可以使用问题描述和约束来生成一个解决方案的高级计划。该计划可以包含多个行动、外部工具的调用以及它们之间的调度关系。智能体可以使用规划算法和启发式方法来生成最佳的解决方案。在Execute阶段，智能体将根据计划逐步执行各个行动和外部工具的调用。智能体需要具备执行计划的能力，并且能够解析和处理来自外部工具的输出。这可能需要涉及调用计算器、搜索API、数据库等工具，并处理它们的返回结果。通过使用Plan-and-execute agents架构，智能体可以更好地处理复杂的问题解决任务。它能够通过生成高级计划来考虑多个行动和工具的协同作用，并在执行阶段灵活地处理外部工具的输出。这种架构可以提高问题解决的效率和准确性。本文从背景、原理、以及三种Plan-and-Execute架构来阐述如何解决这些问题的。

背景
智能体（Agent)的原理
三种Plan-and-Execute架构

—

背景‍‍

在过去的一年中，基于LLM的Agent和状态机已经成为创建灵活有效的人工智能产品中，最有希望的设计模式。

在核心层面，Agent使用LLMs作为通用问题解决器，将它们与外部资源连接起来，以回答问题或完成任务。

LLM Agent通常具有以下主要步骤：

1、提出动作：LLM生成文本以直接回答用户或传递给函数。

2、执行动作：您的代码调用其他软件执行诸如查询数据库或调用API等操作。

3、观察：根据工具调用的响应通过调用另一个函数或响应用户来做出反应。

ReAct Agent是这种设计的一个很好的原型，因为它使用重复的思考、行动、观察循环提示LLM，下面是典型的ReAct风格Agent轨迹：

思考：我应该调用Search()来查看比赛的当前比分。
行动：Search("X队的当前比赛比分是多少？")
观察：当前比分是24-21
…（重复N次）

这利用了思维链（Chain-of-thought ）提示，以便每次只能做出单个动作选择。尽管这对于简单的任务可能是有效的，这种是单一的Action agents的长项，‍

但它有几个主要缺点：

1、每个输入，即每个prompt都需要调用LLM，则成本较高。

2、LLM一次只计划一个子问题，即便prompt很复杂，也只计划一次。这可能导致子优化轨迹，因为它不强制“思考”整个任务。导致输出的结果与用户想要的结果相差很大，无论如何优化prompt，都得不到想要的结果‍

为克服这两个缺点的一种方法是通过一个明确的规划步骤。即Plan-and-execute agents：预先决定完整的行动顺序，然后在不更新计划的情况下全部执行。

—

智能体的原理‍‍‍

智能体的原理

大模型Agents的技术，其实本质上就是写prompt，让模型仿照你的方式来进行执行的一种应用范式，prompt里面包含一些tools的描述，然后我们可以根据模型的输出使用一些外部tools(例如计算器，搜索API，数据库，程序接口，各种模型的API)，能使用外部的API，知识库，只要写好prompt，智能体会调用LLM完成任务，形成用户需要的内容。一个包含Agents自主智能体的系统如上图所示，

1、用户根据prompt模版写了一个prompt，Agents调用LLM，形成一个Plan，即一个任务列表，然后Execute根据任务列表去执行。

2、执行过程根据架构分为串行和并行两种执行方式，在执行任务的同时，智能体会调用它所配置的工具能力，可能是查询数据库获取数据，然后调用LLM,也有可能是写了一段python代码，执行数据分析。工具能力是配置给智能体的，一个任务可能是单个任务，也可能是多个小的任务。‍‍‍‍‍‍‍‍

以上就是智能体的构成，它有访问LLM的能力，以及拆解执行任务的能力，以及配置的工具库，根据任务需要调用工具库执行任务。‍‍‍‍‍‍‍‍‍‍‍

—

三种Plan-and-Execute架构

Plan-And-Execute 计划和执行

该Agent设计 loosely基于Wang等人的“Plan-and-Solve Prompting”论文和Yohei Nakajima的BabyAGI项目，这个简单的架构代表了规划Agent架构。它由两个基本组件组成：

Planner规划器，用于提示LLM生成完成大型任务的多步计划。

Executor执行器，接受用户查询和计划中的一步，并调用1个或多个工具来完成该任务。

一旦某个字任务执行完成后，再次调用Agent，使用重新规划提示，让其决定是以响应结束还是生成后续计划（如果第一个计划没有产生预期效果）。

这种Agent设计让我们避免了每次工具调用都需要调用大型规划器LLM的情况。它仍然受到串行工具调用的限制，并且由于不支持变量赋值，每个任务仍然使用LLM。

如图上描述，针对复杂的任务（prompt），首先规划出一个任务列表，每个任务列表去调用用LLM，根据返回的结果，如果没有达到预期，再次调用Agent，使用重新规划提示，生成后续计划。这种架构对应于单一的Action agents智能体来说区别是，有了规划这个动作，可以把复杂的任务拆分成任务列表，根据任务列表，单次执行任务，而不是把一个复杂的任务直接扔给LLM执行（执行结果肯定不佳）。‍‍‍‍‍‍‍‍

Plan-And-Execute 计划和执行相对于单一的Action agents智能体来说优化了执行结果，但是由于拆分任务以及任务的串行，导致智能体的成本增加以及反应变慢，因为智能体调用LLM是按照次数收费。

为解决成本增加以及反应变慢的问题，于是出现了Reasoning WithOut Observations 无观察推理。

Reasoning WithOut Observations 无观察推理‍‍‍

在ReWOO中，Xu等人提出了一种Agent架构设计，它消除了始终需要为每个任务使用LLM的需要，同时仍然允许任务依赖于先前任务的结果。他们通过允许在规划器的输出中进行变量赋值来实现这一点。以下是Agent设计的图示。

其规划器生成一个包含交错“Plan”（推理）和“E#”行的计划列表。例如，给定用户查询“今年超级碗竞争者的四分卫的统计数据是什么”，规划器可能会生成以下计划：

计划：我需要知道今年超级碗中的队伍
E1：搜索[今年超级碗的竞争对手是谁？]
计划：我需要知道每个队伍的四分卫
E2：LLM[#E1的第一个队伍的四分卫]
计划：我需要知道每个队伍的四分卫
E3：LLM[#E1的第二个队伍的四分卫]
计划：我需要查找第一个四分卫的统计数据
E4：搜索[#E2的统计数据]
计划：我需要查找第二个四分卫的统计数据
E5：搜索[#E3的统计数据]

请注意，规划器Planner可以使用类似#E2的语法引用先前的输出。这意味着它可以执行任务列表，而无需每次重新规划。

工作节点Worker循环遍历每个任务，并将任务输出分配给相应的变量。在调用后续调用时，它还会用其结果替换变量。

最后，求解器Solver将所有这些输出集成到最终答案中。

这种Agent设计可以比原始的plan-and-execute Agent更有效，因为每个任务只能具有所需的上下文（其输入和变量值）。

但是，它仍然依赖于顺序任务执行，这可能会导致运行时间较长。

总结一下，Reasoning WithOut Observations 无观察推理架构相对于Plan-And-Execute 计划和执行架构少了根据反馈重新规划的步骤，减少了调用LLM的次数。但是执行结果按照变量的方式进入到下一步，让结果也趋于变好，但是反应时间久的问题任然没有得到解决。于是出现LLMCompiler LLM编译器架构。

LLMCompiler LLM编译器

LLM编译器，由Kim等人设计，是一种Agent架构，旨在进一步提高任务执行的速度，超越了上述plan-and-execute Agent和ReWOO Agent，甚至超越了OpenAI的并行工具调用。

LLM编译器具有以下主要组件：

1、Planner：流式传输任务DAG。每个任务包含一个工具、参数和依赖项列表。（DAG是有向无环图Directed Acyclic Graph的缩写）

2、Task Fetching Unit：任务获取单元安排和执行任务。它接受任务流。一旦所有任务的依赖关系得到满足，该单元就会安排任务。由于许多工具涉及到对搜索引擎或LLMs的其他调用，额外的并行性可以带来显着的速度提升（该论文声称提高了3.6倍）。

3、Joiner：基于整个图形历史（包括任务执行结果）动态重新规划或完成是一个LLM步骤，它决定是用最终答案回应还是将进度传递回（重新）规划Agent以继续工作。

这里运行时效率提升的关键思想是：