AI 记忆是怎么实现的？上篇：从上下文到记忆层

你有没有发现现在的 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 记忆这件事可以先收成一个判断准确地说它是一套围绕上下文工作的记忆层把有价值的信息保存下来在未来任务里再重新放回上下文。文件式记忆解决的是“稳定规则怎么留下来”。自动记忆解决的是“协作过程中出现的偏好和经验怎么沉淀下来”。但记下来只是第一步。当记忆越来越多问题就不再是“能不能记住”。而是系统怎么在对的时刻找回对的东西。这就是下篇要讲的内容。希望能帮助到大家对大家有用。谢谢你愿意认真看到这里。愿你始终对世界保持好奇。