Letta（由之前爆火的 MemGPT 更名）最近做了一个关于 AI Agents Stack 的研究报告。
原文地址：https://www.letta.com/blog/ai-agents-stack特别鸣谢特工宇宙战略顾问庄明浩老师的推荐，以下为原文内容（由特工宇宙自研 Arsenal-Agent 辅助翻译）尽管我们看到了很多 Agent 技术栈地图和 Agent 市场地图，但我们往往不同意它们的分类方式，并且发现它们很少反映我们观察到的开发者实际使用的情况。在过去几个月里，Agent 软件生态系统随着记忆、工具使用、安全执行和部署方面的进展而有了显著发展，所以，我们决定根据自己在开源人工智能领域一年多的工作经验以及 7 年多的人工智能研究成果，分享我们自己的“Agent 技术栈图谱”。2024 年末的 AI Agents 技术栈，分为三个关键层：Agent 托管/服务、Agent框架以及大语言模型与记忆存储。在 2022 年和 2023 年，我们看到了大语言模型框架和 SDK 的兴起，比如 LangChain（2022.10 发布）和 LlamaIndex（2022.11 发布）。同时，我们看到了几个通过 API 使用大语言模型以及自行部署大语言模型推理（如 vLLM 和 Ollama）的“标准”平台的建立。到了 2024 年，我们看到人们的兴趣朝着“Agent”以及更广泛的复合系统发生了巨大转变。尽管“Agent”作为人工智能领域的一个术语已经存在了几十年（特别是在强化学习中），但在后 ChatGPT 时代，它已成为一个定义模糊的术语，通常指的是输出某任务的动作（工具调用）并在自主环境中运行的大语言模型系统。LLMs that are tasked with outputting actions (tool calls) and that run in an autonomous setting. 从大语言模型转变为 Agent 所需要的工具使用、自主执行和记忆管理等能力的结合，促使了一种新的 Agent 架构的发展。与一般的大语言模型聊天机器人相比，Agent 是一个难度大得多的工程挑战，因为它们需要状态管理（保留消息/事件历史、存储长期记忆、在 Agent 循环中执行多次大语言模型调用）和工具执行（安全地执行大语言模型输出的动作并返回结果）。因此，AI Agents 架构看起来与标准的大语言模型架构非常不同。让我们从底层的模型服务层开始拆解当今的 AI Agents 架构：AI Agents 的核心是大语言模型。要使用大语言模型，通常需要通过付费 API 来给推理引擎来提供服务。OpenAI 和 Anthropic 在拥有闭源模型的 API 提供商中处于领先地位。Together.AI、Fireworks 和 Groq 是几个流行的选择，它们通过付费 API 提供开源模型服务（比如Llama 3）。vLLM 是最常被用来处理生产级别的、基于GPU的服务负载的领先者。SGLang 是一个具有类似开发者受众的新兴项目。SGLang 是一个新兴的项目，它吸引了一群类似的开发者。在那些对 AI 感兴趣的爱好者中，Ollama 和 LM Studio 是两个流行的选择，可以让你在自己的电脑上运行模型。存储是对于有状态的 Agent 来说是一个基本构建块——Agent 由其对话历史、记忆以及用于检索增强生成（RAG）的外部数据源等持久化状态来定义。像 Chroma、Weaviate、Pinecone、Qdrant 和 Milvus 这样的向量数据库常用于存储 Agent 的“外部记忆”，使 Agent 能够利用太大而无法放入上下文窗口的数据来源和对话历史。Postgres 是一个自 80 年代就存在的传统数据库，现在也通过 pgvector 扩展支持向量搜索。像 Neon（无服务器 Postgres）和Supabase这样基于 Postgres 的公司也为 Agent 提供基于嵌入的搜索和存储。AI 聊天机器人和 AI Agents 之间的主要区别之一是 Agent 调用“工具”（或“函数”）的能力。在大多数情况下，这种 Action 的机制是大语言模型生成指定要调用的函数和要提供的参数的结构化输出（例如 JSON 对象）。Agent 工具执行中一个常见的混淆点是，工具执行不是由大语言模型提供商本身完成的——大语言模型只选择调用什么工具以及提供什么参数。支持任意工具或工具任意参数的 Agent 服务必须使用沙盒（如 Modal、E2B）来确保安全执行。Agent 都通过 OpenAI 定义的 JSON 模式调用工具——这意味着 Agent 和工具实际上可以在不同框架之间兼容。Letta Agent可以调用 LangChain、CrewAI 和 Composio 工具，因为它们都是由相同的模式定义的。因此，通用工具的提供商生态系统正在不断发展。Composio 是一个流行的通用工具库，它也管理权限。Browserbase 是用于网页浏览专用工具的一个例子，Exa 提供了用于搜索网页的专用工具。随着更多 Agent 的构建，我们预计工具生态系统将不断发展，并为 Agent 提供诸如身份验证和访问控制等现有新功能。Agent 框架协调大语言模型调用并管理 Agent 状态（State）。不同的框架在以下方面会有不同的设计：Agent 状态管理：大多数框架引入了某种“状态序列化”概念，允许通过将序列化状态（如 JSON、Bytes）保存到文件中，在以后将 Agent 重新加载到同一脚本中——这包括对话历史、Agent 记忆和执行阶段等状态。在 Letta 中，所有状态都由数据库支持（如消息表、Agent 状态表、内存块表），不存在“序列化”概念，因为 Agent 状态始终是持久化的。这允许轻松查询 Agent 状态（例如，按日期查找过去的消息）。状态的表示和管理方式决定了 Agent 应用程序如何随着更长的对话历史或更多数量的 Agent 进行扩展，以及随着时间的推移如何灵活地访问或修改状态。Agent 上下文窗口结构：每次调用大语言模型时，框架会将 Agent 状态“编译”到上下文窗口中。不同的框架会以不同的方式将数据放入上下文窗口（如指令、消息缓冲区等），这可能会改变性能。我们建议选择使上下文窗口透明的框架，因为这最终是你可以控制 Agent 行为的方式。跨 Agent 通信（即 Multi-Agent）：Llama Index 通过消息队列让 Agent 进行通信，而 CrewAI 和 AutoGen 有明确的 Multi-Agent abstractors。Letta和 LangGraph 都支持 Agent 直接相互调用，这允许通过监管 Agent 进行集中式通信以及跨 Agent 的分布式通信。现在大多数框架都支持多 Agent 和单Agent，因为一个设计良好的单 Agent 系统应该也使其跨 Agent 协作易于实现。记忆管理方法：大语言模型的一个基本限制是其有限的上下文窗口，这就需要随着时间推移管理记忆的技术。一些框架内置了记忆管理功能，而其他框架则期望开发者自己管理记忆。CrewAI 和 AutoGen 仅依赖基于检索增强生成（RAG）的内存，而 phidata 和 Letta 使用其他技术，如自编辑记忆（来自 MemGPT）和递归总结。Letta Agent 自动配备了一组内存管理工具，允许 Agent 通过文本或数据搜索以前的消息、写入记忆并编辑 Agent 自己的上下文窗口。对开放模型的支持：模型提供商实际上在幕后做了很多技巧来使大语言模型以正确的格式生成文本（例如用于工具调用）——例如，当大语言模型输出没有生成合适的工具参数时重新采样输出，或者在提示中添加 Prompt（如“请漂亮地输出JSON”）。支持开源模型需要框架处理这些挑战，所以一些框架将支持限制主流模型提供商。如今在构建 Agent 时，框架的正确选择取决于你的应用程序，例如你是构建对话 Agent 还是工作流，你是想在笔记本中还是作为服务运行 Agent，以及你对开源模型支持的要求。我们预计框架之间在部署工作流程方面会出现主要差异，其中状态/记忆管理和工具执行的设计选择将变得更加重要。Agent 托管和 Agent 服务
如今大多数 Agent 框架是为仅存在于编写它们的 Python 脚本或 Jupyter Notebook 中的 Agent 而设计的。我们认为 Agent 的未来是将 Agent 视为一种部署到本地或云基础设施的服务，通过 REST API 进行访问。就像 OpenAI 的 ChatCompletion API 成为与大语言模型服务交互的行业标准一样，我们预计最终会有一个 Agent API 的赢家。但目前还没有……将 Agent 作为服务进行部署，比将大语言模型作为服务部署要棘手得多，这是由于状态管理和安全工具执行的问题。工具及其所需的依赖和环境，需要明确存储在数据库中，因为运行它们的环境需要由服务重新创建（当你的工具和 Agent 在同一脚本中运行时，这不是问题）。应用程序可能需要运行数百万个 Agent，每个 Agent 都会积累不断增长的对话历史。当从原型设计转向生产时，Agent 状态不可避免地必须经过数据规范化过程，并且 Agent 交互必须由 REST API 定义。如今，这个过程通常由开发者编写自己的 FastAPI 和数据库代码来完成，但我们预计随着 Agent 的成熟，这个功能将更多地嵌入到框架中。Agent 的技术栈仍处于非常早期的阶段，我们很高兴看到 Agent 的生态如何随着时间的推移而扩展和演变。（此外省略一个官方的广告）
粤ICP备17114055号
支持私有云部署
