Agent规划大揭秘！这才是真正的planning

agent 的核心是负责解决用户所提出的任务。这个任务由目标和约束条件定义。例如，一个任务是安排一次从上海到北京为期两周的旅行，预算为 5000。目标是为期两周的旅行，约束条件是预算。复杂的任务需要规划。规划过程的输出是一个计划，它是一份概述完成任务所需步骤的路线图。有效的规划通常要求模型理解任务，考虑实现该任务的不同选项，并选择最有希望的一个。

小涂Ss

1168人浏览 · 2025-01-14 10:56:15

小涂Ss · 2025-01-14 10:56:15 发布

前言

今天我们详细聊聊Agent的规划-planning，这可能是全网讲的最清晰的一篇文章了，全文近1万字~

planning

agent 的核心是负责解决用户所提出的任务。这个任务由目标和约束条件定义。

例如，一个任务是安排一次从上海到北京为期两周的旅行，预算为 5000。目标是为期两周的旅行，约束条件是预算。

复杂的任务需要规划。规划过程的输出是一个计划，它是一份概述完成任务所需步骤的路线图。有效的规划通常要求模型理解任务，考虑实现该任务的不同选项，并选择最有希望的一个。

planning概述

给定一个任务，有很多种可能的解决方法，但不是所有方法都能成功。在正确的方案中，有些比其他方案更高效。考虑这个查询：“有多少没有收入的公司至少融了 10 个亿？”，以及两个可能的解决方案：

先找出所有没有收入的公司，然后按照融资金额筛选。
先找出所有至少融资了 10 个亿的公司，然后按照收入筛选。

第二种方案效率更高。没有收入的公司数量远远多于筹集了 10 个亿的公司数量。如果只有这两个选项，一个智能 agent 应该选择方案 2。

你可以将规划和执行放在同一个prompt中。例如，你给模型一个prompt，要求它逐步思考（例如使用思维链提示），然后在同一个提示中执行这些步骤。但如果模型给出了一个 1000 步的计划，结果连目标都实现不了怎么办？在没有监督的情况下，一个 agent 可以跑这些步骤几个小时，浪费时间和 API 调用费用，直到你发现它根本毫无进展。

为了避免这种徒劳的执行，规划应该与执行解耦。

你先要求 agent 生成一个计划，只有在验证该计划之后才执行它。计划可以用一些启发式方法验证。例如，一个简单的启发式方法是排除包含无效操作的计划。如果生成的计划需要 Google 搜索，而 agent 没有访问 Google 搜索的权限，那么这个计划就是无效的。另一个简单的启发式方法是排除所有超过 X 步的计划。

计划也可以使用 AI 评判来验证。你可以让一个模型来评估计划是否合理，或者如何改进它。

如果生成的计划被评估为不佳，你可以要求规划器生成另一个计划。如果生成的计划良好，则执行它。

如果计划中涉及到外部工具，就会调用函数调用。执行该计划的输出结果也需要再次评估。请注意，生成的计划不必是整个任务的端到端计划，它可以只是针对某个子任务的小计划。整个过程如下图所示。

整个系统现在有三个组件：一个用于生成计划，一个用于验证计划，另一个用于执行计划。如果你把每个组件都看作是一个 agent，那么这就构成了一个多 agent 系统。由于大多数 agent 工作流程都足够复杂，需要多个组件，因此大多数 agent 都是多 agent 的。

为了加速这个过程，你可以并行生成多个计划，而不是按顺序生成，然后让评估器选择最有希望的一个。这是一种在延迟和成本之间的权衡，因为同时生成多个计划会带来额外的成本。

规划需要理解任务背后的意图：用户想通过这个查询做什么？意图分类器通常用来帮助 agent 规划。比如说，将复杂任务分解为更简单的子任务，意图分类可以使用另一个提示或一个为这个任务训练的分类模型来完成。意图分类机制可以看作是多 agent 系统中的另一个 agent。

