大语言模型看起来能够 记住 用户真正保存信息的却不是模型本身一次模型调用只能依据当前收到的上下文进行推理跨会话记忆通常由 Agent 外部的文件、数据库、检索器和更新流程共同实现因此设计 Agent 记忆系统不能只问 该用哪个向量数据库而应该依次回答四个问题需要记住什么记忆以什么结构保存怎样找回当前真正需要的信息新事实出现后旧记忆如何更新、失效和追溯记忆类型决定 存什么存储介质决定 放哪里检索策略决定 怎么找维护策略决定 它是否长期可信上下文窗口不等于长期记忆上下文窗口是模型本次推理时能够看到的信息长期记忆则保存在模型之外需要在下一次运行时重新取回并放入上下文一个典型 Agent 的记忆流程如下用户请求 ↓ 判断是否需要历史信息 ↓ 按用户、时间和记忆类型过滤 ↓ 关键词 / 向量 / 图检索 ↓ 重排并组装相关上下文 ↓ 模型推理与工具调用 ↓ 提取值得长期保存的新信息 ↓ 写入、替代或整理记忆这也解释了为什么不能把全部聊天记录直接塞给模型历史越长Token 成本越高噪声越多真正重要的信息反而越容易被淹没先区分短期记忆与长期记忆短期记忆维持当前任务连续性短期记忆通常绑定到某个会话或任务线程包括最近几轮对话当前任务状态已调用的工具及其结果尚未完成的计划临时变量和中间结论它的作用类似人的工作记忆任务结束后其中大部分内容不需要永久保存长期记忆跨会话保留重要信息长期记忆能够跨任务和会话复用按照 LangGraph 等系统采用的认知分类可以进一步分为三类类型保存内容示例语义记忆稳定事实和概念用户偏好深色模式客户要求纯素认证情景记忆带时间和上下文的经历上周参加了会议某次工具调用失败程序记忆规则、流程和操作方法如何生成周报如何完成一次市场调研三种记忆的写入和读取方式并不相同语义记忆适合提炼为事实情景记忆需要保留时间和来源程序记忆则更适合保存为可编辑的规则、提示词或 Skill四种主要存储结构Markdown最简单、最透明Agent 可以通过memory.md保存用户事实通过soul.md保存角色和行为规则再通过单独的 Skill 文件保存操作流程Hermes 等 Agent Harness 都采用了类似思路Markdown 的优势是容易阅读、编辑、审计和版本管理如果信息很少还可以在每次运行时直接加载到上下文它的问题是规模扩展能力有限文件越来越长以后全量加载会增加成本模型也难以持续关注所有内容因此Markdown 更适合少量高价值事实、核心规则和人工维护的程序记忆SQLite结构化记录与全文检索当记忆需要时间、来源、用户和状态等字段时关系数据库会更合适一个实用的数据结构可以包含字段用途user_id隔离不同用户的记忆memory_type区分语义、情景和程序记忆content保存事实或事件内容source记录信息来自用户、网页还是工具valid_from事实开始生效的时间valid_to事实失效的时间supersedes_id指向被当前事实替代的旧记录created_at记忆写入时间SQLite 的 FTS5 是官方提供的全文检索虚拟表模块基于倒排索引实现高速文本检索支持词项、短语、前缀、邻近查询、布尔条件组合以及 BM25 相关性打分排序原生缺少中文分词能力适合读多写少场景可搭配外部分词器适配中文业务关键词检索速度快、成本低、结果容易解释尤其适合姓名、编号、日期、日志和工具调用记录但它依赖分词与词面匹配跨语言、同义表达和模糊意图可能降低召回率中文数据还需要特别验证分词器或考虑 trigram 等索引方案向量存储按语义寻找相似内容向量检索会先使用嵌入模型把一段文本转换成高维向量查询也经过相同处理然后通过余弦距离、内积或欧氏距离寻找语义接近的记录这里需要纠正一个常见误解系统通常为句子、事实或文本块生成向量而不是简单地 把每一个单词分别存成向量pgvector是 PostgreSQL 的扩展不是 SQLite 扩展它允许向量与普通业务字段存放在同一张 PostgreSQL 表中并支持精确近邻搜索HNSW 和 IVFFlat 近似近邻索引余弦距离、内积、L2 和 L1 等距离计算使用普通 SQL 对用户、时间、权限和类别进行过滤精确搜索能获得完整召回但数据规模增大后成本会上升近似索引以部分召回率换取速度其中 HNSW 通常拥有较好的速度与召回率平衡但建索引更慢、占用更多内存IVFFlat 构建更快、内存较少却更依赖数据量和参数设置向量相似只代表 表达接近不代表 事实正确生产系统不能只取相似度最高的几条记录还应结合用户范围、有效时间、来源、权限和后续重排图结构保存实体之间的关系当问题的重点不再是某条独立事实而是事实之间的关系时可以使用图结构图中的节点表示人物、组织、产品或事件边表示它们之间的关系Alex ├── 参加 → Lisbon AI Meetup ├── 创办 → 机器人项目 └── 项目 → 原定五月发布 ↓ 推迟到六月图能够直接表达 谁参与了什么 某个决定影响了哪个项目 一条信息为何与另一条信息相关它适合多跳查询、关系密集数据和需要追溯历史变化的场景四种记忆检索策略检索方式工作方式优点主要局限直接预加载把记忆直接放入上下文简单、不会漏检占用上下文难以扩展FTS/关键词匹配词项、短语和布尔条件快、便宜、可解释不擅长同义词和跨语言向量检索查找语义相似的文本表达灵活、召回能力强相似不等于正确图与混合检索结合实体、关系、时间和语义支持多跳与关系推理索引和维护成本较高成熟系统通常使用混合检索而不是四选一例如先根据user_id和有效时间过滤再并行执行 BM25 与向量搜索最后融合分数、重排结果并组装上下文RAG、GraphRAG 与 Agent MemoryRAG 把语言模型的参数化知识与外部非参数化记忆结合起来系统先从外部知识库检索相关内容再让模型依据这些内容生成答案RAG 解决的是 怎样从外部知识中取回证据Agent Memory 解决的则是 怎样长期保存并管理与用户、任务和 Agent 自身有关的动态信息两者可以重叠但不能画等号企业文档库属于 RAG 知识源却不一定是用户记忆用户偏好属于 Agent Memory也可以通过向量 RAG 取回一次工具调用记录属于情景记忆通常不会进入公共知识库程序记忆可能以 Skill 文件保存根本不需要向量检索Microsoft GraphRAGMicrosoft GraphRAG 不是简单地 给节点和边生成向量它会从非结构化文本中抽取实体、关系和相关描述建立知识图谱与社区层次并生成社区报告其查询方式包括Local Search结合图中的实体关系和原始文本块回答围绕具体实体的问题Global Search在社区报告上执行 Map-Reduce回答关于整个数据集的宏观问题DRIFT Search从社区信息出发扩展局部检索并生成更细致的后续问题Basic Search提供基础向量 RAG便于比较不同检索方式Microsoft 官方明确提示 GraphRAG 的索引可能成本较高它更适合复杂、叙事性强、需要跨文档理解的数据集而不是几条用户偏好这样的小型记忆Graphiti 与时间上下文图Graphiti 是 Zep 体系中的开源时间上下文图引擎更偏向持续变化的 Agent 记忆它把信息组织为Entity人物、产品、组织等实体节点Fact/Relationship带有效时间窗口的事实或关系边Episode产生这些事实的原始对话、文本或 JSON 数据Provenance从派生事实回溯到原始 Episode 的来源关系Graphiti 支持增量更新并将语义搜索、BM25 和图遍历组合为混合检索旧事实被新事实替代时可以失效而不必删除因此既能回答 现在是什么也能回答 过去是什么Zep 是托管式产品Graphiti 是需要自行部署和运维的开源引擎二者不能直接当作同一个软件版本理解写入记忆不能等同于保存聊天记录一次完整对话可能包含寒暄、重复表达、推测、纠正和工具输出如果全部写入长期记忆数据库很快会变成无法使用的聊天垃圾场写入前至少需要完成三步判断重要性判断这条信息未来是否还会使用类型判断它属于事实、事件还是程序冲突判断它是新事实、重复事实还是对旧事实的修正随后再选择具体动作操作含义Add添加新事实Update修正现有记录Delete删除错误或依法必须清除的信息No-op信息重复不做处理Supersede新事实生效旧事实保留但失效例如用户先说 访客将在晚上七点到达随后改为 晚上九点才能到删除七点这条记录会丢失变化历史直接覆盖又无法解释过去的安排更好的方法是让旧记录在更新时刻失效再新增一条从该时刻开始生效的九点记录需要注意的是产品的内部算法会随版本变化当前Mem0 的新一代托管算法在自动提取阶段采用 ADD-only 策略不再让模型直接执行 UPDATE/DELETE同时融合语义、BM25、实体匹配与时间推理这不代表所有历史版本或人工管理 API 都遵循同一策略因此选型时应以实际部署版本的文档为准在线写入与后台整理记忆可以在两条路径上形成在线路径hot pathAgent 在对话过程中立即决定查询或写入记忆后台路径background任务完成后异步提取、合并和更新知识LangMem 同时提供了对话中的记忆管理工具和后台记忆管理器前者响应及时但会增加当前请求的延迟后者不会阻塞回答更适合批量去重、摘要和一致性检查一种实用架构是先把原始对话和工具结果写入 SQLite再异步提取高价值事实短小且必须始终生效的规则写入 Markdown语义事实进入向量索引复杂实体关系再进入时间图后台整理有时被形象地称为 反思 或 做梦但它不是统一技术标准工程上真正需要的是明确的去重、合并、冲突检测、失效和来源追踪流程如何选择从最小可用架构逐步升级场景推荐起点原型或个人助理Markdown SQLite需要保存完整运行轨迹SQLite FTS5用户表达多变或存在跨语言查询结构化过滤 向量检索大量文档问答向量 RAG 或混合检索复杂实体关系与多跳问题知识图谱 / GraphRAG高频变化且需要历史追溯时间上下文图希望直接使用记忆管理能力Mem0、LangMem、Zep 等现成组件最稳妥的演进路线通常是Markdown ↓ SQLite FTS5 ↓ 元数据过滤 向量检索 ↓ BM25 与向量混合召回 ↓ 仅在关系复杂时引入图和时间语义图数据库并不会自动让 Agent 更聪明如果业务问题只涉及少量偏好、日期和联系人引入时间图可能增加写入延迟、索引成本和运维复杂度却没有带来同等价值怎样正确评估记忆系统使用同一组事实测试 SQLite、Mem0、LangMem、Zep 和无记忆对照组能展示关键词检索、跨语言查询、事实替代和图构建延迟之间的差异但单次运行时间不能当作严格性能排名更可靠的评估至少应包含召回率需要的记忆是否被找到精确率返回内容中有多少真正相关事实一致性回答是否忠于存储记录时间正确性能否区分当前事实与历史事实跨语言能力不同语言提问能否找到同一事实更新正确性新信息能否替代旧信息来源可追溯性答案能否回到原始对话或工具结果延迟与成本写入、索引、检索和生成分别消耗多少资源隔离与删除不同用户的数据是否隔离删除请求是否彻底执行测试集还应包含无答案问题一个优秀的记忆系统不仅要在有记录时回答正确也要在没有证据时明确表示不知道一个可靠的最终架构对多数 Agent 项目而言合理的默认设计不是直接采用最复杂的 GraphRAG而是分层组合Markdown 保存少量核心规则和程序记忆SQLite 保存对话、事件、工具结果和审计记录FTS5 负责名称、编号、短语和日志检索向量索引负责同义表达和跨语言语义召回元数据过滤负责用户、权限、类型和时间边界时间字段与替代关系负责处理事实变化后台任务负责提取、去重、合并和失效只有在多跳关系具有明确价值时才建立图结构AI Agent 的长期价值不在于积累了多少聊天记录而在于能否把经历转化为少量、准确、可检索、可更新并可追溯的知识先明确记忆内容再选择存储和检索方式最后建立可靠的生命周期管理才是一套真正可持续的 Agent 记忆系统