LangChain 推出 Plan-and-Execute 智能体执行器

TL;DR：我们推出了一种新型的代理执行器，我们称之为“计划与执行”。这是为了与我们之前支持的代理类型形成对比，我们称后者为“行动”代理。计划与执行代理深受 BabyAGI 和最近的 Plan-and-Solve 论文的启发。我们认为计划与执行非常适合更复杂的长期规划，代价是更多地对语言模型进行调用。我们将此初始版本放在 experimental 模块中，因为我们预计会有快速变化。

链接：

到目前为止，LangChain 中的所有代理都遵循 ReAct 论文开创的框架。我们称这些为“行动代理”。这些代理的算法大致可以用以下伪代码表示：

接收到一些用户输入
代理决定使用哪个工具——如果有的话——以及该工具的输入应该是什么
然后使用该工具输入调用该工具，并记录一个观察结果（这只是使用该工具输入调用该工具的输出）
工具、工具输入和观察结果的历史记录被传回给代理，代理决定下一步采取什么行动
重复此过程，直到代理决定不再需要使用工具，然后直接回复用户。

这种风格到目前为止一直运行良好，但有几件事正在发生变化，给这个算法带来了一些裂痕：

用户目标变得越来越复杂
开发者和组织开始在生产中依赖代理

这产生了双重影响：既希望代理系统能够处理更复杂的请求，又希望它更加可靠。这两个因素结合在一起，迅速导致提示大小增加：

随着目标变得更加复杂，越来越多的历史记录被包含进来，以保持代理专注于最终目标，同时允许它记住并推理之前的步骤
随着开发者试图提高可靠性，他们围绕如何使用工具包含了更多指令

对日益复杂的能力和更高可靠性的需求，在与大多数语言模型合作时引发了问题。

计划与执行实现

在这方面，我们看到了一种新型代理框架的出现。这些代理框架试图将更高层次的规划与短期执行分开。具体来说，它们首先规划要采取的步骤，然后迭代地执行这些步骤。当然，这个核心算法有几个有趣的变体（我们稍后可以讨论）。这些代理的伪代码，我们称之为“计划与执行”代理，看起来像：

规划要采取的步骤
对于步骤中的每一步：确定合适的工具或其他最佳行动方案来完成该步骤

这是用 Python 和 TypeScript 实现的核心代理框架。这个代理框架依赖于两件事：规划器和执行器。

我们先谈谈规划器。这几乎总应该是一个语言模型。这将利用语言模型的推理能力来规划要做什么，并处理模糊性/边缘情况。我们可以在最后添加一个输出解析器，将原始 LLM 输出解析为一个字符串列表（每个字符串是一个步骤）。

现在我们来谈谈执行器。在最初的实现中，我们将其设为一个 Action Agent。这允许执行器 agent 接收一个高层目标（单个步骤），并确定使用哪些工具来完成它（可以一步或两步完成）。

这种方法有几个好处。它将规划与执行分离——这允许一个 LLM 专注于规划，另一个专注于执行。这使得两方面都更加可靠。这也使得将来更容易将这些组件替换为更小的微调模型。这种方法的主要缺点是它需要更多的调用。然而，由于关注点分离，我们希望这些调用可以交给更小（因此更快、更便宜）的模型。

未来方向

我们认为这只是 plan-and-execute agent 的开端。未来方向包括：

更好地支持长步骤序列。目前之前的步骤以列表形式传递——随着规划步骤越来越长，我们会希望将其存储在 vectorstore 中并检索中间步骤
重新审视计划。目前开始时有一个规划步骤，但之后从未重新审视。我们很可能需要某种机制来重新审视和调整计划，可以是每一步或按需进行。
评估。目前，这些改进大多还停留在理论层面，或者至少没有基准测试。我们希望能有更严格的方法来评估 agent 框架。
执行链的选择。目前只有单一执行链。很可能你会想要多个执行链，并由规划器指定使用哪一个。例如，如果你有一个针对网络研究优化的执行链，一个用于分析，等等。

值得注意的是，对于许多这些未来方向，我们可以从现有工作中汲取灵感。例如，BabyAGI 已经使用 vectorstore 来存储中间步骤，并在每次迭代中重新审视规划。Plan-and-Solve 论文通过基准测试对输出进行了更严格的评估。

结论

我们非常兴奋地看到这种新的 agent 范式在 BabyAGI 中出现（我们在几周前的文章中将其列为重大差异点之一）。我们同样兴奋地看到 Plan-and-Solve 论文作为对类似思想的严格评估出现。我们期待看到 Plan-and-Execute 方法如何演变——在这里（Python）或这里（JS）试试吧。