本文是 LangChain 官方发布的关于 Agent 的系列文章，这里我将其汇总和翻译了一下

什么是智能体？

“什么是智能体？”

我几乎每天都会被问到这个问题。在 LangChain，我们构建工具来帮助开发人员构建大语言模型 (LLM) 应用程序，尤其是那些作为推理引擎并与外部数据和计算源交互的应用程序。这类系统通常被称为“智能体”。

每个人对智能体的定义似乎都有些不同。我的定义可能比大多数人的更技术化：

即便在这里，我也不得不承认我的定义并不完美。人们常常认为智能体是高级的、自主的、类人的——但如果只是一个简单系统，其中大语言模型 (LLM) 在两条路径之间进行选择呢？这虽然符合我的技术定义，但并不符合大家对智能体能力的普遍认知。智能体到底是什么，确实很难准确定义！

这就是为什么我非常喜欢 Andrew Ng 上周的推文。在推文中，他建议“与其争论哪些工作应该包含或排除为真正的智能体，我们可以承认系统的智能行为有不同的程度。”就像自动驾驶汽车有不同的自动驾驶级别一样，我们也可以将智能体的能力视为一个光谱。我非常同意这个观点，我认为 Andrew 表达得很好。未来，当有人问我什么是智能体时，我会转而讨论什么是“智能行为”。

智能行为是什么意思？

去年我做了一个关于 LLM 系统的 TED 演讲，并使用下面的幻灯片来讨论 LLM 应用程序中存在的不同自主级别。

一个系统越“智能”，LLM 决定系统行为的程度就越高。

使用 LLM 将输入路由到特定下游工作流具有一定程度的“智能”行为。这会在上图的Router类别中。

如果你使用多个 LLM 进行多个路由步骤？这会介于Router和State Machine之间。

如果其中一个步骤是确定是否继续或结束——有效地允许系统在完成之前循环运行？这会属于State Machine。

如果系统正在构建工具，记住这些工具，然后在未来的步骤中使用它们？这类似于Voyager 论文中实现的，非常智能，属于更高的Autonomous Agent类别。

这些“智能”定义仍然非常技术化。我更喜欢“智能”的技术定义，因为我认为它在设计和描述 LLM 系统时很有用。

为什么“智能”是一个有用的概念？

与所有概念一样，值得问的是我们为什么需要“智能”这个概念。它有何帮助？

了解你的系统有多智能可以指导你在开发过程中的决策——包括构建、运行、与之交互、评估甚至监控它。

你的系统越智能，编排框架就越有帮助。如果你正在设计一个复杂的智能系统，拥有一个具有正确抽象概念的框架可以加速开发。这个框架应该对分支逻辑和循环有一流的支持。

你的系统越智能，运行就越困难。它会越来越复杂，某些任务将需要很长时间才能完成。这意味着你会希望将任务作为后台运行。这也意味着你希望有持久的执行能力来处理中途发生的任何错误。

你的系统越智能，你就越希望在运行时与它交互。你会希望能够观察内部发生的情况，因为所采取的确切步骤可能事先未知。你会希望能够在特定时间点修改智能体的状态或指令，如果它偏离了预定路径，可以将其拉回正轨。

你的系统越智能，你就越希望有一个为这些类型的应用程序构建的评估框架。你会希望多次运行评估，因为有大量随机性叠加。你会希望能够不仅测试最终输出，还测试中间步骤，以测试智能体的效率。

你的系统越智能，你就越希望有一个新型的监控框架。你会希望能够深入了解智能体所采取的所有步骤。你还会希望能够根据智能体所采取的步骤查询运行情况。

了解和利用系统中的智能能力光谱可以提高开发过程的效率和健壮性。

智能是新的

我经常思考的一个问题是，在这场热潮中，什么是真正新的。我们是否需要为人们构建的 LLM 应用程序提供新工具和新基础设施？还是以前的通用工具和基础设施就足够了？

对我来说，你的应用程序越智能，拥有新工具和基础设施就越关键。这正是促使我们构建LangGraph，一个帮助构建、运行和交互智能体的编排器，以及LangSmith，一个用于 LLM 应用程序的测试和可观测性平台。随着我们在智能光谱上不断前进，支持性工具的整个生态系统需要重新构想。

什么是“认知架构”？

