[控场AI]
· 5 分钟阅读· 2,689 字

用NVIDIA NeMo Agent Toolkit与S3 Vectors构建智能体记忆层

用NVIDIA NeMo Agent Toolkit与S3 Vectors构建智能体记忆层

用Amazon S3 Vectors为NVIDIA NAT智能体框架提供低成本、可扩展的持久化向量记忆,并部署于EKS上支撑多智能体长周期任务。

大模型智能体因缺乏跨会话记忆而难以胜任长周期复杂任务。本文介绍了一套以NVIDIA NeMo Agent Toolkit(NAT)为编排核心、Amazon S3 Vectors为持久化向量存储后端、Amazon EKS为弹性运行环境的云原生智能体记忆方案。NAT的可插拔记忆子系统将向量化写入与语义检索抽象为统一接口,开发者只需实现自定义记忆提供者即可接入S3 Vectors,以低于专用向量数据库的成本获得近乎无限的存储扩展能力。文章以多智能体投资研究为实战场景,说明持久化记忆如何让各智能体在数天乃至数周的分析周期内共享历史发现、保持结论连贯,并通过EKS实现按需水平扩展与生产级运维。

为什么智能体需要持久化记忆

大模型智能体在单次对话中表现出色,但一旦会话结束,上下文往往随之消失。对于需要跨会话、跨任务保持状态的复杂应用——比如长期跟踪的投资研究、客户服务或科研助手——缺乏持久化记忆意味着每次都要从零开始。记忆层的核心价值,就是让智能体能够记住过去的交互、检索相关历史信息,并在新的推理中加以利用。

NVIDIA NeMo Agent Toolkit(简称NAT)正是围绕这一需求设计的开发框架。它内置了一套记忆子系统(memory subsystem),允许开发者将不同的存储后端接入智能体的记忆管线。而Amazon S3 Vectors则提供了一种低成本、可扩展的向量存储方案,二者结合可以为多智能体系统搭建起可靠的长期记忆。

NVIDIA NeMo Agent Toolkit与Amazon S3 Vectors构建智能体记忆

NAT 记忆子系统的工作机制

NAT 的记忆子系统采用可插拔的架构设计。它把记忆的"写入"与"读取"抽象成统一接口,底层具体由哪种存储实现并不影响上层智能体逻辑。这种解耦让开发者可以根据场景自由选择后端:既可以用本地向量库做快速原型,也可以切换到云端的托管服务支撑生产负载。

在实际运行中,智能体产生的关键信息会被向量化后存入记忆层。当后续任务需要相关背景时,系统通过语义相似度检索把最相关的记忆片段召回,再注入到模型的推理上下文中。这种基于向量检索的记忆机制,本质上是把 RAG(检索增强生成)的思路应用到了智能体的状态管理上。

RAG(Retrieval-Augmented Generation,检索增强生成)最初被设计用于解决大模型知识截止问题:在推理时从外部知识库检索相关文档片段,拼接进提示词,从而让模型回答训练数据之外的问题。将其迁移到智能体状态管理的关键差异在于,检索的对象从静态文档变成了智能体自身的历史行动与中间结论——这些内容在每次会话后动态增长。向量化的过程通常由嵌入模型(Embedding Model)完成,将文本片段映射为高维稠密向量,语义相近的内容在向量空间中距离也更近,从而支持近似最近邻(ANN)检索。整个流程的延迟和精度,很大程度上取决于嵌入模型的选择和向量索引的构建策略。

将 S3 Vectors 实现为自定义记忆提供者

文章演示的核心做法,是把 Amazon S3 Vectors 实现为 NAT 的一个"自定义记忆提供者"(custom memory provider)。开发者只需遵循 NAT 定义的记忆接口规范,把向量的存储、查询、更新等操作对接到 S3 Vectors 的 API 上,就能让整个工具包无缝使用 S3 作为持久化后端。

选择 S3 Vectors 作为后端有几个现实考量。其一是成本——相比专用向量数据库,基于对象存储的方案在大规模数据下通常更经济;其二是可扩展性,S3 的存储能力几乎没有上限;其三是与 AWS 生态的天然集成,便于统一管理权限、监控和运维。对于已经在 AWS 上构建应用的团队,这种方案能显著降低引入新组件的门槛。

Amazon S3 Vectors 是 AWS 于 2025 年推出的原生向量存储功能,直接在 S3 之上提供向量索引与近似最近邻查询能力,无需额外运维专用向量数据库。传统向量数据库(如 Pinecone、Weaviate、Milvus)通常需要独立部署、独立计费,并自行管理高可用。S3 Vectors 则将向量存储融入对象存储的定价与运维模型,按存储量和查询次数计费,对于写多读少或数据量增长不可预期的场景,成本优势尤为显著。其代价是,相比专为向量检索优化的引擎,查询延迟和高并发吞吐可能略逊一筹,因此在选型时需结合具体的 SLA 要求权衡。

多智能体投资研究的实战场景

原文以一个多智能体投资研究用例来串联整套方案。在这类场景中,通常会有多个各司其职的智能体协同工作——例如一个负责抓取财报数据、一个负责分析市场情绪、另一个负责汇总生成研究报告。每个智能体在工作过程中积累的发现,都可以写入共享的记忆层。

持久化记忆在这里的作用尤为明显:投资研究往往是持续数天甚至数周的长周期任务,智能体需要记住此前分析过的公司、得出的结论以及数据来源。借助 S3 Vectors 支撑的记忆层,系统可以在新一轮分析中快速调取历史判断,避免重复劳动并保持分析的连贯性。

部署在 Amazon EKS 上的生产考量

整个方案被部署在 Amazon Elastic Kubernetes Service(EKS)之上。选择 Kubernetes 作为运行环境,意味着多智能体系统可以按需水平扩展——当并发任务增多时,可以动态增加智能体实例;在负载回落时又能收缩资源。EKS 的托管特性也减轻了集群运维负担。

这种 "NAT + S3 Vectors + EKS" 的组合,实际上勾勒出一条在云原生环境中落地智能体应用的完整路径:NAT 负责智能体编排与记忆抽象,S3 Vectors 提供持久化向量存储,EKS 承载弹性计算。三者各自解决一个层面的问题,组合起来形成了一个可扩展、可运维的生产级架构。

Amazon EKS(Elastic Kubernetes Service)是 AWS 提供的托管 Kubernetes 服务,用户无需自行管理控制平面(Control Plane)。在多智能体部署场景中,Kubernetes 的关键价值在于其声明式的工作负载管理:开发者通过 Deployment、HorizontalPodAutoscaler 等资源描述期望状态,集群自动完成调度、故障恢复和弹性伸缩。对于智能体系统,这意味着可以把不同职责的智能体(如数据抓取、情绪分析、报告生成)分别封装为独立的微服务,通过统一的服务发现和消息机制协调通信,同时各自根据负载独立扩缩,既提升资源利用率,也避免单点故障扩散至整个系统。

小结

智能体从"能对话"走向"能长期协作",记忆层是绕不开的一环。这套方案展示了如何用标准化的接口把成熟的云存储服务接入智能体框架,在控制成本的同时获得生产级的持久化能力。对于正在构建复杂多智能体系统的团队,这种模块化、可插拔的设计思路值得借鉴。需要提醒的是,本文基于单一来源的技术博客,具体实现细节与性能表现仍需结合官方文档和实际测试进一步验证。

分享:

相关推荐