AI Agent的记忆系统秘密

你有没有遇到过这种情况：

跟AI聊了半天，中间去了趟厕所，回来继续聊——AI突然"失忆"了，问你"你刚才说什么来着？"

这不是AI"故意忘记"，而是它的上下文窗口装不下了。

但有些AI助理却能"记住你"——知道你的名字、你的项目、你上次聊到哪。

为什么有的AI能"记住"，有的却"转头就忘"？

今天这篇，我们就来搞清楚：Agent的记忆系统是怎么工作的？

一、为什么Agent需要"记忆"？

LLM的天然缺陷

LLM（大语言模型）的本质是：

输入文本 → 输出文本

它没有真正的"记忆"：

●上下文窗口限制：只能"看到"最近一段上下文（即使是GPT-4o支持的128K上下文窗口，也就只能看8~16万字的书）

●每次对话都是"重新开始"：关掉对话框再打开，它就不认识你了——对话结束后所有内容都已消失

●不会"主动记住"：并不存在真正的"记住"，只是在当前窗口内临时可见。这也是为什么Agent需要额外的记忆系统

Agent为什么需要记忆？

真正的Agent需要：

●跨会话记忆：记住你之前说过的话、你的偏好、你的项目背景

●个性化响应：知道你喜欢"简洁的答案"还是"详细的解释"

●项目级记忆：记住你的代码库结构、你的写作风格、你的常用工具

Agent就像有长期记忆的助理——不仅记得刚才的事，还记得上个月你跟它聊过什么

二、Agent记忆的底层逻辑

早期的Agent用"向量数据库"存储所有记忆，但实践中发现：

●问题1：向量检索不精准（召回"语义接近但时间/场景错误"的记忆）

●问题2：所有记忆"一视同仁"，重要信息可能被淹没

●问题3：成本问题（存储和检索大量向量，API费用高）

所有Agent记忆系统的底层逻辑：两层核心

先把事情想简单——所有Agent的记忆系统，本质上都在解决两层问题。

第1层：上下文窗口（当前可见的）

你在跟Agent聊天时，它能"看到"的全部内容都在上下文窗口里。这就是它"正在处理"的信息空间。

●装了什么：当前对话 + 系统提示词 + 从持久化存储中检索到的记忆

●怎么访问：直接在场，无需搜索

●局限：窗口大小有限（比如GPT-4o是128K tokens，约一本书的几章）

类比：你大脑里"正在想的事"——此刻活跃在你意识中的信息。

第2层：持久化存储（跨会话保留的）

关了对话框再打开，Agent还能记得你是谁——秘密就在这里。

●装了什么：用户画像、关键事实、历史对话摘要

●怎么访问：需要搜索调取（语义检索或关键词匹配），窗口装不下所有历史

●特点：容量几乎无限，但检索有成本

类比：你写在笔记本上的东西——需要时翻出来看，不会时刻记在脑子里。

为什么还需要往细了分？

两层是"最小公分母"——任何Agent系统都得有。但实践中发现，把持久化存储里的东西混在一起有问题：用户画像（"我叫张三"）和三个月前的闲聊放在同一个库里，检索时可能互相干扰。昨天聊的内容和半年前的内容，重要程度也不同。

所以不同框架在这两层基础上，各做各的扩展——有的把用户画像单独拎出来，有的给对话历史单独建索引，有的加任务状态跟踪。这些扩展都是工程选择，没有哪套是"唯一标准"。

两种典型的扩展方式：

●Letta方式：把持久化存储拆成三层——核心记忆（用户画像）+ 召回内存（对话历史搜索）+ 归档内存（长期知识）+上下文窗口，一共四层

●OpenClaw方式：用文件统一管理持久化信息，通过 Dreaming 机制自动筛选哪些值得长期保留

下面我们分别看看这两种做法。

三、记忆系统的工程化实践

Letta（原 MemGPT）：操作系统般的分层管理

