长期记忆

一句话理解：长期记忆的难点不是“存下来”，而是“存对、取准、会改、会忘”：只写入未来确实有用且无法从源头重新获取的信息，按需召回，带上来源与时间，并允许被纠正和删除。

想象一个销售分析 Agent 跟用户合作了三个月。理想状态下，它知道用户看周报习惯按大区汇总、华东区的口径要剔除退货、“大客户”指年采购额 500 万以上的客户，上个月还被纠正过一次“不要把预售订单算进当月销售额”。用户再也不用每次重复这些背景。

现实中更常见的是另一种局面：记忆库里堆了几百条“用户问过华东销售额”这类没用的记录；某条口径已经改了，旧记忆还在起作用；有条记忆来自一封被注入了恶意指令的邮件。Agent 并没有更懂用户，反而更难预测。

长期记忆做得好是护城河，做不好是隐患。这一课讲四件事：写什么、怎么写、怎么取、怎么改和忘。

四件事首尾相连，构成一个循环：

写什么：值得长期记住的四类信息

Claude Code 的自动记忆功能给出了一个很实用的分类。它让模型把笔记分为四类，并明确规定不记录能从代码库推导出来的内容，也不记录项目说明文件中已经写过的内容：

类别	含义	销售分析 Agent 的例子
用户	用户的角色、专长、工作偏好	区域销售总监；周报按大区汇总
反馈	用户给出的纠正，以及确认有效的做法	“预售订单不算当月销售额”
项目	进行中的工作、截止时间、无法从数据推导的决定	Q4 目标于 10 月 8 日调整
参考	在哪里能找到外部信息	口径说明在某个 Wiki 页面

另一种常用的划分来自 LangChain 的文档，借用了心理学的概念：语义记忆（事实与概念）、情景记忆（过去发生的事件与经验）、程序记忆（完成任务的规则，对 Agent 来说体现在提示词和代码里）。两种划分可以互相对照。

不该写入长期记忆的

不该写	原因	应该去哪
业务数据（“华东 8 月销售额 3,200 万”）	会变化、有唯一事实来源	每次实时查询
能从源头推导的信息（代码结构、表结构）	冗余，且会与源头不一致	需要时重新读取
一次性的对话内容	对未来没有价值	会话历史
任务进度	随任务结束而失效	任务状态
密码、API Key、令牌	会被原样带入之后的每次会话	凭据管理系统
未经用户同意的敏感个人信息	隐私与合规风险	不存，或经明确授权后隔离存储

判断标准可以浓缩为一句话：这条信息在未来的会话中有用，且无法可靠地从别处重新获得吗？ 两个条件同时满足才写。

怎么写：时机与结构

写入时机

方式	做法	优点	缺点
在主流程中写	Agent 在对话过程中决定并写入	立即生效；用户能看到“已记住”	增加延迟；模型分心
在后台写	会话结束后由单独流程提炼记忆	不影响主流程体验	有延迟；用户不易察觉
用户显式要求	“记住：以后报表都用万元”	意图明确、准确率高	依赖用户主动

LangChain 文档把前两种称为“在热路径中写入”和“在后台写入”。实际产品常常组合使用：用户显式要求的立即写入，其他候选记忆在后台提炼，并由用户确认或可随时查看。

记忆结构

结构	做法	适合
档案（Profile）	一份持续更新的用户或项目档案	字段明确的偏好与画像
集合（Collection）	许多独立的小条目，不断追加和更新	零散的纠正、经验、事件
文件目录	按主题分文件，加一个索引文件	需要人能直接阅读和编辑

Claude Code 的自动记忆采用“索引 + 主题文件”的目录结构：一个 MEMORY.md 索引文件（每条记忆一行）和若干主题文件。每次会话开始只加载索引的前 200 行或前 25KB（以先达到者为准），主题文件则在需要时才用文件工具读取。这是 渐进式披露 在记忆上的应用：常驻上下文的只有目录，细节按需加载。

这种结构的加载方式如下：

每条记忆建议至少包含这些元数据：

# 一条记忆的建议结构（示意）
type: feedback
scope: user:zhang / project:east-sales
content: 预售订单不计入当月销售额，按发货月份计入
source: 2026-08-21 会话中用户的纠正
created: 2026-08-21
updated: 2026-09-10
confidence: 用户明确声明