了解意图可以帮助 agent 选择合适的工具。例如，对于客户支持，如果查询是关于查工资的，agent 可能需要访问一个工具来检索用户最近的工资条信息。但如果查询是关于如何重置密码的，agent 可能需要访问文档检索功能。

有些查询可能超出了 agent 的能力范围。意图分类器应该能够将请求分类为“不相关”，以便 agent 可以礼貌地拒绝这些请求，而不是浪费计算资源去尝试不可能的解决方案。

到目前为止，我们假设 agent 自动化了所有三个阶段：生成计划、验证计划和执行计划。实际上，人类可以在任何阶段参与进来，协助这个过程并降低风险。

人类专家可以提供计划、验证计划或执行部分计划。例如，对于 agent 难以生成完整计划的复杂任务，人类专家可以提供一个高层次的计划，然后让 agent 在此基础上进行扩展。如果计划涉及到有风险的操作，例如更新数据库或合并代码更改，系统可以在执行前请求明确的人工批准，或者将这些操作交给人工执行。为了实现这一点，你需要清楚地定义 agent 在每个操作中可以拥有的自动化程度。

总而言之，解决一个任务通常涉及以下步骤。反思对于 agent 来说不是强制性的，但它可以显著提高 agent 的性能：

计划生成：提出完成该任务的计划。一个计划是一系列可管理的操作，因此这个过程也称为任务分解。
反思和错误纠正：评估生成的计划。如果这是一个不好的计划，则生成一个新计划。
执行：采取生成的计划中概述的操作。这通常涉及调用特定的函数。
反思和错误纠正：在收到操作结果后，评估这些结果并确定是否已完成目标。识别并纠正错误。如果目标未完成，则生成新计划。

当你要求模型“逐步思考”时，你实际上是在要求它分解任务。当你要求模型“验证你的答案是否正确”时，你实际上是在要求它进行反思。

大模型作为规划器

一个常见的问题是，大模型在规划方面的表现如何。许多研究人员认为，大模型，至少是那些建立在自回归语言模型之上的模型，无法进行规划。Meta 的首席 AI 科学家 Yann LeCun 明确表示，自回归 LLM 无法规划。

虽然有很多传闻证据表明 LLM 是做规划非常的糟糕，但尚不清楚这是否是因为我们不知道如何正确使用 LLM，还是因为 LLM 本质上就不能规划。

规划的核心是一个搜索问题。你在通向目标的不同路径中搜索，预测每条路径的结果（奖励），并选择结果最有希望的路径。有时，你可能会确定根本没有路径可以到达目标。

搜索通常需要回溯。例如，假设你处于一个步骤，其中有两个可能的动作：A 和 B。在执行动作 A 后，你进入了一个不理想的状态，因此你需要回溯到之前的状态以执行动作 B。

有些人认为，自回归模型只能生成前向动作，而不能回溯生成替代动作。因此，他们得出结论：自回归模型无法规划。但这不一定是真的。在执行完动作 A 的路径后，如果模型判断这条路径不合理，它可以修改路径，改为使用动作 B，从而实现回溯。模型也可以随时重新开始，选择另一条路径。

LLM 也可能因为没有获得规划所需的工具而成为糟糕的规划者。要进行规划，不仅需要知道可用的操作，还需要知道每个操作的潜在结果。举一个简单的例子，假设你想爬上一座山。你可能的动作是向右转、向左转、掉头或径直向前走。但是，如果向右转会导致你从悬崖上掉下去，你可能就不会考虑这个动作。用技术术语来说，一个动作会将你从一个状态带到另一个状态，你需要知道结果状态才能决定是否执行这个动作。

这意味着仅仅提示模型生成一系列操作（例如思维链）是不够的。“Reasoning with Language Model is Planning with World Model” 这篇论文认为，LLM 因为包含了大量关于世界的信息，因此能够预测每个动作的结果。这个 LLM 可以将这种结果预测纳入其中，从而生成连贯的计划。

即使 AI 不能规划，它仍然可以是规划器的一部分。有可能使用搜索工具和状态跟踪系统来增强 LLM，以帮助它进行规划。

