★ FEATURED ARTICLE 最近我在做一个长周期对话智能体遇到一个让做 AI 应用的人普遍头疼的问题用户在 20 轮之前说过一句我对花生过敏到了第 21 轮系统就忘了转头推荐了一道含花生的菜。换过更强的模型也没用因为问题根本不在模型智商而在我们压根没给它装海马体——文本模型天生只有一块类似工作内存的上下文窗口窗口一满旧信息就被冲掉。这就是 MemGPT 想解决的核心问题。它的思路很有意思既然模型只有工作内存那我们能不能像操作系统管理虚拟内存一样给模型外面接一块硬盘再配一个内存管理器让模型自己决定哪些信息留在内存里、哪些搬去硬盘、哪些用完直接淘汰这篇我把自己的理解和踩过的坑整理一遍包括 MemGPT 的核心思想、一套最小可用的长期记忆系统怎么搭、调优时最容易翻车的几个点以及它跟 RAG 的边界到底在哪。适合正在做对话机器人、智能体或任何需要跨轮次记住用户信息的开发者参考。1. 先搞清楚问题上下文窗口到底卡在哪1.1 模型的工作内存只有一屏很多人把上下文窗口理解成模型能记住多长的对话这个理解其实有偏差。上下文窗口更像一块白板白板上的内容模型随时能看、能引用但白板一旦写满新内容要进来旧内容就得擦掉。而现实中的大多数实现擦掉的往往是开头那部分——于是用户最早的偏好、约定、背景信息全部随着开头的 token 一起消失了。我在做那个智能体时统计过一轮真实对话一个平均 40 轮的任务型对话tokens 分布大概是系统提示词占 10%长期任务背景占 30%最近交互占 50%剩下都是格式和填充。一旦窗口触顶最简单粗暴的处理是截断最早的历史或只保留最近 N 轮。短期看对话是能跑下去的但代价是用户发现你反复问已经说过的信息或者更糟——你根据过时的信息做出错误判断。这种情况要不要靠加长上下文窗口解决治标不治本。窗口从 8K 扩到 128K 甚至更大只是把白板换大了但白板终究有边界。而且更大的窗口带来两个新问题一是成本和延迟线性上涨二是新研究和我自己的实测都表明模型放在长上下文里的信息召回率会明显下降中间部分往往被视觉盲区吞掉远不如短上下文精准。1.2 遗忘不是模型的错是架构的错如果给这类问题下一个简单定义模型得了顺行性遗忘症——能记住当前正在处理的内容却没办法把已经翻过去的内容稳定固化下来。人类能长期记住事物靠的是大脑里的海马体把短期记忆反复巩固成长期记忆。模型没有这个巩固机制它所有的记忆都只能活在那块白板里白板一刷新记忆归零。所以核心矛盾其实就一句话对话是无限流式的但模型的可用上下文是守恒的。解决这个矛盾靠的不是让模型更会记而是从架构层面引入一个外部存储和一套读写策略。这正是 MemGPT 这类方案真正有价值的地方——它把记忆从模型能力问题转变成了系统工程问题。2. 为什么是 MemGPT把操作系统的分页思想搬进对话系统2.1 虚拟内存给我们的启示MemGPT 这个名字是 Memory-GPT 的缩写核心灵感来自操作系统里的虚拟内存机制。计算机的物理内存有限但进程看起来可以拥有远超物理内存的地址空间靠的就是分页和换入换出不常用的页被写回磁盘需要时再加载回内存。操作系统用一个 MMU内存管理单元统一处理映射对进程来说这些细节透明。把这个模型搬到 LLM 上映射关系非常漂亮操作系统概念MemGPT 对应物作用物理内存上下文窗口模型当前能直接看到和推理的内容磁盘外部存储/向量数据库保存不常在上下文中的历史信息MMU记忆管理器决定何时写入、何时淘汰、何时召回复用页错误记忆压力触发上下文快满时主动执行内存整理这个类比最妙的地方在于它不追求把上下文调大而是承认上下文永远是稀缺资源然后在这个前提下做最优调度。这比单纯堆窗口更符合工程直觉。2.2 记忆分层主记忆、外置记忆、存档记忆MemGPT 对记忆的处理是分层的我理解下来大致三层第一层是主记忆in-context memory它是一小段结构化文本始终常驻上下文窗口用来保存系统的身份和当前最重要的状态。比如用户姓名、核心偏好、当前任务进度。这部分必须精简我一般控制在 500800 token 以内。第二层是外置上下文external context本质是对话历史的滚动缓冲。系统把最近的若干轮对话放在这个缓冲区里供模型推理时引用。第三层是存档记忆archival memory理论上容量无限存放在外部存储中。对话中提炼出的事实、旧摘要、历史事件归档到这里需要时通过检索召回到上下文里。真正体现 MemGPT 特色的是它还允许模型自主管理记忆模型不仅能回答用户问题还能通过函数调用去执行写入记忆检索记忆归档旧内容这类操作。换句话说模型不再是被动接受拼接的上下文而是主动参与了自己记忆的调度。2.3 函数调用是记忆管理器的手臂很多人以为 MemGPT 只是对话 向量检索这是误解。如果没有函数调用能力它就退化成普通 RAG 了。函数调用让模型在推理过程中实时发起记忆操作这相当于给了模型一个自我管理的接口。在实际实现里我用大模型接口提供的工具调用能力定义了这么几个操作查询当前主记忆的状态检索存档记忆向存档记忆写入一条新事实更新主记忆里的某个字段模型在对话过程中发现用户说了一个新偏好就会自主调用写入操作。我的记忆管理器在这一侧只是执行方决定权在模型手上。这个设计有个隐含前提模型必须足够聪明能在正确的时机发起正确的调用。所以底层模型的选型很重要太弱的模型会乱调用或漏调用这一点后面踩坑部分我再展开。3. 工程落地搭一套最小可用的长期记忆系统3.1 整体架构只有一个核心原则我在落地时没有照搬论文里的复杂设计而是先搭了一套自己看得懂的最小实现。整体就四个组件主记忆文件一个 JSON 结构存放用户画像和系统状态每次对话开始前加载进上下文。滚动对话缓冲区一个 deque保存最近 N 轮对话的原始文本。向量存储存放用户事实和旧摘要支持语义检索。记忆管理器一个调度模块负责把上述组件串起来并在适当时机触发压缩、写入、召回。核心原则只有一个不要让记忆操作打断正常对话的流畅度。记忆调度全部放在对话循环的间隙处理用户不该感知到系统正在后台整理记忆这个过程。3.2 记忆管理器的主循环先判断压力再决定操作下面是我实现里最关键的一段逻辑核心是记忆压力检查——每次对话结束后管理器估算当前上下文的 token 占用如果超过软限制就触发归档或压缩。class MemoryManager: def __init__(self, llm, vector_store, memory_file): self.llm llm self.vector_store vector_store self.memory_file memory_file # 主记忆 JSON self.buffer deque(maxlen20) # 滚动对话缓冲 self.soft_limit 6000 # 上下文软限制以 token 计 self.hard_limit 8000 # 硬限制超过必须立即压缩 def after_turn(self, user_msg, assistant_msg): self.buffer.append({user: user_msg, assistant: assistant_msg}) self._update_core_memory(user_msg, assistant_msg) current_tokens self._count_tokens() if current_tokens self.soft_limit: self._handle_memory_pressure(current_tokens) def _handle_memory_pressure(self, current_tokens): if current_tokens self.hard_limit: self._force_compress() else: self._archive_old_turns()这里有个容易忽略的点token 计数必须稳定可靠。我最初直接用模型接口返回的 token 数但发现不同计数库在中文场景下误差很大后来改为统一用本地 tokenizer 预估宁可多估 10% 也不要少估因为一旦实际超出窗口导致请求报错整轮对话就断了。3.3 记忆写入让模型以结构化事实的方式维护记忆记忆写入的第一步是决定什么值得记。最早的版本我让模型每轮都做长摘要结果上下文被摘要挤爆成本翻了好几倍。后来改成只在检测到新信息时触发让模型输出一个 JSON{ need_update: true, facts: [ { content: 用户对花生过敏, category: preference, confidence: 0.95, source_turn: 17 }, { content: 用户正在做一个电商后台重构项目, category: project, confidence: 0.8, source_turn: 23 } ] }注意 facts 里必须带source_turn和confidence。前者标记这条信息的来源轮次方便回溯后者让系统对不确定的信息持保留态度。那些用户好像提到过他住在某个城市但我记不清了这类低置信度信息我不写进主记忆只放进存档等后续对话验证后再升级。3.4 存档记忆的读写接口存档层我用向量数据库保存事实条目写入前做两件事一是把长文本拆成独立的事实单元每一条就是一个可检索的原子记录二是给每条事实打上元数据比如来源轮次、写入时间、会话 ID、置信度。召回时不是只靠向量相似度我还会叠加两个过滤条件时间衰减和会话过滤。向量相似度解决语义上相关的问题时间衰减解决旧信息是否还有效的问题会话过滤避免从其他完全无关的会话里捞出干扰信息。def recall(self, query, top_k5): candidates self.vector_store.search(query, top_ktop_k * 2) filtered [] for c in candidates: if not self._is_recent_enough(c): continue score 0.6 * c.score 0.4 * self._recency_bonus(c) filtered.append((score, c)) filtered.sort(keylambda x: -x[0]) return [c for _, c in filtered[:top_k]]这一步的技巧在于不要把 top_k 设得太大。我在实验里发现检索出来的记忆塞进上下文后前 3 条通常有用第 5 条之后基本是噪声反而干扰模型判断。所以召回到上下文的条目我严格控制宁可少召回也不能带偏。4. 真正的难点什么时候写、什么时候忘、什么时候翻旧账4.1 记忆压力阈值不是拍脑袋定的上下文窗口用多少比例给系统提示、多少给主记忆、多少给历史、多少预留给输出这个预算分配直接决定系统行为的稳定性。我自己试下来一套比较稳的默认预算供参考上下文区域token 预算说明系统提示词10%角色设定和指令几乎不变主记忆10%用户画像 当前任务状态滚动对话缓冲50%最近几轮对话原文召回记忆15%检索进来的存档事实预留输出15%保证模型有足够的生成空间这个预算不是死的。如果任务型对话占比高比如客服我会把滚动缓冲加大到 60%牺牲召回记忆如果信息密集的咨询场景比如法律/医疗问答我会把召回记忆的配额提到 25%。关键是每个区域的 token 上限要在代码里显式声明而不是靠观察模糊判断。一旦某区域超限管理器要能立刻实施裁剪。4.2 上下文压缩把旧事浓缩成摘要卡片当对话缓冲超过软限制时我会触发一次压缩操作选取缓冲区里最早的一部分对话让模型生成结构化摘要然后把这些摘要写入存档从缓冲区里移除原始对话。这里我走过弯路最初让模型直接对整个缓冲区做一次性摘要结果摘要概括性太强把用户说他妈妈周三来北京需要订两个人的餐厅这种具体细节蒸发成用户提到家庭聚餐。细节丢失后后面任何与时间、人物相关的指令都失去参照。后来改成分层摘要每次只压缩最早 5~6 轮摘要保留可检索的关键实体时间、人物、地点、数值并生成一条可直接执行的提醒式条目。压缩完立即问一次模型这些新摘要与当前主记忆中的事实有没有冲突有冲突就以摘要中的新信息为准并记录冲突日志用于后续复盘。4.3 回想策略主动想起 vs 被动触发记忆不该只在上下文快满时才被想起来还应该在用户提问触及某段旧事时主动召回。这就涉及到另一个问题模型怎么知道该翻旧账了我实现了两条召回路径被动触发每次用户提问先让一个轻量级判断逻辑决定这轮问题是否可能依赖历史信息比如提到时间、人名、此前讨论过的话题。如果可能就以当前问题为 query 去向量库做语义检索。主动触发当对话命中某个主题的记忆锚点比如用户再次提到某个项目名即使问题本身不要求检索也主动把相关旧事实拉到上下文中。关键心得不要每轮都做向量检索。我见过很多实现把检索做成流水线必走环节结果是不相关问题也强行检索一堆相似但不相关的文本既浪费 tokens 又引入噪声。检索必须是有条件触发的。5. 我在实践中踩过的坑5.1 记忆污染模型会脑补不存在的用户信息这是最让我意外的一个坑。模型在自主写记忆时经常把推理内容误写成事实。比如用户抱怨最近搬家好累模型可能写出用户已决定定居某城市这种从未被明确说过的事实。这种记忆一旦写入就会在后续所有对话中持续影响判断而且因为是模型自己的产出系统很难自我纠错。我的应对方式是把记忆写入分成两类用户明确说过的原话和模型基于对话的推断。前者直接存原文引用后者必须降低置信度、单独标记为推断。主记忆里只放高置信度的明确事实推断类信息一律放存档层需要时再以推测的形式召回模型看到时会自行判断。5.2 摘要丢失细节一压再压关键信息蒸发摘要压缩是记忆系统里最需要反复打磨的环节。摘要粒度太粗细节丢光粒度太细压缩效果又为零。我后来定了一条强制规则压缩后的每条摘要必须保留可验证的实体信息——时间、地点、人物、数量、决定。每条摘要不超过 80 字长了就继续拆分。还有一个容易被忽略的问题压缩被反复执行后有些信息会被摘要的摘要覆盖原始细节彻底丢失。所以我在压缩前硬性要求先检查档案里是否已有对应事实已有则只做链接不重复写入没有才新建条目。这条规则把信息蒸发控制在了可接受范围内。5.3 检索噪声向量相似度高不代表上下文相关向量检索的作弊陷阱在于相似度高的文本可能语义相关但可能毫无当下价值。比如用户之前在聊菜谱这一轮在聊健身向量检索可能把少油少盐这一类共同出现的文本捞出来实际上对当前健身话题毫无帮助。我只用召回结果做参考不再直接塞进上下文。具体做法是检索出候选后让模型做一个二值判断当前问题是否需要这些旧记忆。只有判断为需要记忆才真正进入上下文。这个判断本身也是函数调用成本可控但效果提升明显。5.4 反复横跳同一件事被写进去又被删掉记忆还会出现翻烙饼问题这轮写入了某个事实下一轮模型又觉得不对删除或改写了再过一轮又重新写回来。反复横跳不仅浪费 tokens还会让记忆系统看起来极不可信。根因在于模型每次做记忆更新时只看到上下文片段缺少全局视角。我的解法是给每条主记忆加版本号和更新时间写入前先做冲突检查如果新信息与已有信息矛盾不直接覆盖而是触发一次对比决策——把新旧两条记忆同时呈现给模型让它解释为什么更新并记录决策原因。这样一来无意义的反复修改会明显减少因为模型必须给出比感觉不对更强的理由。6. 别把引擎装错车MemGPT 的适用边界6.1 短对话和单轮任务别用如果你的场景是客服机器人处理单次问答或者用户每次对话不超过 5 轮MemGPT 这类方案属于纯负担。记忆管理的延迟和 token 开销是固定成本短期会话里收获不了回报。我做了一个简单的判断指标平均对话轮次低于 10 轮、会话之间无状态关联就不要上长期记忆系统老老实实塞满上下文即可。6.2 跟 RAG 是互补不是替代RAG 解决的是外部知识怎么进模型的问题MemGPT 解决的是跨时间的状态怎么稳定保存的问题。前者是读文档后者是记状态。一个典型的区别RAG 会告诉你这个产品的退货政策是什么MemGPT 能记住这位用户上次退货时抱怨过物流慢这次别再推荐快递选项。没有谁替代谁实际系统里两者往往是并存的——外部知识走 RAG用户状态和任务进度走长期记忆。判断要不要引入记忆管理我自己总结了一套筛选条件用户画像是否需要在多次会话间保持稳定任务是否有跨轮次甚至跨天的进度状态系统是否会因为遗忘某条信息而造成明显损失上下文窗口是否频繁成为对话瓶颈四个问题里命中三个以上才值得为它搭一套记忆系统。命中的少于两个建议推迟引入先打磨对话流程本身。6.3 演进路径从简单的提示词技巧起步如果确认场景需要长期记忆能力但团队资源和时间都紧张我有一个务实的建议不要一上来就上向量库和记忆管理器。先从简单的记忆档案做起——用一个 JSON 文件保存关键用户事实每次对话前拼进系统提示词对话结束后让模型更新 JSON。这个方案虽然简单到有点土但它能帮你快速验证记忆需求是否真实存在。等确认有价值了再逐步把档案扩展成向量存储、加入记忆压力调度、接入函数调用最后演化成完整的 MemGPT 风格闭环。回看整个实践过程我最深的体会是给 AI 装海马体这件事难的不是存储和检索技术而是如何定义哪些值得记、哪些该忘、何时该想起。这一层决策逻辑的合理性决定记忆系统的上限。调优阶段我强烈建议先给每次记忆读写都打上日志把时间戳、触发原因、写入内容全部记录下来。你很快就能从日志里看到模型的记忆行为有多离谱然后针对性地调整——这比任何理论推演都管用。
阅读完成 · 觉得有帮助？