如果把持久化存储比作"硬盘"，Letta 就是一个给 Agent 装上"文件系统"的框架。

Letta 的设计理念是"让 LLM 像操作系统一样管理内存"——它在两层核心的基础上，把持久化存储拆成了三层：

●工作记忆（Working Context）：上下文窗口中当前活跃的部分。每次LLM调用时，所有Memory Blocks和检索到的信息都被加载到这里

●核心记忆（Core Memory / Memory Blocks）：包括 persona（"我是谁"）、human（"我了解用户什么"）、tasks（"我需要做什么"）等可编辑的持久化片段，跨会话保持。这是用户画像的专属空间

●召回内存（Recall Memory）：存储完整对话历史，支持语义检索和时间过滤，Agent 通过 conversation_search 主动查找。相当于给对话历史单独建了索引，方便翻旧账

●归档内存（Archival Memory）：无限容量的向量存储，放"不需要时刻在眼前但需要长期保留"的信息，通过 archival_memory_search 按需检索。相当于长期知识库

召回内存和归档内存区别在哪？

一个存"聊了什么"，一个存"知道了什么"。召回内存是对话的原始记录（类似聊天记录），归档内存是知识——可以是读过的文档，也可以是Agent自己生成的反思、分析结论、项目决策等。你去年跟Agent聊过的某次对话存在召回内存里，而Agent从那场对话中总结出的"用户偏好简洁答案"就存在归档内存里。

Letta 的工作流程：

Agent 收到用户消息 → 先看工作记忆里有没有足够信息 → 不够就自主搜索召回内存（对话历史）或归档内存（长期知识） → 检索结果加载到工作记忆 → 根据需要更新核心记忆（用户画像/任务列表） → 生成回复。

OpenClaw：热门项目的另一种思路

如果说 Letta 是"严格按教科书实现"，那 OpenClaw 就是"工程务实的简化版"，它的记忆方案非常有特点：

基于文件的记忆架构

●MEMORY.md：长期记忆（持久化事实、偏好、决策），每次会话开始时加载

●memory/YYYY-MM-DD.md：每日笔记（运行上下文），今天和昨天的笔记自动加载

●DREAMS.md（可选）：Dream Diary，记录"做梦"过程中的记忆提升决策

设计理念："模型只'记住'写入磁盘的内容——没有隐藏状态" —— 所有记忆都是可检查、可编辑的Markdown文件。

记忆工具

OpenClaw提供了两个记忆工具：

●memory_search：用语义搜索找相关记忆，即使用词不同也能找到

●memory_get：读取指定的记忆文件或行范围

这两个工具由memory-core插件提供。

混合检索（Hybrid Search）

当配置了嵌入模型后，memory_search使用混合检索——结合向量相似度（语义含义）和关键词匹配（精确术语如ID和代码符号）。

什么是嵌入模型？ 它不是LLM（LLM负责对话），而是一个专门"把文字变成数字"的模型。一段话输入进去，输出一串数字（向量），两段意思接近的话，数字也接近。向量检索就是靠比对这些数字来判断"哪段记忆跟你的问题最相关"。

优势：

●向量检索找"语义相关"的记忆

●关键词检索找"精确匹配"的记忆

●两者结合，比单一检索更精准

OpenClaw会自动检测你的嵌入模型提供商（OpenAI、Gemini、Qwen...），一旦配置了API密钥，混合检索就开箱即用。

OpenClaw 的做法：用文件统一管理持久化信息

和 Letta 不同，OpenClaw 没有把持久化存储拆成多层——它用一个文件 MEMORY.md 统一存放用户画像、关键事实、偏好和决策，另用一个每日笔记文件 memory/YYYY-MM-DD.md记录运行时的对话上下文。

●上下文窗口：跟所有Agent一样，当前会话内容在窗口里

●持久化存储：全在 MEMORY.md 一个文件里——用户画像和长期记忆不做区分，统一管理。通过 memory_search 工具搜索，通过 memory_get 工具直接读

