在高质量 AI Agent 系统里，记忆模块的设计远比看起来复杂，它要解决三个关键问题：
怎么存历史对话？什么时候检索？该检索哪些内容？
这些问题直接决定了 Agent 的响应速度、资源占用和能力天花板。
而我们常用的 ChatGPT、Claude 这类大模型，之所以能记住用户的长期偏好，越用越顺手，本质上是因为它们也算一种极简版 AI Agent。但在记忆模块的设计上，两者走了完全不同的路。
最近，一位外网大神Manthan Gupta，对 ChatGPT 以及Claude 的记忆系统做了逆向，结论如下：
GPT记忆主要靠预计算注入 + 分层缓存，主打轻量化连续性；Claude采用RAG式按需检索 + 动态更新，来平衡记忆的深度与效率。
原文如下：
https://manthanguptaa.in/posts/chatgpt_memory/
https://manthanguptaa.in/posts/claude_memory/
那么，两者的记忆模块究竟是怎么运作的？对我们的日常agent搭建有什么启发？本文将深入解答。
01
ChatGPT：四层静态注入架构搭建记忆模块
ChatGPT 未采用传统的向量数据库（RAG）或全量对话存储，而是通过四个分层组件将记忆提前注入每次对话的上下文，在保证个性化的同时控制计算成本。其整体上下文结构为：[0]系统指令 → [1]开发者指令 → [2]会话元数据 → [3]用户长期记忆 → [4]近期对话摘要 → [5]当前会话消息 → [6]用户最新消息，其中后四层为记忆核心。
其中，**会话元数据（Session Metadata）**指的是短期、非持久化记忆，仅在会话启动时注入一次，会话结束后销毁，主要用于让模型适配当前场景（如移动端简化回复格式），不影响长期记忆。其内容聚焦用户当前使用环境，包括：设备信息；账号属性（订阅等级如 ChatGPT Go、账号年龄、使用频率）；行为数据（近 1/7/30 天活跃天数、平均对话长度、模型调用分布如 49% 用 GPT-5）。
用户长期记忆（User Memory），则是长期、可编辑的核心记忆，用于记录用户稳定属性（，如姓名、职业目标、过往经历、项目成果、学习偏好），每次对话都会强制注入。其更新方式包括显式更新（用户通过 “记住这个”“从记忆中删除” 等指令直接管理）以及隐式更新（模型检测到符合 OpenAI 标准的事实如姓名、职位且用户默认同意时，自动添加。）
近期对话摘要（Recent Conversations Summary）则是一个轻量化跨会话层，用于替代传统 RAG 的全量检索，每次对话均注入。这一层仅总结用户消息（不包含助手回复）；数量有限（约 15 条），仅保留近期兴趣，不存储细节；整个过程无需嵌入计算或相似度搜索，降低延迟和 token 消耗。
**当前会话消息（Current Session Messages）**则是一个滑动窗口上下文层，用于维持当前会话连贯性的短期缓存，会存储全量对话内容。当超出 token 上限时，自动 “滚除” 最早的消息，但长期记忆和近期对话摘要不受影响；
02
Claude ：工具化按需检索架构做记忆管理
Claude 摒弃了 ChatGPT全量预注入的思路，采用长期记忆 + 按需工具检索的动态架构，仅在需要时调取历史上下文，平衡细节深度与效率。其上下文结构为：[0]系统指令（静态）→ [1]用户记忆 → [2]对话历史 → [3]当前消息。两者的核心差异体现在 对话历史的检索方式和用户记忆”的更新逻辑。
**首先是用户记忆（User Memories），**其定位是智能更新的长期层，与 ChatGPT 长期记忆功能类似，但支持更灵活的动态更新，格式为 XML 标签包裹。其更新机制包括：隐式更新（后台定期基于对话内容自动更新-非实时，删除对话会逐步移除相关记忆）显式更新（通过memory_user_edits工具，用户用 “记住这个”“删除这个” 指令管理）。对比 ChatGPT，Claude 在这一环增加了后台自动优化，无需用户主动干预记忆迭代。
对话历史（Conversation History）方面，Claude 未采用固定摘要注入，而是通过三个互补组件动态调取历史，仅在模型判断需要时触发，避免无效 token 消耗。
这套组件中，比较值得研究的是conversation_search，能在模糊表述、多语言查询等场景依然能实现命中，背后应该使用了语义层面的匹配能力（常见实现是 embedding 检索，或“翻译/规范化 + 关键词/混合检索”的组合）。
整体来看，Claude 这套按需检索系统的特点则在于
非自动触发：工具调用由 Claude 自主判断，如用户提 “上次聊的项目” 时，触发conversation_search。
细节保留：检索结果包含助手回复片段（ChatGPT 摘要仅用户消息），适合需要上下文深度的场景；
效率优势：无需每次注入所有历史，减少无关 token 消耗。
缺点则在于，一旦引入按需检索，系统复杂度上升（索引构建、查询、排序、可能的重排），端到端延迟不如预计算注入可控；同时模型还必须学会判断何时该检索，判断失误就会丢上下文。
03
Claude 式按需检索的技术门槛
一旦选择按需检索路线，向量数据库的选型就变得至关重要。因为，对话检索场景对数据库的要求极为苛刻，须同时满足四个约束。
约束一：延迟容忍度极低
对话系统的 P99 延迟必须控制在 20ms 以内，否则用户会感觉卡顿。这意味着向量检索、元数据过滤、结果排序的全流程都要高度优化。任何一个环节出现性能瓶颈，整个对话体验都会劣化。
约束二：混合检索是刚需
用户的查询包含多维度约束：“最近一周关于 RAG 的讨论”同时涉及时间过滤和语义检索。如果数据库只支持向量检索，先返回 1000 个语义相关的结果，再在应用层做时间过滤可能只剩 3 个，中间 997 次计算全部浪费。必须在数据库层面原生支持向量+标量的组合查询。
约束三：资源占用与扩展性的矛盾
对话历史有明显的冷热特征：最近的对话被频繁检索，几个月前的对话很少访问。如果所有向量数据都必须加载到内存，千万级对话会消耗数百 GB 内存，资源开销不可接受。必须支持存储计算分离，热数据在内存、冷数据在对象存储，按需加载。
约束四：查询模式的多样性
有时是纯语义检索（之前讨论的性能优化方案），有时是纯时间检索（上周的所有对话），有时是复杂组合（三个月内关于 Python 且提到 FastAPI 的讨论）。数据库的查询优化器必须针对不同模式自动选择最优执行策略，避免统一的暴力搜索。
这四个技术挑战构成了对话检索的完整约束。任何想要实现 Claude 式按需检索的系统，都必须系统性地解决这些问题。
04
Milvus2.6：为对话检索场景而生的架构演进
Milvus 2.6 版本的设计选择，与按需检索的核心需求形成了适配。以下是几个关键能力的匹配分析。
稠密+稀疏向量的混合检索
Milvus 2.6 原生支持在同一个 collection 中存储稠密向量和稀疏向量，并在查询时自动融合结果。对话检索场景可以这样组合：用稠密向量（如 BGE-M3 生成的 768 维 embedding）捕捉语义相似度，用稀疏向量（BM25 算法生成）捕捉关键词匹配。查询“上周关于 RAG 的讨论”时，系统会同时执行语义检索和关键词检索，然后通过 Rerank 算法融合结果，召回率相比单一方法有显著提升。
存储计算分离+查询优化器
Milvus 2.6 的架构支持两种分层存储模式：热数据放内存、冷数据放对象存储；以及索引放内存、原始向量数据放对象存储。在这种模式下，100 万条对话只需 2GB 内存+8GB 对象存储就能搞定。在合理配置参数情况下，P99 延迟可控制在 20ms 以内。
JSON Shredding 与标量过滤优化
Milvus 2.6 默认启用 JSON Shredding，将 JSON 字段的嵌套结构打平为列式存储，标量过滤性能提升 3-5 倍（基于官方 benchmark，实际提升幅度取决于查询模式）。对话检索常需要过滤用户 ID、会话 ID、时间范围等元数据，这些字段通常存储在 JSON 中。启用 JSON Shredding 后，查询“用户 A 最近一周的对话”时，不再需要解析完整 JSON，而是直接在列式索引上执行过滤。
开源特性带来的技术掌控力
作为开源方案，Milvus 让你可以根据负载调整索引参数、通过数据分层优化资源占用、定制分布式部署策略。这种灵活性在商业黑盒方案中无法实现。更重要的是，中小团队也能构建百万到千万级检索系统，不再依赖巨额基础设施投入。
05
为什么 ChatGPT 和 Claude 选择了不同的路？
理解了技术约束后，我们可以回答最初的问题：为什么两家公司选择了不同的架构？
ChatGPT 选择主动遗忘（超出固定记忆容量），用确定的边界换系统简单性。Claude 选择延迟遗忘（理论无限累积），把召回责任交给检索系统。
Claude 的架构如果在 2020 年是过度设计：向量数据库延迟几百 ms，不支持混合查询，资源占用指数增长。肯定会被放弃使用。
但到 2025 年，这套架构已成为主流选择，也为agent的设计提供了一定参考。在这背后，Milvus 2.6 等方案已解决存储计算分离、查询优化、稠密+稀疏混合检索、JSON Shredding 等核心问题。
技术基础设施的成熟度，决定了架构选择的可行空间。
06
写在最后
具体落地场景中，如何做选择，我们没必要陷入预计算和按需检索的二元对立。
可以采用更合理的是混合架构：最近对话用滑动窗口直接注入，核心偏好用固定记忆，历史对话用向量检索按需召回。架构则可以随产品演进动态调整，从预计算为主逐步过渡到检索为主。
即使现在选择预计算方案，也要预留迁移路径。在数据结构上记录 ID、时间戳、分类标签、原始来源。未来迁移到向量检索时，只需为记忆生成 embedding，元数据一起写入数据库，检索逻辑无缝切换。
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
