Agent 记忆的分层：工作窗口、摘要与长期存储

Agent 在生产里第二周就"失忆"，通常不是模型的问题，是没人建记忆层。一个客服 agent 上午处理了十五个会话，下午就把每个都忘了，下个用户再讲一遍上个用户讲过的账户历史——这恰恰是把上下文窗口当成了唯一记忆的后果。这篇把 agent 记忆的分层讲清楚，以及最常犯的几个错。

上下文窗口不是记忆

先厘清一个概念：上下文窗口是模型单次调用能看到的东西，记忆是决定"什么被放进这个窗口、什么不放"的基础设施。窗口贵、有硬上限、每次 API 调用都重置。一个只靠窗口的 agent，会话一关就归零，不管之前聊过多少。所以"128k 上下文够用了、不用操心"是最大的幻觉：输入越长成本越高，长输入里注意力在 token 上限之前就衰退了，而且窗口在会话之间重置，根本当不了持久记忆。

分层记忆模型

可靠 agent 的记忆是分层的，每层解决一个不同的失败，存储和生命周期都不一样。

分层的好处是"该留在窗口里的尽量少，该按需取的存起来"。每一轮，agent 读一个高信号的小窗口，只在当前步骤确实需要某个事实时才去查存储。持久存储别一股脑塞进 prompt，需要时再查。

短期、长期与情景

另一种常见切法是三层。短期记忆是当前会话的活跃状态，实现是 key 到 session id 的内存 store 或 Redis，TTL 30 到 60 分钟，它的失败模式是"把它当成唯一一层"。长期记忆存跨会话要存续的事实、偏好、历史，实现是向量库加检索层，会话开始时拉 top-k 相关事实进窗口；写管线跟读一样重要——每个有意义的会话事件在关闭前要摘要写回，跳过写回是生产 agent 学不到东西的最常见原因。情景记忆记过去动作及其结果，实现是结构化事件日志（task id、动作、结果、时间戳），它防的是最显眼的失败：同一个任务类型上重复犯同一个错。

摘要与检索

两个最便宜也最有效的机制。摘要是逃生舱：会话变长时，每隔一段把运行中的记录换成压缩版——"决定了 X，文件 Y 是目标，错误 Z 是阻塞"，让窗口装意图而不是每个原始 token。检索是"取"而不是"堆"：agent 不把存储整段塞进上下文，而是查询它，存储返回匹配的事实，放进当前步骤需要的窗口。价值不在更大的窗口，而在 prompt 负载管理——让模型在一个它真能推理的空间里工作。

这两个机制要配一个纪律才成立：会话开始检索、会话结束写回，每轮都要做，而不是只在"感觉重要"的轮次做。跳过会话结束的写回，是 agent 管线随着时间退化的头号原因——链上每个 agent 都比前一个知道得更少，跨 handoff 的错误会累积。

常见误区

第一个误区是什么都记：未过滤的流水账增加成本、隐私暴露和检索噪声，要留有用信号，不是每句话。第二个误区是记错作用域：一个项目特定的指令变成了全局偏好，或一个人的细节出现在团队上下文里——每条记忆都要挂 owner 和 namespace。第三个误区是旧事实赢：过期偏好静默覆盖当前指令——存时间戳和优先级，重要事实重新核对。第四个误区是记忆不可查：人无法纠正看不见的东西——展示相关来源、为什么检索到这条、怎么改怎么删。第五个误区是把记忆当真相：记住的信息是证据，不是保证，该当假设处理，直到当前来源或 owner 确认。

一句话收尾：记忆不是窗口越长越好，而是作用域可见、可追溯、可编辑、与任务相关。把"什么进窗口、什么进存储"这件事设计清楚，比换更大的模型更值钱。