对于Agent的定义，似乎每个人心中都有不同的答案，Langchain 的创始人 Harrison Chase 是这样定义的，“Agent是一个使用大语言模型（LLM）来决定应用程序控制流的系统。”与其纠结Agent怎么定义，我更喜欢吴恩达之前在推特上面说的这样一句话，“与其争论什么应被归类为真正的智能体，不如承认系统具有不同程度的智能体特性（agentic）。”

是的，我觉得真正的智能体不应该被归类为某一种，而是它在解决某个问题、某件事情上面，它具备解决这件事情的能力。

Langchain 的创始人 Harrison Chase 在博客分享了他对 AI Agent 的思考和看法，我对作者的文章进行整理和翻译，看完这一篇，我相信，你会对 Agent、认知架构、如何规划有更加深刻的理解和启发。

写在前面

读完此篇，我们可以知道，智能体不仅仅是一个技术定义，它还涉及到系统如何“思考和决策”。

要让智能体真正管用，我们就得好好设计它们的认知架构，这就像是智能体的大脑，决定了它们怎么接收信息、怎么干活、怎么回应。而且，即使那些大模型越来越牛，但要让智能体在特定的任务上表现得好，还是得有定制的认知架构。

在设计智能体的时候，得在智能体基础设施的方便性和认知架构的个性化之间找到平衡点，这样才能让智能体表现得最好。

01 什么是智能体？

什么是智能体？Harrison 几乎每天都会被问到这个问题。在LangChain，我们构建工具帮助开发者创建大语言模型（LLM）应用程序，特别是那些作为推理引擎并与外部数据和计算资源交互的系统。这些系统通常被称为“智能体”。

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

即便如此，我承认我的定义并不完美。人们通常认为智能体是高级的、自主的、类似人类的——但如果是一个简单的系统，LLM只是在两条不同路径之间进行路由选择呢？这符合我的技术定义，但与人们普遍对智能体应具备的能力认知不一致。要精确定义什么是智能体，确实非常困难！

因此，我非常喜欢吴恩达发过的一篇推文。在推文中，他建议“与其争论什么应被归类为真正的智能体，不如承认系统具有不同程度的智能体特性（agentic）。”就像自动驾驶汽车有不同的自动化等级一样，我们也可以将智能体的能力视作一个光谱。我非常赞同这一观点，并且认为Andrew表达得非常到位。未来，当再有人问我什么是智能体时，我将转而讨论什么是“智能体特性”。

什么是智能体特性？

去年在一场关于LLM系统的TED演讲中，Harrison 使用了下面这张幻灯片，来讨论LLM应用中不同的自主性级别。

系统越依赖LLM来决定其行为方式，它就越具有“智能体特性”。

使用LLM将输入路由到特定的下游工作流中，表现出少许“智能体”行为。这会归类为上图中的Router（路由器）类别。

如果你使用多个LLM执行多个路由步骤呢？这会介于Router和State Machine（状态机）之间。

如果其中一个步骤是在决定是否继续或结束——实际上允许系统循环运行直到完成？那么这就会归类为State Machine。

如果系统能够构建工具，记住它们，并在后续步骤中再次使用它们？这与Voyager论文所实现的功能类似，并且是非常具有智能体特性的，属于更高的Autonomous Agent（自主智能体）类别。

这些关于“智能体特性”的定义仍然相当技术化。我更倾向于这种技术性的定义，因为在设计和描述LLM系统时，这种定义非常实用。

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

正如所有概念一样，我们有必要思考，为什么我们需要“智能体特性”这个概念？它有什么帮助？

了解系统的智能体特性能够指导你在开发过程中做出决策——包括构建、运行、与之交互、评估，甚至是监控。

系统的智能体特性越强，编排框架的作用就越大。如果你正在设计一个复杂的智能体系统，拥有一个具备这些概念的抽象框架能够加速开发。这个框架应该支持一流的分支逻辑和循环控制。

系统的智能体特性越强，运行难度就越大。它会变得更加复杂，有些任务可能需要很长时间才能完成。这意味着你可能需要将任务设为后台运行。同时，也需要具备持久执行能力，以应对任务过程中出现的错误。

系统的智能体特性越强，你就越希望在系统运行时进行交互。你会希望能够观察系统内部正在发生的事情，因为具体步骤可能无法提前预知。你还需要在某个时间点调整智能体的状态或指令，以便当它偏离既定轨道时纠正回来。