关于RL Agent

Agent 是 RL 中的核心概念。根据维基百科的定义，RL 是一个“关注智能 agent 如何在动态环境中采取行动以最大化累积奖励”的领域。

RL agent 和 FM agent 在许多方面都很相似。它们的共同特点是它们的环境和可能的操作。主要区别在于它们的规划器的工作方式。

在 RL agent 中，规划器由 RL 算法训练。训练这个 RL 规划器可能需要大量的时间和资源。在 FM agent 中，模型本身就是规划器。这个模型可以通过提示或微调来提高其规划能力，而且通常需要更少的时间和资源。

但是，没有什么能阻止 FM agent 采用 RL 算法来提高其性能。从长远来看，FM agent 和 RL agent 将会融合。

planning生成

将模型变成planning生成器的最简单方法是使用提示工程。假设你想创建一个 agent 来帮助客户了解家用显卡的产品。你为该 agent 提供对三个外部工具的访问权限：按价格检索产品、检索热门产品和检索产品信息。下面是一个用于计划生成的提示示例。此提示仅用于说明目的。实际的生产提示可能会更复杂。

system prompt：

提出一个解决任务的计划。你可以使用以下 5 个操作：

*   `get_today_date()`
*   `fetch_top_products(start_date, end_date, num_products)`
*   `fetch_product_info(product_name)`
*   `generate_query(task_history, tool_output)`
*   `generate_response(query)`

计划必须是一系列有效的操作。

**示例：**

**任务：** “告诉我关于 5090 的信息”
**计划：** `[fetch_product_info, generate_query, generate_response]`

**任务：** “上周最畅销的产品是什么？”
**计划：** `[fetch_top_products, generate_query, generate_response]`

**任务：** `{用户输入}`
**计划：**

关于这个例子，有两点需要注意：

这里使用的计划格式——一个函数列表，其参数由 agent 推断——只是构建 agent 控制流的多种方式之一。
generate_query 函数接收任务的当前历史记录和最近的工具输出，以生成要输入到响应生成器的查询。每个步骤的工具输出都会添加到任务的历史记录中。

如果用户输入“上周最畅销产品的价格是多少”，则生成的计划可能如下所示：

get_time()
fetch_top_products()
fetch_product_info()
generate_query()
generate_response()

你可能会想，“每个函数需要的参数是什么？” 确切的参数很难提前预测，因为它们通常是从之前的工具输出中提取的。如果第一步 get_time() 输出“2030-09-13”，那么 agent 可以推断出下一步的参数应该按如下方式调用：

retrieve_top_products(
    start_date="2030-09-07",
    end_date="2030-09-13",
    num_products=1
)

通常，没有足够的信息来确定函数的精确参数值。例如，如果用户问“最畅销产品的平均价格是多少？”，那么以下问题的答案就不清楚：

用户想看多少最畅销的产品？
用户想要的是上周、上个月还是所有时间的最畅销产品？

这意味着模型经常需要进行猜测，而猜测可能会出错。

由于操作序列和相关的参数都是由 AI 模型生成的，它们可能会产生幻觉。幻觉会导致模型调用无效的函数，或者调用有效的函数但参数错误。通常，可以使用提高模型整体性能的技术来提高模型的规划能力。

让 agent 更好地规划的提示：

编写包含更多示例的更好的系统提示。
提供对工具及其参数的更清晰的描述，以便模型更好地理解它们。
重写函数本身，使其更简单，例如将一个复杂的函数重构为两个更简单的函数。
使用更强大的模型。一般来说，更强大的模型更擅长规划。
为规划生成微调模型。

函数调用

现在的模型公司基本都提供了函数调用的能力，从而有效地将它们的模型变成了 agent。工具就是一个函数。因此，调用工具通常称为函数调用。不同的模型 API 的工作方式有所不同，但一般来说，函数调用按以下步骤工作：