更新：有几位读者指出，“认知架构”这个术语在神经科学和计算认知科学中有丰富的历史。根据维基百科的定义，“认知架构”既指关于人类心智结构的理论，也指这种理论的计算实现。这个定义（以及相关的研究和文章）比我在这里提供的定义更为全面。所以这篇博客应该被视为我在过去一年中构建和帮助构建基于大语言模型 (LLM) 应用程序的经验与这一研究领域的对照。

在过去的六个月里，我经常使用“认知架构”这个短语，而且以后可能会更多地使用。这是我第一次从 Flo Crivello 那里听到的术语——所有的功劳都归于他，我认为这是一个很棒的术语。那么我究竟指的是什么呢？

我所说的认知架构是指你的系统如何“思考”——换句话说，就是代码、提示和 LLM 调用的流程，它们接收用户输入并执行操作或生成响应。

我喜欢“认知”这个词，因为智能系统依赖于 LLM 来进行推理。

我喜欢“架构”这个词，因为这些智能系统仍然涉及大量类似于传统系统架构的工程。

将自主水平映射到认知架构

如果我们回顾一下这张幻灯片（最初来自我的 TED 演讲），关于 LLM 应用程序中不同的自主水平，我们可以看到不同认知架构的例子。

首先是代码——所有内容都是硬编码的。这实际上不能称之为认知架构。

其次是单一的 LLM 调用。虽然可能有一些前处理和/或后处理，但主要部分是单一的 LLM 调用。简单的聊天机器人可能属于这一类。

接下来是 LLM 调用链。这种序列可以将问题分解成不同的步骤，或者用于不同的目的。更复杂的 RAG 管道属于这一类：第一次 LLM 调用生成搜索查询，第二次 LLM 调用生成答案。

再往后是路由器。在此之前，你会提前知道应用程序将采取的所有步骤。现在，你不再知道了。LLM 决定采取哪些操作，这增加了一些随机性和不可预测性。

再下一层是状态机。这是将 LLM 路由与循环结合起来。这更加不可预测，因为理论上，系统可以调用无限次 LLM。

最高级别是我称之为“智能体”或“自主智能体”的层次。对于状态机，仍然有对可以采取的操作和后续流程的限制。而对于自主智能体，这些限制被移除了。系统本身开始决定可以采取的步骤及其指令：这可以通过更新提示、工具或代码来实现。

选择认知架构

当我谈到“选择认知架构”时，我指的是选择你想采用的架构。这些架构没有一个绝对“更好”，它们都有其在不同任务中的用途。

在构建 LLM 应用程序时，你可能会像实验提示一样频繁地实验不同的认知架构。我们正在构建 LangChain 和 LangGraph 以实现这一点。过去一年中，我们的大部分开发工作都投入到了构建低级、可高度控制的编排框架 (LCEL 和 LangGraph) 中。

这与早期的 LangChain 略有不同，早期的 LangChain 专注于易于使用的现成链条。这些对于入门很有用，但难以定制和实验。早期大家都在尝试入门时，这还可以，但随着领域的成熟，这种设计很快就达到了极限。

我对我们过去一年里为了使 LangChain 和 LangGraph 更灵活和可定制而做出的改变感到非常自豪。如果你只通过高级包装器使用过 LangChain，请查看低级部分。它们更可定制，并且真的能让你控制应用程序的认知架构。

如果你正在构建简单的链条和检索流程，请查看 Python 和 JavaScript 中的 LangChain。对于更复杂的智能工作流，请尝试 Python 和 JavaScript 中的 LangGraph。

为什么你应该外包代理基础设施，但保留自己的认知架构

当 OpenAI Assistants API 推出时，这是朝代理未来迈出的重要一步。它将 OpenAI 从一家生产大语言模型 (LLM) API 的公司转变为一家生产代理 API 的公司。

我认为 OpenAI Assistants API 在几个方面做得很好——它引入了许多新的、有用的基础设施，特别是针对代理应用程序的运行。同时，它限制了可以在其上构建的复杂（且有价值的）“认知架构”。

这显示了“代理基础设施”和“认知架构”之间的区别。Jeff Bezos 有一句精辟的话：“专注于让你的啤酒味道更好”。如果我们把这个比喻应用到构建代理的公司：

代理基础设施的需求

OpenAI 准确把握了开发者对更好代理应用程序运行基础设施的需求。特别是：