●每日笔记：memory/YYYY-MM-DD.md，相当于上下文窗口的"扩展外存"，今天和昨天的笔记自动加载

为什么不做分层？

工程上的务实选择。一个文件存所有，结构简单，用户可以直接打开 Markdown 编辑，不需要维护多套存储系统。代价是检索时需要靠搜索来区分"用户画像"和"历史片段"。

OpenClaw 特有的 Dreaming 机制：

Dreaming 负责将每日笔记中的高价值内容自动提升到 MEMORY.md。相当于一种智能筛选——不是所有对话都值得变成长期记忆，只有那些频繁被用到、跨多个场景出现的信息，才会被"做梦"整理后保留下来。

Letta vs OpenClaw

Active Memory（主动记忆）

传统记忆系统："你问它才搜"

OpenClaw的Active Memory："在生成回复之前，主动搜索相关记忆并注入"

三种查询模式：

●message：只看最新一条消息（最快，适合简单场景）

●recent：看最近几轮对话（平衡速度和上下文）

●full：看完整对话历史（最准，但最慢）

六种提示风格（控制记忆召回的积极程度）：

●strict：最保守，只在明确匹配时才返回记忆

●balanced：默认推荐，平衡精准度和召回量

●contextual：最关注对话连续性，适合上下文依赖强的场景

●recall-heavy：积极召回，愿意在较弱的匹配上返回记忆

●precision-heavy：激进拒绝，除非匹配非常明显才返回

●preference-only：专为个人偏好优化（习惯、品味、常规事实）

运行时机：只在"直接消息"会话中运行（不在群聊或频道中），需要先在配置中启用。

自动记忆管理

●自动刷新（Memory Flush）：在上下文窗口被压缩之前，OpenClaw会运行一个静默轮次，提醒Agent将重要上下文写入记忆文件。这能防止上下文丢失。

●Dreaming（做梦）：可选的定时记忆整理过程，分三个阶段运行：

○Light（轻睡）：收集短期信号，初步筛选候选记忆

○REM（快动眼）：对候选记忆进行相关性验证

○Deep（深睡）：使用6个加权信号（召回频率0.24、相关性0.30、查询多样性0.15、新鲜度0.15、巩固度0.10、概念丰富度0.06）综合打分，只将高分的记忆提升到长期记忆（MEMORY.md）

○选择性加入：默认关闭，需手动启用

○定时运行：启用后，memory-core会自动管理一个定时任务（默认每天凌晨3点运行）

○人工审核：整理结果写入DREAMS.md，供人工审阅

典型场景：

用户：我叫张三，是产品经理          Agent：（写入MEMORY.md："用户名=张三，职业=产品经理"）

用户：帮我写个PRD模板          Agent：（从MEMORY.md知道"张三是产品经理"，直接生成PRD，不需要再问"你的角色是什么"）

用户：上次说的那个项目，再详细讲讲          Agent：（从memory/YYYY-MM-DD.md检索"上次聊了什么项目"，找到上下文）

优势：

●记忆可检查、可编辑（用户可以直接打开Markdown文件修改）

●混合搜索（向量 + 关键词），比纯向量检索更精准

●主动注入（Active Memory），而不是"被动等待调用"

●分层管理，避免"所有记忆一锅粥"

●自动整理（Dreaming），只提升高质量记忆到长期存储

四、当前记忆系统的局限性

1. 记忆检索不够精准

问题：向量相似度检索有时会召回"语义接近但时间/场景完全错误"的记忆

例子：

用户（2024年）：我喜欢用iPhone          用户（2026年）：我换成了安卓

Agent（2026年）：推荐你用iPhone（召回了2024年的记忆，但已经过时了）

2026年仍未完全解决：需要更好的"时间衰减"和"场景识别"机制。

2. 记忆容量 vs 成本

问题：完整保留所有原始对话，技术上可能，但成本很高

●存储成本：向量数据库按存储量收费

