随着AI技术的快速发展，AI Agent作为一种新型智能系统正在改变我们与AI交互的方式。本文基于Letta公司发布的技术分析文章，为您详细解析当前AI Agent技术栈的全景地图。（这里是英文原文链接-https://www.letta.com/blog/ai-agents-stack）

Letta公司指出，尽管市面上有很多agent技术栈和市场图谱，但这些分类很少能真实反映开发者实际使用情况。

在过去几个月里，agent相关技术在记忆、工具使用、安全执行和部署方面取得了显著进展。基于该公司超过一年的开源AI开发经验和7年以上的AI研究积累，Letta提出了一个更贴近实践的Agent技术栈分析框架。

一、 从LLM到LLM Agents的发展

在2022和2023年，我们见证了LLM开发框架的崛起，如LangChain（2022年10月发布）和LlamaIndex（2022年11月发布）。同时，我们也看到了几个通过API使用LLM的标准平台的建立，以及自部署LLM推理服务（如vLLM和Ollama）的发展。

到了2024年，我们看到对AI Agents 以及更普遍的复合系统的兴趣出现了显著转变。尽管 Agents 这个术语在AI领域已存在数十年（特别是在强化学习中），但在ChatGPT时代后，这个词有了新的含义，通常指那些被赋予输出动作（工具调用）能力并在自主环境中运行的LLM。从LLM转变为 agent 所需的工具使用、自主执行和记忆的组合，催生了一个新的 agent 技术栈的发展。

二、 AI Agent技术栈的独特之处

相比基础的LLM聊天机器人，Agent在工程上是一个更具挑战性的任务，因为它们需要：

• 状态管理（保留消息/事件历史、存储长期记忆、在agent循环中执行多个LLM调用）
• 工具执行（安全地执行LLM输出的动作并返回结果）

因此，AI agents技术栈与标准LLM技术栈有很大的不同。让我们从底层的模型服务层开始，逐层解析当今的AI agents技术栈：

三、 模型服务层（Model serving）

AI agents的核心是LLM。要使用LLM，模型需要通过推理引擎提供服务，最常见的是通过付费API服务。

OpenAI和Anthropic在封闭式API模型推理提供商中处于领先地位，拥有私有的前沿模型。

Together.AI、Fireworks和Groq是通过付费API提供开源权重模型（如Llama 3）的流行选择。

在本地模型推理提供商中，我们最常见到vLLM在生产级GPU服务负载中领先。

SGLang是一个面向类似开发者群体的新兴项目。

在业余爱好者（"AI爱好者"）中，Ollama和LM Studio是两个在个人电脑上运行模型的流行选择（如M系列Apple Macbook）。

四、 存储（Storage）

存储是具有状态的agents的基础构建块 - agents的定义特征包括其持久化的状态，如对话历史、记忆和用于RAG的外部数据源。

像Chroma、Weaviate、Pinecone、Qdrant和Milvus等向量数据库常用于存储agents的外部记忆，使agents能够利用远超上下文窗口大小的数据源和对话历史。

自80年代就存在的传统数据库Postgres，现在通过pgvector扩展也支持向量搜索。像Neon（无服务器Postgres）和Supabase这样的基于Postgres的公司也为agents提供基于embedding的搜索和存储服务。

五、 工具和库（Tools & libraries）

标准AI聊天机器人和AI agents的主要区别之一是 agent 调用"工具"（或"函数"）的能力。在大多数情况下，这个动作的机制是LLM生成结构化输出（例如JSON对象），指定要调用的函数和提供的参数。关于 agent 工具执行的一个常见误解是，工具执行不是由LLM提供商本身完成的 - LLM只是选择要调用什么工具，以及提供什么参数。支持任意工具或任意参数输入的agent服务必须使用沙盒（如Modal、E2B）来确保安全执行。

所有agents都通过OpenAI定义的JSON模式调用工具，这意味着agents和工具实际上可以跨不同框架兼容。Letta agents可以调用LangChain、CrewAI和Composio的工具，因为它们都由相同的模式定义。正因如此，常用工具的提供商生态系统正在增长。Composio是一个流行的通用工具库，同时也管理授权。Browserbase是专门用于网页浏览的工具示例，Exa提供专门的网络搜索工具。随着更多agents的构建，我们预计工具生态系统将增长，并为agents提供现有的新功能，如认证和访问控制。

