我先查一下 “七大模块、两条链路、十六个步骤” 这套说法有没有原始出处，同时核对目前主流 Agent 记忆架构（MemGPT/Letta、Mem0、Zep、LangMem 等）的最新实现细节。
标题：Agent Memory 到底怎么运转：七大模块、两条链路、十六个步骤拆给你听
首段：核心答案
大模型本身是无状态的：每次调用都从零开始，上一次说过的话不会自动留下来。Agent 之所以能 “记住”，靠的是外挂一套记忆系统：它把状态放在上下文窗口之外，并在合适的时刻把合适的片段塞回 prompt。所以记忆系统是带写入策略的状态管理，不等于一个更大的向量库。这套系统拆开看，是七个模块：工作记忆（当前上下文）、会话记忆（本轮的对话与工具调用）、情景记忆（带时间戳的事件日志）、语义记忆（抽取出来的事实与偏好）、知识图谱（实体关系 + 双时间）、程序记忆（可复用的流程与技能）、检查点与归档（整状态快照）。它们各自的 “查询形状” 不同：情景要按时间范围查，语义要按向量近似查，图谱要多跳遍历，所以生产系统基本都混用多种存储，而不是塞进一个库了事。两条链路是写入链路和读取链路，各八个步骤，一共十六步：写入管 “什么值得记、旧的怎么改口、什么时候该忘”；读取管 “这次该取哪些、取多少、怎么标注来源和置信度”。三个最容易被低估的点：第一，难点在写入不在读取，冲突检测、时态覆盖、去重合并决定了记忆库是资产还是垃圾场；第二，向量相似度只能回答 “意思像不像”，回答不了 “现在还算不算数”，用户上周说住在上海、这周搬到北京，纯向量检索会把两条都捞出来；第三，评估要同时看 “记住了吗” 和 “用对了吗”，只测召回率会得到一套越记越错的系统。下面按模块、链路、步骤逐层拆。
一、先分清三个东西：上下文、记忆、RAG
| 概念 | 是什么 | 生命周期 | 典型实现 | 谁负责 “决定” |
|---|---|---|---|---|
| 上下文窗口（Context） | 模型这一次能看到的全部 token | 单次调用 | prompt + 消息 + 工具输出 | 开发者拼装 |
| 记忆系统（Memory） | 跨会话保存并主动管理状态的层 | 跨轮、跨会话、跨任务 | 结构化档案 + 向量 + 图 + 事件日志 | 记忆服务（含策略） |
| 检索增强（RAG） | 从别人整理好的语料里取片段 | 只读为主 | 向量库 + 文档切片 | 语料维护者 |
一句话区分：RAG 读的是一份别人编好的资料，记忆管的是 “你自己经历过的、需要自己判断该不该留的东西”。 记忆系统真正的工作量在于每一轮之后做的决定：这条要不要存、和已有事实冲不冲突、旧的要不要作废、什么时候清掉；单纯多建索引算不上它的主要工作。2026 年很多团队踩的坑就是把记忆当成 “再建一个向量库”，上线三个月后发现库里全是重复、过期、互相矛盾的碎片。
二、七大模块：各存什么、住哪里、怎么查
| # | 模块 | 存什么 | 典型存储 | 查询方式 | 主要失效模式 |
|---|---|---|---|---|---|
| 1 | 工作记忆 Working | 当前任务状态、中间结果、最近几轮原始消息 | 进程内存 / Redis | 直接拼进 prompt | 长任务把上下文撑爆；注意力在长跨度上衰减 |
| 2 | 会话记忆 Conversation | 本轮所有轮次与工具调用 | 线程级 DB（SQLite/Postgres） | 按 thread_id 取 | 会话结束后没人摘要，信息直接蒸发 |
| 3 | 情景记忆 Episodic | 带时间戳的事件：做过什么、结果如何、哪里失败 | 事件日志（追加写）+ 向量 | 时间范围 + 语义混合 | 不写或写得太粗，Agent 反复踩同一个坑 |
| 4 | 语义记忆 Semantic | 稳定事实与偏好：角色、口味、技术栈、口径 | 向量库（HNSW）/ KV / 档案表 | 近似最近邻 + 精确键值 | 过期事实压过当前事实 |
| 5 | 知识图谱 KG | 实体、关系、带有效区间的边 | 图库（Neo4j/Graphiti） | 多跳遍历 + 混合检索 | 不做时态失效，新旧关系同时 “有效” |
| 6 | 程序记忆 Procedural | 流程、工具用法、评审规范、部署步骤 | 文件 /system prompt / KV | 条件触发后整体加载 | Agent 擅自改自己的规则，越改越偏 |
| 7 | 检查点与归档 Checkpoint | 整个 Agent 状态的快照，用于恢复与回放 | 对象存储（S3 / 文件） | 按版本 / 时间点还原 | 只存最终答案，不存中间态，出事无法复盘 |
几个模块的关键设计点，值得单独记：
- 工作记忆的瓶颈不只是长度。 2026 年的共识是 “注意力会在长跨度上衰减”，所以窗口再大也不能替代记忆管理：把 200 轮原文全塞进去，模型反而更容易抓错重点。
- 情景记忆是 “让 Agent 变强” 的那一层，却是采用率最低的一层。 语义记忆（用户是谁、喜欢什么）大家都会做；情景记忆（上次这个 SQL 超时，加日期过滤后成功）写起来更费劲，但不写就永远在原地打转。
- 语义记忆的更新路径比写入路径更重要。 一条事实在被替代前一直有效，所以 “旧值怎么作废” 比 “新值怎么存” 更考验设计。
- 程序记忆最适合放文件，而不是数据库。 让模型自己读写一个目录里的笔记 / 技能文件，比让它查一个 store 更自然，也更容易做版本管理和人工审阅。
- 检查点不是备份，是回放能力。 长任务 Agent 出事时，你需要的是 “回到第 37 步的状态”，而不是 “重新跑一遍”。
三、写入链路：八个步骤，决定记忆库是资产还是垃圾
| 步 | 动作 | 具体做什么 | 漏了会怎样 |
|---|---|---|---|
| 1 | 触发 | 三种触发：用户显式（“记住我对花生过敏”）、确定性规则（订单状态变更、设置页改偏好）、模型自动抽取 | 全靠模型自动抽，等于把噪声当记忆 |
| 2 | 采集与归一化 | 收对话、工具返回、截图 OCR、语音转写，统一成文本 + 元数据 | 多模态信息进不了记忆，任务断片 |
| 3 | 切分与打标 | 定作用域（user /session/agent /project/tenant）、敏感等级、来源 | 把 A 项目的记忆串到 B 项目，或把密钥写进普通库 |
| 4 | 抽取 | LLM 抽事实、偏好、实体、关系、未来意图（“下周提醒我”） | 只存原文，检索时全是长段落，token 成本爆炸 |
| 5 | 冲突检测与去重 | 与既有事实比对：是新增、覆盖、合并，还是矛盾待确认 | 同一件事存五条，召回时互相打架 |
| 6 | 写入决策 | 写 / 改 / 合并 / 丢弃 / 延后确认（低置信度转人工或下轮再判） | 什么都记，信噪比崩掉 |
| 7 | 落库与索引 | 结构化进 KV、语义进向量、关系进图、事件进追加账本 | 只落一种库，另一种查询形状直接不可用 |
| 8 | 巩固与遗忘 | 后台摘要压缩、合并同类、TTL / 衰减、失效标记 | 库越滚越大，延迟和成本一起上涨 |
写入链路里最值得抄的两个工程做法：
- 追加账本 + 派生视图。 原始事件只追加不修改，任何结论都能回溯；模型读的是按任务聚合出来的 “视图”（当前状态卡、本任务相关历史），而不是原始流水。删除时不是去改账本，而是在视图层过滤，保留可审计痕迹。
- 双时间戳。 每条事实带两个时间：valid_time（现实世界里什么时候有效）、transaction_time（什么时候写进系统）。用户搬家不是 “新增一条北京”，而是把 “居住地 = 上海” 的有效区间截止到当下，再插入 “居住地 = 北京，from now”。查询时只取有效区间覆盖当前时刻的那条，新旧信息才不会互相污染。
四、读取链路：八个步骤，决定这次回答对不对
| 步 | 动作 | 具体做什么 | 漏了会怎样 |
|---|---|---|---|
| 9 | 意图识别 | 判断这轮是续旧任务、查事实，还是要执行动作 | 用同一套召回策略打所有场景，精确查询被向量噪声污染 |
| 10 | 作用域过滤 | 按用户、租户、项目、权限、时间窗先筛一遍 | 越权读取、跨用户串记忆（合规事故） |
| 11 | 多路召回 | 关键词（BM25）+ 向量 + 图谱遍历 + 结构化 KV 并行 | 只走向量，专有名词、编号、ID 全部召回失败 |
| 12 | 时态过滤 | 只保留 invalid_at IS NULL / 有效区间覆盖当下的记录 | “住在上海” 和 “搬到北京” 同时被取出来 |
| 13 | 重排 | 相关性 + 时效 + 来源可信度 + 是否被用户纠正过 + 使用风险 | 三条旧偏好压过一条刚改的口径 |
| 14 | 预算分配 | 定 token 预算、top-k、去冗余、必要时让 Agent 二次查询 | 十段原文全塞进去，检索问题变成新的上下文问题 |
| 15 | 组装注入 | 按来源打标签（事实 / 偏好 / 推断 / 待确认），带时间与置信度 | 模型分不清 “用户说的” 和 “系统猜的” |
| 16 | 反馈回写 | 记录命中、采纳、被纠正，回头调整权重与记忆状态 | 错记忆永远不被降权，系统不会自我修正 |
第 13 步是整套系统里最 “产品化” 的一步：排序不只看相似度，还要看 “这条现在该不该用”。 用户说 “我准备开始跑马拉松” 和 “我脚踝扭伤暂停训练”，对 “本周训练计划” 这个查询的相似度都很高，但对行动的含义完全相反。纯向量检索无法解决这种冲突，必须靠时效、状态、来源和用户纠正记录一起参与排序。
第 16 步则决定了系统能不能 “越用越准”：记忆不是一次写死的，被采纳的记忆权重上升，被用户纠正的记忆要么改口要么降权，长期没命中的逐步归档。没有这条回路，记忆库只会单向膨胀。
五、十六步里最容易崩的五个点
| 崩点 | 症状 | 处方 |
|---|---|---|
| 冲突 | 同一属性存了多个版本，模型自行挑一个 | 写入时做冲突检测，冲突不静默覆盖，标 pending 并带置信度 |
| 时态 | 旧事实压过新事实，用户反复纠正也没用 | 双时间戳 + 读取时强制 valid 过滤 |
| 召回预算 | top-k 设太大，上下文被历史挤满 | 按任务类型定预算：简单问答只读档案卡，复杂推理才放开情景与原文 |
| 权限 | 跨用户 / 跨租户串记忆 | 作用域在写入时就打标，读取时先过滤后召回 |
| 遗忘 | 什么都不删，成本和延迟线性上涨 | TTL + 衰减 + 定期 consolidation，删除走视图过滤保留审计 |
再加一条最容易被忽视的：“系统里有记录” 不等于 “记忆”。 用户等级、订单地址这类有 system of record 的字段，应该每次去权威表精确读，而不是当记忆存一份再慢慢变旧。记忆只该负责那些 “没有归属系统的事实”。
六、四类主流实现怎么对照
| 方案 | 核心思路 | 存储形态 | 强项 | 已知短板 |
|---|---|---|---|---|
| Mem0 | 写入时抽取事实并做冲突消解，三层作用域（user/session/agent） | 向量库（Qdrant/Chroma/Pinecone 等） | 接入成本最低；足迹小（基准里约 1,764 tokens / 轮对话） | 写入时丢弃历史细节，后补可能缺上下文；LOCOMO 约 49%（GPT-4o） |
| Letta（原 MemGPT） | 操作系统隐喻：core（常驻）/recall（可搜历史）/archival（长期） | 向量库 + 分层上下文 | 由模型自己决定换入换出，适合超长会话 | 依赖强推理模型；paging 决策本身会出错 |
| Zep（Graphiti） | 时序知识图谱，每条边带 valid_from/invalid_at | 图库 + pgvector，混合检索（向量 + BM25 + 图遍历） | 时间感知查询强；DMR 94.8%、LongMemEval 最高 +18.5%、检索 <200ms | 架构重，实体抽取质量决定上限 |
| LangMem | LangChain 原生，抽语义 / 情景 / 程序记忆，能改 prompt | 任意后端 + LangGraph store | 能把经验写回行为（程序记忆） | 交互场景延迟不佳：LOCOMO 上 p95 检索约 59 秒 |
| 文件式记忆工具（如 Anthropic memory tool） | 给模型一个可读写的目录，让它自己维护笔记 | 文件系统 | 简单、可版本化、可人工审阅 | 规模化管理弱，需要外部规范 |
选型可以照这个顺序问自己：
- 需要时间推理（“上周三说过什么”“什么时候改的口径”）→ 图 + 双时间；
- 需要低延迟交互（语音、客服）→ 避开重抽取、重排序的方案；
- 需要行为自我改进（流程、技能沉淀）→ 程序记忆能否写回；
- 只是个性化（偏好、称呼、口径）→ 结构化档案 + 轻量向量就够。
七、从零搭一个能上线的版本：最小顺序
| 阶段 | 做什么 | 为什么这个顺序 |
|---|---|---|
| 第 1 步 | 结构化档案卡（偏好、身份、口径），主键精确读 | 确定性最高、收益最快，且天然避开向量噪声 |
| 第 2 步 | 会话摘要（每 N 轮压缩成主题 / 意图 / 关键实体） | 用低成本换掉 “塞原文”，token 立刻下来 |
| 第 3 步 | 情景记忆（追加事件日志 + 结果标签） | 让 Agent 不再重复失败路径 |
| 第 4 步 | 时态层（双时间戳 + 失效标记） | 没有它，第 1—3 步迟早互相污染 |
| 第 5 步 | 混合召回 + 重排 | 单路召回的天花板很低 |
| 第 6 步 | 程序记忆（把成功三次以上的轨迹固化成技能，带版本与误触发率门槛） | 从 “记住” 升级到 “变强” |
| 第 7 步 | 遗忘与权限策略（可热更新） | 合规要求会变，写死在代码里必然返工 |
评估别只看一个指标，至少四组：
- 记住了吗：事实召回率、精确匹配率；
- 用对了吗：任务成功率、重复犯错率；
- 代价：每轮 token、p95 延迟；
- 安全：越权读取率、敏感信息误存率、删除请求的彻底性。
有一组公开数字可以做基准感：Anthropic 的 100 轮检索评测里，记忆配合上下文编辑能减少 84% 的 token；而 LangMem 在 LOCOMO 上的 p95 检索接近 59 秒，说明 “能记住” 和 “能实时用上” 是两件事。厂商自报的 DMR、LOCOMO、LongMemEval 分数不能直接横比，语料和评测脚本都不一样。
八、把整篇压缩成一张图
写入链路（8 步）
触发 → 采集归一化 → 切分打标 → 抽取 → 冲突检测 → 写入决策 → 落库索引 → 巩固遗忘
│
┌─────────────── 七大模块 ───────────────┐ │
│ 工作记忆 │ 会话记忆 │ 情景记忆 │ 语义记忆 │ 知识图谱 │ 程序记忆 │ 检查点 │
└───────────────────────────────────────┘ │
▼
读取链路（8 步）
意图识别 → 作用域过滤 → 多路召回 → 时态过滤 → 重排 → 预算分配 → 组装注入 → 反馈回写
记住三句话就够了：写的时候管冲突和时态，读的时候管预算和排序，长期管遗忘和权限。
【常见问题】
问题 1：Agent Memory 和上下文窗口、RAG 到底有什么区别？
回答 1：三者是不同层级。上下文窗口是模型这一次能看到的 token，会话结束就没了；RAG 是从别人整理好的语料里检索片段，以只读为主；Agent Memory 是跨会话保存并主动管理状态的系统，核心工作在 “每一轮之后决定什么该存、旧的怎么作废、什么时候该忘”。所以 Agent Memory 的难点在写入策略而不是检索索引，把它当成 “再建一个向量库” 是 2026 年最常见的误判。
问题 2：Agent Memory 的七大模块是固定的标准吗？
回答 2：不是官方标准，而是把主流生产实现归纳出来的一套教学分解。七大模块指工作记忆、会话记忆、情景记忆、语义记忆、知识图谱、程序记忆、检查点与归档；它们的价值在于 “查询形状不同”—— 情景按时间范围查、语义按向量近似查、图谱要多跳遍历，所以真实系统通常混用多种存储。你可以按业务裁剪（比如不需要时间推理就省掉图谱），但裁剪时要清楚自己放弃了哪种查询能力。
问题 3：为什么说 Agent Memory 的难点在写入，不在读取？
回答 3：因为读取的问题可以靠调参缓解，写入的问题会沉淀成永久污染。同一属性存了多个版本、旧事实没有失效标记、低置信度推断被当成事实写进去，这些错误在检索阶段几乎无法自动修复，只会让模型在两套矛盾口径之间随机挑一个。所以写入链路要做冲突检测、双时间戳、置信度和敏感等级打标，还要有 “延后确认” 这条退路；读取链路再优化，也救不回一个脏库。
问题 4：Agent Memory 里为什么要用双时间戳，普通时间字段不够吗？
回答 4：不够。普通时间只能告诉你 “什么时候写的”，双时间戳还要回答 “这条事实在现实世界里什么时候有效”。典型场景是用户上周说住在上海、这周搬到北京：正确做法是把 “居住地 = 上海” 的有效区间截止到搬家那一刻，再插入 “居住地 = 北京”，查询时只取有效区间覆盖当下的记录，这样 Agent Memory 才不会把新旧信息一起捞出来。这也是 Zep 那类时序知识图谱相对纯向量库的核心优势。
问题 5：Agent Memory 的十六个步骤必须全部实现吗？
回答 5：不必，但缺失的步骤要明确知道代价。写入八步里，最不能省的是冲突检测、写入决策和遗忘；读取八步里，最不能省的是作用域过滤、时态过滤和预算分配。反过来，采集归一化、多路召回、反馈回写可以随规模逐步补。一个务实的路径是：先做结构化档案卡和会话摘要（两三个步骤就够跑起来），再补情景记忆和时态层，最后才上图谱和程序记忆；一上来就追十六步全量，通常会在调参和成本里耗尽预算。
问题 6：选 Mem0、Letta、Zep、LangMem 这些 Agent Memory 方案，看什么指标？
回答 6：先看你的查询形状，再看指标。要时间推理就优先图 + 双时间（Zep 路线）；要低延迟交互就别用重抽取重排序的方案（LangMem 在 LOCOMO 上 p95 检索约 59 秒，不适合语音和客服）；要 Agent 自我改进就看程序记忆能否写回行为；只是个性化偏好，结构化档案加轻量向量就够。厂商自报的 DMR、LOCOMO、LongMemEval 分数不能直接横比，语料和评测脚本都不同，最好用你自己的 50—100 条真实对话做小规模对照。
【参考资料】
- [2026-10-29]（Agent Memory Platform: How AI Agents Store and Use Context——Zep/Letta/LangMem 对比与基准数字）Mastra
- [2026-10-19]（Agent Memory GPU Cloud: Mem0 and Zep Deployment Guide (2026)）Spheron
- [2026-10-03]（AI Agent Memory in 2026: 4 Types, Real Costs and Pitfalls—— 记忆 vs RAG、四类记忆的失效模式）360 Digital Transformation
- [2026-07-19]（Agent 记忆系统全景指南：一文讲透底层原理与产品落地 —— 快慢路径、记忆语义字段清单）人人都是产品经理
- [2026-06-21]（The 7 Types of Agent Memory: A Technical Guide for AI Engineers）AI Future Front（原 MarkTechPost）
- [2026-05-28]（AI Agent Memory Architecture: Persistent State Management for Long-Running Agents—— 七层记忆栈、Mem0/Letta 拆解）Zylos Research
- [2026-05-16]（Long-Term Memory for AI Agents 2026: Mem0, Letta, Zep & the Memory-Augmented LLM Architecture——CoALA 四类记忆、Zep 双时间边）AnhTu.dev
- [2026-04-01]（State of AI Agent Memory 2026: Benchmarks & Trends—— 五类记忆与分层记忆、程序记忆现状）Mem0
- [2025-07-30]（全球首次，「AI 记忆」开源落地，MIRIX 同步上线 APP—— 多记忆管理器与更新 / 检索工作流）36 氪
免责声明
本文的 “七大模块、两条链路、十六个步骤” 是为讲解而做的归纳框架，不是任何厂商的官方规范或行业标准；不同实现的模块划分、步骤顺序差异很大，落地时应按业务裁剪。文中的性能与基准数字（Mem0 约 1,764 tokens / 轮、LOCOMO 约 49%、Zep DMR 94.8%、LongMemEval 最高 +18.5%、检索 <200ms、LangMem p95 约 59 秒、Anthropic 评测减少 84% token 等）均引自厂商博客、第三方评测或媒体报道，属于特定语料、特定模型与特定脚本下的结果，彼此不可直接横比，也不能作为你系统的性能承诺。各方案的价格、免费额度与功能会随时调整，采购前请以官方最新文档为准。文中不构成对任何产品或厂商的推荐、背书或投资建议；按本文框架实施所产生的数据合规、隐私与成本后果，由实施方自行承担。