●检索成本：每次检索都要调用API，费用累积

2026年的实际做法：

●不做完整保留：即使是实现了跨会话记忆的产品，也不会把每轮对话原封不动存下来——成本太高。它们会对内容做压缩和筛选，只保留"值得记住"的信息

●你感觉"AI记不住"，有时是因为它认为那段信息不重要，没有存入持久化存储——不是因为技术上做不到

3. 隐私问题的讨论

问题：Agent"记住你"的同时，也意味着"你的数据被存储了"

2026年的解决方案：

●用户可见、可管理：用户可以查看、编辑、删除自己的记忆

●本地化存储：记忆存储在本地，不上传云端

●加密检索：即使数据库被攻破，攻击者也无法读取你的记忆

但这些都是"工程方案"，技术上的隐私保护记忆（本地化、加密检索），还在早期。

五、实用Tips：如何判断Agent的"记忆力"好不好？

3个问题，快速判断

✅ 问题1：它能"跨会话"记住你吗？

●你今天跟它聊了你的项目，明天打开，它还记得吗？

●好Agent：会记住（比如Claude Projects、ChatGPT Memory）

●差Agent：每次都"不认识你"

✅ 问题2：它能"精准回忆"吗？

●你问它"我上次说的那个项目"，它能找到正确的上下文吗？

●好Agent：能精准召回（混合检索+时间衰减）

●差Agent：经常"张冠李戴"（召回了错误的记忆）

✅ 问题3：你能"管理"它的记忆吗？

●你能查看、编辑、删除它的记忆吗？

●好Agent：用户可见、可管理（比如ChatGPT Memory可以手动编辑）

●差Agent：记忆是"黑盒"，这些看不到也改不了

六、总结

核心观点：Agent的记忆系统本质上只有两层核心——上下文窗口（当前可见的）+ 持久化存储（跨会话保留的）。不同框架在这两层基础上做了各自的扩展。

关键要点：

●LLM没有真正的记忆，只能靠上下文窗口"临时记住"

●Agent需要记忆，才能做到"跨会话个性化"

●2026年的工程共识是按用途分开管理，不同框架的分法不同，但核心都是两层：上下文窗口 + 持久化存储

●工程实践（如OpenClaw）已经能做到"可检查、可编辑"的记忆管理

●当前局限性：记忆检索不够精准、成本与容量的平衡、隐私保护仍在早期

📚 延伸阅读：以下内容面向想深入了解的读者，包含记忆系统的技术架构、最新研究进展、以及为什么记忆是Agent的"大脑"。

延伸阅读：记忆系统的技术原理与研究进展

一、记忆系统的核心架构演进

从"一个数据库装所有"到"按用途分开管理"

早期方案（2022-2023）：所有记忆都存在向量数据库里

●优势：实现简单，语义检索方便

●局限：检索不精准、成本高、重要信息可能被淹没

2026年的工程共识：按用途分层管理

虽然不同框架的分法不一样，但有一个共同趋势——不再把记忆当作"一个品种"，而是按用途拆开：

●上下文窗口：当前正在使用的内容（所有框架都有这一层，这是物理决定的）

●持久化存储：跨会话保留的内容。不同框架拆分方式不同：

○Letta 把它拆成核心记忆 + 召回内存 + 归档内存三层

○OpenClaw 统一放在 MEMORY.md 里

○有的框架只做"用户画像"和"历史对话搜索"两层拆分

没有哪套分法是"唯一标准"——核心思路都是让不同用途的记忆用不同的存储和检索策略，避免"一锅粥"式管理。

为什么分层能改善检索？

一个简单的道理：用户画像（"我叫张三，是产品经理"）是"精确值"，应该用精确匹配直接查；而"上次聊的那个项目"是"模糊回忆"，适合用语义搜索。把两种不同需求的信息混在一起，检索时就无法针对性地优化。

二、向量检索的原理与局限

向量检索是怎么工作的？

