AI Agents技术栈图谱深度解析

最近行业里有个值得关注的动作——Letta（就是之前那个备受关注的 MemGPT，最近改了名）发布了一份关于 AI Agents Stack 的研究报告。说实话，市面上类似的 Agent 技术栈地图和市场格局分析已经有不少了，但坦白讲，很多分类方式让人难以认同。它们往往跟开发者实际使用的真实情况相去甚远。

过去几个月，Agent 软件生态在记忆管理、工具调用、安全执行和部署落地这几个维度上，进步非常明显。所以，基于团队在开源 AI 领域一年多的实战经验，以及背后 7 年以上的 AI 研究积累，我们决定拿出自己的一份判断——一份真正反映当下业界真实面貌的“Agent 技术栈图谱”。

站在 2024 年末这个节点上看，AI Agents 的技术栈可以清晰地划分为三个关键层次：Agent 托管/服务、Agent 框架，以及大语言模型与记忆存储。

从大语言模型到 Agent

回顾 2022 年和 2023 年，那是大语言模型框架和 SDK 的黄金爆发期——LangChain（2022 年 10 月发布）和 LlamaIndex（2022 年 11 月发布）相继登场。与此同时，通过 API 调用大语言模型或自行部署推理的“标准”平台也开始成型，像 vLLM 和 Ollama 就是其中的典型代表。

但到了 2024 年，风向彻底变了。大家的兴趣开始剧烈转向“Agent”和更广义的复合系统。虽说“Agent”这个词在 AI 领域已经存在了几十年（尤其在强化学习里），但在后 ChatGPT 时代，它的含义反而变得模糊了。通常来说，它指的是那种能够输出执行动作（工具调用）、并在自主环境中运行的大语言模型系统。

从大语言模型转向 Agent，关键就在于工具使用、自主执行和记忆管理等能力的组合。正是这种组合，催生了一套全新的 Agent 架构。

Agent 架构的独特之处

相比一般的大语言模型聊天机器人，Agent 在工程上的挑战要大得多。核心原因在于它需要状态管理——比如保留消息/事件历史、存储长期记忆、在 Agent 循环中反复执行多次大语言模型调用。同时还要处理工具执行——也就是安全地执行模型输出的动作并返回结果。

所以，AI Agents 的架构跟标准的大语言模型架构有很大不同。我们从底层的模型服务层开始逐一拆解。

模型服务

AI Agents 的基石就是大语言模型。用大模型基本都要通过付费 API 借助推理引擎来服务。闭源模型 API 提供商中，OpenAI 和 Anthropic 是毫无争议的领跑者。而 Together.AI、Fireworks 和 Groq 也成了几个热门选择，它们通过付费 API 提供服务，不过是基于 Llama 3 这样的开源模型。

在生产级的 GPU 服务负载处理上，vLLM 是目前使用最广泛的方案。SGLang 作为后起之秀，也吸引了一大批同样技术背景的开发者。至于个人爱好者和发烧友群体，Ollama 和 LM Studio 则是最受欢迎的选择——可以让你在自己的电脑上跑模型。

存储

对于有状态的 Agent 来说，存储是最基础也是最基本的构件。Agent 的特性就是由它的对话历史、记忆、以及用于检索增强生成（RAG）的外部数据源等持久化状态来定义的。

像 Chroma、Wea viate、Pinecone、Qdrant 和 Milvus 这样的向量数据库，常被用来存 Agent 的“外部记忆”。这能让 Agent 利用起那些太大、放不进上下文窗口的数据来源和对话历史。有意思的是，Postgres 这个起源于 80 年代的“老古董”，现在也通过 pgvector 扩展支持向量搜索。基于 Postgres 的公司如 Neon（做无服务化的 Postgres）和 Supabase，同样能为 Agent 提供基于嵌入的搜索和存储能力。

工具与库

AI 聊天机器人和 AI Agents 之间最明显的区别之一，就是 Agent 能调用“工具”（或“函数”）。大多数情况下的运作机制是：大语言模型生成结构化的输出（比如 JSON 对象），来指定要调用的函数及参数。

这里有个常见的误解需要澄清：工具执行这件事本身不是大语言模型提供商完成的——模型只负责“选”要调哪个工具、传什么参数。支持任意工具或参数的 Agent 服务，必须借助沙盒（如 Modal、E2B）来确保安全执行。

如今，Agent 几乎都通过 OpenAI 定义的 JSON 模式来调用工具。这意味着 Agent 和工具实际上可以在不同框架之间互相兼容。举个例子，Letta Agent 就能调用 LangChain、CrewAI 和 Composio 的工具——原因很简单，它们用的是同一个模式。通用的工具供应商生态也因此不断壮大。Composio 就是一个比较流行的通用工具库，同时还管理权限。Browserbase 是专门做网页浏览的工具，Exa 则提供网络搜索工具。随着更多 Agent 被构建出来，预计工具生态还会继续进化，为 Agent 带来身份验证、访问控制等更丰富的功能。