• 通过提示和工具“配置”助手的能力，使得开始创建不同的代理变得容易
• 将助手作为后台运行，使得管理长期工作流变得更容易
• 内置的消息持久化功能使得管理状态变得容易

这些都是开发者不应该操心的事情。这些都不会使你的应用程序与众不同——用 Jeff Bezos 的话说，它们不会让你的啤酒味道更好。

还有更多的基础设施可以建设来帮助开发者！在 OpenAI Assistants API 中，目前无法在同一个线程上运行多个进程。你也不能轻易地修改线程的状态。不过，Assistants API 是朝着正确方向迈出的重要一步。

应用程序特定的认知架构的重要性

Assistants API 的问题在于它限制了你能在其上轻松构建的内容。

如果你想构建一个聊天机器人——太棒了！线程的“状态”是消息列表，非常适合这个用途。

如果你想构建一个简单的 ReAct 风格代理——很好！它也适合这个用途——基本上就是在 while 循环中运行一个大语言模型。

但代理应用程序不仅仅是一个单一的聊天模型重复调用相同的工具和提示。它们需要跟踪比消息列表复杂得多的状态。对应用程序状态和流程的控制对于带来任何可靠性都是至关重要的。

通过与数千名开发者的合作，我们发现那些成功投入生产的代理都有各自独特的认知架构。应用程序的认知架构是使其真正发挥作用的方法——这是团队创新的地方，也是他们使应用程序与众不同的关键——使啤酒味道更好的关键。

这并不是说你不能用 Assistants API 做更复杂的事情。你可能可以。但 API 不会让它变得容易。它并不鼓励你这么做。OpenAI 押注于一个通用的认知架构，这使得构建特定应用程序的认知架构变得困难，从而使代理变得可靠。

为什么我们在意？

为什么我如此在意？为什么我写了这么多字？因为我真的认为 OpenAI 在很多方面做对了，他们在市场早期就认识到代理基础设施的必要性。他们让开发者不必担心在哪里存储代理状态，如何管理任务队列等——这很棒。

我们在 LangChain 的目标是让构建代理应用程序变得尽可能容易。这种基础设施绝对是必要的一部分。

我们希望将代理基础设施的好处与 LangGraph 提供的对认知架构的控制相结合。这就是我们构建 LangGraph Cloud 的原因。用LangGraph编写你的自定义认知架构，然后用LangGraph Cloud部署它，获得这种代理基础设施的所有好处。

LangGraph Cloud 提供面向现实世界互动的容错扩展性。我们设计了水平扩展的任务队列和服务器，内置的持久化层针对高负载进行了优化，并在运行过程中对节点进行可配置缓存。这让你可以专注于应用程序的独特部分，并将其他部分外包。

总之，专注于让你的啤酒味道更好：认知架构，而不是基础设施。

智能体的规划

在三月份的 Sequoia AI Ascent 会议上，我讨论了 AI 智能体的三个局限：规划、用户体验 (UX) 和记忆。你可以在 这里观看我的演讲。在这篇文章中，我将深入探讨智能体的规划问题。

如果你问任何一个使用大语言模型 (LLM) 构建智能体的开发者，他们很可能会提到智能体在规划和推理方面的不足是其可靠性的一大痛点。规划对智能体意味着什么？人们目前是如何克服这一缺点的？未来智能体在规划和推理方面会有怎样的发展？我们将在下面讨论这些问题。

规划和推理到底是什么意思？

智能体的规划和推理涉及大语言模型在选择行动时的思考过程。这包括短期和长期步骤。大语言模型评估所有可用信息，然后决定需要采取的步骤，以及当前应采取的第一个步骤。

大多数情况下，开发人员使用 函数调用（也称为工具调用）来让大语言模型选择行动。函数调用是 OpenAI 于 2023 年 6 月首次添加到大语言模型 API 中的功能，之后在 2023 年末/2024 年初由其他公司引入。通过函数调用，你可以为不同的函数提供 JSON 架构，让大语言模型的输出对象匹配这些架构。更多信息请参见我们的指南这里。

函数调用用于选择智能体的即时行动。然而，成功完成复杂任务往往需要一系列连续的步骤。长期规划和推理对大语言模型来说是个挑战，有几个原因。首先，模型需要考虑更长远的目标，然后回到当前的行动。其次，随着智能体采取更多行动，这些行动的结果会反馈给大语言模型，导致上下文窗口增长，可能会使模型“分心”并表现不佳。