第1步：把文本转换成向量（Embedding）

比如"我喜欢苹果"会被转换成一组数字序列，包含1536个数字，每个数字代表一个维度。          "苹果很好吃"也会被转换成另一组1536维的数字序列，这两组数字在多维空间中距离很近。

第2步：计算向量相似度（余弦相似度）

比如"我喜欢苹果"和"苹果很好吃"的相似度是0.92（很接近），而"我喜欢苹果"和"安卓手机很好用"的相似度只有0.23（不接近）。

第3步：召回"相似度最高"的记忆

向量检索的局限

问题1：语义接近 ≠ 相关

例子：          用户（2024年）：我喜欢用iPhone          用户（2026年）：我换成了安卓

问题：向量检索可能召回"我喜欢用iPhone"（语义接近），但实际上已经过时了。

问题2：缺少"时间衰减"

例子：          2024年的记忆和2026年的记忆，向量相似度可能一样，但2026年的记忆应该"更重要"。

问题3：缺少"场景识别"

例子：          "苹果"在"水果场景"和"手机场景"是完全不同的意思，但向量检索可能"混淆"。

三、混合检索：向量 + 关键词 + 知识图谱

为什么需要"混合检索"？

单纯的向量检索有局限（见上文），所以需要结合多种检索方式：

三种检索方式的对比：

●向量检索：优势是"语义相关，适合'模糊回忆'"，局限是"不够精准，缺少时间衰减"

●关键词检索：优势是"精确匹配，适合'找人名/地名'"，局限是"无法处理'语义相似但用词不同'"

●知识图谱：优势是"关联关系，适合'找因果关系'"，局限是"需要预先构建图谱"

当前实践：向量+关键词的混合检索是2026年主流方案（Pinecone、Weaviate、Qdrant等主流向量数据库都已内建支持）；知识图谱是前沿探索方向，在实际产品中仍较少使用

混合检索的工作流程

用户查询："我上次说的那个项目"

第一步（向量检索）：找"语义相关"的记忆          → 召回："上次聊了XX项目"（相似度0.92）、"XX项目的进度"（相似度0.85）

第二步（关键词检索）：找"精确匹配"的记忆          → 召回："项目"（关键词匹配）、"上次"（时间关键词）

第三步（知识图谱）：找"关联关系"的记忆          → 召回："XX项目" → "负责人：张三" → "进度：80%"（关联关系）

第四步（重新排序）：综合考虑"相似度 + 时间衰减 + 场景相关性"          → 最终召回："上次聊了XX项目"（最相关）

四、记忆压缩与摘要技术

为什么需要"记忆压缩"？

问题：随着对话变长，记忆越来越多，成本越来越高

●存储成本：向量数据库按存储量收费

●检索成本：每次检索都要调用API，费用累积

●上下文窗口限制：即使检索到了，也装不下那么多记忆

记忆压缩的两种思路

思路1：自动摘要（把长变短，保留要点）

用LLM把长篇对话总结成几句话。比如10000字的原始对话，自动摘要成100字：保留"用户喜欢用iPhone、负责XX项目、项目进度80%"，丢弃吃饭聊了什么之类的细节。

优势：大幅减少存储和检索成本 局限：摘要可能丢失细节，且每次都要调LLM，本身有成本

思路2：选择性保留（把多的变少，只留重要的）

不是压缩文本，而是决定哪些信息值得存、哪些可以丢。比如100条记忆只保留10条——"用户喜欢用iPhone"（核心偏好）留着，"用户今天吃了拉面"（跟项目无关）丢掉。OpenClaw的Dreaming机制就是这种思路：通过打分判断哪些记忆"值得长期保留"。

优势：减少存储，提高检索精准度 局限：需要准确判断"什么是重要的"，误判了可能丢掉关键信息

五、个性化与隐私保护

个性化：Agent怎么"学习你的偏好"？

方案1：显式用户画像（你告诉它）

