当 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 提供容错的可扩展性，针对真实世界的交互进行了优化。我们将其设计为具有水平扩展的任务队列和服务器、针对重负载优化的内置持久层以及跨运行的可配置节点缓存。这使你可以拥有应用程序的差异化部分，并将其余部分外包。
总之，专注于让你的啤酒更好喝的东西：认知架构，而不是基础设施。