当 OpenAI Assistants API 发布时，这是迈向代理未来的一大步。它将 OpenAI 从一家生产 LLM API 的公司转变为一家生产 Agent 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 提供容错的可扩展性，针对现实世界的交互进行了优化。我们设计它具有水平扩展的任务队列和服务器、针对繁重负载优化的内置持久性层以及跨运行的可配置节点缓存。这使您可以拥有应用程序的差异化部分，并将其他部分外包。
总之，专注于让您的啤酒口感更好的东西：认知架构，而不是基础设施。