大模型本身没有记忆：每次调用都是无状态的，「记忆」完全是工程层的事——你在每次请求里塞进什么上下文，模型就「记得」什么。所以 Agent 的记忆设计，本质上是一个信息管理问题：什么值得存、存在哪、什么时候取出来、什么时候忘掉。
见过太多团队在这里走两个极端：要么什么都不存，Agent 每次从零开始，用户重复解释同样的背景；要么什么都存，把全部历史对话塞进向量库，结果检索出来的「记忆」一半是噪声。这篇文章给出一个三层记忆架构，每层职责清楚，可以按需逐层实现。
记忆设计的核心不是「存」，而是「取」：取不准的记忆比没有记忆更糟。
第一层：短期记忆——任务内的工作状态
短期记忆就是当前任务的上下文窗口内容：用户目标、对话历史、工具调用记录、中间结论。它天然存在，真正的设计问题是上下文膨胀——长任务跑几十步后，历史记录撑爆窗口或者稀释注意力。三个常用手段：
- 滚动摘要：保留最近 N 轮原文，更早的历史压缩成摘要。注意关键约束（「不要动 config 目录」「预算上限 50 元」）必须原样保留在摘要外，摘要最容易把这类否定性约束丢掉。
- 结构化状态对象：不依赖对话流水账，显式维护一个任务状态（goal、完成的子任务、待办、已验证事实、未决问题），每步更新。这比让模型「从历史里自己找」可靠得多，也是Plan-Execute 模式的自然配套。
- 工具结果瘦身：搜索返回的整页 HTML、上万行的文件内容，进入历史前先提取要点。工具原始输出是上下文膨胀的头号来源。
const taskState = {
goal: "为客户生成 Q2 复盘报告",
constraints: ["只用内部数据", "不发送任何邮件"],
done: ["拉取销售数据", "生成图表"],
todo: ["撰写分析", "人工确认"],
facts: [{ claim: "Q2 营收环比 +12%", source: "bi_query#3" }],
};短期记忆的生命周期：任务结束即销毁。它不该自动流入长期记忆——这是防污染的第一道闸门。
第二层：长期记忆——跨会话的事实与偏好
长期记忆解决「下次见面还认识你」：用户偏好（中文回复、报告用 Markdown）、稳定事实（时区、角色、项目背景）、历史决策（上次选了方案 B 及原因）。设计上有四个关键决定：
存什么：只存「事实性、稳定、复用价值高」的条目。判断标准是「三个月后这条还成立、还有用吗」。一次性的任务细节不配进长期记忆。
怎么写：两种触发方式——用户显式要求（「记住我们的 API 前缀是 /v2」）和 Agent 任务后自动提炼。自动提炼必须过滤：权限类结论（「用户说过可以跳过确认」）严禁写入，这是记忆污染防护的核心规则；写入时记录来源会话，保证可审计、可删除。
怎么取：条目少（几十条）时全量注入系统提示词；多了按当前任务相关性检索注入。每条记忆最好带「最近命中时间」，为淘汰提供依据。
怎么忘：没有淘汰机制的记忆库会腐烂——过时的偏好、已废弃的项目约定持续误导模型。定期清理长期未命中的条目，冲突时新事实覆盖旧事实并留痕。
实现形态可以很朴素：一批 Markdown 文件或一张数据库表就够了。Claude Code 的 CLAUDE.md、各家助手的「记忆」功能，本质都是这一层。
长期记忆贵在精不在多：几十条高质量事实，胜过一整库对话流水账。
第三层：向量记忆——大规模经验的检索层
当记忆量大到无法全量注入（成千上万条历史工单、过往任务记录、领域笔记），就需要向量化：用 Embedding 存进向量数据库，任务开始时按语义检索相关条目注入。这一层技术上就是 RAG，所有 RAG 的工程经验都适用——切分、混合检索、重排、阈值拒答，可以直接参考《RAG 为什么答不准》。
向量记忆有两个特有的坑：
- 存对话原文效果很差。原始对话噪声大、指代多（「就按刚才说的办」），检索出来模型也用不上。先提炼再入库：把一次任务压缩成「场景 + 决策 + 结果」的结构化条目，检索质量天壤之别。
- 时效冲突。语义检索不理解「新规定覆盖旧规定」，新旧条目会同时被召回。入库时带时间戳和主题键，同主题只保留最新版，或在注入时按时间加权。
进阶方向是图记忆：把实体和关系存成知识图谱（人 A 负责项目 B，项目 B 依赖服务 C），适合关系密集的场景，Zep、Mem0（图模式）等开源方案都在往这个方向走。但多数应用先把前两层做好就够了。
三层怎么配合：一次任务的记忆流
任务开始
├─ 注入长期记忆（偏好 + 相关事实，全量或检索）
├─ 向量记忆检索「相似历史任务」Top-3，附经验摘要
├─ 初始化短期状态对象
执行中
├─ 每步更新状态对象；历史超限 → 滚动摘要
任务结束
├─ 状态对象销毁
├─ 提炼候选记忆 → 过滤规则 → 写入长期/向量记忆（留来源）
└─ 高风险条目 → 人工确认后才写入按产品形态选实现深度
| 产品形态 | 建议配置 |
|---|---|
| 单轮工具助手 | 只做短期记忆（甚至只是对话历史） |
| 个人助理 / Copilot | 短期 + 长期（文件或表存偏好即可） |
| 客服 / 领域专家 Agent | 三层齐上，向量层存提炼后的工单经验 |
| 多 Agent 系统 | 三层 + 共享记忆的读写权限设计 |
现成方案方面：Mem0、Zep、LangGraph 的 checkpointer/store 都可以直接用，接入前重点考察三件事：能否控制写入规则、能否审计和删除单条记忆、检索是否支持时间加权。记忆框架解决的是存取的工程问题，「存什么、忘什么」的策略永远要自己定。
先想清楚每层的写入规则和淘汰规则，再选框架——顺序反了就会存一堆用不上的记忆。
适用人群与替代方案
适合正在给 Agent 或助手类产品加记忆能力的开发者。替代方案值得认真考虑：很多「需要记忆」的需求，其实用显式配置更好——用户在设置页填写偏好，比模型悄悄「学习」更透明、更可控，也没有污染风险。让用户直接看到并编辑 Agent 记住的每一条内容（像编辑一份档案），是目前体验和安全的最佳平衡。
常见问题
Q：直接把全部历史对话塞进长上下文模型，不就不用设计记忆了？ A：贵、慢，而且长上下文的中间信息利用率不可靠（见《长上下文模型真的更强吗》）。上下文是工作台，不是档案柜。
Q：记忆应该按用户隔离还是全局共享？ A：用户偏好和个人事实必须按用户隔离，这是隐私底线；可共享的是脱敏后的领域经验（「此类工单的处理套路」）。共享层的写入要更严格审核。
Q：怎么评估记忆做得好不好？ A：两个可量化的信号：一是「用户重复解释背景」的频率是否下降；二是抽样检查注入的记忆条目，统计与当前任务真正相关的比例——低于一半就说明取的环节在拖后腿。
小结
三层记忆各司其职：短期记忆管好状态、控住膨胀；长期记忆宁缺毋滥、可审计可删除；向量记忆先提炼再入库、带时间处理冲突。核心原则是把记忆当成有生命周期的资产来管理——会遗忘的记忆系统，才是可靠的记忆系统。