比如用户明确说"我喜欢'简洁的答案'"，Agent就会写入用户画像："回答风格=简洁"。下次用户问"解释一下Transformer"，Agent会从用户画像知道"喜欢简洁"，直接给结论，不展开细节。

方案2：隐式学习（它自己观察）

比如用户多次选择"简洁答案"，Agent会观察到这个模式，然后写入用户画像："回答风格=简洁"。

方案3：反馈循环（你纠正它，它学习）

比如Agent问"你喜欢用iPhone吗？"，用户回答"不，我喜欢用安卓"，Agent就会更新"手机偏好=安卓"。

隐私保护：怎么让记忆系统"既好用又安全"？

方案1：本地化存储

●记忆存储在本地，不上传云端

●优势：数据不离开你的设备，隐私保护好

●局限：换设备后，记忆"带不走"

方案2：加密检索

●记忆加密存储在云端，检索时用"加密搜索"

●优势：即使数据库被攻破，攻击者也无法读取你的记忆

●局限：加密检索的技术复杂度高，仍在研究阶段

方案3：用户可控

●用户可以查看、编辑、删除自己的记忆

●优势：透明度高，用户信任度高

●局限：需要产品设计得"易用"（不能让用户觉得麻烦）

六、2026年的记忆系统前沿研究

研究方向1：因果推理与记忆

问题：当前的记忆系统只能"召回相关记忆"，不能"理解因果关系"

例子：

当前方案：          用户："我上次说的那个项目延期了"          Agent：（召回"上次聊了XX项目"）→ "XX项目怎么延期了？"

理想方案（因果推理）：          用户："我上次说的那个项目延期了"          Agent：（理解"项目延期"→"可能原因：资源不足/需求变更"）→ "是因为资源不足吗？"

2026年研究热点：让Agent"理解"记忆之间的因果关系，而不只是"召回相关记忆"

研究方向2：多模态记忆

问题：当前的记忆系统主要处理"文本"，不能处理"图片/视频/音频"

例子：

用户："上次我给你看的那个产品截图，再发一遍"          Agent：（当前只能召回"文本记忆"，找不到"图片记忆"）

2026年研究热点：让Agent能"记住"图片、视频、音频，并能跨模态检索

研究方向3：终身学习与记忆

问题：Agent在学新任务时，可能"忘记"旧任务（灾难性遗忘）

例子：

Agent学会了"写Python代码"（任务A）          然后学会了"写Java代码"（任务B）          结果发现："写Python代码"的能力下降了（忘记了任务A）

2026年研究热点：让Agent能"终身学习新任务，而不忘记旧任务"

七、本章要点总结

核心观点：Agent的记忆系统本质上只有两层核心——上下文窗口（当前可见的）+ 持久化存储（跨会话保留的）。不同框架在这两层基础上做了各自的扩展。

关键要点：

●LLM没有真正的记忆，只能靠上下文窗口"临时记住"

●Agent需要记忆，才能做到"跨会话个性化"

●2026年的工程共识是按用途分开管理，不同框架的分法不同，但核心都是两层：上下文窗口 + 持久化存储

●向量检索有局限（语义接近≠相关、缺少时间衰减、缺少场景识别）

●混合检索（向量+关键词）是2026年主流方案，知识图谱是前沿方向

●记忆压缩与摘要是降低成本的关键技术

●隐私保护（本地化、加密检索、用户可控）仍是2026年的核心痛点

●前沿研究：因果推理与记忆、多模态记忆、终身学习与记忆

你觉得Agent的记忆系统最需要先突破哪个能力？

●A. 检索精准度 —— 能精准召回"相关且正确"的记忆，不再"张冠李戴"

●B. 记忆容量 —— 能记住更多内容，不再"忘记重要信息"

●C. 隐私保护 —— 能既"记住"又"保护隐私"，让用户放心使用

●D. 多模态记忆 —— 能记住图片、视频、音频，而不只是文本

欢迎在评论区聊聊你的看法吧 👇