LangChain 撰文分析 OpenAI 押注 GPTs 与 Assistants API 背后的认知架构

三周前，OpenAI举办了一场备受期待的开发者日。他们发布了大量新功能。对我来说，最有趣的两个是Assistants API和GPTs。在我看来，这两者代表了同一个赌注——押注于一种特定的、类似代理的、封闭的“认知架构”。它们吸引不同的最终用户，但都体现了OpenAI推动应用走向这种特定认知架构的雄心。在LangChain，我们相信一个由LLM驱动的、真正具有变革性的代理式系统的世界。然而，我们认为实现这一目标的路径是让公司能够控制自己的认知架构。你今天就可以通过像OpenGPTs这样的项目做到这一点——它是Assistants API（以及GPTs）的一个开放、可编辑、可配置的版本。

GPTs与Assistants API

在这两者中，GPTs可能是互联网上讨论更多的那个。它们提供了一种（基本上）无代码的方式来创建你自己的“GPT”。这些GPT可以通过自定义指令、自定义知识和自定义函数进行定制。这些GPT似乎是某种应用商店的第二次尝试，紧随Plugins之后（用Sam Altman自己的话来说，Plugins并未找到产品市场契合点）。

Assistants API是这一理念中更偏向开发者的版本。Assistants API是一个有状态的API，允许存储先前的消息、上传文件、访问内置工具（代码解释器），并可用于控制其他工具（通过函数调用，开发者指定一个要调用的函数，然后可以在客户端执行）。

认知架构

在底层，这两者都代表了一种相似的“认知架构”。在这里，我用认知架构来描述LLM应用的编排。我第一次听到这个术语是由Flo Crivello（自主代理初创公司Lindy的创建者）使用的，我认为这是一个极好的术语。

💡

大多数有趣的LLM应用可以被描述为上下文感知的推理应用。这里有两个主要组成部分：（1）上下文如何提供给应用，（2）应用如何“推理”。这两个组成部分共同构成了应用的认知架构。

在LangChain，我们思考认知架构已经有一段时间了。在最近的一次TedAI演讲中（视频尚未发布），我谈到了我们看到的开发者正在构建的不同层次的认知架构。这些包括：

单次LLM调用，仅决定应用的输出
LLM调用链，仍然仅决定应用的输出
使用LLM作为路由器，选择使用哪个动作（工具、检索器、提示）
状态机——使用LLM在步骤之间路由，以某种循环方式，但允许的转换选项仍在代码中枚举
代理——移除大量脚手架，使得转换选项完全由LLM决定

代理

Assistants API和GPTs都是上述“代理”认知架构的例子。Sam Altman在宣布它们时甚至使用了那个确切的术语（“代理”）。尽管代理可能是一个被过度使用的术语，用来描述无数不同的应用，但OpenAI对这个术语的使用与我们的理解基本一致：仅使用LLM来定义转换选项。

像这样的应用在实践中是什么样子的？这最好被理解为一个循环。给定用户输入，就会进入这个循环。然后调用一个 LLM，产生对用户的响应或要采取的动作。如果确定需要响应，那么就将其传递给用户，该循环结束。如果确定需要采取动作，那么就采取该动作，并得到一个观察结果（动作结果）。该动作及相应的观察结果被添加回提示中（我们称之为“agent scratchpad”），然后循环重置，即再次调用 LLM（使用更新后的 agent scratchpad）。

在高层次上，这就是 GPTs 正在做的事情。当它们调用你给它们的工具（或内置工具，如检索或代码解释器）时，你可以在屏幕上看到一个旋转的小部件。这表示正在采取动作，而 GPT 正在等待观察结果。在某个时刻，它只是用文本响应——没有要采取的动作——循环就结束了。

Assistants API 也是如此。唯一的区别是，API 不会为你调用工具——除非它是像检索或代码解释器这样的内置工具。相反，它会用某种类型的消息进行响应，告诉你应该调用哪些工具（以及这些工具的输入应该是什么），然后等待你在客户端调用这些工具并传回结果。

