Ai Agent技术栈

原文地址：https://www.letta.com/blog/ai-agents-stack

理解 AI 智能体领域格局

尽管我们看到大量智能体技术栈和市场图谱，但我们倾向于不认同其分类方式，发现它们很少反映开发者实际采用的情况。过去几个月里，智能体软件生态在记忆功能、工具使用、安全执行和部署方面取得显著进展，因此我们决定基于开源 AI 领域一年多的实践经验和七年以上的 AI 研究积累，分享我们自己的"智能体技术栈"。

2024 年末的 AI 智能体技术栈，划分为三大核心层级：智能体托管/服务层、智能体框架层，以及 LLM 模型与存储层。

从 LLM 到 LLM 智能体

2022 至 2023 年间，我们见证了 LangChain（2022 年 10 月发布）和 LlamaIndex（2022 年 11 月发布）等 LLM 框架与 SDK 的崛起。与此同时，通过 API 调用 LLM 的若干"标准"平台相继确立，自主部署 LLM 推理的方案（如 vLLM 和 Ollama）也同步兴起。

2024 年，我们见证了人们对 AI"智能体"乃至更广义的复合系统兴趣的急剧转变。尽管"智能体"作为 AI 术语已存在数十年（特指强化学习领域），但在后 ChatGPT 时代，它已成为一个定义宽泛的概念，通常指代那些被赋予输出行动指令（工具调用）能力、并在自主环境中运行的 LLMs。从 LLM 到智能体的跨越，需要整合工具使用、自主执行和记忆功能，这催生了一个全新的智能体技术栈的发展需求。

智能体技术栈的独特之处何在？

与传统的基础 LLM 聊天机器人相比，智能代理面临更艰巨的工程挑战，因为它们需要状态管理（保留消息/事件历史记录、存储长期记忆、在代理循环中执行多次 LLM 调用）和工具执行（安全执行 LLM 输出的操作并返回结果）。

因此，AI 代理技术栈与标准 LLM 技术栈存在显著差异。让我们从最底层的模型服务层开始，拆解当今的 AI 代理技术栈：

模型服务

AI 代理的核心是 LLM。要使用 LLM，需要通过推理引擎提供服务，通常运行在付费 API 服务后端。

OpenAI 和 Anthropic 凭借私有前沿模型，在基于封闭 API 的模型推理服务商中处于领先地位。Together.AI、Fireworks 和 Groq 则是提供开源权重模型（如 Llama 3）付费 API 的热门选择。在本地模型推理服务商中，vLLM 最常见于生产级 GPU 服务负载领域独占鳌头。SGLang 是一个新兴项目，面向类似的开发者群体。对于爱好者（“AI 极客”）而言，Ollama 和 LM Studio 是在个人电脑（如 M 系列苹果 MacBook）上运行模型的两大流行选择。

Storage 存储

存储是具备状态性的智能体基础构建模块——智能体通过持久化状态来定义，例如对话历史、记忆以及用于检索增强生成（RAG）的外部数据源。诸如 Chroma、Weaviate、Pinecone、Qdrant 和 Milvus 等向量数据库常被用于存储智能体的"外部记忆"，使智能体能够利用远超上下文窗口容量的数据源和对话历史。Postgres 作为一款诞生于 80 年代的传统数据库，如今也通过 pgvector 扩展支持向量搜索。基于 Postgres 的企业如 Neon（无服务器 Postgres）和 Supabase 同样为智能体提供基于嵌入向量的搜索与存储功能。

Tools & libraries 工具与库

标准 AI 聊天机器人与 AI 智能体之间的主要区别之一，在于智能体能够调用“工具”（或称“函数”）。在大多数情况下，这一行为的实现机制是 LLM 生成结构化输出（例如 JSON 对象），其中指定了要调用的函数及需提供的参数。关于智能体工具执行的一个常见误解是：工具执行并非由 LLM 供应商自身完成——LLM 仅负责选择调用何种工具及提供哪些参数。支持任意工具或任意参数输入的智能体服务必须使用沙箱环境（如 Modal、E2B）来确保安全执行。

所有智能体都通过 OpenAI 定义的 JSON 模式调用工具——这意味着不同框架的智能体和工具实际上可以相互兼容。Letta 智能体能够调用 LangChain、CrewAI 和 Composio 的工具，因为它们都遵循相同的模式规范。正因如此，面向通用工具的工具提供商生态正在蓬勃发展。Composio 是一个流行的通用工具库，同时还管理授权流程；Browserbase 是专注于网页浏览的专项工具范例；Exa 则提供了专业的网络搜索工具。随着更多智能体的开发，我们预期工具生态将持续扩展，并为智能体提供诸如身份验证、访问控制等现有新功能。

