深夜一点半我盯着终端里那个Agent输出的代码血压有点上头。头天晚上我花半小时跟它解释这个项目的鉴权逻辑告诉它“统一走JWT Bearer不要再往Header里塞自定义token”它当时回答得明明白白。结果第二天重启进程我问它新接口怎么写鉴权它一脸无辜地给我套了个旧格式还反问我要不要加签名。那一刻我意识到大模型应用现在早过了“能不能跑通”的阶段真正卡着所有开发者的是另一件事——它记不住你。这个系列写到这里前两篇聊过Agent的搭建方式、运行逻辑这篇专门解决“金鱼脑”问题主题就是AI Agent记忆。我会把记忆分层、历史对话留档、本地迁移、向量检索还有最近在代码场景里做的记忆召回实测连同踩过的坑一起摆出来给正在搞Agent开发的朋友一条能直接抄的路径。1. 重新理解Agent记忆三层结构与“便签纸/档案柜”模型1.1 会话记忆一刷新就消失的那层大部分人对Agent记忆的第一印象就是对话上下文。你问它“我上句话说了什么”它能答上来是因为这些内容还躺在上下文窗口里。目前主流模型的上下文窗口动辄十万、百万token级别听起来很大但对话稍微长一点就会触顶。我实测过一个重度使用的开发Agent光是文件内容和历史问答就能在半小时内吃掉大半窗口。窗口满了怎么办现成的方案无非两种滑动窗口和摘要压缩。滑动窗口简单粗暴只保留最近N轮代价是最早的信息直接蒸发摘要压缩则是在触发上限之前把旧对话喂给模型生成一段浓缩总结再塞回窗口顶部。后者明显更聪明但摘要本身就是有损压缩细节丢了就是丢了。1.2 长期记忆重启后依然存在的档案层会话记忆最大的问题是进程一重启、会话一清空一切归零。想让Agent真正“记住你”必须把信息落到外部存储里。这里的存储可以是SQLite、JSON文件也可以是向量数据库关键看你的使用场景和数据量。我见过很多刚上手的朋友第一反应是把所有历史消息全部灌进一个向量库结果检索出来的内容一团糟最后得出“向量检索没用”的结论。其实长期记忆的关键不在于存储工具多高级而在于你写进去的是什么结构的信息。我现在的做法是每条记忆都包含时间、类型、摘要、原文触发的上下文标签类似档案柜里的一个独立卷宗而不是把聊天记录像废纸一样整捆塞进去。1.3 便签纸与档案柜我对双网络记忆模型的理解最近“双网络记忆模型”这个词被讨论得很多听上去很玄其实用生活化方式理解非常简单人脑记东西靠的是“便签纸”和“档案柜”两套系统并行。便签纸对应短期记忆特点是快、近、乱适合回答“我最近在做什么”档案柜对应长期记忆特点是有序、全、慢适合回答“我以前有没有处理过类似的事”。Agent的记忆架构也应该是这个逻辑一套短期索引按时间倒排存放最近活跃的信息召回时速度快保证对话的连贯性一套长期档案按向量相似度做语义检索召回时精度高让Agent能在若干天甚至几个月后想起一条关键约定。两套索引可以指向同一条记忆但服务于不同的召回场景这就是“双网络”的直观含义。后面第三章我会给出这套架构的具体实现骨架这里先把这个模型在脑子里立住。维度会话记忆便签纸长期记忆档案柜存放位置模型上下文窗口本地文件 / 向量库生命周期会话结束即失效跨会话、跨重启召回方式按时间顺序保留或摘要按语义相似度检索典型容量几万到几十万token可无限扩展典型问题上下文膨胀、信息蒸发噪声多、检索不准2. 先做留档与迁移把历史对话变成本地可复用的记忆资产2.1 为什么“本地留档”是记忆系统最低成本的起点很多朋友一上来就研究向量数据库、RAG、MCP工具搞得很复杂结果连“历史对话记录”都没留存。我个人的经验是给Agent做记忆第一步不是上重型武器而是先解决“数据从哪来”的问题。不管是哪个Agent工具只要你有过几轮像样的对话那些原始记录就是最好的记忆资产。本地留档的好处很直接一是数据完全在自己手里隐私可控二是格式自由今天用不上明天想接向量库随时能导三是迁移成本低换工具、换电脑文件拷走就行。我看到不少人在问WorkBuddy历史对话记录、本地记忆迁移这类问题本质上就是在找这条路径。2.2 历史对话记录迁移的标准姿势不管你是想把WorkBuddy的聊天记录导出来还是想从其他Agent工具迁移思路是同一套先找数据源再统一格式最后导入新环境。数据源一般在应用的数据目录里常见格式是JSON、SQLite或Markdown。拿到原始数据之后别急着灌进新系统先做三步清洗去重多轮对话里经常有重复表达只保留语义上第一次出现的完整版本后面复述的内容合并掉。打标签给每段对话标上主题、类型、时间。比如“主题鉴权方案类型技术决策时间2026-01-10”。标签是后面检索时的路标没有标签的记忆是一堆死数据。写摘要用模型把长对话压缩成2-3句话保留结论、偏好、关键参数原文作为附件挂在后面。清洗完之后再按统一格式落盘。我习惯的格式是JSON Lines每行一条记忆方便程序逐行读取。导入新Agent时直接把这份文件挂到知识库或灌进向量索引迁移就完成了。整个过程半小时左右收益是换工具后所有“约定”都还在不用重新教一遍。2.3 导入后怎么做索引避免变成一堆死文件这是很多人忽略的一步。文件导进去了但没有索引Agent根本不知道里面有什么。我推荐给记忆库配一个最小的索引逻辑一个index.json记录每个主题对应哪些记忆条目、最近更新时间、关联的文件路径每次写入新记忆时同步更新索引Agent启动时先读索引按需加载相关条目而不是全量扫文件。这样一来工作目录永远是干净的记忆库再大也不会拖慢启动。索引文件本身也可以做成记忆的入口——我先看一眼索引就知道这个项目里有哪些决策、哪些偏好、哪些还没完成的坑。3. 向量索引与双网络检索长期记忆的工程化落地3.1 数据准备记忆条目的结构化设计给Agent做长期记忆最忌讳的是拿原始聊天记录直接embedding。我踩过这个坑启动时灌了上万行聊天文本检索出来的top5全是车轱辘话真正的关键决策沉在下面死活捞不上来。后来我改成“先结构化再向量化”的思路。一条合格记忆长这样{ id: mem_8f2a4c, timestamp: 2026-01-12T20:15:0008:00, type: code_modification, summary: 将鉴权中间件从自定义Header传参改为JWT Bearer老请求不再放行, content: 详细描述、diff摘要、相关文件列表, tags: [auth, jwt, middleware, breaking_change], trigger_context: 当讨论到接口鉴权、新接口认证方式时优先召回此条 }这里面最关键的字段是trigger_context它是我后来加上的效果立竿见影。这段文字告诉召回逻辑“这条记忆在什么情况下应该被想起”相当于给档案柜贴了一张很明确的使用说明。检索时我不仅拿用户问题去匹配summary和content还拿它去匹配trigger_context命中率会高很多。后面结尾我还会具体说到这个小技巧这里先记住这个字段很重要。3.2 双通道检索的代码骨架所谓“双网络”落到代码上就是两条召回路径并行。我自己的实现非常朴素核心就一个类class MemoryManager: def __init__(self, short_index, long_index): self.short_index short_index # 短期索引按时间倒排的最近N条 self.long_index long_index # 长期索引向量检索 def remember(self, memory: dict): # 先写短期索引保证最近内容可被快速召回 self.short_index.add(memory) # 同步写入长期档案异步做embedding与存储 self.long_index.add(memory) def recall(self, query: str, top_k: int 5): short_hits self.short_index.recent(top_k) long_hits self.long_index.semantic_search(query, top_k) # 双通道结果做合并、去重、按时间与相似度加权排序 return self._merge(short_hits, long_hits)短期索引不需要什么复杂结构就是一个内存里的环形列表容量控制在最近20条左右长期索引可以挂在SQLite加向量字段也可以用Chroma或FAISS这类专门的向量库。实测下来这种双通道设计最大的好处是即使用户问得很含糊短期索引也能靠“最近说过”兜底而一旦问题明确指向过去某个具体决策长期索引的语义检索马上就能顶上。两条腿走路比单走任意一条都稳。3.3 召回参数与质量调优top_k、阈值和时间衰减代码写完之后真正的调优才刚开始。我从实际测试里总结出几个值得反复调的参数top_k我一般取3到7。太少容易漏关键信息太多噪声盖过信号。对话场景偏3文档检索偏5到7。相似度阈值不同embedding模型的分数区间不一样不能用一个固定值。我的做法是先跑20条已知应召回的问题统计命中分数分布再定阈值。大致在0.65到0.75之间浮动具体以你的模型实测为准。时间衰减长期记忆不代表所有信息都同等重要。昨天的改动和半年前的约定权重应该不一样。我常用score * 0.95^days_ago做简单衰减让近期记忆更容易被召回但不至于把老记忆完全埋掉。去重合并同一个主题下可能存了多条相似记忆召回时只保留摘要最完整的一条其余折叠成“参考来源”。调优没有一个万能配方建议你建一个小的评测集——20个问题带上标准答案每改一次参数就跑一遍看召回命中率的变化。我自己的命中率从最初的不足一半现在能稳定在八成左右就是这么一版一版试出来的。4. 编程Agent实战让Agent记住“你改过哪些代码”4.1 代码任务的记忆比普通对话记忆更“结构化”做通用对话Agent时记忆可以模糊一点但做编程Agent尤其是处理实际代码库修改时记忆必须是结构化的。原因很简单代码本身有文件路径、函数名、git提交这些天然是精确索引。我看社区里经常吐槽有些编码工具“没有记忆功能码”其实不是模型不行是缺少一层“把代码变更变成记忆”的中间层。你在对话里说了“改好了鉴权”Agent如果只记住这句话下次启动它并不知道你改了哪个文件、怎么改的。正确的做法是监听文件变化生成diff摘要再把摘要写进记忆库和文件路径建立关联。4.2 我的“修改日志记忆”实现思路我现在的编码Agent工作流是这么设计的分享出来供参考每次Agent修改文件后自动执行一条“记录变更”动作解析diff生成一句话摘要例如“修改了auth.py新增verify_jwt_token函数替换原Header校验逻辑”。将摘要连同文件路径、修改时间、会话上下文写入记忆库type标记为code_modification。下次启动会话时Agent先检查当前工作目录涉及哪些文件再召回这些文件的最近3条修改记录拼成一个“已知变更”块放进System Prompt。用户问“上次改了什么”时Agent先做精确文件匹配再做语义召回两边结果合起来回答。这套方案最核心的收益是Agent不再凭“印象”回答代码问题而是基于一条一条可追溯的修改日志。跟人协作时“你上次动过哪里”是最容易遗忘的事情之一现在Agent能准确答出来整个协作体验完全不一样。我实测了一段时间以前每次重启都要重新解释一遍项目上下文现在启动即恢复效率提升非常明显。4.3 跳出代码当Agent需要理解一份draw.io图纸同样一套“结构化记忆”逻辑也能迁移到其他工具场景。最近有朋友问draw.io的图纸能不能对接Agent处理比如让Agent记住图纸上某个流程的走向。先搞清楚一件事draw.io架构文件本质是一份XML里面用mxCell节点描述矩形、连线、文字。Agent要“记住”图纸内容第一步不是做图像识别而是把XML解析成结构化描述——哪些节点是步骤、哪些连线是顺序、文字标签是什么。解析完之后生成一段描述文本或一张关系表再写进记忆库。以后聊到相关流程Agent就能从记忆里调出图纸的逻辑。这里的关键是Agent本身不需要直接支持draw.io格式只需要一个工具或脚本把draw.io转成结构化的“记忆语言”。不管是接Hermes这类Agent框架还是自己写脚本思路都一样。我给一个极简的XML解析方向# 伪代码演示从.drawio提取结构化信息 import xml.etree.ElementTree as ET root ET.parse(open(flow.drawio, encodingutf-8)) for cell in root.findall(.//mxCell): node_id cell.get(id) vertex cell.get(vertex) text cell.find(mxGraphModel/root/mxCell/value) # 把每个节点的 id、位置、文字收集成结构化条目拿到的节点文字和连线关系再用一次大模型调用整理成描述文本存入记忆库即可。整套链路不复杂关键是一次转换、永久可复用。5. 记忆系统排障实录我踩过的四个坑与排查链路5.1 第一坑记忆污染存得越多乱得越快这是我最早踩的坑也是最容易反复出现的。一开始我把所有历史对话都无脑写入记忆库结果检索出来的内容一半是“好的我来帮你看看”之类的客套话另一半是早该删除的过期信息。真实有用的内容被噪声淹没Agent的回答质量反而比没加记忆时更差。后来我加了一个“写入过滤器”每条记忆在落库前先过一遍规则是事实型信息明确决策、偏好、参数、路径留下。是过程性寒暄或临时感叹删除。是过期状态已经废弃的方案、已完成的临时需求归档并标记失效。过滤器可以用规则写死也可以让模型判断我建议先用规则把明显废话挡掉再让模型做更精细的分类效果最稳。记忆系统最怕的不是“忘”而是“记了一堆不该记的”。5.2 第二坑检索不到有效记忆问题多半出在切块和embedding有段时间我明明存了很多关键决策但Agent就是答不上来。排查了半天发现根因不在召回逻辑而在数据准备我把整段长对话直接embedding一个段落里混着三个主题向量被互相稀释无论怎么算相似度都是个模糊的平均值检索自然不精准。解决办法是切块一条记忆最好只表达一个主题长对话拆成多条短记忆每条再配独立摘要。另一个坑是embedding模型选型处理中文内容却用了以英文为主的模型效果可想而知。现在中文场景我习惯用对中文支持较好的开源模型或者直接调大模型的embedding接口差别非常明显。5.3 第三坑上下文爆炸把全部记忆塞回去是最错误的做法有些朋友为了让Agent“记住更多”启动时把整个记忆库全量塞进System Prompt结果token爆炸单次请求又慢又贵而且模型注意力被大量历史信息稀释反而处理不好当前任务。这里要理解一个概念模型的有效注意力在小窗口范围内最强给太多旧信息它不会“主动挑重点”只会“全都看一遍然后平均用力”。我的经验是召回结果最多挑5条每条内容压缩到200到300字以内再注入提示词如果想保留更完整的背景用“记忆编号一句话摘要”代替原文等用户明确问到时再展开。记住给Agent的记忆不是越多越好而是刚好够用最好。5.4 第四坑隐私与格式本地优先为什么值得坚持最后这个坑不是技术问题而是设计取舍。很多Agent记忆方案默认走云端向量库方便是方便但你会把项目的核心决策、代码结构、甚至商业逻辑全交到第三方手里。我的建议是除非必要记忆尽量留在本地。本地JSON、SQLite足够支撑个人项目和中小团队即使需要云端检索也只提交摘要和标引字段敏感原文留在本地。另外记忆格式一定要选可迁移的开放格式别绑定某个工具专属格式否则下次换工具又是一场灾难。我在设计记忆条目时就一直坚持用通用JSON加Markdown描述以此为边界所有工具都只负责读写这套格式。写在最后我现在一直用的最小记忆配方经过这么多轮折腾我自己现在跑Agent用的其实是个极简组合一个本地文件夹放记忆条目、一张index.json做索引、一个带双通道检索的MemoryManager脚本。规模和复杂程度都不高但已经足够覆盖我日常开发和写作的大部分场景。最后分享一个对召回命中率提升最明显的小技巧写记忆条目时顺手在trigger_context字段里写清楚“什么时候需要这条记忆”。这相当于给未来的Agent递了一张便条告诉它这条档案在什么场景下打开。在我自己的实测里加上这一个字段之后相关问题的召回命中率基本稳定在八成以上。如果你正在给Agent做记忆强烈建议先从这一条做起成本几乎为零效果立竿见影。 
长河君 · 2026/9/11 16:14:48 · 阅读 1.2k AI Agent记忆系统实战：从会话上下文到向量检索的完整方案
深夜一点半我盯着终端里那个Agent输出的代码血压有点上头。头天晚上我花半小时跟它解释这个项目的鉴权逻辑告诉它“统一走JWT Bearer不要再往Header里塞自定义token”它当时回答得明明白白。结果第二天重启进程我问它新接口怎么写鉴权它一脸无辜地给我套了个旧格式还反问我要不要加签名。那一刻我意识到大模型应用现在早过了“能不能跑通”的阶段真正卡着所有开发者的是另一件事——它记不住你。这个系列写到这里前两篇聊过Agent的搭建方式、运行逻辑这篇专门解决“金鱼脑”问题主题就是AI Agent记忆。我会把记忆分层、历史对话留档、本地迁移、向量检索还有最近在代码场景里做的记忆召回实测连同踩过的坑一起摆出来给正在搞Agent开发的朋友一条能直接抄的路径。1. 重新理解Agent记忆三层结构与“便签纸/档案柜”模型1.1 会话记忆一刷新就消失的那层大部分人对Agent记忆的第一印象就是对话上下文。你问它“我上句话说了什么”它能答上来是因为这些内容还躺在上下文窗口里。目前主流模型的上下文窗口动辄十万、百万token级别听起来很大但对话稍微长一点就会触顶。我实测过一个重度使用的开发Agent光是文件内容和历史问答就能在半小时内吃掉大半窗口。窗口满了怎么办现成的方案无非两种滑动窗口和摘要压缩。滑动窗口简单粗暴只保留最近N轮代价是最早的信息直接蒸发摘要压缩则是在触发上限之前把旧对话喂给模型生成一段浓缩总结再塞回窗口顶部。后者明显更聪明但摘要本身就是有损压缩细节丢了就是丢了。1.2 长期记忆重启后依然存在的档案层会话记忆最大的问题是进程一重启、会话一清空一切归零。想让Agent真正“记住你”必须把信息落到外部存储里。这里的存储可以是SQLite、JSON文件也可以是向量数据库关键看你的使用场景和数据量。我见过很多刚上手的朋友第一反应是把所有历史消息全部灌进一个向量库结果检索出来的内容一团糟最后得出“向量检索没用”的结论。其实长期记忆的关键不在于存储工具多高级而在于你写进去的是什么结构的信息。我现在的做法是每条记忆都包含时间、类型、摘要、原文触发的上下文标签类似档案柜里的一个独立卷宗而不是把聊天记录像废纸一样整捆塞进去。1.3 便签纸与档案柜我对双网络记忆模型的理解最近“双网络记忆模型”这个词被讨论得很多听上去很玄其实用生活化方式理解非常简单人脑记东西靠的是“便签纸”和“档案柜”两套系统并行。便签纸对应短期记忆特点是快、近、乱适合回答“我最近在做什么”档案柜对应长期记忆特点是有序、全、慢适合回答“我以前有没有处理过类似的事”。Agent的记忆架构也应该是这个逻辑一套短期索引按时间倒排存放最近活跃的信息召回时速度快保证对话的连贯性一套长期档案按向量相似度做语义检索召回时精度高让Agent能在若干天甚至几个月后想起一条关键约定。两套索引可以指向同一条记忆但服务于不同的召回场景这就是“双网络”的直观含义。后面第三章我会给出这套架构的具体实现骨架这里先把这个模型在脑子里立住。维度会话记忆便签纸长期记忆档案柜存放位置模型上下文窗口本地文件 / 向量库生命周期会话结束即失效跨会话、跨重启召回方式按时间顺序保留或摘要按语义相似度检索典型容量几万到几十万token可无限扩展典型问题上下文膨胀、信息蒸发噪声多、检索不准2. 先做留档与迁移把历史对话变成本地可复用的记忆资产2.1 为什么“本地留档”是记忆系统最低成本的起点很多朋友一上来就研究向量数据库、RAG、MCP工具搞得很复杂结果连“历史对话记录”都没留存。我个人的经验是给Agent做记忆第一步不是上重型武器而是先解决“数据从哪来”的问题。不管是哪个Agent工具只要你有过几轮像样的对话那些原始记录就是最好的记忆资产。本地留档的好处很直接一是数据完全在自己手里隐私可控二是格式自由今天用不上明天想接向量库随时能导三是迁移成本低换工具、换电脑文件拷走就行。我看到不少人在问WorkBuddy历史对话记录、本地记忆迁移这类问题本质上就是在找这条路径。2.2 历史对话记录迁移的标准姿势不管你是想把WorkBuddy的聊天记录导出来还是想从其他Agent工具迁移思路是同一套先找数据源再统一格式最后导入新环境。数据源一般在应用的数据目录里常见格式是JSON、SQLite或Markdown。拿到原始数据之后别急着灌进新系统先做三步清洗去重多轮对话里经常有重复表达只保留语义上第一次出现的完整版本后面复述的内容合并掉。打标签给每段对话标上主题、类型、时间。比如“主题鉴权方案类型技术决策时间2026-01-10”。标签是后面检索时的路标没有标签的记忆是一堆死数据。写摘要用模型把长对话压缩成2-3句话保留结论、偏好、关键参数原文作为附件挂在后面。清洗完之后再按统一格式落盘。我习惯的格式是JSON Lines每行一条记忆方便程序逐行读取。导入新Agent时直接把这份文件挂到知识库或灌进向量索引迁移就完成了。整个过程半小时左右收益是换工具后所有“约定”都还在不用重新教一遍。2.3 导入后怎么做索引避免变成一堆死文件这是很多人忽略的一步。文件导进去了但没有索引Agent根本不知道里面有什么。我推荐给记忆库配一个最小的索引逻辑一个index.json记录每个主题对应哪些记忆条目、最近更新时间、关联的文件路径每次写入新记忆时同步更新索引Agent启动时先读索引按需加载相关条目而不是全量扫文件。这样一来工作目录永远是干净的记忆库再大也不会拖慢启动。索引文件本身也可以做成记忆的入口——我先看一眼索引就知道这个项目里有哪些决策、哪些偏好、哪些还没完成的坑。3. 向量索引与双网络检索长期记忆的工程化落地3.1 数据准备记忆条目的结构化设计给Agent做长期记忆最忌讳的是拿原始聊天记录直接embedding。我踩过这个坑启动时灌了上万行聊天文本检索出来的top5全是车轱辘话真正的关键决策沉在下面死活捞不上来。后来我改成“先结构化再向量化”的思路。一条合格记忆长这样{ id: mem_8f2a4c, timestamp: 2026-01-12T20:15:0008:00, type: code_modification, summary: 将鉴权中间件从自定义Header传参改为JWT Bearer老请求不再放行, content: 详细描述、diff摘要、相关文件列表, tags: [auth, jwt, middleware, breaking_change], trigger_context: 当讨论到接口鉴权、新接口认证方式时优先召回此条 }这里面最关键的字段是trigger_context它是我后来加上的效果立竿见影。这段文字告诉召回逻辑“这条记忆在什么情况下应该被想起”相当于给档案柜贴了一张很明确的使用说明。检索时我不仅拿用户问题去匹配summary和content还拿它去匹配trigger_context命中率会高很多。后面结尾我还会具体说到这个小技巧这里先记住这个字段很重要。3.2 双通道检索的代码骨架所谓“双网络”落到代码上就是两条召回路径并行。我自己的实现非常朴素核心就一个类class MemoryManager: def __init__(self, short_index, long_index): self.short_index short_index # 短期索引按时间倒排的最近N条 self.long_index long_index # 长期索引向量检索 def remember(self, memory: dict): # 先写短期索引保证最近内容可被快速召回 self.short_index.add(memory) # 同步写入长期档案异步做embedding与存储 self.long_index.add(memory) def recall(self, query: str, top_k: int 5): short_hits self.short_index.recent(top_k) long_hits self.long_index.semantic_search(query, top_k) # 双通道结果做合并、去重、按时间与相似度加权排序 return self._merge(short_hits, long_hits)短期索引不需要什么复杂结构就是一个内存里的环形列表容量控制在最近20条左右长期索引可以挂在SQLite加向量字段也可以用Chroma或FAISS这类专门的向量库。实测下来这种双通道设计最大的好处是即使用户问得很含糊短期索引也能靠“最近说过”兜底而一旦问题明确指向过去某个具体决策长期索引的语义检索马上就能顶上。两条腿走路比单走任意一条都稳。3.3 召回参数与质量调优top_k、阈值和时间衰减代码写完之后真正的调优才刚开始。我从实际测试里总结出几个值得反复调的参数top_k我一般取3到7。太少容易漏关键信息太多噪声盖过信号。对话场景偏3文档检索偏5到7。相似度阈值不同embedding模型的分数区间不一样不能用一个固定值。我的做法是先跑20条已知应召回的问题统计命中分数分布再定阈值。大致在0.65到0.75之间浮动具体以你的模型实测为准。时间衰减长期记忆不代表所有信息都同等重要。昨天的改动和半年前的约定权重应该不一样。我常用score * 0.95^days_ago做简单衰减让近期记忆更容易被召回但不至于把老记忆完全埋掉。去重合并同一个主题下可能存了多条相似记忆召回时只保留摘要最完整的一条其余折叠成“参考来源”。调优没有一个万能配方建议你建一个小的评测集——20个问题带上标准答案每改一次参数就跑一遍看召回命中率的变化。我自己的命中率从最初的不足一半现在能稳定在八成左右就是这么一版一版试出来的。4. 编程Agent实战让Agent记住“你改过哪些代码”4.1 代码任务的记忆比普通对话记忆更“结构化”做通用对话Agent时记忆可以模糊一点但做编程Agent尤其是处理实际代码库修改时记忆必须是结构化的。原因很简单代码本身有文件路径、函数名、git提交这些天然是精确索引。我看社区里经常吐槽有些编码工具“没有记忆功能码”其实不是模型不行是缺少一层“把代码变更变成记忆”的中间层。你在对话里说了“改好了鉴权”Agent如果只记住这句话下次启动它并不知道你改了哪个文件、怎么改的。正确的做法是监听文件变化生成diff摘要再把摘要写进记忆库和文件路径建立关联。4.2 我的“修改日志记忆”实现思路我现在的编码Agent工作流是这么设计的分享出来供参考每次Agent修改文件后自动执行一条“记录变更”动作解析diff生成一句话摘要例如“修改了auth.py新增verify_jwt_token函数替换原Header校验逻辑”。将摘要连同文件路径、修改时间、会话上下文写入记忆库type标记为code_modification。下次启动会话时Agent先检查当前工作目录涉及哪些文件再召回这些文件的最近3条修改记录拼成一个“已知变更”块放进System Prompt。用户问“上次改了什么”时Agent先做精确文件匹配再做语义召回两边结果合起来回答。这套方案最核心的收益是Agent不再凭“印象”回答代码问题而是基于一条一条可追溯的修改日志。跟人协作时“你上次动过哪里”是最容易遗忘的事情之一现在Agent能准确答出来整个协作体验完全不一样。我实测了一段时间以前每次重启都要重新解释一遍项目上下文现在启动即恢复效率提升非常明显。4.3 跳出代码当Agent需要理解一份draw.io图纸同样一套“结构化记忆”逻辑也能迁移到其他工具场景。最近有朋友问draw.io的图纸能不能对接Agent处理比如让Agent记住图纸上某个流程的走向。先搞清楚一件事draw.io架构文件本质是一份XML里面用mxCell节点描述矩形、连线、文字。Agent要“记住”图纸内容第一步不是做图像识别而是把XML解析成结构化描述——哪些节点是步骤、哪些连线是顺序、文字标签是什么。解析完之后生成一段描述文本或一张关系表再写进记忆库。以后聊到相关流程Agent就能从记忆里调出图纸的逻辑。这里的关键是Agent本身不需要直接支持draw.io格式只需要一个工具或脚本把draw.io转成结构化的“记忆语言”。不管是接Hermes这类Agent框架还是自己写脚本思路都一样。我给一个极简的XML解析方向# 伪代码演示从.drawio提取结构化信息 import xml.etree.ElementTree as ET root ET.parse(open(flow.drawio, encodingutf-8)) for cell in root.findall(.//mxCell): node_id cell.get(id) vertex cell.get(vertex) text cell.find(mxGraphModel/root/mxCell/value) # 把每个节点的 id、位置、文字收集成结构化条目拿到的节点文字和连线关系再用一次大模型调用整理成描述文本存入记忆库即可。整套链路不复杂关键是一次转换、永久可复用。5. 记忆系统排障实录我踩过的四个坑与排查链路5.1 第一坑记忆污染存得越多乱得越快这是我最早踩的坑也是最容易反复出现的。一开始我把所有历史对话都无脑写入记忆库结果检索出来的内容一半是“好的我来帮你看看”之类的客套话另一半是早该删除的过期信息。真实有用的内容被噪声淹没Agent的回答质量反而比没加记忆时更差。后来我加了一个“写入过滤器”每条记忆在落库前先过一遍规则是事实型信息明确决策、偏好、参数、路径留下。是过程性寒暄或临时感叹删除。是过期状态已经废弃的方案、已完成的临时需求归档并标记失效。过滤器可以用规则写死也可以让模型判断我建议先用规则把明显废话挡掉再让模型做更精细的分类效果最稳。记忆系统最怕的不是“忘”而是“记了一堆不该记的”。5.2 第二坑检索不到有效记忆问题多半出在切块和embedding有段时间我明明存了很多关键决策但Agent就是答不上来。排查了半天发现根因不在召回逻辑而在数据准备我把整段长对话直接embedding一个段落里混着三个主题向量被互相稀释无论怎么算相似度都是个模糊的平均值检索自然不精准。解决办法是切块一条记忆最好只表达一个主题长对话拆成多条短记忆每条再配独立摘要。另一个坑是embedding模型选型处理中文内容却用了以英文为主的模型效果可想而知。现在中文场景我习惯用对中文支持较好的开源模型或者直接调大模型的embedding接口差别非常明显。5.3 第三坑上下文爆炸把全部记忆塞回去是最错误的做法有些朋友为了让Agent“记住更多”启动时把整个记忆库全量塞进System Prompt结果token爆炸单次请求又慢又贵而且模型注意力被大量历史信息稀释反而处理不好当前任务。这里要理解一个概念模型的有效注意力在小窗口范围内最强给太多旧信息它不会“主动挑重点”只会“全都看一遍然后平均用力”。我的经验是召回结果最多挑5条每条内容压缩到200到300字以内再注入提示词如果想保留更完整的背景用“记忆编号一句话摘要”代替原文等用户明确问到时再展开。记住给Agent的记忆不是越多越好而是刚好够用最好。5.4 第四坑隐私与格式本地优先为什么值得坚持最后这个坑不是技术问题而是设计取舍。很多Agent记忆方案默认走云端向量库方便是方便但你会把项目的核心决策、代码结构、甚至商业逻辑全交到第三方手里。我的建议是除非必要记忆尽量留在本地。本地JSON、SQLite足够支撑个人项目和中小团队即使需要云端检索也只提交摘要和标引字段敏感原文留在本地。另外记忆格式一定要选可迁移的开放格式别绑定某个工具专属格式否则下次换工具又是一场灾难。我在设计记忆条目时就一直坚持用通用JSON加Markdown描述以此为边界所有工具都只负责读写这套格式。写在最后我现在一直用的最小记忆配方经过这么多轮折腾我自己现在跑Agent用的其实是个极简组合一个本地文件夹放记忆条目、一张index.json做索引、一个带双通道检索的MemoryManager脚本。规模和复杂程度都不高但已经足够覆盖我日常开发和写作的大部分场景。最后分享一个对召回命中率提升最明显的小技巧写记忆条目时顺手在trigger_context字段里写清楚“什么时候需要这条记忆”。这相当于给未来的Agent递了一张便条告诉它这条档案在什么场景下打开。在我自己的实测里加上这一个字段之后相关问题的召回命中率基本稳定在八成以上。如果你正在给Agent做记忆强烈建议先从这一条做起成本几乎为零效果立竿见影。