Agent 记忆系统设计：三层架构与记忆污染清理

2026 年的 agent 应用，拉开差距的不再是 prompt 写得好不好，而是记不记得住事。一个客服 agent 记不住用户上周的投诉，就会重复问同样的问题；一个编码 agent 记不住项目的架构约定，就会每次都重新"发现"一遍。但另一面更危险：我见过一个 agent 把三个月前的过期政策记成了现行规则，给用户办了错业务——记忆不是越多越好，记错的记忆比没记忆更致命。

这篇文章拆开 agent 记忆系统的三层架构，讲清楚每一层存什么、怎么搭，以及那个最容易被忽视的坑：记忆污染——和它的清理策略。

先澄清一个常见混淆：记忆系统不是 RAG。RAG 是"查资料"——从外部知识库里找文档片段，解决的是"模型不知道"的问题；记忆系统是"记经历"——记录这个用户、这个任务发生过什么，解决的是"模型不记得"的问题。一个客服 agent 可以用 RAG 查产品手册（知识），同时用记忆系统记住"这个用户上周投诉过物流"（经历）。两者经常一起用，但设计目标完全不同：RAG 优化的是检索准度，记忆系统优化的是"记住什么、忘掉什么"的判断。

三层架构：工作记忆、情景记忆、语义记忆

直接抄人脑的分类，最实用。每一层解决不同的问题，技术选型也完全不同。

第一层：工作记忆（Working Memory）= 当前上下文窗口。就是这次对话里塞进 prompt 的东西：用户刚说的话、刚调的工具结果。它的特点是快、全、贵——全量保留，但窗口有限。设计要点只有一个：别往里面塞垃圾。工具返回的 10KB JSON，先做一次抽取再进上下文；历史对话超过 N 轮，做滚动摘要。很多 agent 越用越蠢，根子是工作记忆被无关信息撑爆，有效信息被挤到窗口外面。经验数字：给工作记忆设一个预算（比如总窗口的 60%），超了就触发摘要，这是底线设计。

第二层：情景记忆（Episodic Memory）= 发生过的事。"用户在 9 月 12 日投诉过物流慢""上次部署失败是因为数据库迁移没跑"——带时间戳的具体事件。技术实现通常是：每次会话结束，生成结构化摘要（时间、事件、关键实体、结果），存进数据库，检索时按用户 ID + 时间衰减 + 语义相关度召回。这一层是"个性化"的来源：agent 之所以像"记得你"，全靠它。关键设计：每条情景记忆必须带三样东西——来源（哪次会话）、时间戳、置信度。没有这三样，它就是不可审计的黑箱。

第三层：语义记忆（Semantic Memory）= 学到的知识。从多次事件里提炼出的稳定事实："用户偏好用英文沟通""这个仓库的测试命令是 npm run test:unit""退款政策是 7 天无理由"。技术实现是向量数据库 + 知识图谱的组合：向量检索负责"像不像"，图谱负责"准不准"。这一层最难，因为它需要从情景记忆里"提炼"——不是每次对话都写，而是定期（比如每天）跑一个提炼任务，把高频、稳定的模式升级为语义记忆。提炼的阈值要保守：一条规则至少被 3 个独立事件佐证，才配进语义记忆。

三层之间的数据流向是单向漏斗：工作记忆 → 会话结束生成情景记忆 → 定期提炼为语义记忆。反过来检索时是：先查语义记忆（稳定知识），再查情景记忆（具体事件），最后拼进工作记忆。这个漏斗设计，是记忆系统和"无脑向量检索"的本质区别。

每层都有一个典型反模式，提前避开能省你几周调试时间。工作记忆的反模式：塞原始数据。工具返回 10KB 的 JSON 全量塞进上下文，有效信息被淹没，token 账单爆炸。正确做法是工具层先做抽取——只把"结论+关键字段"进上下文，原始数据存下来给需要时再查。情景记忆的反模式：只存摘要，不存出处。摘要写着"用户偏好退款而非换货"，但你找不到是哪次对话说的，就无法核实、无法纠错。每条情景记忆必须能一键回溯到原始会话，这是可审计性的底线。语义记忆的反模式：提炼阈值太低。用户随口提了一次"喜欢深色模式"，就被升级成永久偏好，之后所有推荐都跑偏。记住那条铁律：至少 3 个独立事件佐证，才配进语义记忆。宁可漏记，不可错记——漏记只是少了点个性化，错记是直接犯错。

