本文是 LangChain 博客上关于智能体 (AI Agent) 的系列文章的第三篇，提出在构建智能体时，应将基础设施（状态管理、任务队列等）交由第三方处理，而专注于开发应用特有的认知架构（决策流程、状态表示）。
当 OpenAI Assistants API 发布时，这标志着 AI 领域向智能体时代迈出了重要一步。它使 OpenAI 从一家提供大型语言模型（LLM）API 的公司，转变为一家提供智能体 API 的企业。
我认为 OpenAI Assistants API 在多个方面都表现出色，它引入了许多创新且实用的基础设施，专门用于运行智能体应用。然而，这也在某种程度上限制了开发者在其基础上构建真正复杂（且极具价值！）智能体时所能采用的"认知架构"的灵活性。
这凸显了"智能体基础设施"与"认知架构"之间的本质区别。正如亚马逊创始人杰夫·贝索斯那句经典箴言所言："专注于让你的啤酒更美味"。如果将这一比喻应用到构建智能体的公司身上，我们可以这样理解：
💡 智能体基础设施本身并不能让你的啤酒更美味。
💡 而认知架构则绝对能够提升你啤酒的口感。
对智能体基础设施的需求
OpenAI 准确把握了开发者对更优质基础设施的需求，特别是在运行智能体应用方面。具体表现在：
- 通过提示词和工具"配置"助手的能力，使创建不同智能体变得便捷
- 支持助手在后台运行，简化了长时间运行工作流程的管理
- 内置的消息持久化功能，便于进行状态管理
所有这些功能都是开发者不应该过多考虑的部分。用杰夫·贝索斯的话说，它们不会让你的"啤酒"味道更好，也就是说，它们并不能使你的应用脱颖而出。
事实上，还有更多的基础设施可以进一步构建以辅助开发者！例如，在当前的 OpenAI Assistants API 中，你无法在同一对话上运行多个任务，也难以轻松修改对话的状态。尽管如此，Assistants API 无疑朝着正确的方向迈出了重要一步。
应用专属认知架构的重要性
Assistants API 的局限性在于，它在支持构建更复杂应用方面显得不够灵活。
如果你的目标是开发一个聊天机器人，那么这个 API 确实非常适合！因为对话中的"状态"仅需要一个消息列表就足够了。
如果你想构建一个基础的 ReAct 模式智能体，这同样可行，本质上就是在 while 循环中反复调用大型语言模型。
但智能体应用绝不仅仅是一个不断重复调用相同工具和提示的单一聊天模型。它们需要追踪比消息列表更为复杂的状态，而对应用状态和流程的精细控制正是确保智能体可靠运行的关键所在。
通过与数千名开发者的合作，我们发现那些迈向生产化的智能体，各自都具备略有不同的认知架构。应用的认知架构正是让它 真正卓越 的关键，各团队正是在这一领域不断创新，力图通过构建独具特色的认知架构来使他们的应用脱颖而出，就像让啤酒更美味一样。
这并不是说你无法利用 Assistants API 实现更复杂的功能，理论上可以，但 API 设计上并不鼓励这种做法。OpenAI 押注于一种通用认知架构，这在一定程度上使得构建面向特定应用需求的、能够提升智能体可靠性的专属认知架构变得困难重重。
我们为何如此关注？
为何我对此如此关切？为何要写这么多文字来讨论这个话题？原因在于我坚信 OpenAI 在很多方面做得非常出色，他们早已预见到市场对智能体基础设施的迫切需求，让开发者无需烦恼智能体状态的存储、任务队列的管理等问题，这一点无疑非常振奋人心。
在 LangChain，我们的目标是让构建智能体应用变得简单至极，而这正需要这样的基础设施。
我们希望将智能体基础设施的优势与 LangGraph 所赋予你对认知架构的掌控力相结合，这正是我们开发 LangGraph Cloud 的初衷。你可以利用 LangGraph 设计专属的认知架构，再通过 LangGraph Cloud 进行部署，从而享受智能体基础设施带来的所有优势。
LangGraph Cloud 提供了容错性极强的可扩展性，专为真实世界的交互场景而优化。我们设计了横向扩展的任务队列和服务器，内置持久化层针对高负载进行了优化，同时支持跨运行的节点缓存配置。这样一来，你就可以掌控应用中那些决定性、具有差异化优势的部分，将其余部分外包处理。
总之，专注于让你的"啤酒"味道更美味的关键在于构建优秀的认知架构，而不仅仅是依赖基础设施。
原文地址：Why you should outsource your agentic infrastructure, but own your cognitive architecture
LangChain 智能体系列文章：