创建工具清单。声明你希望模型使用的所有工具。每个工具都由其执行入口点（例如，函数名）、参数和文档（例如，函数的作用以及需要哪些参数）描述。
指定 agent 可以为特定查询使用的工具。

由于不同的查询可能需要不同的工具，因此许多 API 允许你指定每个查询要使用的已声明工具列表。有些允许你通过以下设置进一步控制工具的使用：

required：模型必须使用至少一个工具。
none：模型不应使用任何工具。
auto：模型决定使用哪些工具。

给定一个查询，agent 会自动生成要使用的工具及其参数。某些函数调用 API 将确保仅生成有效的函数，尽管它们无法保证参数值的正确性。

规划粒度

规划是概述完成任务所需步骤的路线图。路线图可以有不同的粒度级别。为一年做计划时，按季度计划比按月计划更高级，而按月计划又比按周计划更高级。

在规划和执行之间存在一种权衡。详细的计划更难生成，但更容易执行。更高级的计划更容易生成，但更难执行。一种规避这种权衡的方法是分层规划。首先，使用规划器生成一个高层次的计划，例如按季度计划。然后，对于每个季度，使用相同或不同的规划器生成一个按月计划。

到目前为止，所有生成的计划示例都使用确切的函数名称，这非常细粒度。这种方法的一个问题是 agent 的工具清单会随着时间推移而改变。例如，获取当前日期的函数 get_time() 可以重命名为 get_current_time()。当工具发生变化时，你需要更新你的提示和所有示例。使用确切的函数名称也使得在具有不同工具 API 的不同用例中重用规划器变得更加困难。

如果你之前微调过一个模型以基于旧的工具清单生成计划，则你需要使用新的工具清单再次微调该模型。

为了避免这个问题，计划也可以使用更自然的语言生成，这种语言比特定领域的函数名称更高级。例如，给定查询“上周最畅销产品的价格是多少”，可以指示 agent 输出如下所示的计划：

获取当前日期   检索上周最畅销的产品   检索产品信息   生成查询   生成响应

使用更自然的语言有助于你的计划生成器更好地应对工具 API 的变化。如果你的模型主要是在自然语言上训练的，它可能会更擅长理解和生成自然语言的计划，并且不太可能出现幻觉。

这种方法的缺点是你需要一个翻译器来将每个自然语言操作转换为可执行的命令。Chameleon中将这个翻译器称为程序生成器。但是，翻译是一项比规划简单得多的任务，并且可以通过幻觉风险较低的弱模型来完成。

复杂规划

到目前为止的规划示例都是顺序的：计划中的下一个操作总是在前一个操作完成后执行。可以执行操作的顺序称为控制流。顺序形式只是控制流的一种类型。其他类型的控制流包括并行、if 语句和 for 循环。以下列表概述了每种控制流，包括用于比较的顺序：

顺序

在任务 A 完成后执行任务 B，可能是因为任务 B 依赖于任务 A。例如，SQL 查询只能在从自然语言输入翻译后执行。
并行

同时执行任务 A 和 B。例如，给定查询“查找 100 元以下的畅销产品”，agent 可能会先检索前 100 名畅销产品，然后为每个产品检索其价格。
If 语句

根据上一步的输出执行任务 B 或任务 C。例如，agent 首先检查宁德时代的财务报告。根据此报告，它可以决定出售或购买宁德时代股票。Anthropic 的帖子将此模式称为“路由”。
For 循环

重复执行任务 A，直到满足特定条件。例如，持续生成随机数，直到出现质数。

Agent 控制流

在传统的软件工程中，控制流的条件是精确的。对于 AI 驱动的 agent，AI 模型决定控制流。具有非顺序控制流的计划更难生成和转换为可执行的命令。

在评估 agent 框架时，请检查它支持哪些控制流。例如，如果系统需要浏览十个网站，它可以同时进行吗？并行执行可以显著减少用户感知的延迟。

反思和错误纠正

即使是最好的计划也需要不断评估和调整，以最大限度地提高其成功的机会。虽然反思对于 agent 的运行并非绝对必要，但对于 agent 的成功至关重要。

