在高質量 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，元數據一起寫入數據庫，檢索邏輯無縫切換。
原文作者：尹珉
原文鏈接：https://blog.csdn.net/weixin_44839084/article/details/156244882