在三月份红杉资本的 AI Ascent 大会上，我谈到了 Agent 的三个局限性：规划、用户体验和记忆。查看那次演讲此处。在这篇文章中，我将更深入地探讨 Agent 的规划。
如果您询问任何使用 LLM 构建 Agent 的开发者，他们可能会指出 Agent 无法良好地规划和推理是 Agent 可靠性的一个主要痛点。规划对于 Agent 意味着什么？我们如何看待人们目前正在克服这一缺点？Agent 的规划和推理的未来（我们最好的猜测）会是什么样子？我们将在下面涵盖所有这些内容。
规划和推理究竟是什么意思？
Agent 的规划和推理涉及 LLM 思考要采取哪些行动的能力。这包括短期和长期步骤。LLM 评估所有可用信息，然后决定：我需要采取哪些步骤，现在应该采取的第一个步骤是什么？
大多数时候，开发者使用 函数调用（也称为工具调用）来让 LLM 选择要采取的行动。函数调用是 OpenAI 在 2023 年 6 月首次添加到 LLM API 的一项功能，然后 在 2023 年底/2024 年初被其他人添加到 LLM API。通过函数调用，您可以为不同的函数提供 JSON 模式，并让 LLM 输出对象匹配其中一个（或多个）模式。有关如何执行此操作的更多信息，请参阅我们的指南此处。
函数调用用于让 Agent 选择要作为立即行动执行的操作。然而，通常为了成功完成复杂的任务，您需要按顺序执行多个操作。这种长期规划和推理对于 LLM 来说是一项更艰巨的任务，原因有几个。首先，LLM 必须考虑更长远的目标，然后跳回到要采取的短期行动。其次，随着 Agent 采取越来越多的行动，这些行动的结果会反馈给 LLM；这会导致上下文窗口增长，这可能会导致 LLM “分心”并表现不佳。
与 LLM 世界中的大多数事物一样，很难准确衡量当前模型在规划和推理方面的表现。有一些合理的基准，例如用于评估函数调用的 Berkeley 函数调用排行榜。我们已经做了一些关于评估多步骤应用程序的 少量研究。但获得对此的了解的最佳方法是为您的特定问题构建一个评估集，并尝试自己进行评估。
目前有哪些改进 Agent 规划的措施？
改进规划最容易实现的措施是确保 LLM 拥有进行适当推理/规划所需的所有信息。尽管这听起来很简单，但通常传递给 LLM 的提示根本不包含足够的信息让 LLM 做出合理的决策。添加检索步骤或澄清提示说明可能是一个简单的改进。这就是为什么实际查看数据并了解 LLM 实际看到的内容至关重要。
之后，我建议您尝试更改应用程序的认知架构。“认知架构”是指您的应用程序用于推理的数据工程逻辑。您可以考虑使用两种类型的认知架构来改进推理：通用认知架构和领域特定认知架构。
通用认知架构 vs 领域特定认知架构
通用认知架构试图以通用方式实现更好的推理。它们可以应用于任何任务。一个很好的例子是“计划和解决”架构。这篇论文探讨了一种架构，其中首先提出一个计划，然后执行该计划中的每个步骤。另一种通用架构是 Reflexion 架构。这篇论文探讨了在 Agent 完成任务后添加一个明确的“反思”步骤，以反思它是否正确地完成了任务。
尽管这些想法显示出改进，但它们通常过于通用，无法在生产中的 Agent 中实际使用。相反，我们看到 Agent 是使用领域特定的认知架构构建的。这通常体现在领域特定的分类/路由步骤、领域特定的验证步骤中。规划和反思的一些通用想法可以应用于此处，但它们通常以领域特定的方式应用。
作为一个具体的例子，让我们看看 AlphaCodium 论文。它通过使用他们所谓的“流程工程”（另一种谈论认知架构的方式）实现了最先进的性能。请参阅下面他们使用的流程图。
该流程非常特定于他们试图解决的问题。他们告诉 Agent 分步骤地做什么 - 提出测试，然后提出解决方案，然后迭代更多测试等等。这种认知架构是高度领域特定的 - 例如，它对您撰写文章没有帮助。
为什么领域特定的认知架构如此有用？
我喜欢从两个方面来思考这个问题。
首先：您可以将此视为仅仅是另一种向 Agent 传达它应该做什么的方法。您可以在提示说明中传达指令，也可以在代码中硬编码特定的转换。任何一种都是有效的！代码是传达您想要发生的事情的绝佳方式。
其次：这本质上是将规划责任从 LLM 转移到我们工程师身上。我们基本上是在说：“不用担心规划，LLM，我会为你做的！” 当然，我们并没有完全消除 LLM 的所有规划，因为我们仍然要求它在某些情况下进行一些规划。
例如，让我们回顾一下上面的 AlphaCodium 示例。流程中的步骤基本上是我们为 LLM 做规划！我们告诉它首先编写测试，然后编写代码，然后运行测试等等。这大概是作者认为编写软件的一个好计划。如果他们正在计划如何解决问题，这就是他们会做的方式。与其在提示中告诉 LLM - 它可能会忽略、不理解、没有所有细节 - 不如他们通过构建领域特定的认知架构来告诉系统去做。
我们正在通过 LangGraph 使构建这些定制认知架构变得更容易。LangGraph 的重点之一是可控性。我们将 LangGraph 设计得非常底层且高度可控 - 这是因为我们已经看到，创建可靠的定制认知架构 100% 需要这种程度的可控性。
规划和推理的未来会是什么样？
LLM 领域一直在快速变化和发展，我们在构建应用程序时，尤其是在构建工具时，应该牢记这一点。
我目前的看法是，通用推理将越来越多地被模型层吸收。模型将变得越来越智能，无论是通过规模还是研究突破 - 押注它不会发生似乎是愚蠢的。模型也将变得更快更便宜，因此将大量上下文传递给它们将变得越来越可行。
但是，我相信无论模型变得多么强大，您始终需要以某种形式向 Agent 传达它应该做什么。因此，我相信提示和定制架构将继续存在。对于简单的任务，提示可能就足够了。对于更复杂的任务，您可能希望将它的行为逻辑放入代码中。代码优先的方法可能更快、更可靠、更易于调试，并且通常更容易/更符合逻辑地表达。
我最近与红杉资本的 Sonya 和 Pat 一起参加了一个播客，讨论了这个话题。他们绘制了一个很棒的图表，展示了提示、认知架构和模型的作用/重要性如何随时间演变。
因此，尽管 LLM 的规划和推理肯定会变得更好，但我们也坚信，如果您正在构建特定于任务的 Agent，那么您将需要构建定制的认知架构。这就是为什么我们对 LangGraph 的未来如此看好。