你有没有发现，现在的 AI 很聪明，但有时候也很气人：
它每次都像第一次认识你。
你刚把一个 AI 调到顺手，告诉它别太啰嗦、先给结论、不要写得像客服话术。
结果第二天开一个新会话，它又恢复默认设置。
语气客气，结构完整，废话也很稳定。
你只能重新说一遍：
不是，我昨天不是教过你吗？
那一刻你会发现，AI 工具现在最大的问题，很多时候不是不会做，而是不记得你之前已经教过它怎么做。
写东西、做计划、整理资料、改代码，本质上都是同一个问题：你已经教过它格式、边界和项目约定，但下一次它还是要从零开始猜。
所以，AI 记忆要解决的不是一个玄乎的哲学问题。
它解决的是一个很具体的问题：
当你不想每次都重新解释一遍时，AI 有没有办法记住那些对你长期有用的信息？
要回答这个问题，得先搞清楚一件事：
AI 为什么会失忆？
AI 为什么会失忆
要理解 AI 记忆，先得把一个误会拆掉：
我们平时说“AI 忘了”，其实不是说它曾经真正记住过，然后又忘掉了。
很多时候，更准确的说法是：
这次生成答案时，它拿不到那段信息。
这背后可以分四层来看。
第一，模型推理本身是无状态的。
LLM 在推理阶段不会自动持久化交互历史。每次生成答案，主要依赖的是当前输入、系统提示词、工具上下文，以及被放进上下文窗口里的内容。
它不是每跟你聊一次，就自动更新一份“用户档案”。
所以你昨天告诉过它“不喜欢汇报腔”，不代表它今天开一个新会话还能天然知道。除非这条信息被重新放进当前上下文，或者被某个外部记忆系统找回来。
很多时候，AI 不是“明明记住了又忘掉”。
而是它从一开始就没有把这件事写进长期记忆。
第二，上下文窗口是临时工作区，不是无限仓库。
模型能处理的不是“所有历史”，而是当前上下文的内容。
你可以把它想象成一张会议桌：桌面上的资料，模型能看见；没放上桌的资料，它就只能靠通用知识和当前输入猜。
长对话、上传文件、代码片段，都会占上下文。内容一多，系统就可能截断早期消息、压缩历史对话，或者只保留最近几轮。
这也是为什么同一个会话聊久了，AI 也会慢慢“漂”。
不是它故意不听话，而是前面那些关键约定，可能已经不在上下文里了。
压缩也不是万能的。摘要能保住大意，但细节很容易丢。
比如你说“以后回答先给结论，别写得像客服话术”，摘要里可能只剩一句“用户希望优化回答风格”。等下次再用这个摘要，它当然又写回那种客气、完整、但废话很多的默认语气。
第三，会话状态不等于长期记忆。
很多 AI 产品会在一个会话里保留当前任务状态。
比如你刚让它改了一个函数，它下一轮知道你还在说这个函数；你刚让它整理一份会议纪要，它下一轮知道你还在改这份纪要。
这叫会话连续性。
它有用，但它不是长期记忆。
本轮任务能接上话，不代表新会话还知道。聊天历史、项目状态、会话摘要，都是产品层或 Agent 层额外维护的状态，不是模型参数内部的记忆。
这也是很多误会的来源。
你以为“我之前说过”，AI 就应该知道；但从系统角度看，真正的问题是：之前那段信息有没有被保存？有没有被召回？有没有被放回这次上下文？
缺任何一步，它都可能表现得像没听过。
第四，跨会话延续需要外部记忆系统。
如果希望 AI 在不同会话、不同任务、甚至不同工具之间延续经验，就不能只靠当前上下文。
它需要一套模型外部的记忆系统。
这个“外部”很重要。
它不是模型参数本身，而是保存在模型外部的一套信息系统。它可以很简单，比如一份写着项目规则的 Markdown 文件；也可以很复杂，比如一套专门负责保存、检索、更新历史信息的记忆系统。
它们解决的是同一个问题：
先把值得保留的信息存下来
↓
未来任务来了，再找出相关部分
↓
重新注入给模型
所以，AI 记忆真正解决的问题不是“让模型永远不忘”。
它解决的是：当某个信息不在当前上下文里时，系统有没有办法把它找回来。
当然，事情到这里还没完。
一旦 AI 开始自动记东西，新的问题马上就来了：
什么值得记？
什么应该忘？
如果记忆一直增长，系统怎么控制规模？
如果它记错了，会不会以后每次都被错误记忆带偏？
这些问题，才是 AI 记忆系统真正难的地方。
AI 记忆到底在记什么
AI 记忆不是保存全部聊天记录。
真正有价值的记忆，通常有两个特征：
- 未来还会被用到；
- 能改变 Agent 下一次的判断或行动。
从工程落地看，AI 主要需要记 5 类信息。
1. 用户偏好
包括输出格式、语言风格、常用工具、禁用表达和交互习惯。
这类记忆决定 Agent 是否“懂你”。
2. 规则与约束
包括项目规范、团队约定、业务限制、权限边界和固定流程。
这类记忆决定 Agent 是否“守规矩”。
3. 任务状态
包括当前做到哪一步、已经完成什么、还缺什么、下一步要验证什么。
这类记忆决定 Agent 是否“接得上任务”。
4. 历史经验
包括做过什么、失败过什么、踩过什么坑、哪些方案被否决过。
这类记忆决定 Agent 是否“少走回头路”。
5. 可复用技能
包括固定操作步骤、常用 Prompt、工具调用方式、排查流程和工作流。
这类记忆决定 Agent 是否“越用越顺手”。
在论文和综述文章里，AI Agent 记忆经常会借用人类记忆的分类：
- Short-term memory：当前任务里的临时上下文。
- Long-term memory：跨会话保留的信息。
- Semantic memory：事实、概念、规则、偏好。
- Episodic memory：过去经历过的事件、任务和反馈。
- Procedural memory：可复用的步骤、技能和行为模式。
这些分类更适合做理论地图。
但工程实现时，问题会变得更具体：
- 哪些信息值得存？
- 存在哪里？
- 什么时候取出来？
- 怎么放回当前上下文？
- 旧记忆错了或过期了怎么办？
所以从这一篇开始，我们会先用工程视角拆开 AI 记忆。
不管叫 semantic memory，还是 episodic memory，最后都要落到一套系统里：
AI 记忆 = 外部状态 + 检索 + 上下文注入
接下来先看这套系统的基础链路：信息怎么被采集、筛选、保存，又怎么被重新放回上下文。
至于当记忆规模变大以后，系统如何检索、组织、更新和遗忘，会放到下篇继续拆。
一套 AI 记忆系统是怎么工作的
到这里，我们可以先把一个关键边界说清楚：
AI 记忆通常不是模型在训练后改写了参数。
更准确地说，它是一套围绕上下文工作的外部状态系统。
不同产品文档、Agent memory 论文/综述和常见记忆框架，实现细节差异很大，但底层动作大致可以归纳成一条链路：
这是我为了方便理解做的一套工程归纳。
它要回答的其实是几件事：信息从哪里来，怎样变成结构化记忆，存在哪里，未来怎么找回来，又怎么重新放进上下文。
如果旧记忆错了、冲突了、过期了，系统还要能更新、降权或删除。
这才是“记忆系统”的完整含义：不是存一段文本就完事，而是让信息能够被保存、找回，并在合适的时候重新影响模型。
第一步：Capture，不是保存记忆，而是捕获事件
在工程里，第一步通常不是 memory，而是 event，也就是先捕获原始事件。
这些事件可能来自用户对话、工具结果、项目上下文、Agent 当前状态，也可能来自 CLAUDE.md、AGENTS.md 这类显式指令文件。
这些原始信息不能直接等于长期记忆。原始事件里噪音太多：一句“这次先写正式一点”，可能只是当前任务需求；一句“以后都不要写汇报腔”，才更像稳定偏好。
所以 Capture 的输出不是“可用记忆”，而是一批候选信息：
原始事件：raw event
对话轮次：conversation turn
工具结果：tool result
文件上下文：file context
↓
候选记忆：memory candidate
这一步真正要控制的是采集边界：
采集太少，后面没有足够材料判断什么值得记；采集太多，后面全是噪音，记忆系统会变成日志垃圾桶。
第二步：Extract，把原始事件整理成结构化记忆
真正开始形成记忆，是 Extract。
这里的关键不是把对话压缩成一段摘要，而是把原始事件整理成一条可以被保存、检索和更新的记录。
一条结构化记忆至少需要包含几类信息：
content: 记忆内容
type: 偏好 / 事实 / 任务状态 / 历史经验 / 流程技能
scope: 用户级 / 项目级 / 会话级 / 目录级 / 团队级
source: 来自哪次对话、哪个文件、哪个工具结果
timestamp: 产生时间或更新时间
confidence: 系统对这条记忆的置信程度
status: active / superseded / expired / deleted
不一定每个产品都显式暴露这些字段。
但成熟一点的记忆系统，背后基本绕不开这些问题。
比如“用户不喜欢汇报腔”是一条用户级偏好。
“这个仓库的提交前检查命令是什么”更像项目级事实。
“上次方案 A 被否掉，因为权限模型不满足”更像历史经验。
这里的难点，是抽取策略。
可以由规则判断，比如用户明确说“以后都……”“记住……”“这个项目规定……”。也可以由模型判断，比如让 LLM 从对话里抽取 memory candidate。很多系统会两者结合：规则负责强信号，模型负责弱信号，最后再交给用户或系统策略确认。
Extract 的失败模式也很典型：
- 抽取不足：重要偏好没有留下来。
- 过度抽取：把一次性需求写成长期偏好。
- 错误泛化：用户说“这篇文章别太正式”，系统记成“用户永远讨厌正式表达”。
- 缺少来源：后面不知道这条记忆从哪里来的，也就很难纠错。
所以记忆系统不能只追求“自动记得多”。
记得多，不一定有用。
记得准，才有价值。
第三步：Store，记忆必须落到模型外部状态
抽取出来的结构化记忆，需要被保存到模型外部。
这一步对应 Store。存储形态可以很轻，也可以很重。
轻一点，是 Markdown 文件，比如 CLAUDE.md、AGENTS.md。
再进一步，是自动生成的 memory files 或 saved memories。
更复杂的，是数据库和索引系统，比如结构化数据库、向量库、图数据库。
但不管形式是什么，关键点一样：
AI 记忆不是模型参数本身，而是模型外部的一份可读、可写、可检索的状态。
这里真正要注意的是：记忆不能只管写入，还要知道它属于哪个范围、来自哪里、什么时候可能过期。
第四步：Index / Retrieve，记忆不是存了就会用
存储解决的是“有没有”。
检索解决的是“用不用得上”。
一个记忆系统只要稍微变大，就不能每次把所有内容都塞进上下文。
它必须先建立索引，再根据当前任务召回相关记忆。
Retrieve 的输入，不只是用户当前这句话，而是当前任务上下文：
current user query
system / developer instruction
current file or project context
tool results
recent conversation summary
系统会基于这些信息生成检索请求，找出可能相关的结构化记忆。
这一步的输出通常不是一条记忆，而是一组候选结果。后面还要过滤、排序、去重和压缩。
这里的难点是：语义相似，不等于任务相关；旧记忆相似，也不代表现在还对。
至于向量索引、metadata 过滤、实体关系和时间线怎么做，会放到下篇展开。
第五步：Inject，召回结果必须变成上下文
Retrieve 之后，记忆还没有真正影响模型。
真正影响生成结果的是 Inject，也就是把召回结果放回模型当前能看到的位置。
这一步听起来像“塞进 prompt”，但实际要处理优先级和上下文预算。
它需要判断：哪些是必须遵守的规则，哪些只是偏好；哪些和当前任务强相关，哪些只是背景信息；哪些还有效，哪些可能已经过期。
这一步处理不好，记忆就会从帮助变成干扰。注入不是越多越好：有些记忆不放进去，模型就看不到关键约束；但放太多，当前任务会被旧信息挤占。
所以“AI 明明有记忆但还是做错”的情况，不是记忆不存在，而是没有被召回，或者召回后没有被正确注入。
第六步：Update / Forget，记忆系统必须能改，也必须能忘
最后一步，是更新和遗忘。
真实世界一直在变：用户偏好会变，项目命令会变，目录结构和团队规则也会变。
如果记忆系统只会追加，不会更新，时间一长就会堆出互相冲突的旧事实。
这时 AI 不是“没记住”，而是“记住了太多过期信息”。
所以 Update / Forget 至少要处理几类动作：新事实覆盖旧事实，相近记忆合并，旧记忆降权，过期或错误记忆删除。
这里还会牵涉作用范围：某个项目里的规则，不一定能带到另一个项目；某个用户的偏好，也不应该污染团队共享上下文。
到这里，再回头看 AI 记忆，就不容易把它想成一个“记住开关”了。
它更像一套运行时系统：先捕获事件，再抽取成结构化记忆，存到模型外部；未来任务来了，再检索、注入、更新或删除。
接下来我们看两个最容易接触到的实现形态：文件式记忆和自动记忆。
文件式记忆：把稳定规则变成长期上下文
那么，普通人怎么真正用上 AI 记忆？
很多时候，不是先接入一套复杂系统，而是先维护一份固定文件。
比如你希望 AI 记住自己的写作偏好、输出风格、项目规范、常用命令，就可以把这些稳定规则写进一个文件里。
比如 Claude Code 里的 CLAUDE.md。
比如 Codex 里的 AGENTS.md。
这种文件里写的东西通常很朴素，比如：
- 回答先给结论，再解释原因。
- 修改代码前，先看现有项目结构。
- 团队约定的测试命令是 npm test。
它不神秘，本质上就是把稳定规则提前放进 Agent 能看到的地方。
Agent 读取这些文件后，就不需要每次都重新问一遍：“这个项目怎么跑？”“你喜欢什么风格？”“哪些目录不能动？”
这些文件看起来更像项目说明书，不像“记忆系统”。
但从机制上看，它们解决的是同一个问题：把稳定规则保存下来，在未来任务开始时重新提供给 Agent。
这类方式可以叫“手写文件式记忆”。
它的核心不是自动学习，而是显式约定。
它通常记的不是某次聊天里的临时需求，而是长期有效的项目上下文：
- 这个项目用什么技术栈；
- 代码风格有什么约定；
- 测试命令怎么跑；
- 哪些目录不能随便动；
- 写文档、写注释、写 PR 说明时有什么格式。
所以它更像“项目规矩”，不是“聊天记录”。
这种方案的数据结构也很简单：通常就是 Markdown。可以被人直接阅读、修改、提交到 Git，也可以随着项目一起演进。
但是它的边界也很明显。
第一，它会占上下文。
文件越写越长，Agent 每次加载时就要吃掉更多 token。规则太多，重点反而会被稀释。
第二，它不会主动检索。
你把 200 条规则都写进去，它不一定知道这次任务真正需要哪 3 条。它只是“看见了”，不等于一定“用对了”。
第三，它不会自动更新。
项目架构变了，测试命令换了，某条规则过期了，如果没人改文件，AI 还是会继续看到旧规则。
当然，你也可以让 AI 帮你总结最近的对话，再把其中可复用的可沉淀的规则更新到 CLAUDE.md 或 AGENTS.md。
但这里仍然需要人做最后判断：哪些经验值得长期保留，哪些只是某次任务里的临时情况。
第四，它不是强制执行系统。
Claude Code 文档里也明确提到，CLAUDE.md 和自动记忆都会被当作上下文，而不是强制配置。真要阻止某类操作，应该放到 hook、权限或工具层，而不是只靠模型“听话”。
所以，手写文件式记忆适合放稳定、明确、团队需要共识的规则。
它不适合放大量历史对话，也不适合承接所有个人偏好。
自动记忆：从历史协作里提取长期经验
文件式记忆解决的是“人已经知道要写什么”。
但很多记忆不是一开始就能写成规则的。
它们往往是在很多次对话里慢慢出现的：你反复纠正过的问题、项目里踩过的坑、某个任务的处理方式、某类错误的排查经验。
这些信息有长期价值，但每次都靠人手动整理进文件，成本太高。
于是就有了自动记忆。
它的思路是：系统从历史会话、用户纠正、工具结果和项目经验中，自动提取一部分值得保留的信息，写进某种记忆存储里；等到未来新会话或新任务开始时，再把相关内容找回来，重新放进上下文。
这类方案可以先理解成“自动记忆”。摘要压缩只是其中一种形态，不是全部。
在开发工具里，它还常常表现为本地 memory files：系统把历史协作里有价值的信息整理出来，未来任务再按相关性放回上下文。
如果按前面的链路拆，它大概是这样：
历史会话 / 用户纠正 / 工具结果
↓
系统判断哪些信息有长期价值
↓
抽取成偏好、摘要或长期记忆条目
↓
写入产品侧或本地 memory files
↓
未来任务中按相关性注入上下文
↓
根据新反馈更新、降权或删除
它和文件式记忆最大的区别，是写入者从“人主动写”变成了“系统从合作历史里提取”。
所以自动记忆的关键，不只是“自动保存”，而是选择、压缩、归档、召回和注入。
哪些信息值得留下，哪些只是临时噪音；一段长对话应该压缩成什么摘要；旧经验未来什么时候该被重新拿出来；拿出来之后应该放在上下文的什么位置，这些才是自动记忆真正要处理的问题。
比如说，现在用 ChatGPT 的人可能会注意到：打开一个新的会话，它有时也知道你过去说过的偏好。
这背后不是模型参数被你训练了。
在 OpenAI 帮助文档的记忆说明里，ChatGPT 的个性化记忆至少包括两类能力：一类是 Reference saved memories，也就是保存下来的记忆；另一类是 Reference chat history，也就是参考过去聊天来改进未来回复。
这些能力可以在 Settings > Personalization 里控制，截图里的“启用记忆”和“记忆摘要”，对应的就是这种产品层能力。
所以，当 ChatGPT 在新会话里好像知道你过去说过什么，其实是 ChatGPT 把某些保存过的记忆或历史信息，重新提供给了当前会话。
类似的能力，在开发工具里也开始出现。
Claude Code 的 auto memory 会把用户明确要求记住的事项、构建命令、调试经验等保存到本地记忆目录里；Codex Memories 则可以把历史线程里的有用上下文转成本地 memory files，在未来任务中作为“可召回的历史上下文”被找回来。
但它们的边界是一样的：这些内容仍然是上下文，不是强制配置。
如果是团队必须遵守的规则，比如权限边界、代码规范、上线流程，更适合放在 AGENTS.md 或 checked-in docs 里，而不是只依赖某个用户本地的自动记忆。
自动记忆的边界
自动记忆的好处很直接：维护成本低。
用户不用每次都想“这条经验要不要写进文件”。系统可以在后台整理。
但它也带来四类风险。
第一，抽取错误。
系统可能误解用户意图，把一次性的要求当成长期偏好。
第二，摘要损失。
长对话被压缩成摘要之后，关键细节可能丢掉，尤其是原因、限制和上下文。
第三，过期污染。
项目命令、目录结构、用户偏好都会变化，旧记忆如果没有更新，反而会持续干扰后续任务。
第四，作用范围。
自动记忆通常是个人化、本地化或产品侧能力，不一定适合团队共享。
所以，自动记忆适合保存用户偏好、常见纠正、项目经验、历史摘要和调试发现；但不适合替代团队规范、合规规则、权限边界，以及需要 code review 的项目约定。
记下来，只是第一步
到这里，AI 记忆这件事可以先收成一个判断：
准确地说，它是一套围绕上下文工作的记忆层：
把有价值的信息保存下来，在未来任务里再重新放回上下文。
文件式记忆解决的是“稳定规则怎么留下来”。
自动记忆解决的是“协作过程中出现的偏好和经验怎么沉淀下来”。
但记下来，只是第一步。
当记忆越来越多，问题就不再是“能不能记住”。
而是：
系统怎么在对的时刻，找回对的东西。
这就是下篇要讲的内容。
希望能帮助到大家，对大家有用。
谢谢你愿意认真看到这里。
愿你始终对世界保持好奇。
我是宅小年，下期我们再见！
关注公众号「宅小年」，阅读更多分享文章
