📢 转载信息
原文链接:https://machinelearningmastery.com/7-steps-to-mastering-memory-in-agentic-ai-systems/
原文作者:Bala Priya C
在本文中,你将学习如何设计、实现和评估记忆系统,使AI代理应用程序随着时间的推移更加可靠、个性化和有效。
我们将涵盖的主题包括:
- 为什么记忆应被视为一个系统设计问题,而不仅仅是一个更大的上下文模型问题。
- AI代理系统中使用的主要记忆类型以及它们如何映射到实际的架构选择。
- 如何在生产环境中检索、管理和评估记忆,而不会污染上下文窗口。
让我们不要再浪费时间了。
7 Steps to Mastering Memory in Agentic AI Systems
Image by Editor
引言
记忆是AI代理系统设计中最常被忽视的部分之一。没有记忆,每一次代理运行都从零开始——没有先前会话的知识,没有用户偏好的记忆,也没有关于一小时前尝试过但失败了的事情的意识。对于简单的单轮任务来说,这是可以接受的,但对于运行和协调多步工作流的代理,或者随着时间的推移反复为用户提供服务的代理来说,无状态性将成为系统实际能做什么的硬性限制。
记忆使代理能够跨会话累积上下文,随着时间的推移个性化响应,避免重复工作,并在先前结果的基础上进行构建,而不是每次都从头开始。挑战在于,代理记忆并非单一事物。大多数生产代理需要短期上下文以进行连贯的对话,需要长期存储以供学习的偏好,以及需要检索机制来提取相关的记忆。
本文涵盖了在AI代理系统中实现有效记忆的七个实用步骤。它解释了如何理解你的架构所需的记忆类型,选择正确的存储后端,正确地写入和检索记忆,以及在生产环境中评估你的记忆层。
第一步:理解为什么记忆是一个系统问题
在接触任何代码之前,你需要重新构思你对记忆的看法。许多开发者的本能是认为使用具有更大上下文窗口的模型可以解决问题。事实并非如此。
研究人员和实践者已经记录了仅仅扩展上下文会发生什么:在实际工作负载下性能下降,检索变得昂贵,成本不断累积。这种现象——有时被称为“上下文退化”(context rot)——发生是因为一个被不加区分地填充了信息的放大上下文窗口会损害推理质量。模型将其注意力预算花费在噪声而非信号上。
记忆根本上是一个系统架构问题:决定存储什么,存储在哪里,何时检索,以及更重要的是,遗忘什么。在没有明确设计的情况下,这些决定都无法委托给模型本身。IBM对AI代理记忆的概述提出了一个重要观点:与根本不需要记忆的简单反射代理不同,处理复杂目标导向任务的代理需要记忆作为核心架构组件,而不是事后添加的东西。
实际的含义是,你应该像设计任何生产数据系统一样来设计你的记忆层。在编写任何代理代码之前,考虑写入路径、读取路径、索引、驱逐策略和一致性保证。
进一步阅读:什么是AI代理记忆?– IBM Think 和 什么是代理记忆?增强AI学习和回忆的指南 | MongoDB
第二步:学习AI代理记忆类型分类
认知科学为我们提供了用于描述智能系统中记忆独特角色的词汇。应用于AI代理,我们可以大致识别四种类型,每种类型都对应一个具体的架构决策。
短期或工作记忆就是上下文窗口——模型在单次推理调用中能够主动推理的一切。它包括系统提示、对话历史、工具输出和检索到的文档。将其想象成RAM:快速且即时,但在会话结束时会被清除。它通常实现为滚动缓冲区或对话历史数组,对于简单的单会话任务来说足够了,但无法在会话之间持久存在。
情景记忆记录了过去具体的事件、交互和结果。当代理回忆起用户昨天的部署因缺少环境变量而失败时,这就是情景记忆在起作用。它对于基于案例的推理特别有效——利用过去的事件、行为和结果来改进未来的决策。情景记忆通常存储为带有时间戳的记录在向量数据库中,并在查询时通过语义或混合搜索进行检索。
语义记忆存储结构化的事实知识:用户偏好、领域事实、实体关系以及与代理范围相关的通用世界知识。一个知道用户偏好简洁答案且从事法律行业的客户服务代理正在利用语义记忆。这通常实现为随时间增量更新的实体配置文件,结合了用于结构化字段的关系存储和用于模糊检索的向量存储。
程序记忆编码了“如何做事”——工作流、决策规则和通过经验学习到的行为模式。实际上,这表现为系统提示指令、少量示例或代理管理的规则集,这些规则集通过经验而演变。一个学会了在建议库升级之前总是检查依赖冲突的编码助手正在表达程序记忆。
这些记忆类型并非孤立运行。能够生产级运行的代理通常需要所有这些层协同工作。
进一步阅读:超越短期记忆:AI代理所需的3种长期记忆类型 和 理解AI代理中的记忆
第三步:了解检索增强生成与记忆的区别
开发者在构建AI代理系统时,一个持续的困惑来源是将检索增强生成(RAG)与代理记忆混淆。
⚠️ RAG和代理记忆解决相关但不同的问题,将错误的方法用在错误的工作上会导致代理过度设计或系统性地忽略正确的信息。
RAG根本上是一个只读检索机制。它通过在查询时查找相关块并将其注入上下文,将模型与外部知识——你的公司文档、产品目录、法律政策——联系起来。RAG是无状态的:每次查询都从头开始,它不区分谁在提问或他们之前说了什么。它是处理“我们的退款政策说什么?”这类问题的正确工具,但对于“这个特定客户上个月告诉我们关于他们账户的事情是什么?”这类问题则不是。
相比之下,记忆是读写且特定于用户的。它使代理能够了解个体用户跨会话的行为,回忆起尝试过但失败的事情,并随着时间的推移调整行为。这里的关键区别在于,RAG将相关性视为内容的属性,而记忆将相关性视为用户的属性。
RAG vs Agent Memory | Image by Author
以下是一个实用的方法:对通用知识或对所有人都适用的信息使用RAG,对用户特定上下文或对这个用户适用的信息使用记忆。大多数生产代理受益于两者并行运行,各自为最终的上下文窗口贡献不同的信号。
进一步阅读:RAG vs. 记忆:AI代理开发者需要了解什么 | Mem0 和 从RAG到代理RAG再到代理记忆的演变
第四步:围绕四个关键决策设计你的记忆架构
记忆架构必须预先设计。你关于存储、检索、写入路径和驱逐的选择与你系统的其他所有部分相互作用。在构建之前,回答以下四个问题,针对每种记忆类型:
1. 存储什么?
并非对话中发生的一切都值得持久化。将原始对话记录存储为可检索的记忆单元是诱人的,但它会导致检索结果嘈杂。
相反,在将交互写入存储之前,将其提炼成简洁、结构化的记忆对象——关键事实、明确的用户偏好以及过去操作的结果。这个提取步骤是大部分实际设计工作发生的地方。
2. 如何存储?
有很多方法可以做到这一点。以下是四种主要的表示方式,每种都有其用例:
- 向量数据库中的向量嵌入 vector database 支持语义相似性检索;它们非常适合情景记忆和语义记忆,因为查询是自然语言的。
- 键值存储,如 Redis,通过用户或会话ID提供快速、精确的查找;它们非常适合结构化配置文件和会话状态。
- 关系数据库提供带有时间戳、TTL(生存时间)和数据沿袭的结构化查询;当需要记忆版本控制和合规级审计能力时,它们很有用。
- 图数据库表示实体和概念之间的关系;这对于推理相互连接的知识非常有用,但维护起来很复杂,所以只有当向量+关系存储成为瓶颈时,才考虑使用图存储。
3. 如何检索?
将检索策略与记忆类型匹配。语义向量搜索对情景记忆和非结构化记忆效果很好。结构化键查找对配置文件和程序规则效果更好。混合检索——结合嵌入相似性与元数据过滤器——处理大多数实际代理所需的复杂中间情况。例如,“这个用户在过去30天内对账单说了什么?”既需要语义匹配,也需要日期过滤器。
4. 何时(以及如何)遗忘已存储的内容?
没有遗忘的记忆与没有记忆一样有问题。请确保在需要之前设计删除路径。
记忆条目应带有时间戳、来源信息和明确的过期条件。实现衰减策略,以便随着存储的增长,较旧、不太相关的记忆不会污染检索结果。
以下是两种实用方法:在检索评分中,较新的记忆具有更高的权重;或者在存储层中使用原生的TTL或驱逐策略自动过期陈旧数据。
进一步阅读:如何使用Redis内存管理构建AI代理 – Redis 和 代理记忆的向量数据库与图RAG:何时使用哪个。
第五步:将上下文窗口视为受限资源
即使有了强大的外部记忆层,所有信息最终都会流经上下文窗口——而这个窗口是有限的。将其塞满检索到的记忆并不能保证更好的推理。生产经验一再表明,这通常会使情况变得更糟。
存在几种不同的故障模式,其中以下两种随着上下文的增长最为普遍:
上下文污染发生在不正确或过时的信息进入上下文时。由于代理在推理步骤之间基于先前的上下文进行构建,因此这些错误可能会悄无声息地累积。
上下文分散注意力发生在模型因信息过多而负担过重,并倾向于重复历史行为而不是对当前问题进行新颖推理时。
管理这种稀缺性需要深思熟虑的工程。你不仅要决定检索什么,还要决定排除什么、压缩什么以及优先处理什么。以下是一些在各种框架中都适用的原则:
- 同时根据时效性和相关性进行评分。纯粹的相似性检索会浮现语义上最相似的记忆,但不一定是唯一有用的记忆。一个适当的检索评分函数应该结合语义相似性、时效性和明确的重要性信号。这对于关键事实能够浮现而不是被随意偏好所掩盖至关重要,即使该关键记忆更旧。
- 压缩,不要仅仅丢弃。当对话历史变长时,将旧的交流总结成简洁的记忆对象,而不是截断它们。关键事实应该在总结中得以保留;低信号的填充物则不应该。
- 为推理预留token。一个将90%的上下文窗口填满检索记忆的代理,其输出质量将低于一个有思考空间的代理。这对于多步规划和工具使用任务最为重要。
- 检索后过滤。并非所有检索到的文档都应进入最终上下文。一个检索后过滤步骤——根据即时任务对检索到的候选进行评分——可以显著提高输出质量。
MemGPT的研究,现在已产品化为Letta,提供了一个有用的思维模型:将上下文窗口视为RAM,外部存储视为磁盘,并赋予代理明确的机制按需分页进出信息。这使得记忆管理从静态的管道决策转变为动态的、由代理控制的操作。
进一步阅读:长上下文如何失败以及如何修复它们,3个难度的上下文工程解释,以及代理记忆:如何构建能够学习和记忆的代理 | Letta。
第六步:在代理循环内部实现记忆感知检索
在每次代理回合之前自动触发的检索是次优且昂贵的。一个更好的模式是给予代理检索作为一种工具——一个它可以在认识到需要过去上下文时调用的显式函数,而不是预先填充不相关的记忆转储。这反映了有效的人类记忆工作方式:我们在每次行动前不会回放所有记忆,但我们知道何时停下来回忆。代理控制的检索产生更具针对性的查询,并在推理链的正确时刻触发。在ReAct风格的框架(思考→行动→观察)中,记忆查找自然地适合作为可用工具之一。在观察到检索结果后,代理会评估其相关性,然后再将其纳入。这是一种在线过滤形式,可以显著提高输出质量。
对于多代理系统,共享记忆会引入额外的复杂性。代理可能会读取同伴写入的过时数据,或覆盖彼此的情景记录。设计共享记忆时要明确所有权和版本控制:
- 哪个代理是特定记忆命名空间的主导写入者?
- 当两个代理同时更新重叠记录时,一致性模型是什么?
这些是设计时需要回答的问题,而不是在生产调试期间试图回答的问题。
一个实际的起点:从对话缓冲区和基本的向量存储开始。当你的代理进行多步规划时,添加工作记忆——显式的推理草稿。只有当记忆之间的关系成为检索质量的瓶颈时,才添加基于图的长期记忆。过早地引入记忆架构的复杂性是团队减慢自身速度的最常见方式之一。
进一步阅读:AI代理记忆:构建有状态的AI系统以实现记忆 – Redis 和 构建记忆感知代理。
第七步:有意识地评估你的记忆层并持续改进
记忆是AI代理系统中进行评估最困难的组成部分之一,因为故障通常是不可见的。代理产生一个听起来合理但基于过时记忆、检索到的但无关的片段或代理本应拥有但缺失的情景上下文的答案。如果没有有意识的评估,这些故障就会隐藏起来,直到用户注意到。
定义记忆特定的指标。除了任务完成率,还要跟踪隔离记忆行为的指标:
- 检索精度:检索到的记忆是否与任务相关?
- 检索召回率:重要的记忆是否被浮现?
- 上下文利用率:检索到的记忆是否真的被模型使用,还是被忽略了?
- 记忆时效性:代理多久依赖一次过时的事实?
AWS通过AgentCore Memory在LongMemEval和LoCoMo等数据集上进行的基准测试,专门用于衡量跨多会话对话的保留能力。这种严谨程度应该是生产系统的标杆。
构建检索单元测试。在进行端到端评估之前,构建一个检索测试套件:一组经过精心策划的查询,以及它们应该检索到的记忆。这会将记忆层问题与推理问题区分开来。当代理在生产中的行为退化时,你将能快速知道根本原因是在检索、上下文注入还是模型对检索内容的推理。
同时监控记忆增长。生产记忆系统会不断积累数据。随着存储的增长,检索质量会下降,因为更多的候选记忆意味着检索集合中的噪声增加。随时间监控检索延迟、索引大小和结果多样性。计划进行定期的记忆审计——识别过时、重复或低质量的条目并将其修剪。
使用生产纠正作为训练信号。当用户纠正代理时,该纠正就是一个标签:要么代理检索了错误的记忆,要么没有相关记忆,要么拥有正确的记忆但没有使用它。关闭这个反馈循环——将用户纠正视为提高检索质量的系统性输入——是生产代理团队可获得的最有用的信息来源之一。
了解你的工具。一个不断增长的专用框架生态系统现在负责处理困难的基础设施。以下是一些你可以看看的AI代理记忆框架:
- Mem0提供智能记忆提取,具有内置的冲突解决和衰减功能
- Letta实现了类似操作系统的分层记忆结构
- Zep从对话中提取实体和事实,形成结构化格式
- LlamaIndex Memory提供与查询引擎集成的可组合记忆模块
选择一个可用的框架而不是从头开始构建自己的框架,可以节省大量时间。
进一步阅读:构建更智能的AI代理:AgentCore长期记忆深度解析 – AWS 和 2026年你应尝试的6个最佳AI代理记忆框架。
总结
如你所见,AI代理系统中的记忆不是一次设置好就不用管的事情。这个领域的工具改进了很多。专用记忆框架、向量数据库和混合检索管道使得实现健壮的记忆比一年前更加可行。
但核心决策仍然很重要:存储什么,忽略什么,如何检索它,以及如何在不浪费上下文的情况下使用它。良好的记忆设计归结为有意识地决定什么被写入,什么被移除,以及它在循环中是如何使用的。
| 步骤 | 目标 |
|---|---|
| 理解为什么记忆是一个系统问题 | 将记忆视为架构问题,而不是更大的上下文窗口问题;像设计任何生产数据系统一样,决定存储什么、检索什么以及遗忘什么。 |
| 学习AI代理记忆类型分类 | 理解四种主要的记忆类型——工作记忆、情景记忆、语义记忆和程序记忆——以便你能将每种类型映射到正确的实现策略。 |
| 了解检索增强生成与记忆的区别 | 使用RAG处理共享的外部知识,而使用记忆处理用户特定的、读写上下文,以帮助代理在会话中学习。 |
| 围绕四个关键决策设计你的记忆架构 | 通过决定存储什么、如何存储、如何检索以及何时遗忘来有意识地设计记忆。 |
| 将上下文窗口视为受限资源 | 通过优先处理相关记忆、压缩旧信息以及在噪声到达模型之前进行过滤,来保持上下文窗口的焦点。 |
| 在代理循环内部实现记忆感知检索 | 仅在需要时让代理检索记忆,将检索视为一种工具,并避免过早引入不必要的复杂性。 |
| 有意识地评估你的记忆层并持续改进 | 使用特定的检索指标衡量记忆质量,直接测试检索行为,并利用生产反馈持续改进系统。 |
善用记忆的代理通常会随着时间的推移表现得更好。这些才是值得关注的系统。祝你学习和构建愉快!
🚀 想要体验更好更全面的AI调用?
欢迎使用青云聚合API,约为官网价格的十分之一,支持300+全球最新模型,以及全球各种生图生视频模型,无需翻墙高速稳定,文档丰富,小白也可以简单操作。
评论区