来源与时间特别重要。Claude Code 在 Claude 写入带 YAML 头信息的记忆文件时，会自动记录一个 modified 时间戳，用来提示这条事实有多新，对人和模型都有用。

怎么取：召回策略

记忆存得再好，取不出来或取错了都没用。三种常见策略：

策略	做法	优点	风险
全量常驻	每次都把全部记忆放进上下文	简单，不会漏	记忆一多就挤占上下文、干扰推理
索引常驻 + 按需读取	常驻简短索引，模型判断需要时再读详情	兼顾覆盖与成本	依赖模型判断何时读取
检索召回	按当前问题语义检索相关记忆	可扩展到大量记忆	可能召回不相关或漏掉关键条目

Claude API 提供的记忆工具（memory tool）走的是“让模型自己管理文件目录”的路线：模型通过查看、创建、替换、插入、删除、重命名等命令操作 /memories 目录，而实际存储由你的应用实现，可以是本地文件、数据库或云存储。它强调的是按需取用：把学到的东西记下来，需要时再读回来，而不是一次性全部装入上下文。

召回时还要注意 作用域：用户 A 的偏好不能出现在用户 B 的会话里；项目甲的约定不能影响项目乙。多用户隔离的做法见 记忆的隐私与可控。

怎么改、怎么忘

记忆一定会出错和过期。设计时要为这些情况留出路径：

冲突：新信息与旧记忆矛盾时，默认以新的、来源更可靠的为准，并更新或删除旧条目，而不是两条并存让模型猜。

纠正：用户说“不对，大客户的门槛上个月改成 800 万了”，Agent 应该找到并修改原记忆，而不是新增一条。Claude 的应用中，用户可以直接告诉 Claude 要记住、修改或忘记什么，更新会在下一次对话中生效。

过期：给不同类型的记忆设定复审或过期策略。偏好类可以长期有效；“Q4 目标”这类项目信息应在季度结束后过期。Claude API 记忆工具的文档也建议定期清理长时间未访问的记忆文件，并限制单个文件的大小。

整理：记忆会碎片化、重复。定期合并同类条目、删除失效条目，保持索引简洁。Claude Code 在 MEMORY.md 接近读取上限时，会提醒 Claude 精简索引、合并或删除过时条目。

防投毒：如果 Agent 会处理不可信内容（网页、邮件、第三方工具输出），一次成功的 Prompt 注入 可能把恶意内容写进记忆，之后每个会话都会把它当作可信信息读取。Claude Managed Agents 的记忆存储文档就专门提醒：只需要读取参考资料的会话，应以只读方式挂载记忆库。

例子：一条记忆的生命周期

以销售分析 Agent 的一条口径记忆为例：

常见误区

• “能记的都记下来，总有一天用得上。” 无用记忆会稀释有用记忆，增加召回错误和隐私风险。
• “用向量检索就解决了记忆问题。” 检索只解决“取”，写入标准、纠错、过期和隔离一个都没解决。
• “记忆是 Agent 自己的事，用户不需要看到。” 用户看不到的记忆无法被纠正，错误会一直影响后续结果。

设计要点

• 写入前问两个问题：未来有用吗？能从别处可靠获得吗？
• 记忆带类型、作用域、来源、时间，必要时带置信度。
• 常驻上下文的只放索引或摘要，细节按需读取。
• 冲突以新的、可靠来源为准，更新而非追加。
• 为项目类、时效类记忆设置过期或复审机制。
• 处理不可信内容的 Agent，对记忆写入设置审核或限制写权限。

练习

为「销售分析 Agent」设计长期记忆方案，用时约 50 分钟：

1. 列出 10 条候选记忆，逐条用“未来有用吗？能从别处获得吗？”筛选，保留下来的标明类型与作用域。
2. 选择一种召回策略，说明理由。
3. 写出三条规则：遇到冲突怎么办、用户纠正怎么办、多久复审一次。
4. 找出一条“看起来应该记，但其实应该实时查询”的信息，说明原因。

延伸阅读

• How Claude remembers your project：CLAUDE.md 与自动记忆的类型、存储结构和加载规则。
• Memory tool：记忆工具的命令、实现方式与安全注意事项。
• LangChain：Memory 概念：长期记忆的类型、结构与写入时机。
• Using agent memory：托管平台上记忆存储的版本、审计与访问控制。

下一步

记忆越有用，越涉及隐私。下一课「记忆的隐私与可控」讨论如何让用户看得见、改得了、删得掉，以及多用户之间如何隔离。