一个学习助手在周一听到“我主要写 Java”，周二听到“我最近在学习 Python”，周三被问到“上次学到哪里了”。如果它只是把三句话存进数据库，是否就拥有了记忆？如果它把“学习 Python”理解成“已经不写 Java”，又该由哪个模块纠正？这套专题从这样的具体问题出发，讨论可以解释、测试和维护的记忆系统。
我们的目标是让读者沿着一条完整链路走一遍：从原始交互中形成候选信息，判断是否值得保存，为变化保留时间语义，在回答前选择合适证据，最后验证这些处理有没有改善任务。每个环节都会给出失败案例，避免只看一次顺利运行的演示。
这套专题适合谁
主要读者是已经掌握 Java、数据库和接口开发，希望理解 Agent 长期记忆的后端工程师。阅读不要求先训练模型，也不要求购买向量数据库。你需要能够理解集合、不可变对象、事件标识、版本和时间区间，遇到模型相关部分时，我们会说明模型承担什么职责，以及工程系统仍需承担什么职责。
如果你已经做过 RAG，可以重点关注“信息持续变化”带来的新问题。知识库文档可能定期更新，个人记忆却会在每次交互后产生补充、纠正和撤回。两者可以共用检索设施，但业务生命周期不一定相同。如果你主要做工作流，重点可以放在异步写入、重试、版本冲突和删除传播上。
六篇正文如何衔接
| 顺序 | 文章 | 阅读后的产出 |
|---|---|---|
| 01 | AI 记忆、RAG 与上下文管理是什么关系？ | 能为对话、知识、画像和任务状态划分职责 |
| 02 | 从一段对话到一条可靠记忆 | 能解释候选提取、证据、幂等与合并 |
| 03 | 用户改变主意后，AI 如何更新记忆？ | 能定义事实更新、有效期与遗忘语义 |
| 04 | 检索到了，为什么还是答错？ | 能定位召回、过滤、重排和上下文装配问题 |
| 05 | 用同一个案例拆解 Mem0、Graphiti 与 LangGraph 记忆机制 | 能根据机制而非接口数量选择实现方式 |
| 06 | 加了记忆，Agent 到底变好了吗？ | 能设计公平对照实验并区分契约测试与模型效果 |
推荐按顺序读完前四篇，再看选型与评测。已有系统的读者也可以从第六篇开始：先把失败分成提取、更新、召回、使用四类，再回到对应文章寻找改进位置。每篇都可以独立阅读，术语和案例仍保持一致。
贯穿案例与状态变化
示例中的 Alice 和 Bob 是虚构用户。Alice 先声明主要语言为 Java，再补充正在学习 Python，随后记录进度为“Python 生成器”，最后把主要语言改为 Kotlin。Bob 的主要语言是 Python。这个小场景同时包含跨会话使用、属性补充、事实替换和用户隔离。
最终 Alice 的当前状态应该有三项：主要语言 Kotlin、学习目标 Python、学习进度 Python 生成器。Java 作为已经失效的历史版本仍可解释变更过程，但不应进入当前背景检索。Bob 的 Python 背景不能成为 Alice 的证据。删除学习目标后，学习进度仍然存在，因为它们是两个不同的事实槽位。
这也说明删除必须先说清对象。“删除学习目标”与“删除所有提到 Python 的内容”不是同一个动作。专题示例只实现按用户、按槽位删除所有版本，避免把一个没有定义清楚的自然语言请求偷偷扩大为全量删除。真实产品需要在交互和接口层明确范围。
先运行，再阅读实现
示例使用 Java 21 标准库，不连接模型、数据库或网络服务。下载以下三个文件到同一目录：
java -version
javac -encoding UTF-8 -d out MemoryDemo.java MemoryDemoTest.java
java -cp out MemoryDemo
java -cp out MemoryDemoTest
编译器与运行时都应为 Java 21。macOS 如果安装了多个版本，可先执行 export JAVA_HOME=$(/usr/libexec/java_home -v 21)，再把 $JAVA_HOME/bin 放到 PATH 前面。示例固定时钟为 2026-09-23T08:00:00Z，因此隔天运行也不会让有效期测试随机变化。
程序会输出当前事实、带来源标识的 Python 检索上下文，以及删除学习目标后的剩余命中数量。测试程序使用显式断言抛出异常，不依赖 -ea。示例中对象只存在当前进程，重启即清空；跨会话是通过不同事件模拟的业务过程，并不表示程序已经具备跨进程持久化能力。
哪些结论已经验证
我们验证的是可重复的工程契约：同一事件不会重复写入；学习目标不会覆盖技术背景；替换后的旧版本退出当前检索；有效区间右端点不再生效；不同用户之间没有数据混入；删除后旧事件重试不会重新建立那条记忆。这些条件由离线测试直接检查。
我们没有用这个示例证明模型能正确理解任意中文，没有测量向量检索质量，也没有给出某个框架优于另一个框架的准确率。规则提取器只接受几种明确句式；中文双字词项也不是语义向量。把复杂模型组件暂时替换为确定性实现，是为了把状态管理问题单独暴露出来。
第六篇会进一步说明如何接入真实模型开展实验。离线契约全部通过，只能说明这些案例下的行为符合定义。一个真实模型可能提取了错误的主体，也可能把否定句当成肯定句；一个通过检索测试的系统，也可能在生成回答时忽略证据。它们需要不同测试集和不同指标。
把后端经验带入记忆系统
可以把记忆写入理解为一条有语义处理的数据管道。模型生成的是候选，校验和业务规则决定是否接纳；事件标识处理重试，版本控制处理并发，失效时间处理历史，索引和缓存负责查询效率。任何一个环节失败，都需要可观测结果，不能仅用“模型没记住”来概括。
从离线实现走向服务时，应先补充可信身份和持久化，再接入异步队列与索引。先确保用户隔离和事务边界，再决定是否需要图数据库。给每次生成记录“使用了哪些有效记忆、来自哪些事件、被哪些规则过滤”，比只记录一段最终 Prompt 更容易排查问题。
生产扩展还要区分删除当前可见内容、撤销未来使用和清理备份中的历史副本。示例只证明进程内存储与查询的删除行为，不覆盖其他进程、日志、历史响应或备份。工程设计必须为每个副本定义责任方、保留时间和完成条件，不能用一个布尔字段代替整条传播链路。
如何使用这组文章做一次小型实践
第一轮只跑已有案例，确认能够解释每条状态变化。第二轮增加一个反例，例如“我在帮朋友学习 Python”，看看规则或模型是否错误地把朋友的信息归给本人。第三轮引入变更：缩短有效期、打乱事件顺序、重放已经删除的输入，观察系统是否仍满足原先约定。
完成这三轮后，再替换一个组件，例如把规则提取器换成模型调用。保持存储和检索逻辑不变，单独记录提取质量的变化。每次只替换一个主要变量，可以减少“整体好像变好了，却不知道为什么”的情况。失败记录也应留下，它们往往比成功截图更能帮助你选择下一步工作。
延伸阅读与资料边界
已有的长期记忆生命周期文章适合建立整体认识；全模态记忆开源方案调研提供更广的方案视野；ES 混合检索实践可以帮助理解检索基础设施。旧文中的框架描述应结合其调研时间阅读，新系列的源码篇单独记录本次固定版本。
本专题的案例、Java 实现和测试由本站组织编写；框架行为通过官方文档与固定源码核对。参考 LangChain 记忆概念说明，可以进一步比较会话内状态与跨会话信息的组织方式。阅读和运行之后，最重要的产出是一套可解释的行为定义，而不是记住某个 SDK 的方法名。