系统的智能体特性越强，你就越需要为此类应用构建一个评估框架。由于随机性会逐步累积，因此你可能需要多次进行评估。你不仅需要测试最终输出，还需要评估中间步骤，检查智能体的行为效率。

系统的智能体特性越强，你就越需要一种全新的监控框架。你希望能够深入分析智能体执行的每一个步骤，还希望可以根据智能体执行的步骤来查询运行情况。

理解并运用系统的智能体能力光谱，能提升开发过程的效率与稳健性。

02 什么是“认知架构”？

在过去的六个月里，我经常使用的一个短语是“认知架构”，并且未来可能会更频繁地使用。这个词我最早是从Flo Crivello那里听到的——这个词的提出归功于他，我认为它是个极好的术语。那么我的意思是什么呢？

我所说的认知架构是指系统如何“思考”——也就是说，从接收用户输入，到执行操作或生成响应的代码/提示词/LLM调用流程。

我喜欢“认知”这个词，因为具备智能体特性的系统依赖LLM进行推理来决定该做什么。

我也喜欢“架构”这个词，因为这些具有智能体特性的系统仍然涉及大量类似于传统系统架构的工程设计工作。

将自主性级别映射到认知架构

如果我们回顾这张幻灯片，我们可以看到不同自主性级别的认知架构示例。

首先是代码——所有内容都是硬编码的。这甚至还不能称作真正的认知架构。

接下来是单次LLM调用。在调用前或调用后可能会进行一些数据预处理，但单次LLM调用构成了应用程序的主要部分。简单的聊天机器人可能属于这一类别。

接下来是LLM调用链。这种序列可能将问题分解为多个步骤，或是为了不同的功能服务。更复杂的RAG（检索增强生成）管道属于这一类别：首先使用LLM生成搜索查询，然后通过第二次LLM调用生成答案。

再接下来是路由器。在这之前，应用程序的所有步骤都是预先确定的。现在不再如此，LLM会决定要采取的操作。这增加了一定的随机性和不可预测性。

再往上是我称为状态机的架构。它将LLM的路由与循环结合起来。这更加不可预测，因为结合了路由和循环，系统理论上可以无限次调用LLM。

最高级别的自主性是我称为“智能体”的层次，或者说是真正的“自主智能体”。在状态机中，依然存在某些限制，决定哪些操作可以执行，执行后会采取哪些流程。而在自主智能体中，这些防护栏被移除了。系统本身开始决定哪些步骤是可用的，指令是什么：这可以通过更新提示词、工具或代码来实现。

选择认知架构

当我谈论“选择认知架构”时，我指的是选择你想要采用的架构类型。它们没有绝对的优劣之分——每种架构都有其适用的任务。

在构建LLM应用时，你可能会像尝试不同提示词一样频繁地尝试不同的认知架构。我们构建了LangChain和LangGraph来支持这一点。在过去一年中，我们的大部分开发工作都集中在构建低级别、高度可控的编排框架（LCEL和LangGraph）上。

这与早期LangChain的设计方向有所不同，早期LangChain主要关注易于使用的现成链条。这些链条非常适合入门，但在定制和实验方面较为局限。在早期阶段，这样的设计尚可接受，因为大家只是想快速入门，但随着领域的发展，这种设计很快达到了瓶颈。

我对我们在过去一年中为LangChain和LangGraph增加灵活性和定制化所做的努力感到非常自豪。如果你只使用过LangChain的高级包装器，建议你查看一下低级部分。它们更加灵活，真正能够让你控制应用程序的认知架构。

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

在选择认知架构时，重要的是要记住，不同的任务可能需要不同的架构。较为简单的任务可能只需要单次LLM调用，而更复杂的任务可能需要LLM调用链甚至状态机。对于完全自主的应用，你可能需要构建自主智能体架构。

此外，认知架构不仅影响系统的运行方式，还影响其灵活性、可控性以及可解释性。较简单的架构通常更易于理解和调试，而复杂的架构则可能提供更强的功能，但也伴随着更大的系统复杂性和不确定性。

无论你选择哪种架构，关键是要根据你的任务需求找到最佳平衡。

03 为什么你应该外包智能体基础设施，但拥有认知架构

当OpenAI的Assistants API发布时，这是朝着智能体未来迈出的大胆一步。它将OpenAI从一个提供LLM API的公司，转变为一个提供智能体API的公司。

我认为OpenAI的Assistants API做对了几件事——它引入了许多新的、有用的基础设施，专门用于运行智能体应用程序。与此同时，它限制了在其上构建真正复杂（且有价值的）智能体的“认知架构”。

