GPT 的记忆到底怎么做：不是把聊天塞进 Redis，而是重建一套上下文系统
你应该遇到过这种体验。
你只是说一句：“按我之前公众号的风格来，不要机器腔。”
它好像真懂了。
不是简单复读你上一轮的话，而是能记住你的偏好、项目背景、交付格式，甚至知道哪些名字不能对外出现。
于是很多人开始问：这到底是怎么做的？
是不是有个 Redis，把所有对话都存起来？
是不是模型参数被悄悄改了？
是不是只要接一个向量库，就叫长期记忆？
都不准确。
先说边界： ChatGPT 服务端完整源码没有公开。 我们不能假装看过内部实现。
但我们能看到三类东西：OpenAI 对 ChatGPT 记忆的官方说明、OpenAI Agents SDK 的公开源码、以及 Mem0、LangGraph 这类可审计记忆系统的真实代码。
把这些放在一起看，答案就清楚了。
一个真正好用的 Agent 记忆，不是一个存储组件，而是一条上下文生产线。
这篇文章真正要证明的是：一个有用的 Agent 不是“存了很多聊天记录”，而是在每次回答前，把短期对话、长期偏好、任务状态、文件证据和知识库结果，按权限和时效重新装配进上下文。
企业要做记忆，不能只买 Redis 或向量库。
你要设计的是一套从“该不该记”到“怎么忘”的闭环。
一、先把误区掰正：模型不是把所有话永久刻进脑子
多数人把记忆误解成存储，其实记忆首先是上下文装配。
大模型生成答案时，直接看到的是当前上下文。
这个上下文可以来自刚刚的聊天，也可以来自系统提示、文件、工具返回、知识库检索、用户偏好摘要。
但这不等于模型参数被实时改写。
更像一次会议。
你进会议室前，秘书把上次会议纪要、客户资料、老板偏好、合同版本、风险清单放到桌上。
你看起来像“记得”。
本质上，是开会前材料准备得足够好。
所以 Agent 记忆至少有两步。
第一步，判断什么值得留下。
第二步，在未来某个问题出现时，把相关材料放回上下文。
如果只有第一步，就是资料堆积。
如果只有第二步，就是临时搜索。
两者连起来，才叫记忆。
二、ChatGPT 公开讲了什么：从保存偏好，到后台整理
ChatGPT 记忆的关键变化，不是“记得更多”，而是更会合成、更新和召回。
OpenAI 官方帮助文档把 ChatGPT 的记忆分成两类。
一类是 saved memories，也就是你明确让它记住的东西。
例如：“以后叫我詹老师。”
另一类是 reference chat history，也就是从过往聊天里提取可用背景。
例如你多次提到公众号写作、企业 AI、流程管理，它会逐渐形成偏好。
2026 年 6 月 4 日，OpenAI 又发布了名为 Dreaming 的记忆更新。
这次官方说得很直白：ChatGPT 会在后台花时间综合近期对话、文件、连接应用和显式反馈，用来刷新用户记忆。
它不是只把某一句话复制进数据库。
它会看“新鲜度、连续性、相关性、是否重复、是否过时”。
这就解释了为什么好记忆不是越来越长。
好记忆应该越来越像一份可用的用户画像和工作档案。
比如你今年 3 月说“我要去新加坡开会”，6 月再问“帮我写下周行程”，系统不能还把 3 月的新加坡行程当成当前事实。
它应该知道：这是历史背景，不是当前安排。
这就是时间感。
三、看源码一：短期记忆其实是会话流水账
短期记忆不神秘，就是每次运行前读历史，每次运行后写新增。
OpenAI Agents SDK 的 session 源码里，可以看到最基础的记忆接口。
它有四个动作：get_items、add_items、pop_item、clear_session。
翻译成人话就是：
取出历史、追加新内容、撤回最后一条、清空会话。
SQLiteSession 的实现也很朴素。
它建了 sessions 表和 messages 表，把每条消息序列化成 JSON，按 session_id 存起来。
运行前，Runner 会取出历史。
再把新问题接到后面。
运行后，它把用户输入、助手回复、工具调用结果等新项目写回 session。
这就是很多人说的短期记忆。
它不负责“理解你是谁”。
它负责让第二轮对话接得上第一轮。
例如你第一轮问：“金门大桥在哪座城市？”
第二轮问：“那它在哪个州？”
系统能答“加州”，不是因为模型新学会了什么，而是因为上一轮问答被放回了上下文。
源码里还有 compaction，也就是压缩。
当历史太长时，系统会把多轮内容压成更短、可回放的摘要，避免上下文无限膨胀。
这就是滑动窗口之外的关键能力： 不是简单丢弃，而是压缩后继续可用。
四、看源码二：长期记忆不是聊天记录，是被提炼过的事实
长期记忆如果只是聊天全文归档，很快就会变成噪音仓库。
Mem0 的源码给了一个很典型的长期记忆流水线。
当你调用 add 时，它不会简单把整段对话塞进库里。
它先解析消息，再用 user_id、agent_id、run_id 做范围隔离。
然后取出相近的旧记忆，让 LLM 判断新消息里有哪些事实值得保存。
抽取后，它会批量生成 embedding，做哈希去重，写入向量库。
还会抽取实体，把“人、地点、项目、产品”等实体和记忆关联起来。
检索时，它也不是只靠向量相似度。
源码里能看到语义搜索、关键词 BM25、实体增强、过滤条件和重排序。
这很接近一个生产系统的样子。
因为人类的问题经常不是纯语义问题。
你问“上次那个新加坡客户的合同风险是什么”，如果系统只做向量匹配，可能找错。
它还要知道“新加坡客户”这个实体、你所属项目、权限范围、最近一次合同版本。
长期记忆真正要保存的，不是“你说过什么”。
而是“未来还会影响判断的事实”。
比如下面这些就值得记：
1 你要求公众号默认输出完整 HTML，而不是 Markdown。
2 对外文章要隐去真实人名、公司名、群名和内部 ID。
3 你偏好企业 AI、流程管理、Agent 落地这类选题。
而“好的，我明白了”这种话，基本没有保存价值。
五、看源码三：文件系统也是记忆，但更像工作档案
文件系统不是低级记忆，它反而是企业 Agent 最可靠的外层记忆。
OpenAI Agents SDK 的 Sandbox Agent Memory 文档和源码里，有一个很有意思的设计。
它把记忆明确和普通会话 session 分开。
session 保存消息历史。
sandbox memory 则把先前运行中的经验沉淀成文件。
默认目录里有 sessions、memories、MEMORY.md、memory_summary.md、raw_memories、rollout_summaries。
这说明一件事：复杂任务的记忆，不能只靠数据库字段。
它需要像项目档案一样组织。
第一阶段，系统把一次运行提炼成原始记忆和运行摘要。
第二阶段，再把这些原始记忆合并进 MEMORY.md 和 memory_summary.md。
读记忆时，也不是一次性全读。
它先注入小摘要。
如果当前任务看起来相关，再搜索 MEMORY.md。
必要时才打开 rollout_summaries 里的详细记录。
这叫 progressive disclosure，渐进式展开。
对企业很重要。
比如一个咨询 Agent 管理端到端项目。
它的记忆不应该只存在 Redis。
它还应该能看项目章程、访谈纪要、合同版本、交付模板、风险登记表、会议行动项。
这些文件本身就是记忆。
知识库也是记忆。
审批系统、CRM、ERP、工单系统里的状态，也是记忆。
只不过它们不是“个人偏好记忆”，而是“组织事实记忆”。
六、真正好用的 Agent 记忆，是五层结构
如果只做一层记忆，Agent 要么健忘，要么乱记。
我更建议把企业 Agent 的记忆分成五层。
L0 是当前上下文。
这一层解决“这次对话刚刚说了什么”。
L1 是会话状态。
这一层解决“这一条流程运行到哪一步”。
LangGraph 的 checkpoint 就是典型代表。
它会保存 graph state、thread_id、checkpoint_id、pending writes。
节点失败后，可以从中间恢复，不必重跑所有步骤。
L2 是用户和角色画像。
这一层保存偏好、禁忌、常用格式、稳定事实。
L3 是项目档案和知识库。
这一层保存任务相关的文件、版本、证据和业务规则。
L4 是流程和技能记忆。
这一层保存“下次遇到类似任务，应该怎么做”。
比如某类合同审查先看付款、验收、违约、数据合规，再决定是否需要法务复核。
这不是知识点。
这是工作方法。
七、企业最容易犯的错：把 Redis 当成记忆
Redis 能让数据拿得快，但不能决定什么值得记。
Redis 很适合做缓存。
比如保存最近会话、工具调用中间结果、短期状态、限流信息。
但它不天然解决记忆问题。
它不会帮你判断一句话是偏好、事实、噪音还是风险。
它也不会自动处理冲突。
例如你去年说“我喜欢长文”，今年说“以后尽量短一点”。
系统不能把两条都平等召回。
它要知道哪条更新、更稳定、更适用于当前场景。
向量库也一样。
向量库能帮你找相似内容。
但相似不等于正确。
相似也不等于有权限。
企业系统里，真正难的是边界。
谁的记忆能被谁看？
项目结束后哪些记忆要归档？
客户隐私能不能进长期记忆？
AI 生成的结论能不能当事实？
员工离职后，个人偏好和组织资产怎么分开？
这些问题不解决，记忆越强，风险越大。
八、怎么做一个靠谱的企业 Agent 记忆系统
先别急着选库，先把记忆策略写清楚。
我建议从五个动作开始。
第一，定义记忆类型。
至少分清偏好、事实、项目、流程、证据五类。
偏好可以主动召回。
事实要有来源。
项目记忆要有权限。
流程记忆要可复用。
证据记忆要能回到原文件。
第二，定义写入规则。
显式要求、重复出现、高价值纠错、影响后续交付，这些才值得长期保存。
一次性的寒暄、情绪判断、AI 自己的猜测，不要轻易写入。
第三，定义检索规则。
不要只靠向量相似度。
要同时看关键词、实体、时间、项目、权限、任务类型。
第四，定义装配规则。
召回不是越多越好。
进入模型上下文前，要压缩、去重、排序，并标清来源。
第五，定义遗忘规则。
过期、冲突、用户删除、项目归档、权限变化，都要能触发更新。
没有遗忘机制的记忆系统，本质上是不负责任的资料堆。
九、人的位置变了：从反复交代，变成设计上下文
Agent 记忆做得好，人不是被替代，而是不用再当复读机。
过去我们和系统协作，最大的问题是每次都要从头解释。
客户是谁，项目做到哪，偏好是什么，哪些话不能说，哪个版本才是最新。
这些重复交代，本来就是低价值劳动。
Agent 记忆真正改变的是这里。
它把人从“每次重新输入背景”里解放出来。
但它也把新的责任交给人。
你要决定哪些事实能沉淀为组织资产。
哪些只能存在于个人会话。
哪些必须带来源。
哪些到期要自动失效。
哪些需要人确认后才能写入。
所以企业做 Agent 记忆，第一步不是采购一个向量库。
第一步是盘点十个高频流程。
对每个流程问五个问题：
它需要哪些短期上下文？
它依赖哪些长期偏好？
它必须读取哪些文件和系统？
它的结果要写回哪里？
它什么时候必须忘记或复核？
把这五个问题答清楚，你才知道 Redis、向量库、文件系统、知识库、审批系统分别该放在哪一层。
未来的企业 AI 能力，不是让 Agent 会聊天。
而是让 Agent 带着正确的上下文进入正确的流程，在正确的边界内完成正确的动作。
记忆不是让机器“更像人”。
记忆是让机器不要每次都像第一次上班。
调研依据
1. OpenAI 官方： ChatGPT Memory FAQ，用于核对 saved memories、reference chat history、Temporary Chat 和可管理记忆等公开机制。
2. OpenAI 官方： Dreaming: Better memory through longer thinking，用于核对 2026 年 6 月记忆更新中“后台综合近期对话、文件、连接应用和反馈”的公开表述。
3. OpenAI Agents SDK 源码： session.py、 sqlite_session.py、 session_persistence.py、 compaction session，用于分析会话记忆、写入、读取和压缩。
4. OpenAI Agents SDK Sandbox Memory： 官方文档、 storage.py、 manager.py，用于分析文件系统记忆和两阶段合并机制。
5. Mem0 源码： memory/main.py、 prompts.py，用于分析事实抽取、向量化、去重、实体链接、检索排序和更新删除。
6. LangGraph 源码： checkpoint README、 SQLite checkpointer、 SQLite store，用于分析状态 checkpoint、thread、pending writes 和向量检索 store。