AI 协作工程（十）：记忆与上下文系统
本文以 Manthan Gupta 的两篇逆向分析为线索，对比 ChatGPT 与 Claude 的记忆机制。核心问题不是谁“记得更多”，而是：面对同一个跨会话连续性问题，两者为何选择不同的系统路径。
文中将记忆问题还原为上下文工程问题，并指出两种典型方案：ChatGPT 的预注入式连续性，以及 Claude 的按需检索式连续性。两者差异本质在于：过去信息是在一开始就引入，还是在需要时再引入。
最终，这两种设计分别服务于不同目标：前者偏向对话连续性与流畅体验，后者偏向上下文可控性与边界清晰。同时说明，相关结论均来自推断，不代表官方实现。
引言
很多关于 AI 产品“记忆”的讨论，表面上是在比较哪个助手更懂用户、哪个更容易接上前文，但如果放回工程视角，这并不是一个 feature 的差异，而是一个 context system 的差异。所谓 memory，本质上是在回答三件事：哪些历史信息会进入当前 prompt、以什么形式进入，以及是在默认注入，还是按需检索。
最近看到 Manthan Gupta 的两篇逆向分析，一篇针对 ChatGPT，一篇针对 Claude。它们都不是官方说明，而是基于对话实验、提示探测和行为观察做出的推断，虽然不适合被当作“内部机制揭秘”，但它们的价值在于：提供了一个对照两种上下文工程路线的切入点。同时也需要注意，两篇材料的证据强度并不对等——作者自己提到，Claude 在实验中更容易被 probe 和追问，因此相关推断相对更容易展开，这一点本身就是阅读时的前提。
把两篇文章放在一起看，会出现一个清晰的差别：
- ChatGPT 更像是把跨会话信息提前整理为轻量摘要，并在后续对话中默认注入；
- Claude 则更像是把历史上下文放在工具层，在需要时再通过检索引入。
两者都在解决“记忆”，但优先级不同：一个让连续性默认注入，一个让历史按需加载。
因此，本文不把它们当作功能差异，而是理解为两种系统取舍：一种偏向预处理与持续注入，另一种偏向运行时检索与选择性回收。沿着这条线索，不仅可以解释两者带来的不同连续体验，也能反过来理解 context engineering、AI IDE 以及 agent workflow 到底在设计什么。
最后需要补充一个点。这类文章属于 reverse engineering，真正有价值的不只是结论本身，还包括推导过程。因此后面会同时关注两层内容：一是“系统可能如何工作”，二是“这些判断是如何从行为中推出来的”。
---
title: Memory 是 Context System 的一部分
---
flowchart LR
A["Long-term Memory
长期稳定事实"] --> E["Current Prompt"]
B["Recent History Summary
轻量历史摘要"] --> E
C["On-demand Retrieval
按需检索历史"] -.需要时调用.-> E
D["Current Session
当前会话窗口"] --> E
1. 为什么记忆问题本质上是上下文工程问题
很多文章会把 memory 当作一个独立功能来描述，但从系统角度看，它更接近一组 上下文进入规则。当前窗口保留什么，长期事实如何沉淀，最近历史是被压缩成摘要直接注入，还是停留在外部等待检索——这些并不是同一层的设计。所谓“记不记得”，本质对应的是：系统如何为当前这一次回答准备上下文。
之所以重要，是因为这里同时在平衡几件天然冲突的事：连续性（对话不应每次都像第一次开始）、细节保留（关键历史不能被压缩丢失）、成本与延迟（上下文不可能无限扩展）、以及 稳定性（如果由模型自行决定取舍，判断本身就会影响结果质量）。memory 并不是简单的“存与不存”，而是这些约束下的一种取舍结果。
因此，讨论 memory，如果还停留在“有没有这个功能”，其实已经不够。更有价值的比较，是看 哪些信息被默认带入 prompt，哪些信息被延后到运行时再决定引入，以及系统优先保护的是哪一种体验。顺着这个视角再看 ChatGPT 和 Claude，就会发现它们之间的差异是默认策略的不同。
这也是为什么原文里的实验方法本身值得关注。Manthan Gupta 并没有依赖官方文档，而是通过 让系统自述、观察上下文形态、验证跨会话表现，以及检查删除和更新后的行为变化，一步步反推出可能的结构。面对这类材料，更稳的读法不是抓住某个结论，而是看 多个观察是否在同一方向上相互印证，从而形成整体判断。
2. ChatGPT：把连续性预先整理后注入
根据 Manthan Gupta 的观察，ChatGPT 的记忆结构可以理解为多层上下文共同作用：session metadata、user memory、recent conversations summary，以及当前会话窗口。其中真正关键的，不是“有没有长期记忆”，而是 recent conversations summary 这一层的存在——它把跨会话连续性从“要么依赖长期画像，要么依赖当前窗口”，变成了 中间多一层对近期历史的轻量整理。
这层结构承担的角色很清晰：长期记忆用于稳定事实（身份、偏好、长期兴趣），当前窗口维持单次对话的推理连贯，而 recent summary 用来告诉模型“最近一段时间在关注什么”。它不是完整历史，也不是精确检索，更像一张被压缩过的导航图。实验中可以看到，这些信息通常以 数量有限的结构化条目存在，而不是把整段历史原文直接塞回 prompt。更重要的是，summary 更偏向 总结用户关注的主题，而不是复述 assistant 说过的具体内容，因此它更接近“用户状态”，而不是“会话全文”。
正因为这一点，这套机制更接近 “预先整理 + 默认注入”，而不是传统的 RAG。在典型 retrieval 体系里，系统需要先判断是否检索，再按需取回片段；而这里的观察更像是：系统持续维护一层近期摘要，并在对话开始时直接带入上下文。这样做的结果是，连续性不需要额外触发就能成立，同时 token 成本也比回灌原始历史更可控。
这个判断来自多方面的验证：一是上下文中能稳定看到相对固定的 memory 与 summary 结构，而不是每次临时拼接；二是 summary 的粒度明显比原始对话更粗，呈现出 事先整理过的主题条目；三是没有明显观察到“先检索再拼接”的行为模式。正是这些观察叠在一起，才指向 summary injection 这一解释路径。
从产品体验看，这条路线的优势在于 顺滑的默认连续性。很多时候，用户并不需要精确找回某一次对话的细节，而只是希望系统能沿着最近的主题继续展开。在这种场景下，轻量摘要刚好提供足够的方向感，而不引入额外的调用成本。
同时还有一个值得注意的点是 session metadata。实验显示，一些环境信息（设备、时区、订阅状态、使用模式等）可能在会话开始时一并进入上下文。即使这仍属于推断，它也提示了一个方向：ChatGPT 的个性化不仅依赖长期记忆，也依赖当下环境上下文。再加上长期记忆中既包含显式保存的信息，也可能包含系统对稳定偏好的隐式提取，这几层共同构成了其连续体验的基础。
但这条路线的问题也很明确：摘要提供的是方向，而不是细节。它更擅长维持“最近在聊什么”，不擅长恢复“当时具体怎么说”。本质上，这是在用 浅但稳定的连续性，换取 更低的使用摩擦和更一致的默认体验。
3. Claude：把历史当作需要时才调用的工具
相比之下，根据 Manthan Gupta 对 Claude 的观察，呈现出另一条明显不同的路径。Claude 同样具备长期记忆与当前会话窗口，但在跨会话这一层，它并不会把一份近历史摘要默认带入每次 prompt，而是通过类似 conversation_search、recent_chats 的机制，在需要时再把历史拉回当前上下文。需要注意的是，这些观察建立在开启 memory 的付费版本之上，本身属于实验性推断的边界之内。
这使得 Claude 的记忆结构更像一个 agent 化的系统：历史不再是默认背景，而是一个 外部可调用资源。模型需要先判断当前问题是否相关，再决定是否调用工具、如何调用，并将取回的内容纳入推理过程。也就是说，它的默认状态不是“带着历史工作”，而是 “先不带，需要时再查”。
更细看这一层，还能发现它并不是单一入口。conversation_search 更偏向 按主题或关键词检索历史，而 recent_chats 更像 按时间回看最近对话。这种拆分意味着，Claude 并不是简单做“有没有历史”，而是把历史访问进一步细化成不同路径，从一开始就带有 工具化和结构化调用的特征。
这种设计的优势在于 潜在的细节深度更高。一旦触发检索，系统可以取回比摘要更具体的历史片段，而且这些片段既可能包含用户输入，也可能包含模型过去的回复，更适合处理那些 必须依赖具体历史细节才能完成的任务。同时，历史只在相关时才被引入，也意味着不会为每一次普通对话承担额外的上下文成本。本质上，这是 “当前窗口 + 外部检索” 的组合，而不是始终携带一层固定的近历史摘要。
这种方式也非常接近工程中的 agent workflow。在复杂系统里，历史通常不会被无条件注入，而是先判断“是否需要”，再通过工具拉回上下文。Claude 的记忆机制之所以值得关注，正是因为它把一个消费级聊天产品里的 memory 问题，处理成了 接近 agent 执行链的结构。与此同时，作者还观察到长期记忆存在 隐式更新（implicit updates）：系统会根据长期互动逐步调整记忆，而删除相关会话后，这些记忆也可能随时间衰退。这种 持续演化的记忆状态，明显不同于静态存档的理解方式。
从证据链看，Claude 这一侧的推断也更完整：不仅有 memory 条目的观察，还有 工具调用行为、不同检索入口的分工、返回结果的结构，以及删除后记忆变化的现象。这些信号相互支撑，使得整体判断不仅停留在“看到什么”，而是延伸到“如何运作”。
但代价同样清晰：连续性不再是默认存在的，而依赖模型是否判断出“此刻需要历史”。一旦判断失误，相关上下文就可能缺失。因此，这条路线的特点不是始终顺滑，而是 在判断正确时，可以把历史作为工具更深入地调回当前任务中。
4. 真正的差别不在记忆有无，而在默认策略
把两篇分析放在一起，可以清晰的看出它们背后的 默认策略差异。两者都清楚，长上下文不是解法，也都没有走“把所有历史原文回灌”的路径。真正的分叉在于：系统默认如何处理历史信息。
ChatGPT 的选择，是让 连续性先成立。即使没有完整细节，系统也会优先把近期主题、长期偏好以及 session 环境整理后带入上下文，让模型一开始就处在“带背景”的状态。这更接近消费级产品逻辑，核心是 减少断裂感，让对话自然延续。
Claude 的选择，则是让 历史默认退出当前 prompt。只有当模型判断“这次确实需要过去信息”时，才通过工具把历史取回。这更接近工程系统的取舍：历史是一种资源，而不是默认负担，是否使用由当前任务决定。
如果用更抽象的语言概括，这对应两条不同的 context engineering 路线：
- 一条是 summary injection（先压缩，再持续注入），
- 一条是 on-demand retrieval（默认不带，运行时决定是否取回）。
前者提供的是 稳定但较浅的连续性，后者提供的是 按需触发但更深的细节回收能力。同时，前者尽量减少对模型判断的依赖，而后者则把一部分成败交给模型：是否知道该不该调历史。
换个角度看，两者其实在回答不同的问题。ChatGPT 更像在解决 “用户最近在做什么”应该成为默认背景；Claude 更像在解决 “过去具体发生过什么”应该作为可检索证据保留。这不是能力差异，而是优先级的不同。
这种差异甚至体现在可观察证据上。Manthan Gupta 对 ChatGPT 的推断，更多来自 上下文结构与行为结果，指向一层“预先整理的摘要”；而对 Claude 的分析，则依赖 工具入口、返回内容、记忆更新与删除后的变化，拼出一套“按需检索 + 动态更新”的机制。也就是说，两者不仅设计不同，连对外暴露的行为形态也不同，这本身就反映了 两条系统路线的差异。
---
title: ChatGPT 与 Claude 的记忆路线对照
---
flowchart LR
subgraph B["Claude"]
B1["User Memory"]
B2["Current Session"]
B3["conversation_search
recent_chats"]
B4["Current Prompt"]
B1 --> B4
B2 --> B4
B3 -.按需调用.-> B4
end
subgraph A["ChatGPT"]
A1["Session Metadata"]
A2["User Memory"]
A3["Recent Summary"]
A4["Current Session"]
A5["Current Prompt"]
A1 --> A5
A2 --> A5
A3 --> A5
A4 --> A5
end
5. 两种记忆设计背后的产品取向
把记忆设计放回产品语境，会发现这不是实现细节的差异，而是 产品目标的差异。ChatGPT 更像在构建一种 连续性默认成立的体验：不一定每次都还原最细的历史，但尽量让对话不断裂，让系统始终像在“接着上一次继续”。在日常问答、轻任务衔接、长期陪伴这类场景里，这种设计更自然，也更低摩擦。
Claude 则更像在把历史当作 可调度的工作资源。它不会把最近发生的一切默认带入，而是把历史留在可检索层，只有在任务真正需要时才调取。这种思路更贴近复杂任务、工具调用和 agent workflow，也更符合工程系统里常见的 按需引入上下文 的方式。
需要强调的是，这是一种 设计倾向，不是绝对分类。但从这些观察出发，可以看到一条清晰的分界：前者优先保证“默认接得上”，后者优先保证“需要时查得深”。
6. 总结
如果只把记忆理解成“模型有没有记住个人信息”，很容易把问题看窄。更稳的理解方式是：AI 产品里的 memory，本质是在设计一套跨时间的上下文进入规则。什么需要长期保留，什么只在当前 session 生效，什么要先被压缩成摘要，什么要等到需要时再检索，这些选择共同决定了系统的连续性体验。
从这个视角看，ChatGPT 与 Claude 的差异就变得清晰：前者更像 把近期历史预先整理并默认注入，让系统始终保持一层弱连续性；后者更像 把历史留在工具层，等模型判断相关时再按需调回。两条路线都成立，也不存在简单的优劣，它们只是服务于不同的产品目标。
这组对照真正有价值的地方，在于它能反过来解释更大的工程问题：AI IDE 为什么越来越依赖 summary、spec 与 workflow，agent 为什么要把历史当作工具化资源管理，以及 context engineering 为什么本质是在做信息分层与进入控制。这些并不是独立问题，memory 只是它们在产品层的一个缩影。