这展示了“智能体基础设施”和“认知架构”之间的区别。杰夫·贝索斯曾说过一句充满智慧的话：“专注于让你的啤酒味道更好”。如果我们将这个比喻应用到构建智能体的公司上：

对智能体基础设施的需求

OpenAI非常准确地指出，开发者希望有更好的基础设施来运行智能体应用。特别是：

• 通过提示词和工具来“配置”助手的能力，使得入门变得简单，可以创建不同的智能体

• 以后台运行的方式运行助手的能力，使得管理长时间运行的工作流程变得更容易

• 消息的内置持久化功能，使得管理状态变得容易

所有这些都是开发者不需要过多操心的事情。这些东西都不会让你的应用程序与众不同——用杰夫·贝索斯的话说，它们不会让你的啤酒味道更好。

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

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

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

如果你想要构建一个聊天机器人——太棒了！线程的“状态”是一个消息列表，这对这种用途来说很完美。

如果你想要构建一个简单的ReAct风格智能体——很好！它也许对这种情况也有效——基本上就是在一个while循环中运行一个LLM。

但智能体应用程序不只是一个单一的聊天模型不断调用相同的工具和提示词。它们跟踪的状态比一系列消息要复杂得多。对应用程序状态和流程的控制对于让智能体具备任何可靠性至关重要。

通过与成千上万的开发者合作，我们看到那些投入生产的智能体都有稍微不同的认知架构。应用程序的认知架构是使其真正有效运作的关键——这是团队创新的地方。这是他们构建的差异化部分——让他们的啤酒味道更好的部分。

这并不是说你不能用Assistants API做更复杂的事情。你可能可以。但是API并不让这些事情变得容易。它并不期望你这样做。OpenAI押注于通用的认知架构，这使得构建需要的、应用特定的认知架构来让智能体可靠变得困难。

为什么我们在乎？

我为什么这么在意？为什么我要写这么多字？因为我认为OpenAI做对了很多事情，他们在市场早期就采取了立场，认为智能体基础设施是必需的。他们让开发者不用担心智能体的状态存储在哪里，如何管理任务队列等问题——这非常棒。

我们在LangChain的目标是让构建智能体应用程序变得尽可能简单。这类基础设施绝对是其中的重要组成部分。

我们希望将这种智能体基础设施的优势与LangGraph为你提供的对认知架构的控制结合起来。这就是为什么我们构建了LangGraph Cloud。使用LangGraph编写你的定制认知架构，然后通过LangGraph Cloud部署它，并获得所有智能体基础设施的好处。

LangGraph Cloud提供容错扩展性，针对现实世界的交互进行了优化。我们设计了水平扩展的任务队列和服务器，内置的持久层针对重负载进行了优化，并在多个运行中配置了节点缓存。这让你可以拥有应用程序的差异化部分，而将其他部分外包。

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

04 为智能体进行规划

在三月份的Sequoia AI Ascent大会上，我提到了智能体的三大限制：规划、用户体验（UX）和记忆。下面将深入探讨智能体规划问题。

如果你询问任何使用大语言模型（LLM）构建智能体的开发者，他们很可能会提到规划和推理能力的不足是影响智能体可靠性的一大问题。那么，规划对智能体意味着什么？人们目前是如何克服这一短板的？未来智能体的规划和推理能力可能会如何发展？我们将在下文中讨论这些问题。

什么是规划和推理？

智能体的规划和推理涉及LLM决定采取哪些行动的能力。这个过程包括短期和长期的步骤。LLM需要评估所有可用的信息，然后决定：我需要采取哪些步骤？当前我应该采取的第一步是什么？

大多数情况下，开发者使用函数调用（也称为工具调用）来让LLM选择行动。函数调用是OpenAI于2023年6月首次在LLM API中引入的功能，随后在2023年底和2024年初被其他平台采用。通过函数调用，你可以为不同的函数提供JSON架构，让LLM输出的对象匹配这些架构之一。有关更多信息，请参阅我们的函数调用指南。

函数调用通常用于让智能体选择当前的即时行动。然而，成功完成复杂任务往往需要一系列连续的行动。这种长期规划和推理对LLM来说更具挑战，原因有以下几点。首先，LLM需要考虑一个长远的目标，但同时还必须跳回到当前的短期行动中。其次，随着智能体采取更多的行动，这些行动的结果会反馈给LLM，这会导致上下文窗口不断扩大，进而可能导致LLM分心，表现不佳。

