有人说 Agent 最难的不是让它“会做事”而是让它“记得事”。我自己在本地搭过好几个智能体项目最崩溃的体验就是明明上一轮刚告诉它我的服务器是 2C4G 的配置让它写部署脚本时别开大内存应用结果下一轮它又给我生成一个需要 8G 内存的方案。这种“过目即忘”的问题不解决Agent 再聪明也落不了地。这也就是为什么在 Agent 的六大核心模块里“记忆”占据了非常特殊的位置——它不直接产生智能但没有它任何智能都是“一次性”的。这篇是系列第四篇专门聊记忆。我会从记忆的分类、存储设计、检索策略、遗忘机制到主流记忆框架的选型再到一个完整的实操案例完整拆解“让 Agent 记住之前说过什么”这件事。这不是一篇纯概念科普而是我在实际项目中反复调优总结出来的落地经验适合那些已经跑通了 Agent 基础流程、正被“多轮对话失忆”和“上下文管理混乱”折磨的开发者和爱好者。1. Agent 记忆问题到底卡在哪1.1 没有记忆的 Agent 是什么体验先说一个最典型的场景。你把 Agent 接入了钉钉或者飞书机器人用于内部技术支持。同事问“我们前端项目用的 Vue 3 还是 Vue 2”Agent 答对了。过了一会儿同事又问“刚才那个项目的构建命令是什么”Agent 开始胡编——因为它根本“不记得”刚才聊的是哪个项目。于是同事只能把项目名、技术栈、路径这些信息重新填一遍体验跟填表没什么区别。这种问题的本质是当前绝大多数 Agent 的工作方式就是“无状态请求”。每次用户对话进来模型只看到当前这轮消息加上系统提示词它没有“会议纪要”没有“用户档案”更没有“历史上下文”。ChatGPT 能记住你之前聊过什么是因为它内部帮你管理了上下文窗口但自建 Agent 没有这套东西一切都要自己设计。做 Agent 记忆首先要解决的还不是“怎么存”而是“存什么、取什么、什么时候忘”。很多人在这个环节走了弯路一开始就上向量数据库结果发现检索出来的全是杂音反而把模型带偏了。1.2 记忆其实分很多层从“过目就忘”到“终身不忘”人的记忆不是一块硬盘而是分层的。Agent 也一样。业界基本形成了一套约定俗成的分层方式我按实际开发中的使用频率给你排一下短期工作记忆指的是当前会话内马上要用的信息比如用户刚说的需求、上一步生成的结果。这部分通常直接在 Prompt 上下文里管理。长期语义记忆指的是用户画像、项目背景、领域知识这类需要跨会话保留的信息。这是自建记忆系统的核心也是最花功夫的部分。情景记忆指的是“某时某刻发生了什么”比如用户上个月让你部署过一个服务、三周前提过一个需求。这类记忆往往跟时间线绑定。永久记忆系统级的不变量比如用户的 ID、权限、组织架构、基础配置。这类信息一般不参与模型的“自由发挥”而是作为硬约束存在。很多讲 Agent 记忆的文章把长短期记忆网络LSTM那段历史也扯进来我觉得在应用层面意义不大。Agent 的记忆工程本质上不是训练一个网络而是设计一套存取系统让 LLM 在合适的时候拿到合适的信息。你把它当成一个“带智能筛选功能的数据库”来设计思路就顺了。2. 记忆系统的整体设计与分层2.1 短期工作记忆上下文窗口的实用主义管理短期记忆最直观的实现就是“聊天记录全塞进上下文”。但这样做很快就会撞上两个致命的墙Token 费用墙和模型注意力墙。我实际测试过GPT-4 级别的模型在上下文超过一定长度后对中间部分的注意力会明显衰减这个在行业内叫“lost in the middle”。你塞进去 5 万字聊天记录模型真正有效利用的可能只有开头和结尾的部分。花了钱效果反而变差。所以短期记忆的主流做法是“摘要压缩 滑动窗口”窗口内保留最近 5-10 轮完整对话保证连续性和语气一致。窗口之外更早的对话用 LLM 批量生成摘要只保留关键信息。当摘要太大时再递归摘要或者向量化后按需检索。这里有一个很关键的参数窗口长度。不要贪多。我自己的经验是普通任务 6-8 轮足够复杂任务最多到 12 轮再多就要靠“总结模块”去压缩成结构化的要点而不是硬塞。注意短期记忆的摘要生成不能每轮都做。一般可以只在“累计对话达到 N 轮”或“预估 Token 超过阈值”时触发一次摘要刷新否则 LLM 调用成本会飙升。2.2 长期语义记忆向量化 RAG 的经典组合长期记忆解决的是“跨会话保留”问题。用户昨天跟你说他喜欢简洁的代码风格今天再让你写脚本你得“记得”这个偏好。这个场景最成熟的方案就是 RAG检索增强生成。核心链路是从对话中抽取需要长期保留的信息。用 Embedding 模型把信息向量化。存进向量数据库。新对话进来时把当前问题也向量化做相似度检索。把检索到的历史记忆拼到 Prompt 里。这套方案看起来简单真正做起来容易踩坑。最大的坑是“检索相关性 ≠ 任务相关性”。用户昨天说了一句“我讨厌红色”今天问你“帮我设计一个按钮颜色”向量相似度可能根本检索不到那条“讨厌红色”的记忆因为这两句话在语义上差太远了。所以我现在做长期记忆很少只靠向量。线上生产环境用的是“混合检索”向量 关键词 时间衰减加权。关键词负责精确命中向量负责语义扩展时间衰减负责让近期的记忆权重更高。2.3 情景记忆与永久记忆哪些该结构化哪些该格式化情景记忆和永久记忆很多人会跟长期语义记忆混在一起但其实在工程实现上的差别很大。永久记忆是“硬编码”级别的比如用户 ID、角色、权限。我通常建议放到独立的配置表或者 Redis 里每次构造 Prompt 时直接注入不走向量检索。因为这类信息不允许模糊匹配——你把用户权限检索错了那是安全事故。情景记忆更适合用结构化的方式存储。比如维护一张事件表字段包含时间、事件类型、涉及的实体、结果。用户说“上个月我把博客从 Hexo 迁移到了 Hugo”这条记录应该被打上“2025-06-xx”“迁移”“博客”“Hexo→Hugo”这些结构化字段。这样后续用户在讨论博客技术栈的时候Agent 不光能“想起来”这件事还能准确调出迁移日期和涉及的工具链。2.4 双网络记忆模型给了我们什么启发这个热词“双网络记忆模型”指的其实是两种不同方向的参考一个方向是记忆相关的神经网络结构比如 DNC、LSTM另一个方向是 Agent 架构里的双通道记忆设计。我理解它在工程上更实用的含义是——把“实时响应通道”和“沉淀通道”分开。实时响应通道用户提问 → 快速检索 → 直接回答整个过程要在几百毫秒内完成不能拖泥带水。沉淀通道异步处理 → 从对话中抽取重要信息 → 分类、清洗、去重、写入长期存储。这两个通道在物理上可以是同一个模型但在任务上必须解耦。如果你让一个主对话流程既要做实时响应又要做深度记忆抽取响应速度会显著下降而且记忆抽取的质量也堪忧。我的实践是多开一个异步任务调用一个小模型专门做“记忆提炼”把结果写入储存层主 Agent 完全不去关心这个过程。3. 记忆核心流程写入、存储、检索、遗忘、注入3.1 记忆的写入不是所有对话都值得记住“全记住”和“全不记”一样糟糕。我在实际项目中总结了一套筛选逻辑我给每个潜在记忆点打分按分数决定是否入库。打分考虑四个维度信息完整性用户表达是否明确、具体。比如“步长为 2”比“调大一点”更有资格入库。关联性跟当前任务或用户画像的相关度。闲聊内容的权重要降。时效性临时性的信息“我今天下午开会”不需要进长期库。情感强度用户表现出强烈偏好时“我特别不喜欢啰嗦的解释”优先级要上调。简单计算方式就是总分 完整性 × 0.3 关联性 × 0.4 时效性 × 0.2 情感强度 × 0.1。超过阈值的才写入长期记忆库。这个权重可以根据你自己的场景去调节但思路值得借鉴——先过滤再入库比先全存再清理要省事得多。3.2 记忆的存储结构化与非结构化的边界之争存储这块有一个经典争论记忆到底该存成结构化数据JSON、表格还是非结构化文本纯文本、向量。我的态度很明确混合存储按用途分流。用户画像、偏好、基本事实 → JSON 结构化存储字段明确方便精确查询。对话摘要、项目背景、历史决策 → 自然语言摘要 向量化方便语义检索。事件记录、操作日志 → 时序数据库或者普通表结构按时间轴查询。结构化数据的优势是精确、可筛选、可控非结构化数据的优势是语义丰富、不丢细节。你让 Agent 回答“我之前是不是提过要迁移博客”语义检索比较合适但要回答“我对代码注释的偏好是什么”结构化查询更可靠。一个容易犯的错误是把 JSON 整个塞进向量库。这样既丢了结构化的精确性又污染了向量检索的语义空间。正确的做法是结构化字段独立存储同时抽出一个“描述文本”作为向量化的对象两边通过同一个记忆 ID 关联。# 伪代码示意记忆双写 memory_record { id: mem_001, user_id: u_10086, type: preference, structured: {topic: code_style, value: prefer_comments, level: 3}, description: 用户偏好代码有详细注释认为注释是代码的一部分, created_at: 2025-07-12T10:00:00Z } # 1. 写入结构化存储 db.save(memory_record) # 2. 将 description 向量化后写入向量库 vector embed(memory_record[description]) vector_db.upsert(memory_record[id], vector, metadata{type: preference})3.3 记忆的检索相关性排序怎么调才不跑偏检索阶段常见的痛苦是“搜出来了但没用”。这背后其实是排序逻辑太单一的问题。单纯用向量相似度排序容易出现语义接近但实际无效的结果。我现在的做法是加一个重排rerank环节。第一轮先用向量召回 Top 50关键词召回 Top 30做并集第二轮用一个轻量级重排模型或者让 LLM 打分对这 80 条候选排序选出 Top 5-10 注入 Prompt。重排打分考虑三个维度语义相似度跟当前问题的相关性。时效权重近期记忆适当加分防止旧记忆频繁覆盖新记忆。冲突消解如果两条记忆内容矛盾优先保留时间靠后的一条并把冲突标记出来。这里特别提醒检索环节一定要控制注入条数。我见过有人把 Top 20 条记忆全塞进 Prompt 的结果模型被一堆历史信息干扰连当前用户问的是什么都忽略了。注入 3-5 条高质量记忆往往比塞 20 条低质量记忆效果好得多。3.4 记忆的遗忘反直觉但必须做有个反直觉的事实Agent 的记忆系统必须设计“遗忘”功能。很多开发者觉得记忆当然是越多越好但实践下来垃圾记忆累积只会让 Agent 越来越“糊涂”。遗忘策略我总结为三种时间衰减超过一定期限没有访问的记忆自动降权。比如 90 天内未被命中的记忆移入冷存储。冲突清理当新记忆与旧记忆冲突时旧记忆并不是直接删掉而是标记为“deprecated”避免下次检索时左右互搏。显式遗忘用户明确说“不要再按这个来”的时候必须能把对应记忆删除或者覆盖。这个能力在合规和体验层面都是刚需。遗忘不是简单地“delete from table”。历史记录建议保留但要从“活跃记忆库”中移除。相当于让人回想起来很难但查日志还能翻到。这样既不干扰正常的记忆检索又保留了事后审计的能力。3.5 记忆的注入放在 Prompt 的哪个位置大有讲究记忆检索出来之后注入到系统提示词里的位置会影响最终效果。我试过很多种排布目前的稳定做法是系统提示词最前面放“身份与原则”这部分固定不变。紧接着放“用户画像与持久偏好”这是从长期库检索出来的结构化信息。然后放“当前会话摘要”这是短期记忆的压缩结果。再放“相关历史记忆”这是从情景记忆和语义记忆里检索出来的内容。最后放“最近的对话轮次”保证模型有足够上下文来理解当下的语义。有研究显示LLM 对 Prompt 开头和结尾部分的注意力更强。把用户画像放在开头、最新对话放在结尾正是利用了这个特性。历史记忆放在中间位置起到信息补充作用不跟“最新指令”抢注意力。4. 记忆框架选型主流方案盘点与横向对比4.1 记忆框架不是越多越好先看匹配度现在市面上的 Agent 记忆框架已经有挺多选择开源的和商业的都有。选型的核心不是“哪个最强”而是“哪个跟你现有技术栈、部署环境、成本预算匹配”。我盘点了几个在社区里热度比较高的方案你在选型之前可以先对照一下框架记忆模型存储后端适合场景备注Mem0图结构 向量混合记忆向量库 图数据库需要强关联推理、用户画像较丰富的场景自动抽取记忆实体和关系社区活跃MemGPT / Letta虚拟上下文管理内置存储 / 可接外部库研究型项目、需要模型自主管理记忆的实验场景思路新颖但生产稳定性需要自己打磨Zep时序记忆 知识图谱内置存储 / 可接 Postgres生产环境、需要跨会话长期记忆的客服或助手类应用商业版本完整开源版有基础能力MemoryScope分层记忆 可插拔存储支持 SQLite、向量库等轻量级场景、快速原型验证中文友好文档好读适合入门4.2 我的记忆框架选择经验我自己在实际项目里用过两种路线一种是直接用 Mem0 这类现成框架另一种是自己写一套轻量记忆层。两条路各有取舍。用现成框架的好处是“开箱即用”不需要重复造轮子。Mem0 的抽取能力确实不错能自动从对话里识别实体和关系生成结构化记忆。但问题也很明显框架有一定“脾气”它有自己的 Prompt 模式和存储格式你不太容易按自己的场景去精调。而且引入一个重框架往往意味着要多维护一套服务对个人项目和中小团队来说负担不小。自己写记忆层的优势是“完全可控”。比如我在做一个垂直领域的内部助手时用户画像的字段是固定的角色、项目、技术栈、偏好我可以用一个简单的 JSON 文件或者 SQLite 表存起来完全不用向量库。因为字段确定、查询方式确定结构化存储的效率远高于向量检索。只有当知识库和对话记录是非结构化的自由文本时我才引入向量库。选型的核心判断标准就一句话你的记忆是“查字典”还是“凭印象”。查字典的场景用结构化存储就够了凭印象的场景才需要上向量检索和语义模型。别一上来就堆技术先想清楚你要的是精确还是模糊。5. 实操案例为你的 Agent 装上记忆模块5.1 需求场景做一个能记住用户偏好的部署助手我用一个真实做过的项目来演示整套方案。场景是给内部运维团队做一个 Web 部署助手Agent 需要记住每个开发者的技术栈偏好、服务器地址、常用部署流程并且能跨会话调用这些信息。目标很明确开发者 A 第二次来用助手时说一句“按老规矩部署”Agent 就要知道“老规矩”指的是什么——用 PM2 还是 Docker、跑在哪个服务器、需要执行哪些构建命令。这个需求对记忆系统的要求非常高因为“老规矩”这三个字本身没有语义信息全靠记忆来补全。5.2 基础架构选型与部署我选择自己搭轻量记忆层不引入重框架原因有三个第一内部工具的用户量不大几十人不需要弹性伸缩第二用户画像字段非常确定用结构化存储完全可以覆盖“老规矩”这类需求没必要上向量数据库第三运维场景对可解释性和可控性要求高我需要清清楚楚知道 Agent 到底“记得”了什么而黑盒式的自动抽取容易埋雷。架构设计是主 Agent负责对话 SQLite存用户画像 内存缓存存会话摘要 一个异步的“记忆提炼”服务负责从对话中抽取结构化信息。# 项目目录结构 deploy-agent/ ├── agent/ # 主 Agent 逻辑 │ ├── chat.py │ └── prompt_templates.py ├── memory/ # 记忆模块 │ ├── profile_store.py # 用户画像读写 │ ├── extractor.py # 记忆提炼与写入 │ ├── retriever.py # 记忆检索与注入 │ └── forgetting.py # 遗忘策略 ├── storage/ # SQLite 缓存 │ └── schema.sql └── main.py核心表设计如下CREATE TABLE user_profile ( user_id TEXT PRIMARY KEY, tech_stack TEXT, -- JSON 数组如 [Vue3, Node.js] deploy_tool TEXT, -- 如 docker-compose server_addr TEXT, build_cmd TEXT, custom_rules TEXT, -- 自由文本记录特殊偏好 updated_at DATETIME );这个表就是“永久记忆 长期语义记忆”的简化实现。字段明确、可查、可改Agent 每次构造 Prompt 时直接读取根本不需要向量检索。5.3 核心代码实现记忆的抽取、存储、检索、注入记忆抽取的逻辑是用异步任务实现的。当一轮对话结束后我调一个小模型用本地部署的量化模型成本很低去对话文本里提取结构化信息# memory/extractor.py import json from llm import chat_completion EXTRACTION_PROMPT 从对话中提取用户的部署偏好信息以 JSON 格式输出 { tech_stack: [Vue3, Python], deploy_tool: docker-compose, server_addr: 10.0.0.5, build_cmd: npm run build, custom_rules: [测试环境不做 HTTPS] } 如果没有提到的字段请设为 null。只输出 JSON不要别的。 def extract_profile(conversation_text: str) - dict: resp chat_completion( modellocal-qwen2.5-7b, messages[{role: user, content: EXTRACTION_PROMPT \n\n对话 conversation_text}] ) return json.loads(resp)检索和注入的逻辑在每次用户发消息时同步执行# memory/retriever.py def build_memory_context(user_id: str) - str: profile profile_store.get(user_id) if not profile: return parts [] if profile.get(tech_stack): parts.append(f用户技术栈{, .join(profile[tech_stack])}) if profile.get(deploy_tool): parts.append(f部署工具{profile[deploy_tool]}) if profile.get(server_addr): parts.append(f服务器地址{profile[server_addr]}) if profile.get(custom_rules): parts.append(f用户自定义规则{.join(profile[custom_rules])}) return \n.join(parts)Prompt 注入的模板长这样# agent/prompt_templates.py SYSTEM_PROMPT 你是内部部署助手。请基于用户画像和对话上下文提供部署建议。 【用户画像】 {memory_context} 【对话要求】 - 如果用户说按老规矩部署请优先参考用户画像中的部署偏好。 - 用户画像中没有的信息允许提问补充。 - 用户明确修改偏好时请记住新偏好。 这里有个细节很关键我给 Agent 加了“允许提问补充”的兜底逻辑。记忆系统再完善也有盲区与其让模型瞎猜不如让它直接问。很多 Agent 项目失败的原因就是模型假装记得实际上在编。5.4 效果评测与参数调优这个系统上了之后我做了两轮评测。第一轮是功能验证连续模拟 20 轮跨会话对话检查 Agent 能否准确调用历史记忆。第二轮是压力测试故意让用户频繁修改部署偏好看系统能不能“忘掉”旧信息、记住新信息。测试中暴露了几个问题结构化抽取的准确性受对话长度影响。对话太长时抽取模型会漏掉一些靠后的信息。解决办法是分段抽取每 10 轮对话单独抽一次最后再做合并。用户修改偏好时旧值没有被即时覆盖。比如用户先说“用 Docker 部署”后来又说“算了还是用 PM2”但库里还是 Docker。原因是抽取逻辑没有处理“修改”场景。后来我加了一个规则凡是用户对话中出现“改”“换成”“不用”这类词优先以最新表达为准。记忆注入的 Token 占用比预期高。一度用户画像塞了太多 custom_rules把模型上下文占掉不少。后来我限制 custom_rules 最多保留 5 条并且优先注入最近更新的条目。6. 常见问题与排查技巧实录6.1 Agent 答非所问检索到的记忆全是噪声这是最常遇到的问题。表象是 Agent 答非所问根源往往是检索环节把一堆低相关记忆塞进了 Prompt。排查思路第一步把注入 Prompt 的记忆内容打印出来人工看看检索结果是否合理第二步检查向量化模型跟领域是否匹配——通用 Embedding 模型在垂直领域的效果可能很差第三步检查是否缺少重排环节Top 几条结果不一定是最有用的。解决措施加一个简单的重排模型或者让 LLM 对候选记忆打标签“有用”/“无关”滤掉无关项再注入。实测重排之后记忆命中率能从 60% 提升到 85% 以上。6.2 记忆越用越乱甚至互相矛盾长期运营下来记忆库里很容易出现自相矛盾的内容。用户在 3 月说“不要自动升级”5 月又说“有新版直接升级”两条记录并存模型就糊涂了。我的处理办法是做“记忆归并”每次写入新记忆前先检索同主题的旧记忆如果发现冲突把旧记忆标记为“deprecated”同时把更新记录存到事件表。这样模型只看到最新有效记忆同时审计日志保留了完整的变更轨迹。6.3 上下文爆炸Token 成本失控很多 Agent 项目做到后期Prompt 里恨不得塞下所有历史信息Token 成本飙升响应速度下降模型效果还变差。解决思路是分层压缩。会话层做摘要压缩用户画像层做字段限制只保留最关键的 5-8 个字段历史记录层做时间窗口限制默认只能检索最近 30 天的记忆。每一层都设一个 Token 预算哪层超了就去优化哪层而不是整体无脑追加。注意Token 成本的控制不能靠“少检索”来解决。少检索会导致记忆命中率下降最终用户体验变差。正确的方向是“高质量检索 低冗余注入”用更少的 Token 传递更有效的信息。6.4 记忆污染用户随口一句话被当成事实这是最隐蔽的坑。用户可能只是随口说“我觉得这个项目快不行了”结果被抽取模型当成“项目状态异常”的事实存了下来。下次对话时这个错误记忆可能诱导 Agent 做出错误的判断。应对策略是“置信度分级”。抽取模型不仅要抽取信息还要输出一个置信度分数。只有置信度超过阈值的记忆才进入活跃记忆库低置信度的记忆只进“候选池”等后续多轮验证后再确认为正式记忆。这个机制能有效过滤掉大量随口一说的话造成的污染。6.5 多 Agent 协作时的记忆共享与隔离在复杂场景里往往有多个 Agent 协作比如一个负责对话理解一个负责工具调用一个负责知识问答。它们之间的记忆怎么共享、怎么隔离是个容易被忽视的问题。我的做法是定义记忆的“可见范围”。用户级记忆偏好、画像所有子 Agent 可见任务级记忆当前任务的状态、中间结果仅当前编排流程内可见工具级记忆某个工具的内部状态仅该工具自己可见。三个级别分开存储通过记忆 ID 和权限标记来隔离。这样既保证了协作效率又避免了不同 Agent 之间的记忆污染。7. 一点收尾的体会做 Agent 记忆系统这么久我最深的体会是记忆设计的成败不在于用了多高级的模型或多强大的向量库而在于想清楚“什么值得记住什么不值得”。一个能把“记住”和“遗忘”都做好的系统才是真正可用的记忆系统。如果你现在还在起步阶段我给的建议是不要一上来就做全家桶。先用一个简单的用户画像表 会话摘要缓存跑通“结构化记忆”这条路观察 Agent 的行为是否变聪明了。然后再逐步加入向量检索、重排、遗忘机制这些高级能力。记忆系统是典型的“增量迭代”工程越迭代越贴合你的场景一步到位往往意味着处处不舒服。最后分享一个我自己踩了多次坑总结出来的小技巧记忆系统的调试一定要留“后门”——随时能查看 Agent 当前记忆了什么、检索到了什么、注入了什么。把记忆的存取日志完整记录下来出问题的时候不用猜直接看日志。没有这个后门记忆系统就是个黑盒出了问题你连从哪里排查都不知道。