AI Agent长期记忆四层设计：写入、压缩、检索与遗忘

Agent 的记忆如果按日志追加来做，通常三周内会出现两种退化：延迟变长，判断变差。原因多半不在模型，而在库里堆的是「当时看得见、以后用不上」的东西。

2026 年 11 月 6 日，Anthropic 发布工程文《智能体记忆的组成部分》，用一场宝可梦红版的长程任务把这件事量了出来：记得多的一方，进度反而更少。

413 个记忆文件，只换来 1 枚徽章

实验设置很朴素：给每个模型一个可读写的记忆文件夹，跑约一万步之后对比目录内容。Sonnet 3.7 认为所有东西都可能有用，于是逐场战斗、逐个道具、每位非玩家角色各建一个文件。

结果是 413 个记忆文件、225 个文件夹，只换回一枚徽章；Fable 5 只写了九个文件、两个文件夹，外加一个顶层的全局记录文件，换到四枚徽章（Anthropic 研究页）。

差异不在记得多不多，而在记得对不对。原文的判断很直接：玩家有多少钱、在地图哪个位置，这类每回合都能从屏幕上读到的状态，写进记忆属于冗余。

冗余还会变成负担。约第一万步时，Sonnet 3.7 开始建第四个主目录，其后的 17 步里它创建了六个文件、删掉九个，游戏内一次动作都没有执行。

反过来，真正该写的是那些不写就会消失的东西：策略、计划、验证过的规则。Fable 5 那个全局文件承担看板的角色，装着当前目标、攻克道馆的计划，以及它自己使用记忆的规则；具体路线放一个文件夹，玩法策略放另一个。

反直觉的一条：预先定规则会削弱收益

Anthropic 还测了「给人写死规则」这条路径。把规则设成只记录失败之后，Opus 5 和 Opus 4.7 都丢掉了记忆带来的大部分收益。

原文的结论是：告诉模型记忆用来干什么有用，教它怎么用用处不大。对前沿模型，给判断显著性的自由度，比预先定死规则更有效。

这直接影响第一层设计。写入策略不该是一张硬编码清单，而应是一段用途说明加少量示例。

四层怎么拆：写入、结构化、压缩、检索与遗忘

把上面的事实落成工程结构，我建议分四层，每层回答一个不同的问题：写什么、怎么摆、怎么瘦身、怎么取用与丢弃。

第一层：写入策略，什么值得写、何时写、谁决定

判据只有一条：下一轮能不能重新观测到。能重新观测的（页面状态、当前库存、屏幕上的坐标）不写；不能重新观测的（验证过的规则、计划、目标与约束）必须写。

时机上分两步。任务进行中只在会话日志上打标，标出显著事件；任务结束后由独立的整理任务提炼成笔记。不要让主循环每一步都写盘，那等于把维护成本搬进推理路径。

谁来决定，取决于模型档位。前沿模型给一句用途说明和自由度；小模型或旧模型要给模板和字段约束，因为它们在无引导时倾向于不读记忆、也不检验自己的假设。

第二层：结构化，目标、计划、规则，加一个看板

按三类落库：目标、计划、规则。第四类是事实，只在它能省掉一次昂贵查询时才写。

再叠一个全局看板，每次会话都注入：当前目标、下一步、以及使用约定。它的作用不是存数据，而是让模型知道该去哪里找什么。

注入层必须小。看板加少量高频规则是合理预算；把整个目录塞进系统提示，等于把每次调用的 token 成本乘以会话数。

第三层：压缩与整理，跑在空闲期

整理任务与主任务解耦，做四件事：合并语义重复项、对照会话原始记录纠错、把稳定笔记升格为维基条目、标记过期与冲突版本。

Anthropic 把这件事叫做梦式整理，收益有具体数字：整理从两次会话扩到 128 次会话，25 道题的评分从 13% 升到 48%（同篇原文）。

但 48% 仍然低于搜索加维基的组合。整理不是检索的替代品，两者叠加才成立。

第四层：检索与遗忘，混合召回加硬预算

召回走混合路径。关键词检索负责精确的实体与标识符，向量检索负责语义近似。只靠向量，遇到版本号、订单号、错误码这类强标识符容易失手。

每次注入给硬预算。超出预算时按相关性、新鲜度、近期使用次数排序截断，宁少勿多：注入一条错笔记的代价，是它会在每一个后续会话里被信任。

冲突处理的原则是不覆盖、只追加。同一作用域内同一键出现新版本时，旧版本标为已取代，保留可追溯链路；真正失效的进软删除，再定期归档。

