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

在我们“In The Loop”系列的第三篇文章中，了解为什么你应该根据应用定制认知架构，并运行更好的智能体应用基础设施。

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

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