Agent 框架

Agent 框架负责协调大语言模型的调用，并管理 Agent 的状态。不同框架之间的设计差异，主要体现在几个维度上：

首先是Agent 状态管理。大多数框架引入了某种“状态序列化”的概念——把序列化后的状态（JSON、Bytes 等）保存到文件里，后续可以重新加载到脚本中。这里面包括对话历史、Agent 记忆、执行阶段等信息。但在 Letta 里，所有状态都是由数据库支撑的（比如消息表、Agent 状态表、内存块表），没有“序列化”这一步，因为 Agent 状态本来就是始终持久化的。这带来的好处是查询状态非常方便（比如按日期查找过往消息）。

其次是Agent 上下文窗口结构。每次调用大语言模型时，框架都会把 Agent 状态“编译”进上下文窗口。不同框架放入数据的方式各异（如指令、消息缓冲区等），这会影响性能。我的建议是，优先选择那些让上下文窗口逻辑透明的框架——因为最终，这才是你能控制 Agent 行为的关键所在。

然后是跨 Agent 通信，也就是多 Agent 的场景。Llama Index 通过消息队列让 Agent 互相通信；CrewAI 和 AutoGen 则专门设计了明确的 Multi-Agent 抽象层；Letta 和 LangGraph 都支持 Agent 直接互相调用，既能通过一个监管 Agent 实现集中式通信，也能支持跨 Agent 的分布式通信。现在大多数框架都已经同时支持多 Agent 和单 Agent——因为一个设计得当的单 Agent 系统，理应能让跨 Agent 协作变得容易。

最后是记忆管理方法。大语言模型有一个根本性的限制：上下文窗口有限。要解决这个问题，就必须依赖持续管理记忆的技术。有些框架自带记忆管理功能，有的则把这件事丢给开发者自己处理。CrewAI 和 AutoGen 只依赖于基于 RAG 的记忆；而 phidata 和 Letta 用了其他技术，比如自编辑记忆（来自 MemGPT）和递归总结。Letta Agent 自动配备了一套记忆管理工具，让 Agent 能通过文本或数据搜索找回过去的消息、写入记忆，甚至编辑自己的上下文窗口。

至于对开放模型的支持，事情也复杂些。模型提供商在幕后做了很多功夫来确保大语言模型能按正确格式输出（比如工具调用所需的格式）——当输出不对时重采样，或在 Prompt 里加一些“请漂亮地输出 JSON”之类的话。支持开源模型就需要框架自己来处理这些难题。所以有些框架干脆把支持范围限制在主流模型提供商上。

老实说，目前在搭建 Agent 时怎么选框架，完全取决于你的应用场景：是对话 Agent 还是工作流？是在笔记本里跑，还是作为服务上线？是否必须支持开源模型？预计未来框架之间的主要差异会集中在部署工作流上，而状态/记忆管理和工具执行的设计选择会变得越来越重要。

Agent 托管和 Agent 服务

如今，大多数 Agent 框架还是为那些只存在于 Python 脚本或 Jupyter Notebook 里的 Agent 设计的。但我们的判断是：Agent 的未来应该是作为一种服务部署到本地或云基础设施上，通过 REST API 来访问。

想想看，OpenAI 的 ChatCompletion API 已经成为与大语言模型服务交互的行业标准。同样，我们最终应该会看到一个 Agent API 方案的胜出者……但到目前为止，还没有出现。

把 Agent 作为服务来部署，比把大语言模型作为服务部署要棘手得多，这全是因为状态管理和安全工具执行的问题。工具及其依赖项和环境必须明确存储在数据库中——因为运行这些工具的环境需要被服务重新创建（如果工具和 Agent 在同一个脚本里跑，这不是问题，但一旦分离就完全不一样了）。

实际应用中，可能需要运行数百万个 Agent，而每个 Agent 都会积累不断增长的对话历史。从原型设计转向生产环境时，Agent 状态不可避免地要经过数据规范化，Agent 的交互也必须由 REST API 来定义。目前，这个工作基本都得开发者自己写 FastAPI 和数据库代码来完成。不过可以预见的是，随着 Agent 不断成熟，这类功能会更多地被内嵌到框架本身。

结论

坦白讲，Agent 的技术栈现在还处于非常早期的阶段。这个生态接下来会如何扩展和演变，非常值得持续关注。

-- 完 --

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：AI Agents技术栈图谱深度解析要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题