做 AI Agent 的都知道模型本身没有记忆这是个绕不开的坑。我见过太多 Demo 站起来能聊坐下来就失忆你前一轮告诉它我是一个做咖啡烘焙的帮我设计一下新品豆单下一轮它就开始跟你聊旅游路线你让它修改一段代码它改完你换了个会话问刚才改到第几行了它两眼一抹黑。于是圈子里聊得最多的就是同一件事——AI Agent 记忆。作为走进 AI Agent系列的第三篇这篇我想把让 Agent 记住你这件事讲透。我会从短期记忆和长期记忆的分层开始聊接着展开双网络记忆模型、hindsight 记忆库、workbuddy 这类本地记忆迁移方案如何落到工程里最后给出一套可以照着抄的记忆模块实现思路顺便把代码开发场景里让 Agent 记住上次改到哪的玩法也讲清楚。适合正在搭建自己的 Agent、想给产品加个性化能力、或者准备 AI Agent 相关面试的同学参考。1. 先把记忆这件事拆清楚Agent 为什么总失忆1.1 你遇到的失忆到底属于哪一种先说结论Agent 的失忆不是一种病是至少三种病混在一起。第一种是会话内的失忆。哪怕你在同一个对话窗口里聊长了之后早期的信息也会被挤出上下文窗口。这不一定是模型笨而是 LLM 推理时注意力范围有限输入 token 越多成本和延迟越高很多实现里会对旧的上下文做截断或压缩早期细节就这样丢了。第二种是跨会话的失忆。用户昨天和 Agent 说过我家有两只猫一只叫小满一只叫小乐今天新开一个会话Agent 完全不认识这俩名字。这是最影响体验的一种失忆也是我们通常说的长期记忆要解决的核心问题。第三种是环境状态的失忆。Agent 在跑多步骤任务时中间结果没有持久化进程一重启所有工作上下文就没了。这种问题往往被归到有状态服务或工作流编排里但本质上也是记忆管理的一部分。排查一个记不住的问题先别急着写向量库先定位它是哪一种。我见过不少团队把会话内截断问题当成长期记忆问题去解决最后搭了一个很大的向量检索服务结果发现根本用不上还白白增加了几百毫秒延迟。分清失忆类型是解决记忆问题的第一步。1.2 短期记忆与长期记忆不是同一个存储层在 AI Agent 设计里短期记忆和长期记忆不应该简单当成时间长短不同的两个概念。短期记忆准确说是工作记忆指的是 Agent 在完成当前任务时临时持有的信息典型载体就是对话窗口中的上下文。它对应人类手里正在做的事的状态特点是高频读写、快速失效、只对当前任务有意义。它不需要永久保存但要保证当前任务的连续性。长期记忆则对应跨会话、跨任务的持久化知识比如用户偏好、历史事件、项目背景。它的读取不应该依赖上下文窗口而应该从外部存储里按需检索类似人类调用长期经验。设计上有个简单原则短期记忆负责当前对话的连贯性长期记忆负责跨对话的一致性。两者需要联动但不能互相替代。你去看现在的 Agent 框架基本都是这个套路短期记忆做成上下文窗口的动态裁剪长期记忆做成向量库加实体抽取、偏好存储。我听过一个很好的类比短期记忆是草稿纸长期记忆是笔记本。草稿纸上的东西用完就扔笔记本上的东西需要整理、编号、定期复习。两者如果混在一起要么草稿纸太厚上下文爆掉要么笔记本太乱召回一堆垃圾。1.3 双网络记忆模型为什么大家都开始分层近期讨论度很高的双网络记忆模型简单说就是把短期和长期当成两套独立但协作的网络来设计。短期记忆网络负责实时状态捕捉具备快速写入和快速失效的能力长期记忆网络负责稳定知识的沉淀具备检索和更新的能力。这个模型最吸引我的地方在于它强调写入路径的分离。短期记忆沿着对话的主流程自然流转不做过多的格式化长期记忆则需要经历抽取、加工、存储三个步骤不是什么东西都往长期记忆里塞。具体到实现短期记忆可以是队列或滑动窗口每次只保留最近 N 轮对话再加上一轮摘要压缩长期记忆则需要一个持久化存储常见有 SQLite、PostgreSQL、向量数据库再加一个语义检索接口。短期记忆的写入成本极低长期记忆的写入成本高一些因此需要设置触发条件和重要性判断。用这个模型去设计 Agent系统会变得清晰很多先判断这条信息是当前任务要用还是未来会反复用到后者才进入长期记忆链路。这也是 hindsight 记忆库、workbuddy 本地记忆迁移这类方案背后共同的影子它们虽然落地细节不同但骨架都是短期、长期分层的思路。2. 记忆模块的三种落地方式从裸上下文到本地记忆库2.1 上下文拼接最直接但最容易爆的方案最朴素的记忆实现是把用户的历史对话或用户画像直接拼进 prompt。比如每次请求都带上用户偏好咖啡烘焙师、喜欢浅烘、预算 200 元以内或者把最近 20 轮对话拼接成 system prompt。优点是实现成本极低几分钟就能跑通也不需要额外组件。对于短会话和轻量场景这确实够用。很多人在原型验证阶段也都是这么做的先把功能跑起来再说。但它的瓶颈非常明显。一个是长度问题上下文窗口终归有限随着历史变长拼接的内容会越来越多最终把预算和延迟都推高。另一个是信号衰减问题当 prompt 里塞了大量不相关信息时模型容易抓错重点该用的偏好反而被忽略。我自己的做法是上下文拼接只用来承载刚发生的事和必须始终在场的约束比如系统设定、用户 ID、近期指令。至于历史事实和偏好有条件就移出 prompt交给检索层。这也是很多 Agent 框架默认的做法messages 只保留当前会话最近几轮其余存入长期记忆库。2.2 外部记忆库与向量检索把记忆变成可查询的数据当记忆数据积累到一定程度外部化存储是必然选择。基本思路是每轮对话结束后从对话文本里抽取有意义的信息形成一条条记忆条目写入数据库当用户发起新请求时根据当前 query 去数据库里检索最相关的记忆注入到 prompt 里。记忆条目可以有不同的类型用户偏好喜欢简洁回答、事实家里有两只猫、事件上周三部署了新版、技能回复时需要附代码示例等。每条记忆还可以附上重要度、创建时间、最后访问时间等元数据这些后面都会用到。检索通常用向量相似度先把记忆内容和当前 query 都 embed 成向量然后取 top-k。如果想要更准可以在向量检索后再加一个相关性重排或者结合关键词过滤也可以给记忆条目打标签实现按类型过滤的检索。这套方案对应了很多工具里的 hindsight 记忆库做法不是原样存储整段聊天记录而是把聊天记录压缩成结构化记忆提高召回的精确度同时减少 token 占用。说白了存一堆原文进去不如存几条提炼过的经验进去更划算。2.3 本地记忆迁移workbuddy 带给我们的提示workbuddy 历史对话记录、本地记忆迁移这个方向我理解指的是另一类需求把 Agent 从一个环境迁移到另一个环境时历史对话和记忆数据不丢失。比如你在 A 机器上训练了一个顺手的工作助手换到 B 机器想让它接着用就需要本地记忆迁移。workbuddy 这类产品/方案的思路是把记忆数据独立于模型和 Agent 配置持久化在本地存储SQLite 或本地目录并提供导出、导入机制。迁移时只需要复制一份记忆文件在新环境重新加载Agent 就能恢复记忆。这里有几个工程细节值得注意。第一记忆数据最好用版本化的格式升级时能迁移第二如果记忆里包含向量迁移后最好重新生成 embedding因为不同模型的向量维度不同第三本地化存储天然符合隐私要求敏感信息不会上传到云端业务服务这也是很多用户选择本地记忆方案的原因。2.4 选型对比什么场景该用哪套方案这三种方式其实不是互斥的一个成熟的 Agent 往往会组合使用。我直接做个对比方案优点缺点适合场景上下文拼接实现快、无需额外组件长度受限、成本高、易稀释注意力单会话对话、原型验证外部记忆库 向量检索可扩展、召回精准、跨会话持久需要 embedding、存储、维护多会话长期记忆、知识型助手本地记忆迁移隐私好、状态可移植需要设计导出格式、更新链路桌面工具、个人工作流助手组合使用的典型形态是上下文窗口存当前工作集向量库存长期偏好和事实本地文件或数据库负责持久化和迁移。这套形态也是我后面实操部分要重点展开的。3. 手把手搭一套可用的 Agent 记忆模块把理论落到代码3.1 先定数据结构记忆和状态的模型动手前先把数据模型定好后面能少踩很多坑。我一般会给 Agent 设计三层状态第一层是消息状态对应当前会话的消息列表这是短期记忆的载体。第二层是用户画像保存用户的持久偏好和属性属于长期记忆的一部分。第三层是记忆条目列表由历史对话抽取而来带有类型、重要度、时间戳等元数据。如果用 LangGraph 这类编排框架状态可以设计成类似下面这样Python 伪代码实际以框架 API 为准class AgentState(TypedDict): messages: Annotated[list, add_messages] user_id: str session_id: str user_profile: dict memory_ids: list[str]几个字段的考虑messages 走框架自带的 reducer每次节点输出都会追加user_id 用于区分不同用户的记忆空间防止多人串扰user_profile 会在每次会话开始前从记忆库加载memory_ids 是当前请求召回的记忆条目 ID 列表方便调试时追溯这次到底用了哪些记忆。3.2 记忆写入什么时候记住、记住什么记忆写入是被人低估最多的环节。很多人直接把整段历史塞进向量库结果是噪音太大召回质量很差。我在实际项目里验证下来比较靠谱的写入策略是触发式抽取 事件式总结。触发式抽取的意思是每轮对话结束后让模型判断当前对话里有没有值得长期记住的信息。相当于一个二分类加信息抽取的任务如果值得就抽取成结构化记忆如果不值得就不写。判断条件可以包括出现了新的用户偏好、发生了关键事件、用户明确提出了长期要求等。事件式总结则针对长对话当对话轮数超过阈值比如 10 轮就对之前的对话做一个摘要把摘要存为一条记忆条目同时将旧消息从短期上下文里归档。这样既保留了历史梗概又控制了上下文长度。写入记忆时建议加一个重要度评分0~1 或 1~5。之后召回和清理都依赖这个评分。实现上可以简单写一个 Node用 LLM 输出结构化 JSON 格式{ extracted: [ { type: preference, content: 用户偏好简洁回答, importance: 0.8 }, { type: event, content: 2025-01-12 完成支付模块重构, importance: 0.6 } ] }这部分我踩过最大的坑是不加判断地抽取。有段时间我的记忆库写满了类似用户问了一个问题用户说了谢谢这种完全没有长期价值的条目检索时的噪音高到几乎不可用。后来加了触发式判断记忆条目的质量明显提升召回结果也干净多了。3.3 记忆召回防呆但必要的 top-k 检索到了召回环节核心目标不是召回更多而是召回更准。每个新请求进来我会先用规则过滤一轮比如只看当前用户、只看有效记忆条目再做 embedding 相似度检索取 top 3~5 条。召回之后还要做一次排序把重要度因子、时间衰减因子考虑进去。一个简单可用的公式是score 相似度 * 0.6 重要度 * 0.3 时间衰减 * 0.1。时间衰减可以按最后访问时间和当前时间的差来指数缩小保证很久没用的记忆慢慢沉底但也保留被重要标记的记忆不被埋没。召回的时机也要控制。不是每一轮都要查长期记忆否则每次请求都多一次向量检索延迟不可接受。我的策略是当前对话里已经有足够上下文时跳过召回只有在会话重建、用户切换话题、或主动提到与过去相关的内容时才触发召回。日常对话就只依赖短期记忆。在 LangGraph 里这可以抽象成一个 memory_retrieve 节点节点内先从向量库查询再把召回的记忆内容追加进 prompt 上下文。3.4 记忆更新与遗忘不清理记忆库迟早变成垃圾场长期记忆如果不做更新和清理数据积累到一定程度就会变得又乱又杂。这和人类记忆一样只记不复习、只存不整理最后什么都想不起来。更新策略方面我常用的做法是版本叠加而非覆盖。当同一用户出现新的偏好信息时不是删掉旧条目而是新增一条带时间戳的新条目系统在召回时优先返回更新后的内容。如果确定旧条目已经失效比如用户明确说我现在做后端了不做前端了就把旧条目标记为过期而不是物理删除方便留痕和回滚。遗忘策略可以基于两个维度重要度 最近访问时间。定期比如每周跑一次清理任务把重要度低、长时间未被访问的条目归档或清除。这里的关键是归档而不是直接删除——万一用户某一天又用到了你还有恢复空间。当时我接手一个项目时数据库里有几万条记忆条目可实际每次能召回到的有效信息不到一成。排查后发现大量条目是同一事件的重复变体比如用户喜欢深色主题被写了几十条。后来我加入了去重合并和冲突消解机制新增前先做一次相似记忆检索如果相似度高于阈值就合并或只更新元数据。3.5 编程场景实操让 Agent 记住代码改到哪了编程辅助场景对记忆的需求很典型。像 opencode、Cursor 这类的工具里用户经常要 Agent 连续修改多个文件如果 Agent 不记得上一次改动的内容下一次就会重复劳动甚至破坏已有实现。opencode 的思路值得借鉴每次执行代码修改时把改了什么、为什么改、涉及哪些文件、改动前后的关键片段、有没有遗留问题记录成结构化记忆。下次 Agent 工作前先召回这个项目最近的修改记录就能知道上次改到哪一步从而接着做。实现上可以做一个简单的修改日志记忆池每条记录包含任务 ID、文件路径、变更摘要、时间戳、关联分支名。在启动新任务时先按项目路径检索最近记录再把结果注入工作引导里。实测下来这种状态回放对长任务特别有用Agent 很少再问你刚才是不是改过这个文件。我建议所有做编程类 Agent 的朋友都至少把这个最近操作日志做起来它比泛化的用户画像更能提升开发体验。毕竟对程序员来说记住代码改到哪了往往比记住我喜欢什么主题更重要。4. 常见问题与排查技巧实录把踩过的坑一次说清4.1 上下文一长就爆怎么办上下文爆掉的本质是短期记忆管理不当。三个手段组合使用滑动窗口、摘要归档、动态裁剪。滑动窗口就是只保留最近的 N 轮N 根据模型上下文长度和成本来定摘要归档是把超出窗口的旧消息合并成一个 summary 存回上下文动态裁剪则是去掉无用的中间工具调用结果只保留关键输出。实际操作时我会给上下文设置两个阈值软阈值和硬阈值。超过软阈值时触发一次摘要归档超过硬阈值时强制裁剪。这样既能保持响应质量又不会让上下文无限膨胀。4.2 记忆串了怎么排查记忆串扰最常见的原因是隔离没做好。长期记忆表里没有 user_id 字段或者召回时忘了过滤导致用户 A 的记忆出现在用户 B 的会话里。排查思路比较直接第一步看日志中注入 prompt 的记忆条目 ID 列表第二步检查这些条目是否属于当前用户第三步检查召回条件是否有全局默认值。隔离规则没有捷径就是每次读写都带上命名空间从查询的第一步就限制死只能看当前用户的数据。4.3 向量库迁移后记忆全部失效怎么办这个问题我在 2.3 节提过这里再展开。如果你之前用 OpenAI embedding 模型生成向量后来换成开源模型或换了向量维度旧的向量就无法和新查询做相似度计算了。解决方案是记录每个记忆条目使用的 embed 模型和维度迁移时检查版本不一致就重新 embedding。最好的做法是记忆库里始终存储文本原文和向量两个字段文本用于兜底和重建。以后不管换什么模型只要有原文向量都能重新生成。4.4 记忆写得太乱、太碎怎么办这是很多人会忽视的一个问题不是检索不够好而是写入时就不该存。写得太碎会让召回结果里全是噪音。我的经验是先定义一个值得记住的标准比如用户主动表达的偏好跨会话要复用的任务上下文有关键时间点的事件再定义不该记住的标准比如随口一说的一次性指令临时性排错信息情绪化的瞬时评价。过滤比后来清理更省力也更能保证记忆库的质量。4.5 面试题速查面试官问 Agent 记忆到底想听什么最近 AI Agent 面试题里记忆是高频考点。我整理几个核心回答思路短期和长期记忆的区别可以从载体上下文窗口 vs 外部存储、生命周期、读写路径来讲。怎么实现记忆召回说清楚 embedding、top-k 检索、重排、prompt 注入这几个环节。记忆污染怎么避免写入时做抽取与重要度评估召回时做过滤与去重使用时做版本管理。多用户隔离怎么做user_id/session_id 命名空间隔离数据权限控制。记忆迁移怎么做导出结构化数据、重新 embedding、版本兼容。回答这类问题时最好配上自己做过的项目案例。面试官更看重你有没有动手踩过坑能说出我当时遇到记忆串扰后来加了命名空间隔离才解决这种细节比背理论强得多。5. 进阶方向与落地建议从能记住到用得聪明5.1 多 Agent 记忆共享不能各记各的当系统从单 Agent 走向多 Agent比如 spring ai multi agent 的场景记忆就不能再各自为政。我建议把记忆模块抽成独立的记忆服务以 MCP 工具的方式暴露读写接口。各 Agent 通过接口读写共享记忆行为才能协调。实践中需要注意记忆的一致性两个 Agent 同时写同一用户记忆时要以时间戳和来源区分优先级否则会出现互相覆盖。比如一个 Agent 更新了用户的偏好另一个 Agent 同时写了旧偏好那后来的数据到底以谁为准我的做法是给每条记忆加来源标记和版本号写的时候做冲突检测而不是无脑覆盖。5.2 从记住到个性化Agent 越用越懂你记忆的终极价值是让 Agent 在长期使用中形成对用户的理解。前面说的都是基础设施真正的个性体验来自对记忆的持续挖掘比如基于用户历史选择推荐具体参数基于过往纠错记录调整回复风格基于项目历史主动提出下一步建议。这个方向上hindsight 记忆库的理念很有启发在任务结束后做一次事后反思提炼出对后续任务有用的经验而不是仅仅记录对话本身。这套机制让记忆从流水账升级为经验库。我现在做记忆模块都会加一个事后反思节点跑完一个完整任务后自动生成几条经验条目效果比单纯存对话好很多。5.3 给刚开始的人三条落地建议如果现在要从零开始做 Agent 记忆我给三条建议。第一不要一上来就上向量库。很多情况用 SQLite 加规则判断就够先跑通再迭代。向量库看起来高大上但维护成本和排查难度都不低数据量小的时候完全没必要。第二记忆方案和 Agent 架构解耦。不要和某个框架绑死单独封装记忆模块最好支持导出和迁移。这样以后换框架、换模型记忆数据还能继续用。第三把可调试性放在第一位。每次用什么记忆、为什么用都要能查能回溯否则线上出了问题根本无法排查。我在记忆模块里专门加了一个 debug 接口可以看到每次请求召回了哪些记忆条目、各自的得分排查效率提升非常大。我自己把这套记忆结构在不同项目里跑过几轮之后最大的体会是记忆系统没有银弹但分层思路是绕不开的地基。无论你用 workbuddy 做本地迁移、用 hindsight 做经验提炼还是用向量库做长期召回背后的核心都是同一件事——别想用一个容器装下所有记忆也别指望模型自己记住。把该归短期处理的交给短期把该沉淀的交给长期Agent 才真正开始像有记忆的样子。如果你现在也被Agent 总失忆困扰不妨从最小的方案开始先记录用户偏好再做跨会话召回最后再考虑迁移和分享。记忆做到位了用户对 Agent 的信任感会完全不一样。后面我会继续更新这个系列如果你在实操中遇到有趣的问题欢迎带着场景来聊。