在任务过程中，有很多地方可以使用反思：

在收到用户查询后评估请求是否可行。
在初始计划生成后评估该计划是否合理。
在每个执行步骤之后评估它是否在正确的轨道上。
在整个计划执行完毕后确定任务是否已完成。

反思和错误纠正是相辅相成的两种不同机制。反思产生有助于发现需要纠正的错误的见解。

反思可以使用具有自我批评提示的同一个 agent 来完成。它也可以使用单独的组件来完成，例如专用评分器：一个为每个结果输出具体分数的模型。

ReAct 首先提出，交错推理和行动已成为 agent 的常见模式。在每一步，都会要求 agent 解释其想法（规划）、采取行动，然后分析观察结果（反思），直到 agent 认为任务完成。通常会使用示例提示 agent 以以下格式生成输出：

想法 1: ...   行动 1: ...   观察 1: ...      ... [继续，直到反思确定任务已完成] ...      想法 N: ...   行动 N: 完成 [对查询的响应]

你可以在多 agent 设置中实现反思：一个 agent 规划并采取行动，另一个 agent 在每个步骤或多个步骤后评估结果。

如果 agent 的响应未能完成任务，你可以提示 agent 反思失败的原因以及如何改进。基于此建议，agent 生成新计划。这使 agent 可以从错误中学习。

例如，给定一个代码生成任务，评估器可能会评估生成的代码在 ⅓ 的测试用例中失败。然后，agent 反思失败的原因是它没有考虑到所有数字都是负数的数组。然后，执行器生成新代码，其中考虑了所有负数数组。

这是 Reflexion 采用的方法。在此框架中，反思分为两个模块：一个评估结果的评估器和一个分析哪里出错的自我反思模块。下图是Reflexion agent 的工作示例。作者使用术语“trajectory”来指代规划。在每一步之后，经过评估和自我反思，agent 都会提出新的trajectory。

与规划生成相比，反思相对容易实现，并且可以带来令人惊讶的性能提升。这种方法的缺点是延迟和成本。想法、观察，有时还有行动可能需要生成大量的 token，这会增加成本和用户感知的延迟，特别是对于有很多中间步骤的任务。为了促使他们的 agent 遵循格式，ReAct 和 Reflexion 的作者都在他们的提示中使用了大量的示例。这会增加计算输入 token 的成本，并减少可用于其他信息的上下文空间。

工具选择

由于工具通常在任务的成功中起着至关重要的作用，因此工具选择需要仔细考虑。为你 agent 提供的工具取决于环境和任务，但也取决于驱动 agent 的 AI 模型。

没有关于如何选择最佳工具集的万无一失的指南。在 agent 文献中，你会发现各种各样的工具清单。例如：

Toolformer (Schick et al., 2023) 微调 GPT-J 以学习 5 个工具。
Chameleon (Lu et al., 2023) 使用 13 个工具。
Gorilla (Patil et al., 2023) 尝试提示 agent 在 1,645 个 API 中选择正确的 API 调用。

更多的工具可以为 agent 提供更多的功能。但是，工具越多，就越难有效地使用它们。这类似于人类难以掌握大量工具的情况。添加工具也意味着增加工具描述，这可能不适合模型的上下文。

与构建 AI 应用程序时的许多其他决策一样，工具选择需要实验和分析。以下是一些可以帮助你做出决定的事情：

比较 agent 在不同工具集下的表现。
进行消融研究，以查看如果从其清单中删除某个工具，agent 的性能会下降多少。如果可以删除某个工具而不会降低性能，则将其删除。
查找 agent 经常出错的工具。如果事实证明某个工具对于 agent 来说太难使用（例如，大量的提示甚至微调都无法让模型学会使用它），请更改该工具。
绘制工具调用的分布图，以查看哪些工具使用最多，哪些工具使用最少。图 6-14 显示了 GPT-4 和 ChatGPT 在 Chameleon (Lu et al., 2023) 中的工具使用模式差异。

不同模型具有不同的工具偏好