落地：PostgreSQL 加 pgvector 的两张表

优码云交付带记忆能力的 Agent 时，习惯把结构建在客户自己的 PostgreSQL 里：记忆项与版本分两张表，覆盖式更新只在版本表里追加。

记忆项表承担索引与状态，关键字段如下。

版本表只做追加：每条正文变更记一行，带上版本号、内容哈希与来源片段。内容哈希用于判断正文是否真的变了，来源片段指向当时的会话记录，复盘时能回到现场。

索引按两种召回方式各建一个：向量列上建近邻索引走余弦距离，分词列上建倒排索引走关键词。软删除的过滤条件要进查询本身，而不是查完再在应用层筛。

整理任务的幂等靠三个约束。唯一键让重复提炼落回同一项；内容哈希让重复正文不新建版本；任务表用状态加锁到期时间的状态机，配合行级锁，保证同一范围不会并发跑两遍。

对照学术侧：213 个 token 拿到 0.85

同一条「少即是多」的思路，学术侧走得更远。2026 年 7 月的 LazyMem 把记忆构建整体推迟到查询时：检索出的候选池交给一个 4B 小模型，在重叠窗口里只保留与当前问题相关的内容。

论文摘要给出的数字是：长程记忆评测集上 LazyMem-4B 的模型裁判准确率 0.85，只用 213 个答案侧记忆 token，比基线少 21.0 倍，并能在不做目标域训练的情况下泛化到多会话对话集（arXiv:2607.22690）。

适用边界要看清。它的评测集是长多会话的对话历史，问题是「过去对话里说过什么」；企业侧的记忆还包括跨租户的业务事实、权限与流程约束，这些不能靠查询时临时重建。

另外两条代价：查询时构建会加首跳延迟；4B 权重意味着多一个需要私有化部署的推理服务。如果连检索源都没有，压得更狠只会更差。

三个能落地的度量

记忆工程最容易变成玄学，所以至少要有三个可采集的口径，改动前后跑同一批样本。

三个指标要一起看。命中率单独升高，往往意味着注入预算被撑大；成本单独下降，可能是记忆被删得太狠，重复率随后会抬头。

如果团队还没建立这套观测，可以先从同类错误重复率入手，它最容易被业务侧读懂。站内另有几篇关于 Agent 生产化的记录，见文末延伸阅读。

三个反模式

• 把屏幕或环境的实时状态写进记忆。宝可梦那组实验说明了后果：状态一直在变，记录持续过期，模型花在整理上的时间超过做任务。
• 无界追加。没有合并、没有过期，行数线性增长，检索质量与延迟同时恶化，而且越早的数据越难清理。
• 无版本直接覆盖。原地改写让冲突不可回溯，模型无法判断哪条是当前有效版本，纠错也失去对照物。

常见问题

记忆表和会话日志要分开存吗

要分开。日志是证据，记忆是结论。日志可以冷存归档，记忆要参与检索、要版本化、要有过期策略。混在一起，日志表会变成一张没人敢删也查不动的表。

每次注入多少 token 算合理

没有通用数字，取决于主任务本身占用多少上下文。可行做法是先设一个硬上限，再用召回命中率验证这个上限够不够；命中率不达标时，先修写入与结构化，不要先加上限。

能不能直接用厂商的托管记忆服务

冷启动阶段可以，进入交付阶段要评估两件事：数据是否可导出、版本是否可追溯。不可导出的记忆，等于把客户的运行经验锁在一家供应商里。

遗忘只做软删除够吗

软删除解决可见性，不解决成本。成本发生在检索和注入这两步，所以过期标记要参与召回打分：低新鲜度降权，已过期直接排除，而不是等整理任务批量清理。

优码云在评估这类改造时，通常先把写入判据和注入预算这两处定死，再谈检索算法；需要对照自己的场景，可以从案例页看交付范围怎么拆，或直接聊需求。

延伸阅读

• Agent 工程化：失败率背后的模型与工程归因
• 跨平台 AI Agent 工程化：跨端任务接续的三条路线
• Web 端 AI Agent 能力评估：四层模型与团队协作误区
• AI Agent 生产部署实战：从验证到规模化请求的架构演进
• AI Agent 企业落地工程实践：从 Demo 到生产的系统性方法
• Web 端 AI Agent 团队建设：交互、编排与治理的三维模型
• 企业 AI 应用开发：Web 端长时运行 Agent 的 4 个生产化改造点

参考

• Anthropic 研究原文：智能体记忆的组成部分（2026-11-06 发布）
• LazyMem 论文摘要（arXiv:2607.22690，v2 2026-07-28）