推荐语
ChatGPT与Claude在记忆模块设计上各显神通，一文揭秘两大AI如何实现个性化记忆。核心内容： 1. ChatGPT采用四层静态注入架构，轻量化实现连续记忆 2. Claude运用RAG式按需检索，动态平衡记忆深度与效率 3. 两种记忆系统对日常Agent搭建的实践启示
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
文：尹珉
在高质量 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，元数据一起写入数据库，检索逻辑无缝切换。
粤ICP备14082021号
免费POC，
零成本试错