这种“agent”认知架构在过去一年半里一直在演进。AI21 Labs 在一年半前发布了他们的 MRKL 论文。ReAct 提示策略（一年多前发布）是一种特定类型的提示策略，能够实现这种架构。我们大约一年前在 LangChain 中引入了 ReAct，并迅速扩展到更通用的零样本提示策略。AutoGPT 大约九个月前横空出世，使用同样的认知架构，但赋予它更多工具、更持久的记忆，以及通常更庞大的任务。

OpenAI 下的赌注

我非常感兴趣地看到 OpenAI 如此大力押注 agents，因为据各方说法，这种认知架构对于严肃应用来说还不够可靠。他们是最有资格做到这一点的人——毕竟他们控制着底层模型。但这仍然是一个赌注。他们赌的是，随着时间的推移，困扰 agents 的问题会消失。

我们看到的几乎所有真正有用的“自主 agents”在两个关键方面有所不同。

首先，许多实际上并不是这种“agent”认知架构，而是要么是精心设计的复杂链，要么更类似于“状态机”。两个很好的公开例子是 GPT-Researcher 和 Sweep.dev。

我们曾多次详细撰文介绍 GPT-Researcher，并在上周与他们合作发布了一个 LangChain 模板。它们是少数能产生有价值结果的复杂 LLM 驱动应用之一，但它们的认知架构更像是一个复杂的链。如果我们看下面的图，可以看到它是单向流动的。它做了很多复杂的步骤，但以定义好的方式：它首先生成子问题，然后为每个子问题获取链接，然后总结每个链接，然后将总结合并成一份研究报告。

Sweep.dev 是另一个很好的例子。他们在夏天写了一篇博客，描述他们的认知架构，其中还包含一张很棒的示意图。

其中有清晰定义的转换和步骤。首先，进行一次搜索。然后，生成一个计划。接着，执行该计划。之后有一个验证步骤：如果通过，就创建一个 PR，Sweep 就完成了。如果失败，则生成一个新计划。这是一个相当清晰的状态机，不同状态之间有明确定义的转换。

我们合作的许多其他构建者和团队，都用复杂的链/状态机来驱动他们的应用。

💡

这些认知架构的好处很简单：更多控制。没有两个问题是相同的，选择适合问题空间的恰当认知架构，对于提供良好体验至关重要。

对于确实使用更接近这种智能体架构的应用，它们与 GPTs 的另一个不同之处在于：上下文如何提供给智能体。

我和 Flo Crivello 聊过认知架构，他提出了一点：智能体架构的一个不同之处在于上下文如何提供给智能体。记住，我们描述大多数有趣的 LLM 应用的方式是“上下文感知推理应用”。

💡

上下文可以通过拉取或推送来提供。在大多数高性能且可靠的智能体中，我们看到大量上下文是通过推送提供的。

智能体拉取上下文是什么意思？这意味着智能体决定它需要什么上下文，然后去请求它。这通常通过工具发生。举个具体例子，一个用于与 SQL 数据库交互的智能体可能需要知道 SQL 数据库中有哪些表。因此，我们可以给它一个返回数据库中表列表的工具，它可以在开始时调用该工具。

相反，当上下文被推送给语言模型时，它被编码在应用的逻辑中，即某段特定上下文应该被获取并推入提示词。在上面的 SQL 智能体例子中，这相当于提前自动获取 SQL 表并将它们插入提示词。

大多数确实使用智能体架构的应用都有大量推送的上下文。举个例子，LangChain 中的 SQL 和 Pandas 智能体将表结构作为系统消息的一部分。再举个例子，Rubrics 团队为 Cal.com 构建的智能体将大量用户信息推送到了提示词中。

这种上下文的推送 vs 拉取再次给开发者带来了更多控制。它让我们能够在决定要做什么时，强制规定哪些上下文与 LLM 相关。具体来说，知道哪些上下文最相关、如何获取该上下文以及如何提供它，这些看似微小的决策可以对质量和性能产生巨大影响。

GPTs——在某种程度上还有 Assistant API——在很大程度上让应用拥有不受约束的智能体架构，更依赖按需拉取上下文。这对于快速上手或简单任务来说可能很棒，但对于更复杂的用例，控制适合当前问题的认知架构是无可替代的。