六、 Agent框架（Agent Frameworks）

Agent框架负责编排LLM调用和管理agent状态。不同框架在以下方面有不同的设计：

• 管理agent的状态：

大多数框架都引入了某种序列化状态的概念，通过将序列化状态（如JSON、字节）保存到文件中，允许agents在稍后时间重新加载到相同的脚本中 — 这包括对话历史、agent记忆和执行阶段等状态。在Letta中，所有状态都由数据库支持（如消息表、agent状态表、记忆块表），因此没有序列化的概念，因为agent状态始终是持久化的。这允许轻松查询agent状态（例如，按日期查找过去的消息）。状态的表示和管理方式决定了agents应用程序如何随着更长的对话历史或更多数量的agents而扩展，以及状态如何灵活地被访问或修改。

• Agent的上下文窗口结构：

每次调用LLM时，框架都会将agent的状态编译到上下文窗口中。不同的框架会以不同方式将数据放入上下文窗口（如指令、消息缓冲区等），这可能会改变性能。我们建议选择使上下文窗口透明的框架，因为这最终是如何控制agents行为的方式。

• 跨agent通信（即多agent）：

LlamaIndex通过消息队列进行agents通信，而CrewAI和AutoGen则有明确的多agent抽象器。Letta和LangGraph都支持agents直接相互调用，这允许通过监督agent进行集中式和分布式通信。现在大多数框架都支持多agent和单agent，因为设计良好的单agent系统应该使跨agent协作易于实现。

• 记忆方法：

LLM的一个基本限制是它们的有限上下文窗口，这需要随时间管理记忆的技术。记忆管理内置于某些框架中，而其他框架则期望开发者自己管理记忆。CrewAI和AutoGen仅依赖基于RAG的记忆，而phidata和Letta使用额外的技术，如自编辑记忆（来自MemGPT）和递归总结。Letta agents自动配备了一套记忆管理工具，允许agents通过文本或数据搜索以前的消息、写入记忆和编辑agent自己的上下文窗口。

• 开放模型支持：

模型提供商实际上在后台做了很多技巧来让LLM以正确的格式生成文本（例如工具调用）— 比如当它们没有生成正确的工具参数时重新采样LLM输出，或在提示中添加提示（例如"请输出JSON"）。支持开放模型需要框架处理这些挑战，所以一些框架限制了对主要模型提供商的支持。

在今天构建agents时，正确的框架选择取决于你的应用，比如你是在构建会话agent还是工作流，你是想在笔记本中运行agents还是作为服务运行，以及你对开放权重模型支持的要求。

我们预计框架之间的主要差异将出现在它们的部署工作流中，在这里状态/记忆管理和工具执行的设计选择变得更加重要。

七、 Agent托管和服务（Agent hosting and agent serving）

今天大多数agent框架都是为不存在于它们编写的Python脚本或JupyterNotebook之外的agents设计的。我们相信agents的未来是将其作为部署到本地或云基础设施的服务，通过REST API访问。就像OpenAI的ChatCompletion API成为与LLM服务交互的行业标准一样，我们预计最终会出现Agents API的赢家。不过目前还没有...

由于状态管理和安全工具执行的问题，将agents部署为服务比将LLM部署为服务要复杂得多。

• 工具及其所需的依赖项和环境需要明确存储在数据库中，因为环境需要由服务重新创建（当你的工具和agents在同一脚本中运行时这不是问题）。
• 应用程序可能需要运行数百万个agents，每个agent都在积累增长的对话历史。
• 从原型到生产时，inevitably agent状态必须经过数据规范化过程，而agent交互必须由REST API定义。

今天，这个过程通常由开发人员编写自己的FastAPI和数据库代码完成，但我们预计随着agents的成熟，这个功能将更多地嵌入到框架中。

总结

AI Agent技术栈仍处于早期阶段，未来发展重点可能包括：

• 标准化的Agent API
• 更完善的部署方案
• 丰富的工具生态
• 更强大的记忆管理机制

*关于Letta：该公司源自MemGPT开源项目，专注于构建高级AI Agent系统。其技术实力得到业界认可，吴恩达教授曾与其创始人合作开设短期课程，向开发者介绍Letta Agent的应用。

如果你觉得今天的分享有帮助，记得点赞、收藏并转发，下次找起来更方便哦！