正如LLM领域的许多事情一样，当前模型在规划和推理方面的表现难以准确衡量。有一些合理的基准测试，例如伯克利函数调用排行榜，用于评估函数调用能力。我们也进行了一些关于多步骤应用的研究。但是，要了解这方面表现的最佳方式是针对你的具体问题建立一个评估集，并自行进行评估。

目前有哪些方法可以改善智能体的规划能力？

改善规划能力最简单的方式是确保LLM拥有进行合理推理和规划所需的所有信息。虽然这听起来很基础，但很多时候传递给LLM的提示中并没有包含足够的信息，导致它无法做出合理的决策。添加一个信息检索步骤，或者更加明确地说明提示中的指令，可以作为简单的改进措施。这也是为什么需要实际查看数据，看看LLM实际接收到的信息是什么。

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

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

通用认知架构尝试在任意任务中提升推理能力。一个很好的例子是“规划与解决”架构。这篇论文探讨了一种架构，在这种架构中，首先制定一个计划，然后逐步执行计划中的每一步。另一个通用架构是Reflexion架构，这篇论文提出，在智能体完成任务后增加一个“反思”步骤，以评估任务执行得是否正确。

尽管这些想法展示了推理能力的提升，但它们往往过于通用，难以应用于生产环境中的智能体。相反，我们发现智能体通常使用领域特定的认知架构。这通常体现在领域特定的分类和路由步骤、验证步骤等方面。虽然某些通用的规划和反思理念在这里同样适用，但通常是以领域特定的方式应用。

以AlphaCodium论文为例，它通过使用“流程工程”（认知架构的另一种说法）实现了当前最先进的性能。下图展示了他们所使用的流程。

该流程非常针对其要解决的问题。他们要求智能体按步骤进行操作——首先编写测试，然后编写解决方案，接着迭代更多的测试等。这个认知架构高度领域特定，并不会对写作任务产生帮助。

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

我喜欢从两个角度来解释这一点。

首先：你可以将其视为另一种向智能体传达其应执行任务的方式。你可以通过提示来传达指令，也可以通过代码明确规定具体的步骤。两种方式都是有效的！代码是传达预期行为的极佳方式。

其次：这实际上是将规划责任从LLM转移到了我们这些工程师手中。我们基本上是在告诉LLM：“不用担心规划，我来替你做！”当然，我们并没有完全移除LLM的规划责任，因为在某些情况下我们仍要求它进行部分规划。

例如，回到上面的AlphaCodium例子。流程中的步骤基本上是我们替LLM进行的规划！我们告诉它先编写测试，然后写代码，再运行测试等。这实际上是作者认为编写软件的一个好计划。如果他们要为某个问题制定一个解决方案，可能也是以这种方式进行规划的。与其通过提示告诉LLM执行这些步骤——提示可能被忽略、误解或缺少细节——他们通过构建领域特定的认知架构向系统传达如何操作。

我们通过LangGraph让构建这些定制认知架构变得更加容易。LangGraph的一个核心重点是可控性。我们设计了LangGraph，使其操作非常底层且高度可控——因为我们发现，要创建可靠的定制认知架构，100%的可控性是必须的。

规划和推理的未来会怎样？

LLM领域变化迅速，我们在构建应用程序时，尤其是在构建工具时，应该对此保持关注。

我目前的看法是，通用推理将越来越多地融入模型层。模型将变得越来越智能，无论是通过规模的扩大还是研究的突破——押注这一趋势似乎是不明智的。模型也会变得更快、更便宜，因此传递大量上下文信息给它们将变得更加可行。

然而，我相信，无论模型多么强大，你始终需要以某种形式向智能体传达其应执行的任务。因此，我认为提示和定制架构将继续存在。对于简单任务，提示可能就足够了；而对于复杂任务，可能需要通过代码来定义其行为。代码优先的方法可能更快、更可靠、更易于调试，并且在很多情况下表达起来更加简洁、合理。

我最近参加了一个podcast，与Sequoia的Sonya和Pat讨论了这个话题。他们绘制了一张很棒的图，展示了提示、认知架构和模型的角色和重要性如何随着时间推移而演变。

Last but not least

当我们考虑AGI时，Agent的工作方式无疑占据了技术前沿的中心舞台。随着大模型的快速进步，我们见证了各种新模式的涌现，这些模式不仅提升了llm的效能，更在根本上改变了它们与人类互动的方式。