长期记忆是架构决策，不是提示词技巧。Meta 在 10 月 12 日发布的 Muse Wonder 把 Active Memory 与 Active Focus 作为核心能力，蚂蚁灵光被曝测试长期记忆版本，腾讯元宝在开发承载个人长期记忆的独立 App——头部厂商都在把「记得住」作为下一阶段的主战场。本文拆解四层记忆架构、三道遗忘闸与四类治理动作。
很多团队做智能体记忆时的第一反应是「把聊天记录存进向量库，下一轮再检索出来」。这条路在 demo 阶段能跑，但一进生产就会暴露三个问题：记忆和知识库混在一起、建了向量库却说不清什么时候忘、检索出来的内容自己污染了自己。
2026 年 10 月的一连串发布把这条线彻底推到了台面。Meta 在 10 月 12 日发布的前沿模型 Muse Wonder 与 Muse Wonder Full，把 Active Memory（主动记忆） 和 Active Focus（主动专注） 列为两款模型的核心能力；蚂蚁集团旗下灵光 App 的新版本据新浪科技 10 月 11 日报道，正在小规模内测，核心升级正是「长期记忆 + 主动执行推进」，并通过 Skill 与 MCP 协议接入钉钉和智能家居；腾讯元宝则被曝在开发独立 App 形态的 Personal Agent 产品「元宝助手」，专门承载长周期任务与个人长期记忆。当头部厂商把「记得住」作为下一阶段的主战场时，工程侧的问题就不再是「要不要做」，而是「怎么分层、怎么遗忘、怎么治理」。
本文把智能体长期记忆拆成四层存储架构、三道遗忘闸与四类治理动作，并说明每一层的落地顺序、常见误区与行业差异。这条线与 RAG 知识库落地 高度相关但不是同一件事——RAG 解决的是「把外部资料检索进来」，记忆解决的是「把已经付出的理解成本变成下次还能用的资产」。
---
大模型本身是无状态的：每次推理只看到本次传入的 token，无论上下文窗口是 128K 还是更大的规模，会话一关，模型对之前发生过的事一无所知。因此「连续性」必须由应用层显式提供。但提供方式有三种，问题性质完全不同：
| 概念 | 解决什么 | 典型实现 | 失效表现 |
|---|---|---|---|
| 上下文工程 | 单次推理里塞什么 | 压缩、滚动摘要、上下文裁剪、分块排序 | 单轮任务失真、长对话注意力被稀释 |
| 知识库（RAG） | 外部资料有哪些 | 切分、向量化、混合检索、重排 | 召回不到、召回了不相关片段 |
| 长期记忆 | 跨会话、跨任务记住什么 | 分层存储、语义召回、结构化事实库 | 自相矛盾、重复劳动、旧事实污染新推理 |
最常见的工程错误是把三者塞进同一张表。知识库是注入静态事实资料，产品文档、公司制度；记忆是记录交互过程中产生的动态信息，用户偏好、上次确认过的约束、踩过的坑。它们的建表逻辑、更新策略和失效处理完全不同。
用户说「我刚才不是说过我的需求了吗，你怎么忘了」，开发者的第一反应往往是去做记忆。但这类问题严格说属于上下文工程——它的目的是在有限窗口里保住高价值信息，而不是跨会话保留信息。压缩、滚动摘要、窗口裁剪才是正道。
这个区分在成本上尤其关键。据 imversion.com 在 2026 年 10 月整理的上下文管理策略对比，滚动摘要和事实抽取在「token 削减」这一维度表现最强，但摘要方式本质是有损的——它可能把例外情况抹平、把相似事实合并、丢掉硬约束；而检查点快照与历史步骤检索在「关键事实保真度」上更靠前，因为它们保留了结构化状态或更接近原始的来源历史。一份务实的做法是分工：用摘要压缩闲聊，用结构化存储保住事实。
还有一个容易被忽略的性能事实。据 ClaudeWave 在 10 月的一篇分析中引用的 HackerNoon 观点，Claude Opus 4.8 可选的 1M token 上下文窗口会给人「问题已经解决」的错觉，但实际上把更多历史塞进上下文会让每次调用更贵，而且不保证模型会优先关注真正重要的部分。设计良好的记忆决定什么该进上下文，这比指望模型从草料堆里找针更省也更可控。
在动手建表之前，有一个常被跳过、但真正决定架构走向的判断：这份记忆归智能体所有，还是归用户所有？
这个决策在最底层，决定了所有读写逻辑的写法：归用户所有的实现里，所有记忆的键必须带 user_id，所有检索必须在用户维度做隔离。多租户场景下漏掉这一步，串号就是必然结果而不是意外。这一点与 企业后台权限模型设计 里的数据边界思路是一致的——记忆表本质上是权限模型的一部分，不是纯粹的检索索引。
---
在工程落地中，把记忆拆成四层是较为通行的做法。学术上的起点是 Packer 等人 2023 年的《MemGPT: Towards LLMs as Operating Systems》，首次提出把大模型当作操作系统、用分层记忆管理上下文。国内方面，中国信通院《人工智能发展报告（2026 年）》把记忆与上下文工程列为大模型工程化的关键环节。
按 saturn.pub 在 2026 年 10 月整理的企业选型框架，记忆可分为四层：
| 层级 | 职责 | 典型存储 | 写入策略 |
|---|---|---|---|
| 工作记忆（Working） | 当前任务的上下文，会话结束即清空 | 运行时变量 / 消息列表 | 自动，不落库、不污染长期层 |
| 情景记忆（Episodic） | 历史会话与操作轨迹，可回放 | 时序库 / 消息日志 / 对象存储 | 自动，但需要保留审计 |
| 语义记忆（Semantic） | 沉淀的实体、规则、术语 | 向量库 + 关系表 + 知识图谱 | 需准入条件，不能默认全存 |
| 程序记忆（Procedural） | 可复用的技能与工作流（SOP、工具链） | 配置中心 / 版本化技能库 | 人工审核为主，版本化管理 |
四层的核心原则是职责单一、读写分离，切忌「一层存所有」。混层带来的直接后果是：情景记忆的临时结论污染了语义层的事实，导致智能体把三个月前的一次讨论当成本周确认过的约束。
情景记忆记录的是「在某次交互中发生了什么」，比如「用户周三下午要求把接口超时从 10 秒改成 5 秒，因为移动端弱网体验差」。这类记忆带有强烈的时间属性，检索时如果忽略时间，会把旧要求当成本周的新约束。
对应的处理方式有三种：检索时做强时间衰减；给每条记忆打「事实时间」与「摄入时间」双时间戳（双时态模型），以支持追溯性更正；以及在返回结果里把时间戳一并给到模型，让模型自己判断这条记忆是否已经过期。
语义记忆是从多次交互中提炼出的稳定事实，比如「团队主要使用 Go 语言」「生产环境部署在某云上」。它不依赖具体时间，但必须处理冲突场景：用户昨天说「我们用 MySQL」，今天说「我们迁移到了 PostgreSQL」，系统必须知道后者覆盖前者，而不是同时召回两条互相矛盾的记忆。
处理原则是按来源权威度与时间戳裁决，且不静默覆盖——冲突应该被标记为待裁决，或者保留双版本并注明生效时间，静默覆盖在审计场景下是不可接受的。这一条在政务监管和医疗健康类系统里尤其重要，具体可参考 医疗信息化的数据隐私与操作留痕 中关于留痕与防篡改的思路。
程序记忆更像是技能和流程，比如「当用户要求排查线上问题时，先查日志、再看监控、最后给根因」。这类内容适合写在系统提示词或工具描述里，而不是塞进向量库——因为它的召回依赖意图识别，而非语义相似度。把 SOP 放进向量库，模型很可能在不需要的时候召回它，或者在需要的时候漏掉。
Meta 在 Muse Wonder 的发布材料中提到，其模型用多样的长周期任务训练以提升在软件开发工作流中持续推进的能力，SWE-Marathon 与 DeepSWE 这类基准正是针对长时间持续工作设计的。这类能力在工程上不可能只靠提示词支撑，程序记忆必须版本化、可回滚、可审计。
长期记忆既要支持「语义检索」（上次客户投诉过什么），又要支持「精确查询」（用户手机号），这两类需求对存储的要求不同。向量库解决语义近邻搜索：把文本经 Embedding 模型映射到高维空间，用余弦相似度度量语义接近程度，相比关键词匹配，它能召回字面不重叠但语义等价的内容——比如「用户抱怨登录太慢」和「认证接口响应时间超过阈值」。
工程上需要关注的三个点：
补充一点容易被忽略的：Embedding 模型本质是编码器，把可变长度文本压缩成固定维度向量。两个文本的余弦相似度越接近 1，语义越相似；接近 0 则基本无关；接近 -1 则语义相反。余弦相似度对向量长度不敏感，这正是它适合文本检索的原因——但在某些实现里如果忘了归一化，排序结果会失真。
---
「存下来总比不存好」是记忆系统里代价最高的一个直觉。陈旧事实比没有记忆更危险——智能体可能检索到一份过时的策略并当作现状执行。据 CSDN 上 2026 年工程实践文章的梳理，对策是给每条记忆打双时间戳并支持追溯性更正，同时加入新鲜度元数据与冲突检测。
据同一份梳理，真正棘手的是记忆中毒：被注入的错误或恶意记忆会在多个智能体之间传播。对策包括对来源智能体打标，防止跨智能体污染。这条线与 AI Agent 提示词注入怎么防 中的六道防线是互补关系——那里讲的是不让攻击发生，这里讲的是攻击发生后不让污染留存。
按 saturn.pub 提出的框架，遗忘闸可以分成三类，本质是让记忆做到「敢忘、会裁、能拒」：
闸一 · 过期闸。 带 TTL 的临时记忆到期即清，防止陈旧事实污染后续推理。适用对象是情景记忆中的临时状态——「用户当前在排查某个故障」这类信息有效期可能只有几分钟。
闸二 · 冲突闸。 新记忆与旧记忆矛盾时，按来源权威度与时间戳裁决，不静默覆盖。适用对象是语义记忆中的稳定事实。
闸三 · 越权闸。 记忆写入须过权限校验，默认拒写未授权来源，防止越权注入污染知识库。这一闸与 AI 安全 讨论的权限边界直接相关：记忆的写入权限应当比读取权限更严格，因为错误写入的影响面远大于读不到。
把常见方案放在一起对比，可以看清各自的代价：
| 维度 | 长上下文硬塞 | RAG 检索 | 专用记忆库 | 知识图谱 |
|---|---|---|---|---|
| 成本 | 高（token 线性涨） | 中 | 中 | 高 |
| 多轮一致性 | 短会话尚可 | 弱（不记轨迹） | 强 | 强 |
| 可审计 | 差 | 中 | 强 | 强 |
| 落地复杂度 | 低 | 中 | 中 | 高 |
| 适配场景 | 单轮问答 | 静态知识问答 | 多轮智能体助手 | 强关系推理 |
选型不看哪套方案更先进，而要看智能体是「答一次」还是「陪一路」。如果是单轮问答，长窗口硬塞就够；如果要做长期陪伴，专用记忆库的成本优势会迅速显现。
---
把一切塞进上下文会稀释信号、抬高成本，甚至让智能体被旧结论带偏。据 CSDN 上的工程实践总结，对策是严格预算控制（条目数 + 字符数双封顶）加分层蒸馏：L0 原始内容 → L1 原子事实 → L2 场景 → L3 画像，只把 L2/L3 作为快速引导，具体事实再检索回退。
装配上下文时可以按块管理预算并按优先级裁剪，一个常见的分块方式是：系统提示词、程序记忆、检索到的语义记忆、会话摘要、最近几轮历史消息、当前用户输入。裁剪顺序应当是：先裁历史消息，再裁情景记忆，语义记忆尽量保留，因为语义记忆是长期沉淀的知识，价值最高。
还有一项常被忽略的优化是符号化压缩——把冗长的工具日志压缩成紧凑图并保留节点引用，在保留可追溯性的同时显著降低 token。这条与 大模型调用成本怎么控制 里的模型路由是互补的：路由减少单次调用的成本，记忆压缩减少调用的次数与体积。
团队记忆不等于所有信息透明。据 CSDN 工程实践文章的表述，应把含敏感信息的记忆默认设为 private，分享必须是显式动作；落地 ACL（按团队、用户、智能体、可见性先收窄再检索），新记忆默认 private，对受限资产用精细授权。
有一条是硬性的：绝不在记忆里存储密钥、凭证或个人隐私数据。这类内容应走独立的安全存储，而非记忆层。记忆会被检索、被摘要、被跨会话拼接，一旦密钥进入记忆层，它就出现在了每一次模型调用的上下文里，暴露面远大于直接存储。
回到前面提到的双时态模型。给每条记忆打「事实时间」（事情真正发生的时间）与「摄入时间」（系统记录它的时间）双时间戳，支持追溯性更正；加入新鲜度元数据与冲突检测（新事实与旧记录比对后合并、更新或标记待裁决）。
时效治理的另一半是用户侧的控制权。记忆是关于用户的，删除权与导出权必须落到实现上——这一点在个人信息保护框架下不是可选项。这一条与医疗健康类项目中的脱敏要求同理，落地思路可参考 医疗信息化的数据隐私与操作留痕。
记忆操作如果没有埋点，出问题时无法定位。据 agentpatterns.ai 的 OpenTelemetry GenAI 语义约定整理，记忆相关操作已经是一等 span 类型：search_memory、create_memory、update_memory、delete_memory，与 chat、embeddings、retrieval、execute_tool、invoke_agent 并列。
这个约定值得注意的点是：它把「检索记忆」和「检索文档」在遥测层面区分开了。也就是说，一次模型调用的召回质量下降，可以从 trace 上直接看出是知识库召回的问题还是记忆召回的问题，而不用靠猜。评测体系如何围绕这些 span 展开，可参考 AI Agent 可观测性与评测。
记忆的写入量与删除量应当是被监控的指标，而不是事后没人看的日志。一个突然暴涨的写入量往往意味着某个循环在反复写入垃圾记忆，而一个长期为 0 的删除量意味着遗忘机制根本没生效。
评估记忆质量时，会遇到 LoCoMo（长对话记忆）、LongMemEval（大规模异构记忆库中的准确检索）、HaluMem（召回时的幻觉抵抗，专门衡量系统是调取已存事实还是编造看似合理的替代品）等基准。
但引用这些数字时必须区分来源。以 Meta Muse Wonder 为例：据 Meta 自身测试，Muse Wonder 在 MemoryBench 上超过 Fable、Opus 与 Astra；而 Artificial Analysis 独立评测给出的 Intelligence Index 分数是 Muse Wonder 52、Muse Wonder Full 56，对比此前 Muse Spark 1.3 的 48。两组口径方向一致但都属特定来源，厂商公布的基准对比未经第三方独立验证。第三方评测机构自己也提示，基准表现并不等同于模型在不可预测的企业生产环境中的可靠性。
同样值得注意的是benchmark的时效性：EverMind 在其产品页公布 LoCoMo 93.05%、LongMemEval 83.00%、HaluMem 召回 90.04% 以及 p95 检索延迟低于 500 毫秒，同时明确说明这些是自家发布的结果、不是与竞品的共同测试集；Membase 在其对比文中被指出未在 LoCoMo、LongMemEval、HaluMem 上公布可比数据。如实指出这种数据缺口，对技术选型比把营销口径等同于实测结果更有价值。
---
记忆架构的分层决策之外，还有一个正在变化的变量：推理算力的位置。2026 年 10 月 13 日，面壁智能发布新一代端侧多模态大模型 MiniCPM-V 4.7，包含 35B-A3B 与 1B 两个版本。据环球网与每日经济新闻的报道，35B-A3B 采用 MoE 架构，总参数 350 亿、每次推理仅激活 30 亿，约 3GB 内存即可运行，iPad Pro 实测解码速度为 15+ token/s，发布当日支持瑞芯微、NVIDIA、Intel 和 Apple 等主流芯片平台。
这条消息对记忆设计的意义在于：当足够强的模型可以跑在设备本地，记忆的物理归属问题就变了。如果推理在云端，记忆几乎必然存在服务端；如果推理在端侧，部分记忆可以是本地私有的，云端只同步用户明确选择共享的部分。这对隐私敏感型场景是实质性改变。
不过要清醒看待这类进展的边界。端侧模型的内存约束（3GB 左右）意味着本地记忆的容量上限很硬，语义层这类需要较大向量存储的部分短期内仍难完全本地化。更现实的做法是分层：程序记忆与近期情景记忆本地，语义记忆与跨设备情景记忆在服务端。存储成本与隐私要求的分层逻辑，和 2.1 节四层架构的划分其实是同构的。
---
综合上面五部分，一套务实的落地顺序如下：
search_memory、create_memory、update_memory、delete_memory 埋成 span，把写入量与删除量纳入监控，围绕 LoCoMo、LongMemEval、HaluMem 一类基准建立自己的回归集。对于中小规模项目或单会话任务，第五、六步可以省掉——一份写得好的项目说明文件和干净的上下文就足够。上述六步的完整工程化保障，涵盖需求分析、技术设计、开发实现到部署上线的环节，可参考科芃科技的交付流程与工程与质量保障说明。
---
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 把所有历史塞进长上下文 | 成本线性上涨、注意力被稀释 | 分层存储 + 按优先级裁剪 |
| 记忆和知识库建同一张表 | 临时结论污染静态事实 | 两套表、两套更新策略 |
| 情景记忆检索不做时间衰减 | 旧约束被当成新约束 | 双时间戳 + 时间衰减 |
| 语义记忆静默覆盖 | 无法审计、结论不可追溯 | 冲突闸裁决，保留双版本 |
| 程序记忆塞进向量库 | 召回时机不可控 | 留在提示词与工具描述 |
| 默认全存，不设准入 | 记忆库被噪音淹没 | 设准入条件 + 定期清理合并 |
| 记忆层存放密钥凭证 | 每次调用都暴露 | 走独立安全存储 |
| 记忆写入不做权限校验 | 越权注入污染知识库 | 越权闸 + 默认拒写未授权来源 |
| 记忆操作不打遥测 | 出问题无法定位 | 按 OTel GenAI 约定埋 span |
| 只看厂商基准选型 | 被营销口径误导 | 区分厂商口径与独立评测 |
| 缺少用户侧删除与导出 | 合规风险 | 记忆表按用户维度隔离并支持导出 |
---
长期记忆正在从一项加分功能变成智能体的基础能力。Meta 把 Active Memory 与 Active Focus 作为前沿模型的核心能力，蚂蚁灵光据新浪科技 10 月 11 日报道把「长期记忆 + 主动执行」作为新版本升级的重点，腾讯元宝被曝开发承载个人长期记忆的独立 App，头部厂商的路线虽各不相同，但对「跨会话保持连续性」这件事的判断是一致的。
对企业来说，这带来的不是「要不要追一个新概念」的判断题，而是一组具体的工程问题：记忆归谁所有、分几层存储、什么时候忘、谁能写、怎么审计。这些问题的答案都不在提示词里，而在架构里。把这五道问题在动手前想清楚，比上线后返工要划算得多。
需要针对具体场景讨论记忆架构的落地细节，可以查看人工智能应用开发与软件研发的服务说明，或通过联系我们页面沟通需求。
关键区别在于内容的来源与生命周期。知识库是注入静态事实资料——产品文档、公司制度、操作手册，靠切分、向量化、混合检索与重排被召回，更新靠人工或批量同步。长期记忆是记录交互过程中产生的动态信息——用户偏好、上次确认过的约束、踩过的坑、已完成的任务，靠对话与工具调用自动积累，更新靠写入策略与冲突消解。工程上最常见的错误是把两者建在同一张表里，导致情景记忆里的临时结论污染了语义层的稳定事实。判断标准很简单：这条信息是「资料里本来就有的」还是「这次交互才知道的」。此外还有第三个容易混淆的概念是上下文工程，它解决的是单次推理里塞什么，用压缩、滚动摘要与窗口裁剪实现，目的是保住高价值信息而非跨会话保留。
需要，两者解决的不是同一个问题。据 ClaudeWave 在 2026 年 10 月引用的 HackerNoon 分析，Claude Opus 4.8 可选的 1M token 上下文窗口会给人「问题已解决」的错觉，但把更多历史塞进上下文会让每次调用更贵，而且不保证模型优先关注真正重要的部分；设计良好的记忆决定什么该进上下文，比指望模型从草料堆里找针更省也更可控。具体取舍上，滚动摘要与事实抽取在 token 削减上最强，但摘要本质有损，可能抹平例外情况或丢掉硬约束；检查点快照与历史步骤检索在关键事实保真上更靠前。务实做法是分工——用摘要压缩闲聊，用结构化存储保住事实。另外长窗口不等于注意力均匀，「中间遗忘」现象说明把关键信息放在窗口首尾比堆在中间更有效。
这必须在动手建表前决定，因为它决定所有读写逻辑的写法，是真正决定架构走向的前置判断。归智能体所有，就是在做「这个智能体的履历」——多个用户共享一套记忆，相当于给智能体喂了所有人的交互历史，适合客服机器人与内部知识助手。归用户所有，就是在做「这个用户的档案」——每个用户一套记忆，智能体只是路过读档的人，这是绝大多数面向个人助手的场景应该走的路线。归用户所有的实现里有一条硬性要求：所有记忆的键必须带 user_id，所有检索必须在用户维度做前置过滤。多租户场景下漏掉这一步，串号是必然结果而非意外。记忆表本质上是权限模型的一部分，不只是检索索引，这一点与企业后台的数据边界设计是同一套逻辑。
根因是缺三道「遗忘闸」。第一道是过期闸：带 TTL 的临时记忆到期即清，防止陈旧事实污染后续推理；情景记忆检索时如果忽略时间，还会把三个月前的旧要求当成本周的新约束。第二道是冲突闸：新记忆与旧记忆矛盾时，按来源权威度与时间戳裁决，且不静默覆盖——用户昨天说用 MySQL、今天说迁移到 PostgreSQL，系统必须知道后者覆盖前者。冲突应标记为待裁决或保留双版本并注明生效时间，静默覆盖在审计场景下不可接受。第三道是越权闸：记忆写入须过权限校验，默认拒写未授权来源，防止越权注入污染记忆库。更棘手的是记忆中毒——被注入的错误或恶意记忆会在多个智能体间传播，对策是给每条记忆打双时间戳（事实时间与摄入时间）支持追溯性更正，并对来源智能体打标防止跨智能体污染。
不能把 MCP 当存储，它解决的是接口而非持久化。据 ClaudeWave 在 2026 年 10 月整理的分析，Model Context Protocol 诞生时就是无状态的，这是有意的设计——每次工具调用是一次请求与响应，协议本身没有提供把一次会话学到的东西带到下一次会话的原生机制。正确的用法是把记忆暴露为另一个 MCP 服务，提供读写工具，但存储的设计、schema 与遗忘策略仍然是团队自己的责任。这个分离有一个明确好处：记忆变得可移植——它住在 MCP 接口后面，任何兼容客户端都能消费而不必重写持久化逻辑。2026 年 10 月的国内动态显示这个方向正在被验证：据新浪科技 10 月 11 日报道，蚂蚁灵光新版本正是通过 Skill 与 MCP 协议接入钉钉和智能家居。协议层正在成为智能体生态的国际通用接口，但记忆的治理责任不会转移给协议本身。
分两层看。第一层是自动化基准：LoCoMo 测长对话记忆，LongMemEval 测大规模异构记忆库中的准确检索，HaluMem 专门测召回时的幻觉抵抗——衡量系统是调取已存事实还是编造看似合理的替代品。第二层是生产环境监控：按 OpenTelemetry GenAI 语义约定埋点，记忆操作已经是一等 span 类型，包括 search_memory、create_memory、update_memory、delete_memory，与 chat、retrieval、execute_tool 并列——这意味着召回质量下降时可以从 trace 上直接区分是知识库召回的问题还是记忆召回的问题。写入量与删除量必须纳入监控：写入量突然暴涨往往意味着循环在反复写垃圾记忆，删除量长期为 0 意味着遗忘机制没生效。引用基准数字时务必区分厂商口径与独立评测——厂商公布的对比通常未经第三方独立验证，且基准确认的能力不等于生产环境中的可靠性。