检索策略上，别迷信纯向量检索。生产级的记忆检索是混合打分：语义相似度（向量）占 50%，关键词匹配占 20%，时间衰减占 20%，置信度占 10%。为什么时间衰减这么重要？因为"用户上周说的"通常比"用户三年前说的"更相关，而纯向量检索是 timeless 的——它会把三年前的一句玩笑话和上周的正式要求等同对待。时间衰减函数的具体形状可以调，但"越新越重要"这个先验必须写进排序。另一个实战经验：检索时永远多召回、再重排——先拿回 top-20， 用一个轻量重排模型（甚至规则）筛到 top-5 再进上下文。直接 top-5 进上下文，漏检率会让你在半夜被叫醒。

记忆污染：最贵的坑，和清理策略

记忆污染（Memory Pollution）指错误、过期或被操纵的记忆进入系统，并被 agent 当成事实使用。它有三个来源，每个都真实发生过。

来源一：过期记忆。最常见。某电商客服 agent 记住了"满 200 包邮"的旧政策，政策改成"满 299 包邮"后，agent 还在按旧政策承诺用户，公司赔了三个月运费。教训：每条记忆必须有 TTL（生存时间）。政策类记忆 TTL 设 30 天，到期自动降级为"待核实"，而不是继续当事实用。时间敏感的记忆没有 TTL，就是定时炸弹。

来源二：错误写入。用户随口一句"我姓王"（其实是开玩笑），agent 记下来，之后每次都叫"王先生"。或者 agent 自己幻觉出一条"用户喜欢红色"，写进记忆后自我强化。清理策略：写入前做"三问"校验——这条信息是用户明确说的吗？有第二个证据吗？写错的代价大吗？代价大的记忆（如身份、偏好、合规规则）必须走"人工审核或高置信度双源确认"，不能自动写入。

来源三：恶意注入。这是 2026 年最值得警惕的：攻击者通过对话诱导 agent 记住"管理员说可以退款 10 倍"之类的虚假指令，之后 agent 会"基于记忆"执行。防御策略：记忆分级——用户提供的记忆和系统/管理员提供的记忆分开存储，agent 做决策时，系统级记忆的优先级永远高于用户级记忆；任何试图改写系统级规则的"记忆"，直接拒绝写入并告警。

再给一套通用的清理机制，我称之为"记忆 GC"：每周跑一次垃圾回收——删除 90 天未被检索过的低置信度记忆；对被检索过但导致过错误决策的记忆，打标降级；所有删除和降级写审计日志。这套机制上线后，上面那个电商 agent 的记忆错误率从每月十几起降到接近零。记住：记忆系统的核心能力不是"记住"，是"忘掉"——忘得准，比记得多重要十倍。

GC 之外，还有两个工程实践值得做。第一，记忆版本化。像 git 管理代码一样管理语义记忆：每次提炼生成新版本，保留 diff，支持回滚。当某次提炼引入错误规则，你能一键回到上一版，而不是在数据库里手动翻找。这个设计在出故障时的价值，怎么强调都不为过。第二，审计日志四要素。每条记忆的写入、修改、删除、降级，都记录：谁触发的（用户/系统/提炼任务）、什么时候、原来是什么、置信度变化。当用户投诉"你们 agent 记错了"，审计日志是你唯一能拿出来复盘和举证的东西——没有它，你连"错在哪"都定位不了。

落地清单：你真的需要记忆系统吗

别为了"高级感"上记忆系统。三个判断标准，全满足再动手：第一，用户会回来。一次性工具型 agent（比如单次文档转换）不需要记忆；客服、个人助理、长期协作的编码 agent 才需要。第二，跨会话的信息真的有用。问自己：如果 agent 记住上次的事，用户体验有质变吗？没有就别做。第三，你有处理污染的人力或机制。没有 GC 机制的记忆系统，不如没有记忆。

