去年底我们接了一家 200 人规模的连锁零售客户的 Agent 项目，第一版上线后业务方提了一个让我们「破防」的问题：「为什么我昨天告诉它我们门店周日不发货，今天它又把周日的订单排进了配送计划？」我们查了日志，发现模型其实「听到」了那句话，但因为当时是另一个工单的对话，没有任何机制把这条偏好沉淀下来——下一次会话，Agent 就像第一次见这个用户。这不是 prompt 的问题，也不是模型不够聪明，是记忆架构压根没设计。后来我们用了三周时间，把它从「单轮上下文」改造成了「短期+长期+RAG」三层结构，业务方的复述次数从平均每天 4-6 次降到了不足 1 次。这篇文章想把这套架构、走过的坑和工程取舍都讲清楚。
很多团队做 Agent 卡在第二个月，并不是因为 prompt 写不好、也不是因为工具调用不灵，而是因为 Agent「记不住」。一次性问答的体验做到 80 分不难，但企业里真正能跑起来的 Agent，本质是一个「会持续累积上下文、会区分公共知识和私人偏好、会在合适的时机遗忘旧信息」的协作体。记忆系统的设计水平，几乎直接决定了它能不能从「演示玩具」长成「数字同事」。
为什么记忆是 Agent 系统设计的核心
如果说 LLM 是 Agent 的「大脑皮层」，工具调用是「手」，那么记忆系统就是「海马体+长期皮质」的组合。没有它，Agent 每一次对话都是「失忆症患者从零开始」——这在 demo 场景里看不出问题，在真实业务里则是灾难。
我们在做 AI Agent 落地路线图 的咨询时，反复跟客户强调一个判断：Agent 能不能产生复利价值，关键看它有没有记忆。 没有记忆，每次交互的 ROI 都是孤立的；有了记忆，Agent 会越用越懂业务、越用越像一个新同事，每一次对话都在喂养下一次对话。
更现实的层面，记忆决定了三件事：
| 维度 | 没有记忆的 Agent | 有完善记忆的 Agent |
|---|---|---|
| 单次对话上限 | 受限于上下文窗口（一般 8k-200k token） | 理论上可跨越多个会话累积 |
| 用户体验 | 反复复述、解释、纠正 | 越用越「懂你」，复述次数指数下降 |
| 业务沉淀 | 知识停留在个人脑子里 | 个性化偏好和历史决策沉淀为团队资产 |
| 工程复杂度 | 低（只管当前对话） | 高（需要写入/召回/过期/合规多层设计） |
记忆系统并不是「锦上添花」，它是从「能用」到「好用」之间那道最大的坎。
短期记忆：上下文窗口的管理与压缩
短期记忆对应的是 LLM 的上下文窗口——它最直接、也最容易被滥用。很多团队的第一个版本就是「把所有历史消息都塞进 prompt」，结果三五轮之后就触发了 token 上限或 latency 暴涨。
短期记忆的核心是「窗口管理」，常见策略有三类：
- 滑动窗口（Sliding Window）：保留最近 N 轮对话。实现最简单，但容易丢掉关键背景。
- 摘要压缩（Summarization）：用 LLM 把早期对话压成简短摘要，最近几轮保持原文。质量上限高，但每次压缩有额外推理开销。
- 结构化抽取（Structured Extraction）：把对话里的事实、决策、待办抽成结构化 JSON，与原文分开存。适合工单/客服/项目协作场景。
开沿的实践是「分层缓冲」：最近 3-5 轮保留原文（高保真），更早的对话压缩成摘要（中保真），再早的提取成结构化事实（低保真但精确）。这套结构在 Claude/GPT 类模型上跑得很顺，配合 AI 路由的多模型策略 可以让摘要这一步用更便宜的小模型来做，整体成本控制得住。
短期记忆里有一个常被忽视的细节：工具调用的中间产物。如果 Agent 调用了三次数据库查询、两次 API，这些中间结果是放进上下文还是丢弃？我们的经验是「关键路径保留摘要、原始 payload 丢弃」——既保留可追溯性，又不撑爆窗口。
长期记忆：用户偏好/历史决策/事实知识的持久化
长期记忆是「跨会话存活」的那部分信息。它一般分四种：
- 用户偏好类：用户喜欢什么报表格式、习惯几点发周报、不接受周末打扰。
- 历史决策类：上次为什么选了 A 方案而不是 B、某个客户去年签的是哪个版本。
- 事实知识类：某个客户的联系人是谁、某个项目的截止日期、某个 SKU 的成本。
- 关系图谱类：用户 A 和客户 B 的对接历史、订单 C 关联的服务工单。
在工程实现上，长期记忆通常落在两类存储：
| 存储类型 | 适合内容 | 检索方式 | 典型选型 |
|---|---|---|---|
| 结构化数据库 | 有明确字段的事实 | SQL/Key | PostgreSQL、MySQL |
| 向量数据库 | 自由文本的偏好/对话片段 | 语义检索 | Qdrant、Milvus、PGVector |
| 图数据库 | 实体关系类 | 图遍历 | Neo4j、NebulaGraph |
| 文档存储 | 半结构化 JSON | 字段+全文 | MongoDB、Elasticsearch |
很多团队一上来就堆向量库，但向量检索的召回精度对短文本（一句偏好）其实不够稳。开沿的做法是：能结构化就结构化，能用关键词检索就别用向量。比如「周日不发货」这种偏好，我们会落到 user_preferences 表的 delivery_schedule 字段，命中率 100%；只有那些没法预定义字段的自然语言备注，才走向量。
这里还涉及一个重要话题：长期记忆的写入触发。不是每句对话都该被记住——什么样的信息值得「写进长期记忆」？我们的判断标准是「四要素」：用户主动表达的偏好、有时间跨度的事实、影响后续决策的约束、用户明确说「记住这个」。其他的对话片段留在短期记忆里就够了。这一点在 AI Agent 数据安全实践 里也反复提及——记得越多，合规风险越高。
RAG 记忆：知识库 + 向量检索的实战
RAG（Retrieval-Augmented Generation）是这两年最热的范式，但很多团队把 RAG 等同于「向量数据库+LLM」，这是简化过头的理解。从「记忆」的视角看，RAG 装的是企业的公共知识——产品手册、SOP、政策文件、技术文档、行业资料。
企业知识库 RAG 实战 里我们详细写过 RAG 的工程链路，这里只补几个和「记忆」相关的关键点：
- 分块策略决定召回质量。同一份合同，按 512 token 死板切和按语义段落切，召回准确率能差出 20-40%。
- 混合检索（Hybrid Search）已成标配。纯向量在长尾词、专有名词上召回差，结合 BM25 关键词检索几乎是必选项。
- 重排序（Rerank）是性价比最高的优化。在向量召回 Top-20 后，用一个小的 reranker 模型选 Top-3，对答案质量的提升通常比换大模型更显著。
- 元数据过滤不可省。「只检索当前用户有权限看的文档」「只检索某部门的文档」这类约束必须在向量库层就过滤掉，不能等到 LLM 出答案再后处理。
RAG 和长期记忆有一个常见的边界问题：它们都用向量检索，是不是该放一张表？ 我们的答案是坚决的「不」。RAG 装公共知识、版本化、可审计、权限按文档走；长期记忆装个体化的私有上下文、动态变化、有遗忘曲线、权限按用户/会话走。一旦混表，后期想做权限隔离、做 GDPR/PIPL 风格的「被遗忘权」处理，会非常痛苦。
三层混合：如何在不同场景下切换
把短期、长期、RAG 三层装好了，下一个问题是「在某次对话里，怎么决定从哪一层取信息」。这是个调度问题，没有银弹，但有一些经验性规则：
| 场景类型 | 短期记忆 | 长期记忆 | RAG 知识库 |
|---|---|---|---|
| 多轮对话/工单处理 | 必用 | 选用 | 选用 |
| 个性化推荐/偏好类问答 | 选用 | 必用 | 不用 |
| 政策/SOP 类问答 | 选用 | 不用 | 必用 |
| 涉及历史决策的复盘 | 必用 | 必用 | 选用 |
| 全新任务/冷启动 | 必用 | 不用 | 必用 |
实战中，我们一般用一个轻量的路由层来做这个选择：先看用户问题里有没有「我」「我们」「上次」「记得」这类指向私人上下文的代词，有则走长期记忆；再看有没有「政策」「规范」「文档」「制度」这类指向公共知识的词，有则走 RAG；剩下的默认只用短期记忆。这个路由可以用规则也可以用小模型，不必上重型方案。
需要警惕的是「过度召回」——把三层信息全塞进 prompt，看似稳妥实则灾难：token 飙升、关键信息被噪声淹没、模型注意力分散。我们的目标永远是「最少必要召回」，宁可少一条也不要多一条。
记忆的失效与遗忘机制
人脑会遗忘，Agent 也得会。一个永远不忘的 Agent 不仅占用资源，还会带来严重的合规问题。遗忘机制的设计有四种主流思路：
- 时间衰减（Time Decay）：每条记忆带时间戳，超过阈值自动降权或删除。简单粗暴但有效。
- 访问频率（LRU/LFU）：长期不被召回的记忆优先清理。适合用户偏好类。
- 冲突覆盖（Conflict-based Eviction）：新事实与旧事实矛盾时，新的覆盖旧的（并保留版本）。适合事实知识类。
- 用户主动遗忘（Explicit Forget）：用户明确说「忘掉那条」时立即删除。合规必选。
AI 合规 PIPL 实战 里我们提到过：用户主动遗忘必须做——《个人信息保护法》第 47 条明确要求企业提供删除入口。这不是技术细节，是法律红线。
遗忘机制还有一个微妙之处：软删除 vs 硬删除。前者方便审计回溯，但合规风险大；后者干净彻底，但出问题时不好追溯。开沿的方案是「向量库硬删、明文库软删并加密」——满足合规的同时保留运维侧的故障排查能力。
工程实现的三条主流路径
到了 2026 年，记忆系统的实现路径基本收敛成三条，各有取舍：
| 路径 | 代表方案 | 上手速度 | 灵活性 | 合规友好度 | 适合团队 |
|---|---|---|---|---|---|
| Memory Bank（文件型） | Claude Projects、Cursor Memory | 极快 | 低 | 一般（数据出境） | 个人开发者/小团队 |
| 框架方案 | Mem0、Letta（前 MemGPT）、Zep | 快 | 中 | 看部署方式 | 中小企业 AI 团队 |
| 自研架构 | 业务定制 | 慢 | 高 | 可控 | 中大型企业/强合规场景 |
第一类是文件型 Memory Bank：把记忆塞进一个 markdown 或 JSON 文件，Agent 每次读取。Claude Projects、Cursor Memory 都是这条路线，胜在零门槛，但灵活性低、规模上去就乏力。
第二类是开源框架：Mem0、Letta、Zep 这类专门做 Agent 记忆的项目，提供了向量检索、增删改查、过期策略等基础能力。Mem0 比较轻、API 友好；Letta 是从 MemGPT 演化来的，更偏长上下文管理；Zep 在生产环境的稳定性口碑不错。这类框架的缺点是：续费曲线和数据出境政策需要仔细看，特别是 SaaS 版本。
第三类是自研架构：在 Postgres+向量库+缓存层上自己搭。开沿在做几个中大型客户的 Agent 时走的就是这条路——主要是因为客户的数据必须留在内网、字段级权限要严格、记忆要绑定到业务对象（如客户/项目/工单）。自研的成本不低，但可控性、可审计性、与 钉钉云盘 等内部系统的集成深度都是框架做不到的。
我们的建议是：框架打底、关键链路自研——用 Mem0 这类框架做向量检索和基础 CRUD，自研写入策略、过期策略和业务绑定层。这样既省了 2-3 个月研发，又保留了灵活性。
记忆和合规：什么数据该留、什么该忘
合规是记忆系统绕不开的话题，尤其在 PIPL、GDPR 都已经成熟落地的今天。我们在做客户项目时，一般用一张「记忆数据合规矩阵」来对齐：
| 数据类型 | 是否可写入长期记忆 | 保留期建议 | 是否需要用户授权 |
|---|---|---|---|
| 工作偏好（如报表样式） | 可 | 6-12 个月无活跃则降权 | 隐式即可 |
| 业务事实（如订单、客户档案） | 可 | 跟随业务对象生命周期 | 走业务侧协议 |
| 个人敏感信息（身份证号/银行卡） | 不写入 | - | 单独授权且加密 |
| 健康/生物特征 | 不写入 | - | 严格授权+本地化 |
| 对话原文（含他人对话） | 谨慎写入 | 7-30 天 | 双方授权 |
实操层面有几条铁律：
- PII 信息进入记忆前必须脱敏或加密——开沿的做法是用本地化的 NER 模型先扫一遍，标记出身份证、手机号、银行卡等字段，要么不存，要么加密存。
- 记忆必须有用户侧的「查看+导出+删除」入口——这不是产品功能，是法律义务。
- 跨境传输要慎之又慎——如果用 SaaS 版的记忆服务（如 Mem0 Cloud），要确认数据中心位置，必要时切到私有部署。
AI Agent 的权限审计 这篇我们详细讨论过记忆的权限模型——记忆不是「我说了它就该记」，而是要回答「谁能写、谁能读、谁能改、谁能删」这四个问题。
决策树：怎么为你的 Agent 选记忆架构
给一个简化的决策清单，可以帮你快速锚定：
- 你的 Agent 是单轮问答还是多轮协作？ 单轮问答（如 FAQ 机器人）：只要 RAG，可能连短期记忆都不需要。多轮协作：短期记忆必上。
- 是否需要跨会话累积？ 不需要（如一次性数据分析任务）：只要短期+RAG。需要（如客服、销售助理）：长期记忆必上。
- 是否涉及大量企业内部文档？ 是：RAG 必上。否：可以暂缓。
- 用户量级？ 小于 100 人：用框架方案省事。100-1000 人且合规要求一般：框架+少量自研。大于 1000 人或强合规：考虑自研。
- 是否涉及多租户隔离？ 是：从第一天就把租户字段加到所有记忆表的主键里，别等数据飞了再补。
- 是否要绑定业务对象？ 是（如绑定到客户、订单、项目）：用结构化数据库做主存，向量库做副存。否：向量库为主即可。
- 遗忘机制是否设计过？ 没设计：补上时间衰减+用户主动遗忘两条，剩下的可以慢慢加。
自检清单（任何一条 No 都不要上线）：
- 长期记忆有 created_at / last_accessed_at / source 字段吗？
- 有用户侧的「查看我的记忆+删除」入口吗？
- PII 字段有脱敏或加密吗？
- 短期记忆有窗口管理策略吗（不是无限累加）？
- RAG 和长期记忆是分开的存储吗？
- 记忆的写入是异步还是同步？同步会不会拖垮主链路？
- 多租户隔离做了吗？
- 有压测过同时 500 人在线的延迟吗？
结语
我们这两年看过太多团队在记忆这一层栽跟头——有的因为没有长期记忆，Agent 永远停留在「演示效果」；有的因为长期记忆没有遗忘机制，三个月后变成一个 100GB 的向量库噩梦；还有的因为合规没想清楚，上线半年被合规部门叫停。记忆架构没有标准答案，但有相对清晰的取舍框架：结构化能解决的别用向量、公共知识和私人记忆分开存、能少召回就少召回、能让用户控制就让用户控制。 把这几条守住，你的 Agent 大概率能从「玩具」长成「同事」。如果你正在做企业级 Agent 项目，记忆这一层值得你投入比 prompt 工程多 3-5 倍的精力——这是我们走过弯路之后最朴素的体会。
