很多人一想到 Agent 记忆，就会想到“把历史都存起来”。这其实很危险。
Agent 真正需要的不是更多记忆，而是在合适的时候拿到合适的信息。记得太少，它每次都从零开始；记得太多，它会被旧信息、无关信息甚至错误信息带偏。
本文要点
- Agent 记忆要分层：当前任务、短期会话、长期偏好不能混用。
- 长期记忆必须有来源、时间和适用范围。
- 检索记忆时，相关性不够，还要判断是否过期、是否高风险。
- 有些信息不该记，比如一次性密码、临时决定、敏感数据。
记忆先分三层
Agent 的记忆可以先简单分成三层。
第一层是工作记忆。这是 Agent 当前正在处理的信息，比如用户刚刚提出的目标、正在修改的文件、刚跑出来的错误日志。它只服务当前任务，不需要长期保存。
第二层是会话记忆。这是当前对话里的上下文，比如用户前面已经确认过的范围、刚才排除过的方案、暂时不想改的文件。它可以跨几轮对话存在，但不一定要进入长期记忆。
第三层是长期记忆。这是跨会话仍然有价值的信息，比如用户偏好、团队规范、项目常用命令、某类任务的固定流程。
什么值得保存
长期记忆只适合保存“以后还会影响决策”的信息。
值得保存的例子：
- 这个项目使用
pnpm，不要用npm。 - 文章发布前必须跑
pnpm build。 - 用户偏好中文技术文章，语言要通俗，不要堆概念。
- 代码审查输出要先列风险，再写总结。
不值得保存的例子：
- 用户刚才随口说的一次性偏好。
- 某次临时绕过测试的决定。
- 过期的接口地址。
- 密码、Token、密钥、身份证号等敏感信息。
判断一条信息要不要进入长期记忆，可以问三个问题：
- 下次类似任务还会用到吗？
- 它足够稳定吗？
- 用错它会不会造成风险？
如果答案不明确，就不要自动沉淀。
怎么把记忆拿出来
记忆检索不能只看“语义相似”。
比如用户说“帮我发布文章”，系统检索到“不要直接 push”。这条记忆很相关，也应该进入上下文。
但如果检索到“三个月前临时允许跳过构建”，即使语义相关，也不应该直接使用。因为它可能是一次性例外，不是长期规则。
所以检索后还要做四步过滤：
- 看来源：是用户明确说的、项目文件写的，还是 Agent 自己总结的？
- 看时间：这条信息是不是已经过期？
- 看范围：它适用于所有项目，还是只适用于某个仓库？
- 看风险：如果用错，会不会导致发布、删除、泄露、收费等高风险后果？
高风险记忆不能静默使用，最好让 Agent 明确说明依据，必要时让用户确认。
坏记忆怎么伤人
坏记忆比没有记忆更麻烦。
没有记忆时，Agent 至少会重新确认。坏记忆会让 Agent 很自信地做错事。
常见问题有三类。
第一类是过期记忆。比如项目以前用 npm，现在改成 pnpm，但 Agent 还记着旧规则。
第二类是范围错配。比如某个项目允许自动 commit，不代表所有项目都允许。
第三类是用户临时决定被永久化。比如用户某次说“这次先不用图片”，Agent 以后每次写文章都不放图片，这就错了。
解决办法不是完全禁用记忆，而是给每条长期记忆加元信息：
memory:
content: "文章发布前必须运行 pnpm build"
source: "AGENTS.md"
scope: "problem_helper 仓库"
confidence: "high"
expires: null
risk: "medium"有了这些信息，Agent 才能判断这条记忆该不该用。
设计检查清单
设计 Agent 记忆系统时，可以用这份清单。
- 当前任务信息是否只放在工作记忆里？
- 会话信息是否会在任务结束后清理？
- 长期记忆是否记录来源和适用范围？
- 敏感信息是否禁止进入长期记忆？
- 检索结果是否经过时效和风险检查？
- 高风险动作是否要求用户确认？
- 用户是否能查看、修改、删除记忆？
- 记忆更新是否有日志，能追溯是谁写入的？
结论
Agent 记忆的目标不是“什么都记住”，而是让下一次执行少走弯路，同时不被旧信息误导。
如果一条信息稳定、可复用、有明确来源，就可以沉淀。否则宁愿让 Agent 重新确认。好的记忆系统不是最大化存储，而是最大化正确使用。