Agent frameworks 智能体框架

智能体框架负责协调 LLM 调用并管理智能体状态。不同框架在以下方面会有不同设计：

智能体状态管理：多数框架引入了状态"序列化"概念，通过将序列化状态（如 JSON 格式、字节流）保存至文件，使得智能体能在后续重新加载到同一脚本中——这包括对话历史、智能体记忆和执行阶段等状态。在 Letta 系统中，所有状态均由数据库（如消息表、智能体状态表、记忆块表）支持，因此不存在"序列化"概念，因为智能体状态始终持久化存储。这种设计支持便捷的状态查询（例如按日期检索历史消息）。状态的表示与管理方式既决定了智能体应用能否随着对话历史增长或智能体数量增加而扩展，也影响着状态随时间推移被访问或修改的灵活性。

智能体的上下文窗口结构：每次调用 LLM 时，框架会将智能体的状态"编译"到上下文窗口中。不同框架会以不同方式将数据（如指令、消息缓冲区等）置入上下文窗口，这会影响性能表现。我们建议选择能透明展示上下文窗口的框架，因为这是最终控制智能体行为的关键所在。

跨智能体通信（即多智能体）：Llama Index 通过消息队列实现智能体间通信，而 CrewAI 和 AutoGen 则采用显式的多智能体抽象层。Letta 与 LangGraph 均支持智能体直接相互调用，这种设计既支持通过监督智能体进行集中式通信，也支持智能体间的分布式交互。当前多数框架已同时兼容多智能体与单智能体模式，因为设计良好的单智能体系统应能轻松实现跨智能体协作。

记忆管理方法：LLMs 存在一个根本性限制——有限的上下文窗口，这要求采用技术手段实现长期记忆管理。部分框架内置了记忆管理功能，而其他框架则要求开发者自行处理。CrewAI 和 AutoGen 仅依赖基于 RAG 的记忆系统，而 phidata 与 Letta 则运用了更多技术，如源自 MemGPT 的自编辑记忆和递归摘要。Letta 智能体默认配备全套记忆管理工具，支持通过文本或数据检索历史消息、写入记忆、甚至编辑智能体自身的上下文窗口（详见此处说明）。

开源模型支持：模型提供商实际上采用了许多幕后技巧来确保 LLMs 生成格式正确的文本（例如工具调用场景）——比如当 LLM 输出不符合工具参数要求时进行重新采样，或在提示词中添加暗示（如"请务必输出 JSON"）。支持开源模型需要框架能应对这些挑战，因此部分框架仅限支持主流模型提供商。

在构建智能体时，选择合适的框架取决于具体应用场景，例如开发对话型智能体还是工作流系统、选择在笔记本环境运行还是作为服务部署，以及对开源权重模型支持的需求。

我们预计各框架在部署工作流中将出现重大差异，其中状态/内存管理的设计选择与工具执行将变得更为关键。

智能体托管与智能体服务

如今大多数智能体框架的设计初衷，是让智能体仅存在于编写它们的 Python 脚本或 Jupyter 笔记本中。我们相信智能体的未来是将它们视为可部署到本地或云基础设施的服务，通过 REST API 进行访问。正如 OpenAI 的 API 成为与 LLM 服务交互的行业标准一样，我们预计最终会出现一个胜出的智能体 API 标准。但目前…这个标准尚未诞生。

将 AI 智能体部署为服务比部署 LLMs 服务复杂得多，这涉及状态管理和安全工具执行的问题。由于运行环境需要服务重新创建（当工具和智能体在同一脚本中运行时不存在此问题），工具及其所需依赖项和环境配置必须明确存储在数据库中。应用程序可能需要运行数百万个智能体，每个智能体都会积累不断增长的对话历史。从原型开发转向生产环境时，智能体状态不可避免地要经过数据规范化处理，且智能体交互必须通过 REST API 来定义。目前，这一过程通常由开发人员自行编写 FastAPI 和数据库代码完成，但我们预计随着智能体技术的成熟，这类功能将更多地集成到框架中。

Conclusion 结论

智能体技术栈仍处于极早期阶段，我们期待见证整个生态如何随时间扩展与演进。若您有意托管智能体或构建具备记忆功能的智能体，可查看 Letta 开源项目并申请 Letta 云服务的早期体验权限。

编者注：在制作 AI 智能体技术栈图谱时，我们力求涵盖 2024 年 11 月期间开发者构建垂直领域智能体应用时最可能采用的代表性企业和开源项目。难免会遗漏某些杰出公司和高影响力开源项目——若您未被收录，我们深表歉意！若希望入选未来版本的技术栈图谱，请在 LinkedIn 帖文/Discord 留言或发送邮件至我方。