开放 vs 封闭

除了认知架构的选择之外，Assistants API 和 GPTs 的另一个显著特点是认知架构本身是封闭的。我们不知道底层发生了什么。我们不知道确切的算法。我们不知道对聊天历史上下文的管理做了什么。我们不知道检索方面做了什么。

目前我们可以对这两者做出猜测。然而，随着他们添加越来越多的东西，系统变得越来越复杂，它就会变得越来越像一个黑箱。

💡

关于开源与闭源的许多讨论都围绕着模型本身。但还有另一个需要考虑的因素：开源认知架构与闭源认知架构。

随着时间的推移，我敢打赌这会成为比模型本身更大的讨论话题。一年前，大多数新功能（我敢打赌内部的大部分关注点也是）都集中在更好的模型上。现在，核心模型改进与如何以智能体方式最好地连接它们之间似乎是五五开。作为这一点重要性的更多证据，Karpathy 的 Twitter 动态（AGI 相关一切的权威阅读清单）正越来越多地转向将 LLM 视为操作系统的理念。在上个周末，他发布了一个精彩的视频，正是关于这一点。

我完全预期这一趋势会持续下去，OpenAI（也许还有其他实验室）会在模型周围的平台和工具上投入更多，而不仅仅是模型本身。通往 AGI 的道路不（只）在于更好的模型——还在于将它们与周围环境连接起来。随着这些实验室关注点的转移，我预期——也希望——关于开源与闭源的讨论不仅会针对模型，也会针对认知架构。

认知架构能让你的啤酒更好喝吗？

Jeff Bezos 有一句名言，说要只做能让你的啤酒更好喝的事。这指的是工业革命早期，当时酿酒厂也自己发电。酿酒厂酿造好啤酒的能力并不真正取决于他们的电力有多大差异化——所以那些将发电外包并更专注于酿造的酒厂获得了优势。

认知架构也是如此吗？掌控自己的认知架构真的能让你的啤酒更好喝吗？目前，我会强烈认为答案是肯定的，原因有二。第一：让复杂的智能体真正运作起来非常困难。如果你的应用依赖于智能体正常工作，而让智能体正常工作又充满挑战，那么几乎从定义上讲，如果你能做好这一点，你就会比竞争对手更有优势。第二个原因是，我们经常看到 GenAI 应用的价值与认知架构的性能紧密相关。当前很多公司都在销售用于编程的智能体、用于客户支持的智能体。在这些情况下，认知架构就是产品本身。

最后一个原因也是我很难相信公司会愿意锁定在一个由单一公司控制的认知架构上的原因。我认为这与云甚至 LLM 的锁定形式不同。在那些情况下，你使用云资源和 LLM 来构建或驱动某个特定应用。但如果一个认知架构越来越接近成为一个完整的应用本身——你不太可能希望它被锁定。

LangChain 如何融入其中

在 LangChain，我们相信一个 LLM 驱动真正具有变革性的类智能体系统的世界。然而，我们认为实现这一目标的路径是让公司能够控制自己的认知架构。

💡

从我们与交付 LLM 驱动应用的团队合作中所看到的一切来看，让类智能体系统可靠运行真的非常非常难。你可以用通用的智能体架构做出演示，也许还有简单的玩具应用。但当需要提升性能并大规模运行时，你 NEED 针对你的应用和用例进行定制。

这需要大量的工程工作。我们正在构建工具来帮助做到这一点。通过 LCEL，我们有了灵活的方式来组合链。通过 LangChain，我们有 600 多个集成，让你在使用什么模型/向量存储/数据库方面拥有完全的灵活性。通过 LangSmith，我们明确专注于提供尽可能最好的调试体验（因为大多数团队都处于这个阶段），但我们也加入了管理工具（回归测试、监控、数据标注、提示中心），帮助你在走向生产时管理这些系统。

我们最近还发布了 OpenGPTs。这是尝试复刻 Assistants API 以及 GPTs 的相同体验（我们对 GPTs 的实现只是 Assistants API 之上的一个简单 UI）。这是开源的，目前可配置四种不同的模型提供商，并且所使用的确切检索方法可以轻松修改。

这仅仅是开始。