像大多数大语言模型领域的问题一样，衡量当前模型在规划和推理方面的表现非常困难。虽然有一些合理的基准，例如评估函数调用的 伯克利函数调用排行榜，我们也对多步骤应用进行了一些研究。但是，最好的方法是为你的特定问题建立评估集，并尝试自己评估。

目前有哪些改进智能体规划的方法？

最简单的改进方法是确保大语言模型拥有所有必要的信息进行合理的推理和规划。虽然这听起来很基础，但传递给大语言模型的提示通常信息不足，无法做出合理的决定。添加检索步骤或澄清提示说明可以显著改善结果。这就是为什么查看数据并了解大语言模型实际看到的内容非常重要。

接下来，我建议尝试改变应用的认知架构。所谓“认知架构”，指的是应用用来推理的数据处理逻辑。你可以考虑两类认知架构：通用认知架构和特定领域认知架构。

通用认知架构与特定领域认知架构

通用认知架构试图以通用方式实现更好的推理，适用于任何任务。一个例子是“计划和解决”架构。这篇论文探讨了一种先制定计划再执行每一步的架构。另一个例子是 Reflexion 架构。这篇论文探讨了在智能体完成任务后增加一个反思步骤，以检查任务是否正确完成。

虽然这些通用方法有所改进，但它们通常对实际生产中的智能体不太实用。相反，我们看到更多的是特定领域的认知架构。这通常表现为特定领域的分类/路由步骤和验证步骤。虽然规划和反思的一些通用理念可以应用于这些领域，但它们通常以特定领域的方式应用。

例如，AlphaCodium 论文通过使用他们称为“流程工程”的方法达到了最先进的性能。请参见下图。

这个流程非常具体，针对他们要解决的问题。智能体被指示按步骤执行——先提出测试，再提出解决方案，然后不断迭代更多测试等。这种认知架构高度领域特定——不会帮助你写文章。

为什么特定领域认知架构如此有用？

我从两个角度来看待这个问题。

首先：这是一种与智能体沟通应做什么的方式。你可以在提示中传达指令，或者在代码中硬编码特定的步骤。两者都是有效的！代码是一种绝佳的沟通方式。

其次：这实际上是将规划责任从大语言模型转移到我们工程师身上。我们基本上是在说：“不用担心规划，大语言模型，我来帮你！”当然，我们并不是完全移除所有规划，因为我们仍然在某些情况下要求大语言模型进行一些规划。

例如，在 AlphaCodium 的例子中，流程中的步骤实际上是我们为大语言模型进行的规划！我们告诉它先进行测试，然后编写代码，然后运行测试等。这大概是作者认为的编写软件的好计划。如果他们在规划如何解决问题，这就是他们会做的方式。与其在提示中告诉大语言模型去做——它可能会忽略、无法理解或缺乏细节——他们通过构建一个特定领域的认知架构来指导系统。

我们正在通过 LangGraph 使构建这些定制认知架构变得更容易。LangGraph 的一个主要关注点是可控性。我们设计了 LangGraph，使其非常底层和高度可控，因为我们看到这种可控性在创建可靠的定制认知架构时是绝对必要的。

规划和推理的未来是什么样的？

大语言模型领域正在快速变化和发展，我们在构建应用程序时应牢记这一点，尤其是在构建工具时。

我目前的看法是，通用推理将越来越多地被吸收到模型层。模型将变得越来越智能，无论是通过规模还是研究突破——似乎对这一点下注是愚蠢的。模型将变得更快更便宜，因此传递大量上下文给它们将变得越来越可行。

然而，我相信无论模型变得多么强大，你都需要以某种形式与智能体沟通它应该做什么。因此，我相信提示和定制架构将继续存在。对于简单任务，提示可能就足够了。对于更复杂任务，你可能希望将其行为逻辑放在代码中。代码优先的方法可能更快、更可靠、更易调试，并且通常更容易表达。

我最近在 播客 上与 Sequoia 的 Sonya 和 Pat 谈论了这个话题。他们画了一张很棒的图表，展示了提示、认知架构和模型的重要性/角色如何随着时间的推移而演变。

因此，虽然大语言模型的规划和推理肯定会变得更好，但我们也坚信，如果你在构建特定任务的智能体，那么你将需要构建一个定制的认知架构。这就是我们对 LangGraph 的未来充满信心的原因。