AI Agent记忆系统：从短期上下文到长期记忆的工程落地

你有没有遇到过这种情况一个AI助手用得挺顺手但你新建一个会话它又一脸茫然地问你“你是谁你之前让我改的需求是什么来着”那种感觉就像你和一个人聊得火热对方一转身就把你忘干净了。没有记忆的AI Agent就是这种状态。这是《走进AI Agent》系列的第三篇前两篇聊了Agent的整体运行逻辑和核心组件这一篇专门讲记忆。为什么重要因为记忆是Agent从“能聊”走向“能干活”的关键分水岭。这篇文章会从记忆的分类、存储形态、召回机制、生命周期管理到实际工具的案例分析把“让Agent记住你”这件事讲透。适合已经在折腾Agent开发、或者至少深度用过几个Agent产品的朋友不扯太玄的认知科学就是工程上怎么落地。1. 为什么说“会记”是Agent从玩具走向生产力的分水岭1.1 没有记忆的Agent工作流被切成无数个孤岛我先描述一个典型场景你让Agent帮你梳理项目的技术债清单聊了半小时它产出了一份很详细的重构计划。第二天你打开新会话想让它继续执行其中某个任务结果它完全不记得昨天聊过什么你得从头把背景再讲一遍。更难受的是讲完之后它理解的版本和你昨天的版本可能还有出入。这种体验短期看是“麻烦”长期看是“不可用”。真实生产环境里的Agent要处理的事情大多是跨会话、跨时间片的。写代码的人关心“这个模块我昨天改到哪了”做运营的人关心“我之前的投放节奏和文案风格是什么”做研究的人关心“上个月收集的资料放在哪些主题下面”。这些需求没有记忆就不可能满足。所以行业里已经形成一个共识记忆能力是Agent从demo走向生产系统的分水岭之一。这也是为什么各家都在做Memory、上下文持久化、会话管理本质上就是在补这门课。没有记忆的Agent干活永远从零开始有记忆的Agent才能积累经验、越用越顺手。1.2 记忆服务于两类真实需求个性化与连续性再往深了想Agent需要记忆其实是要回答两个问题。第一个问题是“你是谁”。你的偏好、习惯、背景信息属于个性化。比如你习惯用中文写commit message、你负责的项目是Java技术栈、你对某个术语有自己的定义方式。Agent记住这些后每次交互都会更“懂你”不用重复交代背景。第二个问题是“我们之前进行到哪了”。上次聊了什么、做过什么决定、有哪些待办这些属于连续性。对话历史、任务状态、代码改动记录都归这一类。跨会话的连续性一旦打通Agent就不只是单次问答工具而是一个能持续协作的“工作伙伴”。理解这两类需求之后技术方案的设计方向就清楚了个性化的东西往往需要结构化存储连续性的东西往往需要检索召回两者最终都会落到“短期记忆长期记忆”的双网络模型上。这也是这一篇的核心主线。2. 大脑怎么分工Agent就怎么设计短期记忆与长期记忆2.1 短期记忆上下文窗口里的“临时工位”先说短期记忆。在Agent的语境里短期记忆指的就是模型当前上下文窗口里能“看到”的内容。正在聊的这一轮对话、用户刚贴的报错日志、Agent上一步生成的中间结果都在这个窗口里。你可以把它想象成你在工位上随手摊开的资料干活的时候正好要用到的都在手边。但上下文窗口是有上限的。哪怕一些模型支持上百万token的窗口也不是无限大而且窗口越大推理延迟和成本涨得越厉害。所以短期记忆必须做管理不能“能塞多少塞多少”。我常用的管理策略是三步走滑动窗口保留最近N轮完整对话我一般取8到10轮保证当前任务上下文不丢。摘要压缩当对话超过一定长度调用模型把更早的对话压缩成结构化摘要继续留在上下文里当背景。比如“用户正在重构登录模块已确定用JWT替换Session还剩单元测试未写”。归档转移再早的、已经被摘要覆盖的完整对话转入长期记忆存储不再占用上下文窗口等需要时再按需召回。这里有个容易踩的坑摘要压缩这一步如果做得太频繁会显著增加token消耗做得太少上下文还是会爆。我调下来的经验是每5轮左右做一次增量摘要比较合适同时把上一次的摘要合并进来保证信息不丢。2.2 长期记忆模型之外的“外部硬盘”长期记忆就更好理解了——存在模型参数之外、能够持久化保存的信息。可以是本地的一个SQLite文件、一个JSON文件、一个向量数据库甚至一份Markdown笔记。模型本身不负责记住这些记忆系统负责。关键点在于长期记忆不是越多越好而是“按需召回”。你不可能每次对话都把整个记忆库塞进上下文那样既不经济效果也差。你得有一套机制判断“这次对话需要哪些历史记忆”把它精确捞出来再拼接进上下文。很多刚接触Agent记忆的人会犯一个错误把对话历史的每一句都存下来然后每次对话全部丢给模型。最后结果就是又贵又慢而且模型被一堆无关信息干扰回答质量反而下降。长期记忆的核心不是“存得多”而是“捞得准”。2.3 双网络协作的关键动作写入与回读短期记忆和长期记忆如何配合本质上就两个动作写和读。写发生在对话进行中。用户说了一句“以后邮件都抄送给财务组”Agent判断这是一个值得长期记住的信息异步地把它写入长期记忆库。这里要注意“异步”——写操作不能阻塞主对话链路否则用户会明显感觉到卡顿。读发生在新的对话开始时或对话过程中。用户抛出一个新问题Agent先判断“这事是否需要历史记忆”如果需要就发起检索把相关记忆取回来放到短期记忆窗口里相当于把“外部硬盘”的数据加载到“工位”上。这个“写什么、什么时候写、怎么写读什么、什么时候读、怎么读”就是Agent记忆系统的四个核心设计决策。接下来的内容基本都是在展开这四个问题。所谓的“双网络记忆模型”说的就是这套工作机制短期记忆管实时上下文长期记忆管持久知识两者协同Agent才具备完整的记忆能力。3. 记忆的存储形态向量、键值、叙事文本各管一摊3.1 事实型记忆用键值语义型记忆靠向量长期记忆具体存什么、用什么存直接决定了后续好不好用。根据我的实践经验可以把记忆分成三大类对应不同的存储形态。第一类是事实型记忆。比如“用户叫李工”“负责订单中台”“技术栈是Spring Boot”“邮箱是xxx”。这类信息结构化程度高、确定性强的直接存键值对或者一行一行的结构化记录。检索时用精确匹配或简单的条件过滤就行完全不需要向量检索。硬要上向量库反而画蛇添足。第二类是语义型记忆。比如用户某次讨论中表达过的观点、Agent之前处理过的一个需求背景。这类信息很难用字段描述清楚最好的方式是转成向量embedding存入向量数据库通过相似度检索来召回。比如用户问“上次那个限流方案是怎么定的”语义型记忆能把当时讨论的上下文捞出来。这三类记忆我自己是混着用的而系统里大量的对话内容、思考过程都沉淀成了“叙事文本型”记忆——带时间戳的事件流。这类存储用文档型数据库或者Markdown文件都行关键是要有结构化字段。3.2 复杂记忆要用结构化文档与知识图谱如果记忆之间存在关系比如“用户A参与了项目B项目B用到了中间件CC的记录在Git仓库D”纯向量检索会丢失关系信息。这时候就需要引入知识图谱或者在存储结构上把“实体”和“关系”显式记录下来。不过知识图谱属于进阶玩法维护成本相当高要定义实体、关系、属性还要解决实体对齐问题。对大部分中小型Agent项目来说一张带标签的结构化文档加一个向量索引已经能覆盖80%的用例。我建议先别一上来就上重型知识图谱等确认你的场景确实需要关系推理时再引入。3.3 存储选型背后的现实权衡举个我自己项目的选型参考表具体场景可以按需调整记忆类型推荐存储适合场景召回方式事实型短记录SQLite / 键值库用户偏好、配置项精确匹配、条件过滤语义型段落向量库Chroma、Qdrant、pgvector对话内容、需求背景向量相似度检索事件与过程时间线摘要开发记录、任务历史时间范围标签过滤实体关系知识图谱或关系表复杂多项目协作图遍历、关系查询选型的核心原则是能用简单存储解决的就别上复杂的免得系统后面变成维护负担。4. 召回是好记忆的关键从“存得下”到“记得起”4.1 一条完整的召回链路每一步都不能省长期记忆系统里最容易翻车的地方不是存储而是召回。很多项目存储做得很好但就是“想不起来”问题就出在召回链路不完整。一条标准的召回链路应该包含六步Query改写把用户当前这句话改写成更适合检索的表达。比如用户说“上次那个bug处理得怎么样了”改写引擎要判断这是查询“bug处理”相关事件可能补充关键词“bug”“修复”“历史”提高检索命中率。向量化把改写后的query转成embedding。向量检索在记忆库里按相似度取top-k我一般取3到5条。重排序用时间衰减、类型权重、关键词命中等因素对top-k重新打分把最该出现的记忆排到前面。阈值过滤低于相似度阈值的记忆直接丢弃宁缺毋滥。注入上下文把最终选中的记忆整理成“记忆卡片”拼进system prompt或首轮对话里。4.2 并非所有对话都需要召回记忆召回不是每次对话都要做的。如果用户问的是“11等于几”没必要翻半天历史。我的做法是用一个轻量规则或小模型先做意图判断这个问题是否涉及历史信息、用户偏好或上下文连续性。只有判断为“需要”才发起召回否则直接走常规对话。这一步能省掉大量不必要的延迟和成本尤其在并发量上来之后效果非常明显。我会把意图判断做成一个可配置的开关不同场景可以灵活调整召回策略。4.3 召回翻车的三种典型姿势与对策我见过太多人栽在召回上总结下来三种姿势最典型。第一种不设相似度阈值。结果是什么都召回各种不相关的历史记忆混在上下文里Agent被干扰得胡说八道。阈值一定要设并且要根据实际效果反复调。不同embedding模型的相似度分布不一样同一个模型在不同数据分布下也不一样最好先跑一批样本数据观察分布再定。第二种只按向量相似度排序忽略时间。用户上周喜欢A方案这周已经定稿B方案了向量检索却把A方案的记忆捞出来产生冲突。重排序时一定要把时间衰减算进去给新记忆更高的权重。第三种把记忆注入得太多。一口气塞10条记忆进上下文主任务被淹没。我实测下来注入的记忆卡片控制在3到5条、每条一到两句话是最稳的既能提供背景又不喧宾夺主。5. 记忆的生命周期写入、更新、遗忘三件事缺一不可5.1 有选择地写入记忆库才不会变成垃圾场记忆写入不是把每一句话都存档那样很快会变成垃圾场。要有选择地写。我总结了三类值得写入的时机用户显式表达偏好“以后都用表格给我汇报”“commit message记得用中文”。对话中出现了稳定的事实信息用户提到自己的技术栈、岗位角色、项目背景。关键任务完成后的状态Agent完成了一次重构、一次部署把结论和关键文件记录下来。写入时建议异步执行别让记忆存储拖慢主对话。我见过有些产品让用户明显感受到“回答卡了一下”就是因为在同步路径上做了太多存储操作。写操作放到后台任务里用户几乎没有感知但记忆已经悄悄存好了。5.2 冲突更新与版本控制别让旧记忆误导Agent用户是会变的。今天说“用Java写”明天可能就换Go了。记忆更新要考虑冲突新记录和旧记录矛盾时以哪个为准我的做法是给每条记忆加时间戳和来源会话ID。默认情况下同一个“记忆键”下新记录覆盖旧记录但有一个例外——如果旧记录在多个会话里被反复引用说明它是一个相对稳定的上下文事实这时候不直接覆盖而是标记为“待确认”在合适的时机让用户确认是否真的变了。举个例子用户在好几天里都说“我不喜欢用子查询”某天突然说“子查询其实也行”。如果直接覆盖旧记忆后面Agent可能就往“用户接受子查询”这个方向走了但用户可能只是那天心情好随口一说。加一步待确认能让记忆更新更稳。5.3 遗忘机制主动丢弃与被动衰减最后是记忆系统里最容易被忽略的一环遗忘。记忆如果只增不减时间一长就会积攒大量过时信息。检索的时候“干扰项”越来越多质量自然下降。我实际维护的Agent记忆库里目前引入了三种遗忘策略TTL过期临时记忆设生命周期比如“用户正在处理的任务上下文”只要7天过期自动清理。访问频率衰减长期没有被检索到的记忆权重越来越低最后被归档。这一步很关键能让高频使用的核心记忆保持活跃。定期整理跑一个总结任务把零散记忆压缩成更高层的结构化记忆。比如把过去两周关于“登录模块重构”的20条琐碎记录压缩成一条“登录模块重构已完成使用JWT方案遗留单测问题”的总记录再删除原始细节。6. 两个真实案例opencode如何召回代码修改情况Workbuddy怎么做本地记忆迁移6.1 opencode让代码修改情况跨会话可回溯opencode是我最近在用的终端AI编码助手围绕“代码修改情况”的记忆召回业界有一套很实用的思路。它的持久化关键是“项目级上下文会话续接”。每次进入项目目录Agent会加载项目根目录的说明文件里面可以写项目背景、当前进度、代码约定。同时它会读取历史会话记录相当于把“上次改到哪了”作为背景重新加载进上下文。我更推荐的实践是维护一个“项目日志”文件每次Agent改完代码让它顺手把“改了哪些文件、为什么改、有没有遗留问题”追加进去。下次新会话开始时通过一条指令让它先读日志再继续干活。这本质上就是一个最简单的代码修改记忆召回方案。更硬核的做法是社区里一些人在做的把每次代码变更的diff和message向量化存起来用户问“上次改了登录模块什么逻辑”时直接在提交历史里检索。这种方式能做到“不用翻日志直接问就能召回”但实现成本略高适合对代码记忆要求严苛的项目。6.2 Workbuddy对话历史记录与本地记忆迁移Workbuddy这类AI助手解决的是另一个层面的问题Agent记住了“我”但它换台设备、换个浏览器还认不认得我Workbuddy的思路是“历史对话记录本地记忆迁移”。对话历史存在本地记忆库可以导出成文件换设备时导入新会话就能继续沿用之前记录的偏好和上下文。这个体验对重度用户来说很重要——没有人希望换了个浏览器AI又把自己当陌生人。从工程角度看本地记忆迁移的核心就是记忆序列化加导入导出。但有个设计点很值得借鉴迁移时要带“记忆版本”概念。不同版本的记忆库结构可能不一样导入时要兼容处理否则旧记忆可能变成乱码或者直接读不出来。我自己的方案是在导出文件里加一个version字段导入时先校验版本再做字段映射。6.3 从这两个案例能直接抄走的工程思路我复盘了一下这两个案例有几条经验是通用的项目级说明书加会话续接是目前成本最低、效果最稳的记忆召回方式任何Agent项目都可以先做这一层。主动维护日志或变更记录文件让Agent在任务完成后更新比纯向量检索更可控、更持久。记忆库要支持导入导出和版本化这是“让Agent记住你”跨设备、跨环境的基础保障。数据源接入优先选git、工单、文档这类天然结构化的数据因为它们本身就有明确的时间线和实体关系召回质量比自由文本高得多。7. Agent记忆的工程落地选型、成本、避坑清单7.1 技术选型从轻到重的渐进路线别一步到位不同规模的Agent项目记忆方案可以差出好几个数量级。我建议按进阶路线走实验阶段一个JSON文件或者SQLite就够。字段就时间戳、类型、内容、标签写一个函数按需捞取。小规模产品引入向量库。本地用Chroma或Qdrant数据量不大没必要上分布式方案。中大规模产品向量库加关系库加消息队列写入和读取解耦异步写入加缓存层。复杂场景再加知识图谱、多租户隔离、记忆审计。我见过不少团队栽在“记忆系统比Agent本身还复杂”上。一开始就上分布式向量库、消息队列、知识图谱全套结果维护成本爆炸。起步阶段SQLite加一个embedding接口已经能做出很不错的记忆效果了。7.2 成本与延迟记忆不是越多越聪明记忆系统的成本大头不是存储而是召回时的模型调用和重排序计算。每次对话都召回再让大模型重新排序成本会很可观。我常用的优化思路如下缓存把高频记忆定期预取到本地缓存减少重复查询。降级策略简单规则过滤能解决的别上大模型。控制注入数量只注入当前任务真正需要的3到5条记忆。异步写入记忆写入放后台不阻塞主响应链路。延迟上还有一个细节向量检索本身很快但embedding生成有网络开销。如果query是短文本有时候直接用词法匹配反而更快。一个很小的优化策略是在向量检索之前先做一次关键词精确匹配命中就直接返回命中不了再走向量检索这样大部分常见问题可以秒回。7.3 隐私与数据边界必须先做好聊到“让Agent记住你”隐私和数据边界一定绕不开。我的建议是默认本地存储记忆数据除非用户主动开启同步否则不要上传对敏感信息账号、密码、个人身份信息要做脱敏处理导出和删除记忆的功能必须做到一键可用。现在的用户对隐私越来越敏感体验再好隐私上不过关后面翻车更难看。另外“记忆的边界”需要在产品层面设计清楚。Agent应该记住什么、不该记住什么要能让用户看见、能修改、能删除。这不只是合规要求更是建立用户信任的基础。我在自己的项目里会定期导出记忆库人工检查一遍哪些信息不该留及时清理。这个习惯值得所有人学。7.4 下一阶段的探索主动记忆记忆沉淀完成之后下一步可以做“主动记忆”Agent不只是被动等用户提问才去检索而是在合适的时机主动把相关历史知识推送出来。比如你打开一个好久没碰的项目Agent主动提醒你“上次你改到登录模块的鉴权逻辑有个遗留的TODO还没处理”。这种体验才算真正体会到‘Agent记住你’的意义。我最近在做的实验是给Agent加一个“记忆观察者”角色它在后台持续监控当前对话和项目状态一旦发现“值得提醒”的旧记忆就主动插入一条提示。效果整体上是惊喜的但触发频率和插入时机都还在调等攒够更多案例之后我会继续把这个方向写成一期内容。