决定要做，按这个最小可行顺序：先做好工作记忆的预算管理（零成本，立刻见效）；再上情景记忆的会话摘要（一个 prompt 模板的事）；最后才碰语义记忆的提炼和向量检索（最复杂，放最后）。80% 的 agent，做到第二层就够了——别一上来就搭知识图谱。

给你两个可以直接抄的落地模板。第一个是会话摘要 prompt，每次会话结束时调用："请从刚才的对话中提取值得长期记住的信息，按 JSON 输出：facts（稳定的事实，如用户偏好、项目约定）、events（发生过的事件，带时间）、todos（未完成的待办）。只提取未来会话可能用到的，不要记流水账。如果无可记，返回空数组。" 这个模板的精髓在最后一句——默认不记，值得才记，这是对抗记忆膨胀的第一道防线。

第二个是每日提炼任务：每天凌晨跑一个批处理，把过去 7 天的新情景记忆拿出来，问模型三个问题：哪些事实出现了 3 次以上（升级为语义记忆候选）？哪些旧记忆被新事件推翻了（标记过期）？哪些记忆 30 天没被用过（降置信度）？候选的语义记忆先进入"待审核"状态，人工每周看一次，点个确认才生效。这一套跑下来，一个中等规模 agent 的记忆系统，人工维护成本大约是每周 30 分钟。

我的观点：记忆正在成为 agent 的"人格"

往深想一层：agent 的记忆系统，决定了它"是谁"。两个用同样模型的 agent，一个记得你所有的偏好和历史，一个每次从零开始——用户会觉得前者"聪明"十倍，尽管模型一模一样。2026 年 agent 应用的竞争，正在从"模型之争"转向"记忆之争"：谁的记忆更准、更干净、更懂取舍，谁的产品就更像"人"。

但硬币的另一面是责任。记住用户，意味着你有义务记对、记安全、可删除。GDPR 的"被遗忘权"在 agent 时代会变得无比具体：用户说"忘了我刚才说的"，你的三层记忆能不能真的删干净？设计记忆系统的第一天，就要把删除路径设计好——这是合规要求，更是信任底线。

删除路径具体怎么做？三层要分别处理：工作记忆随会话结束自然丢弃，但要确保日志和 trace 里不留明文；情景记忆按用户 ID 做硬删除，同时清掉向量索引里的对应条目（只删数据库不删索引是常见 bug）；语义记忆最麻烦——从多条情景记忆提炼出的规则，可能"包含"了该用户的信息，严格删除需要重新跑提炼。工程上的折中方案：给每条语义记忆打"贡献者"标签，删除请求触发一次增量重提炼。这个机制复杂，但它是"被遗忘权"在 agent 时代的真正含义——不是删一条记录，是删一个"影响"。

再往前想一步：记忆的可携带性可能是下一个差异化点。如果用户能把"调教了半年的专属记忆"从一个 agent 带到另一个 agent，记忆就从产品功能变成了用户资产。谁先支持记忆导出、记忆迁移，谁就先拿到"用户舍不得走"的护城河。反过来想：你的 agent 要是连记忆删除都做不好，用户凭什么相信你能保管好他的记忆？删除和导出，是记忆系统的两个试金石，上线前自己先测一遍。

还有一个 2026 年正在发生的趋势：记忆正在从"单个 agent 的私产"变成"跨 agent 的共享层"。用户在一个 agent 里教会的偏好，能不能被他用的第二个、第三个 agent 继承？谁先做出好用的"记忆同步协议"，谁就定义了下一代 agent 生态的入口。这也是为什么现在就要把记忆设计成独立服务、而不是耦合在某个 agent 里的原因——架构上解耦，未来才有资格参与这场游戏。

所以，动手前先回答三个问题：我的 agent 需要记住什么？记错的代价是什么？忘掉的机制是什么？答不上来第三个，就先别建记忆系统。记住：好的记忆系统让 agent 像个靠谱的老朋友，坏的记忆系统让它像个记仇又健忘的糊涂蛋——而区别，全在"忘"的设计上。