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

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

链接：

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

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

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

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

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

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

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

计划-执行实现

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

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

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

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

现在让我们谈谈执行器。在我们最初的实现中，我们将其设为一个行动代理。这使得执行器代理能够接收一个高层次目标（单个步骤），并确定使用哪些工具来完成它（可以一步或两步完成）。

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

未来方向

我们认为这只是计划-执行代理的开始。未来方向包括：

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

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

结论

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