P3：Agent 记忆系统设计

Easy Data x AI 课程 · 道篇 · 第三期
给 Agent 加记忆，难的不是“存”——难的是“忘”。

开场：那个永远记不住你的同事

想象你公司新来了一个助理，聪明、勤快、有问必答。你第一天告诉他：“我负责海外市场，汇报对象是VP，所有文档请用英文写。”他干得很好。

第二天你找他帮忙写一份报告。他问你：“请问你负责什么业务？汇报对象是谁？需要用什么语言？”

你又说了一遍。第三天，同样的问题。第四天，还是一样。

你会怎么想？这个人是不是有什么问题？

不，他没有任何问题——除了一个：他每天早上醒来，都会彻底忘记前一天发生的所有事情。

这就是今天绝大多数 AI 助手的真实状态。

你用了三个月的 ChatGPT、Claude 或者任何 AI 工具。你告诉过它你是做什么的、你喜欢什么样的回答风格、你的项目背景是什么。但每次开一个新对话，一切归零。你不得不重新自我介绍，重新解释上下文，重新设定偏好。

它不是变笨了——它每次都一样聪明。问题是，它根本不记得你。

这不是一个小小的体验瑕疵。这是 AI 从“工具”变成“助手”的根本障碍。一个不记得你的助手，永远只能提供通用的、标准化的服务。而一个记得你的助手，才能真正理解你、适应你、越用越好用。

今天这节课，我们来拆解这个问题：为什么 AI 会“失忆”？记忆系统应该怎么设计？以及——为什么这件事最难的部分，不是让 AI 记住，而是让 AI 学会忘记。

第一部分：为什么 AI 助手会“失忆”

在 F1 中我们讲过，大模型有一个上下文窗口——它一次能处理的信息容量。你可以把它想象成一张工作台：所有对话内容都摊在这张台子上，模型看着台上的内容来回答你的问题。

关键在于：每次新对话开始，这张工作台会被彻底清空。

上一次对话中你说的所有话、提供的所有背景、表达的所有偏好——全部消失。不是模型“忘了”，而是那些信息根本没有被保存到任何地方。工作台清空了，新的对话就是一张白纸。

你可能会说：“那现在不是有些 AI 产品已经有记忆功能了吗？比如 ChatGPT 的 Memory。”没错，但这恰恰证明了一件事——记忆不是大模型自带的能力，而是产品团队在模型之外额外建造的系统。模型本身没有任何地方可以存储跨对话的信息，必须有一个外部的数据系统来承担这个角色。

这意味着什么？意味着 “AI 没有记忆”本质上是一个数据问题——不是模型不够聪明，而是没有地方存用户的数据。

这和 F1 中我们讨论的“个性化盲区”是同一个根因。大模型只有训练数据，没有你的数据。记忆系统要解决的，就是在模型之外，为每个用户建立一个持久的数据层。

那么，这个数据层应该存什么？怎么组织？我们需要一个框架。

第二部分：Agent 记忆的分类框架

业界已经形成了一套被广泛接受的分类方法，来自 CoALA 论文（Cognitive Architectures for Language Agents），LangChain 等主流框架已采用。

不用被名字吓到——逻辑非常直觉。Agent 的记忆分为短期记忆和长期记忆，长期记忆又细分为三种类型。

短期记忆：桌上的便利贴

短期记忆就是当前这一轮对话的上下文。你在对话中说的每一句话、AI 回复的每一段内容，都在短期记忆里。

它的特点是：随用随取，但会话结束就没了。

类比一下：你开会时在桌上贴了一堆便利贴，记录讨论要点。会议期间随时可以瞄一眼。但会议结束你把桌子一收拾，便利贴扔了，这些信息就消失了。

大多数 AI 产品目前只有这一层记忆。这就是为什么每次新对话都要从零开始——它只有便利贴，没有档案柜。

长期记忆：跨越对话的持久存储

长期记忆是存在于会话之外的、可以持久保存的信息。这是让 AI 真正“认识你”的关键。

CoALA 框架把长期记忆分成三种，每种记的东西不一样，用途也不一样：

第一种：语义记忆——百科全书

语义记忆存储的是事实和知识。关于用户的确定性信息，比如：

“用户是 Python 开发者”
“用户偏好简洁的回答”
“用户的公司是做跨境电商的”
“用户对 Docker 比较熟悉，但对 Kubernetes 了解较少”

就像一本百科全书，记录的是“什么是什么”——确定的、可以查阅的事实。一旦记住，后续对话中用户不需要再说一遍“我是 Python 开发者”，Agent 就会自动用 Python 的例子来解释。

第二种：情景记忆——日记本

情景记忆存储的是过去的经历和交互。不是抽象的事实，而是具体发生过的事情，比如：

“上次用户问部署问题时，Docker 方案成功解决了”
“用户之前尝试过 Redis 缓存方案，但因为数据一致性问题放弃了”
“用户上周讨论过要把系统从 AWS 迁移到阿里云”

就像一本日记，记录的是“发生了什么”——什么时候、在什么情况下、用了什么方法、结果怎么样。

情景记忆在实践中常以 few-shot 示例的形式发挥作用——Agent 从过往成功经验中学习，用来处理当前类似的问题。一个有情景记忆的 Agent，不会在同一个坑里让用户掉两次。

第三种：程序记忆——操作手册

程序记忆存储的是行为规则和工作流程。它规定了“遇到某种情况该怎么做”，比如：

Agent 的 System Prompt（系统提示词）
“用户问代码问题时，先给解释再给示例”
“回答前先确认用户的技术背景”
“当遇到多步骤任务时，先列出步骤大纲再逐步执行”

就像一本操作手册，规定的不是事实，而是行为方式。

重要特性：程序记忆是三种记忆中唯一一种 Agent 可以自我修改的。如果用户多次表示“回答太长了”，Agent 可以自动加一条“回答要简洁”的规则。这就是“AI 从反馈中学习”的底层机制——不是模型重新训练了，而是它修改了自己的操作手册。

值得预告：程序记忆和下一期要讲的 Skill 天然相连。Skill 本质上就是被外部化、结构化了的程序记忆。P4 再展开。

三种记忆的对比

记忆类型	存什么	类比	举例
语义记忆	事实和知识	百科全书	“用户是 Python 开发者”
情景记忆	过去的经历	日记本	“上次用 Docker 方案解决了部署问题”
程序记忆	行为规则	操作手册	“回答代码问题时先解释再给示例”

理解了这个框架，你就有了一个分析工具：当你觉得 AI 助手”不够懂我”的时候，可以问自己——它缺的是哪种记忆？

是不记得关于你的基本事实（语义记忆缺失）？是不记得之前的交互经验（情景记忆缺失）？还是不知道该怎么和你打交道（程序记忆缺失）？

不同的缺失，对应不同的产品设计决策。

第三部分：记忆的读写——什么时候记、怎么想起来

有了分类框架，下一个问题是：记忆的读和写应该怎么设计？这是产品经理需要做出的具体决策。

写入：什么时候记？

记忆写入有两种主要模式：

实时写入——Agent 在对话过程中主动判断“这条信息值得记住”。比如用户说“我下个月要去日本出差”，Agent 当场决定把这条信息存入语义记忆。

好处是透明——用户能感知到 AI 在记住什么。缺点是占用对话中的推理资源。

异步写入——对话结束后，后台任务从对话历史中提炼值得保存的信息。

好处是不干扰对话体验，缺点是写入有延迟。两种方式没有绝对优劣，有些产品会结合使用：对话中轻量实时记录，结束后深度异步提炼。

读取：怎么想起来？

记忆写入了，还得在正确的时候被想起来。这个“想起来”的过程，实际上是一个检索问题。

想象一个优秀的私人助理：你说“帮我订个餐厅”，他会想起你喜欢的菜系和常去的地点，而不会把你三个月前讨论的服务器部署方案也翻出来。他不是按时间顺序翻记忆，而是根据当前话题，自动想起最相关的信息。

Agent 的记忆读取也是同样的逻辑——基于语义搜索召回相关记忆，而不是按时间线浏览历史。

这和 P2 讲过的 RAG 是同一个检索问题。RAG 从知识库检索相关文档，记忆系统从用户历史检索相关记忆——底层机制一模一样。记忆系统又一次验证了“数据的存储与检索是 Agent 一切能力的基础”这个判断。

第四部分：记忆系统真正的设计挑战——“忘”比“存”难

到这里，你可能觉得记忆系统的逻辑已经很清晰了：分好类、存进去、需要时检索出来。听起来不太难？

真正的挑战在后面。

记什么：不是所有对话都值得存

你和 AI 助手的一次对话可能有上千字。其中有闲聊、有试探、有修改、有最终确认。如果把原始对话全部存进记忆，不出一个月，记忆库就会被大量无用信息淹没。

好的记忆系统需要提炼——从对话中萃取关键事实，而不是做对话录音。

比如一段对话中，用户先说“我在考虑用 React 还是 Vue”，后来说“算了，我们团队决定用 Vue 了”。应该记住的是“用户团队使用 Vue”，而不是把整个纠结过程都存下来。

这就像一个好的助理做会议纪要：他记录的是结论和决策，不是每一句发言的逐字稿。

忘什么：这才是最难的部分

让我们用一个具体的场景来说明这个挑战。

三个月前，你和 AI 助手聊天时说：“我特别喜欢意大利菜，尤其是正宗的拿坡里披萨。”AI 把这条偏好记住了。

过去三个月里，每次你说“帮我推荐个餐厅”，它都优先推荐意大利餐厅。体验很好。

然后昨天，你说了一句：“我最近开始吃素了。”

现在问题来了：下次你让 AI 推荐餐厅，它应该推荐什么？

如果 AI 只看最新的信息——推荐素食餐厅。但你“吃素”也许只是最近一段时间的饮食调整，并不意味着你永远不吃意大利菜了。

如果 AI 只看历史偏好——推荐意大利餐厅。但你明确说了最近在吃素，推荐一个满桌肉食的餐厅显然不合适。

最好的回答可能是推荐一家有优质素食选项的意大利餐厅，或者先问一句“你最近在吃素，要不要推荐一些素食友好的餐厅？还是想找一家有素食选项的意大利餐厅？”

一个真正优秀的私人助理会怎么做？他不会因为你说了一句“最近在吃素”就把你过去所有的饮食偏好全部删掉。他也不会无视你最新的变化继续推荐五分熟牛排。他会做的是：把旧的偏好权重降低，把新的偏好权重提高，但保留两者，在合适的时候做出综合判断。

这就是“忘”的精髓——不是删除旧数据，而是对旧信息自然降权。

让我们把这个挑战再推进一步。

你不只有饮食偏好。你的技术栈偏好在变（从 Java 转向了 Go）、你的工作职责在变（从开发转向了技术管理）、你的项目阶段在变（从架构设计进入了上线冲刺）、甚至你的沟通风格偏好在变（之前喜欢详细解释，最近赶时间只要结论）。

人是不断变化的。一个好的记忆系统必须跟得上这种变化。

如果 AI 永远用你三个月前的画像来服务你，时间越长，它反而越“不懂你”——因为它记住的是一个过去的你。这比没有记忆可能更糟：没有记忆时用户有预期（“它不认识我，我需要说清楚”），有了过期记忆后用户会困惑（“它明明记得我，但怎么推荐的都不对？”）。

所以，记忆系统的核心设计挑战不是”怎么存”——存储在技术上并不难。真正难的是设计一套时效性管理机制：什么信息应该长期保持高权重？什么信息应该随时间自然衰减？

下面这套框架，就是我们在设计记忆系统时用来回答这些问题的心法。

怎么忘：一套基于艾宾浩斯曲线的记忆衰减策略

我们将从认知科学的方向去探索，并把这套思路系统化，将其翻译成 Agent 记忆系统可以落地的产品设计。

艾宾浩斯曲线

19 世纪末德国心理学家赫尔曼·艾宾浩斯通过实验发现：人类对新信息的记忆不是等权保存的。如果不被反复使用，保留率会随时间快速下降，大约一小时后只剩 44%，一天后 33%，一个月后 21%。

但如果一条信息被反复回忆和使用，它会从短期记忆逐渐固化为长期记忆，衰减速度大幅降低。

艾宾浩斯用一条简洁的公式描述这个规律：

R(t) = e^(-λt)

其中 R(t) 是保留率（还记得多少），t 是时间，λ 是遗忘速率——λ 越大，忘得越快。曲线形态是指数衰减：刚记住时权重最高，之后先快后慢，逐渐趋于平缓。你可以把它理解成一条记忆保鲜曲线，不是在某一刻突然归零，而是持续、可预测地变淡。

这对 Agent 记忆系统意味着什么？

说明遗忘的核心动作不是删除，而是降权。 助理不会因为你最近开始吃素，就把喜欢意大利菜从档案里撕掉。那条旧偏好还在，只是它在推荐决策里的影响力，会随时间和使用情况自然减弱。而新信息因为刚写入、权重高，会优先被想起。

这其实是生物进化出的一套高效信息管理策略：不是所有信息都值得永久保存，经常被用到的要牢牢记住，不再被用到的就让它自然淡去。

遗忘分数

要让降权可执行，记忆系统需要为每条信息算出一个遗忘分数，取值在 0 到 1 之间。分数越高，说明越新鲜、越可靠；分数越低，说明越接近被遗忘的边缘。

艾宾浩斯的公式描述的是实验条件下、纯靠时间流逝的遗忘。落到 Agent 记忆里，工程师在前人研究基础上做了扩展：真实的记忆不只受时间影响，还取决于刚写入时有多重要、放在哪一层、后来有没有被再次提起。扩展后的计算思路可以概括为：

遗忘分数 = 初始权重 × 时间衰减

初始权重是写入时的起跑线，时间衰减则沿用艾宾浩斯指数下降的规律——越久没被想起，乘数越小。档案柜里的长期记忆比便利贴上的临时便签掉分更慢，正是分层存储在发挥作用。

被再次访问时，遗忘分数会回升，计时会从那一刻重新算起。这对应我们前面说的：忘不是删，而是权重自然变淡；被再次需要时，记忆会重新变“新鲜”。

围绕这个分数，写入、存续、检索三个阶段各做一件事：

写入：先定起跑线。 不是所有对话都值得同等地记住。用户是 Python 开发者、偏好简洁回答——这类关于本人的稳定信息，初始权重应该高；一句“今天天气不错”的闲聊，起跑线就应该低。

存续：让时间自然拉低分数。 写入之后，如果再也没被提起，遗忘分数会逐步下降。三个月前喜欢意大利菜、之后再也没聊过吃的，分数会慢慢变低；昨天刚说最近在吃素，分数还处在高位。便利贴上的临时信息掉得快，档案柜里的核心偏好掉得慢——这些都是前面讲过的分层存储在“忘”上的体现。

检索：相关度和新鲜度一起看。当用户说“帮我推荐个餐厅”时，系统不能只看哪条记忆和“餐厅”最像，还要看哪条更新鲜。“最近在吃素”这条消息相关且新鲜，那就需要排前面；而“三个月前的意大利菜”偏好虽然仍然相关，但分数已经降低所以退居其次。

用一句话概括：最终排名 ≈ 语义相关度 × 遗忘分数。

遗忘分数降到什么程度该处置？

遗忘分数可以持续下降，但记忆库不能无限膨胀，所以我们还需要一套主动淘汰策略：根据分数和访问情况决定什么时候把一条记忆从活跃服务中移出。

关键原则是，淘汰是分级的，不是非删即留。 比如在 PowerMem 中就给出了一套具体的处置规则：

处置动作	触发条件	系统行为	用户感知
降权（默认）	遗忘分数在下降，但尚未低到需要处理	仍保留在库中，检索排名自然靠后	逐渐想不起来，等于软遗忘
归档	遗忘分数低于 0.3，或超过 30 天未被访问	移出日常检索，不再自动想起	日常对话中不再出现，但可查历史
硬淘汰	遗忘分数低于 0.1 且多轮机会都未被唤醒；或写入后 7 天内从未被用到	从存储中删除	彻底移除

降权是默认路径。 大多数“忘”发生在检索层——分数低了，自然排不上去，对用户来说就等于忘了。

归档是软淘汰。 分数低到不再值得占用日常带宽，但仍有历史参考价值。用户问“我去年还说过什么”时，仍有机会找到。

硬淘汰宜保守。 真正的删除操作会被两类信号触发：一是分数已经很低，且多次该被想起时都没被唤醒；二是写入后长期零访问、从未进入任何一次决策，留着只会添噪声。

而被反复使用的记忆，则应该升到更高层级、衰减更慢，比如用户是一名 Python 开发者这条信息如果被一次次验证，就应该从便利贴挪进档案柜。每次被想起，都是一次重新巩固。

一条记忆的衰减生命周期

把上面的机制串起来，任意一条信息在记忆系统里大致会经历这样的旅程：

用户说了一句话
  → 评估重要性，定下初始权重和存储层级
  → 写入后遗忘分数随时间自然下降
  → 被再次提到？分数回升，可能升到更高层级
  → 分数持续走低 → 降权 → 归档（低于 0.3）→ 硬淘汰（低于 0.1 或长期无人使用）
  → 检索时：语义相关度 × 遗忘分数，决定会不会被想起

遗忘不是记忆系统的事后补救，而是贯穿写入、存续、检索全流程的核心设计维度。 从写入那一刻起，遗忘分数就在变化；真正决定一条记忆命运的，是它有没有在后续交互中被再次需要。

冲突了怎么办：记忆冲突解决策略

吃素和意大利菜的例子，除了引出问题该怎么忘，还留了一个更具体的追问：两条相关记忆同时被想起时，听谁的？记忆冲突处理，解决的就是这个裁决问题。

先识别冲突形态

不同形态的冲突需要不同的处理方式。产品团队首先要做的，是判断眼前属于哪一种：

冲突类型	举例	特征
直接矛盾	爱喝咖啡，后来改喝茶	新旧互斥，必须二选一
时间演进	在用 Flask，后来改用 FastAPI	版本更新，可合并为一条
粒度差异	喜欢意大利菜，同时最近在吃素	可并存，检索时综合判断
历史与当前	去年负责人是 A，现在是 B	两条都成立，适用时段不同

形态识别错了策略一定跟着错。并存偏好被当成直接矛盾去删旧留新，会误伤上下文；明确变更被当成并存来处理，用户又会觉得 AI 跟不上变化。

三种常见解决策略

识别出形态之后业界通常从以下三种策略中选择，也可以组合使用：

策略	做法	适合什么冲突	典型场景
时间戳优先	新信息覆盖旧信息	直接矛盾、时间演进	团队决定用 Vue、从 Java 转向 Go
置信度加权	新旧并存，按新近度、确认次数、遗忘分数排序	粒度差异	最近在吃素 vs 长期喜欢意大利菜
人工介入	检测到冲突时询问用户	高敏感或系统不确定	换工作、健康与财务相关话题

时间戳优先适合用户已经做出明确决定的场景。从考虑 React 还是 Vue，到团队决定用 Vue，应记住的是结论，写入时直接更新或合并旧记录，而不是让两条矛盾信息并存。

置信度加权适合新旧可能都对、只是权重不同的场景。最近在吃素遗忘分数高，喜欢意大利菜分数已降，检索时两条都参与排序，新偏好自然靠前。这和前面的遗忘分数机制直接衔接：衰减本身就是在做软裁决。

人工介入适合系统不该替用户做主的场景。检测到潜在冲突时问一句是否需要保留旧偏好，把裁决权交给用户。后面讲到的记忆查看与修正，本质上也是这一策略的延伸。

实际产品中，三种策略往往组合使用：明确事实变更走时间戳优先，阶段性偏好走置信度加权，敏感信息或系统拿不准时走人工介入。

决策顺序可以记一句：先判形态，再选策略；能自动裁决的就自动处理，不该替用户做主的再询问确认。

什么时候处理冲突？

冲突处理有两个时间点。

写入时。新信息进来就和存量记忆比对，决定新增、更新、合并还是标记失效，适合处理明确的矛盾和时间演进，记忆库更干净。
检索时。矛盾记忆暂时都留着，被想起时再按时间和遗忘分数综合排序，适合处理可并存的粒度差异。

比较好的做法是两者进行配合：简单事实在写入阶段定下来，复杂偏好在检索阶段按分数综合。落到产品体验上，用户说决定用 Vue 了，下次就不该再推 React；用户说最近在吃素，优先推荐素食友好选项，但不必抹掉过去的饮食偏好；用户说换工作了，最好确认一下是否要替换旧的职业画像。冲突处理做对了，用户才会觉得 AI 跟得上变化，而不是活在过去。

给谁看：用户信任比功能完善更重要

记忆系统还有一个容易被忽视但极其关键的维度：用户是否知道 AI 记住了什么？

想象一个场景：你和 AI 助手随口聊到“最近工作压力挺大的，考虑过要不要换工作”。两周后，AI 在一次对话中主动提起：“上次你提到在考虑换工作，需要帮你更新简历吗？”

你什么感觉？

有些用户会觉得贴心。有些用户会觉得被监视。差别在于——用户是否知道、是否预期 AI 会记住这些内容，以及用户是否有能力管理这些记忆。

这不只是一个隐私合规的问题（虽然合规确实也很重要）。这是一个产品信任设计的问题。

好的记忆系统应该让用户：

知道 AI 记住了什么——提供一个可查看的记忆列表
能够修正错误的记忆——“不，我不是 Java 开发者，这条记错了”
能够删除不想被记住的内容——“我不希望你记住这个”
理解记忆会如何影响 AI 的行为——“因为你说过偏好简洁回答，所以我精简了这段解释”

ChatGPT 的 Memory 功能在这方面做了一个不错的尝试：用户可以查看所有被记住的条目，可以逐条删除。这不是技术炫技，而是产品团队深刻理解了一件事——如果用户不信任你的记忆管理，他们宁可你什么都别记。

多 Agent 的边界：记忆该共享还是隔离？

最后一个设计挑战，是一个目前行业还没有标准答案的问题。

今天的用户越来越多地同时使用多个 AI 助手：工作中用 Cursor 写代码，日常用 ChatGPT 问问题，专业领域用某个垂直 AI 工具。每个 Agent 都在各自积累关于你的记忆。

这些记忆应该共享还是隔离？

共享的好处显而易见，你不需要在每个 AI 工具中重复自我介绍：在 ChatGPT 里说过自己是 Python 开发者，Cursor 写代码时应该直接知道，而不是每次开新对话都从零讲起。

但风险也同样明显。你在 ChatGPT 私人聊天里吐槽“最近工作压力挺大，考虑过要不要换工作”，你希望 Cursor 写代码时也知道吗？在某个平台上聊过的健康、财务、家庭话题，你愿意另一个平台的 AI 也能看到吗？

隔离虽然安全，但用户体验是割裂的：每换一个工具就要重新“教育” AI。一个记得你在做数据分析项目的 ChatGPT，和一个完全不知道项目背景的 Cursor，用起来像是两个互不相干的助理。

这个问题的本质，是数据主权和隐私边界的划定，这不仅仅是技术问题，更是产品哲学和商业模式的选择。

何时隔离，何时共享

没有一种策略适合所有场景，产品团队需要先回答：这条记忆，在什么边界内是合理的？

场景	建议策略	理由	举例
默认隔离	各 Agent 只访问自己的记忆	防止串味、保护隐私、职责清晰	Cursor 记住的项目分支策略，不必泄露给通用聊天助手
按用户共享	同一用户跨 Agent 共享基础画像	减少重复自我介绍，提升一致性	用户是 Python 开发者、偏好简洁回答——各工具都应知道
按项目共享	同一任务/项目内的 Agent 互通	协作需要共同上下文	开发 Agent 和测试 Agent 共享同一个上线冲刺的项目背景
显式授权共享	用户确认后才跨边界流通	平衡体验与信任	用户主动勾选“允许工作助手读取个人助手的偏好设置”

一个实用的判断标准：这条记忆如果出现在错误的 Agent 里，用户会不会感到不适？ 会则隔离；不会可以考虑共享。

回到前面的例子。用户是 Python 开发者，这条信息跨工具共享能增强体验感且风险低；而用户最近在考虑换工作这条信息，敏感度高，默认应隔离，除非用户明确授权。

命名空间：给记忆划界

要让隔离和共享不变成一句空话，记忆系统需要从设计之初就有一套命名空间：给每条记忆贴上“属于谁、属于哪个 Agent、属于哪段任务”的标签，检索时按标签过滤。

业界实践里，命名空间通常分三层，由粗到细：

第一层：用户。 同一个人在不同 Agent 里的记忆，首先必须能区分开“这是谁的数据”。多用户产品里，这一层是硬边界：A 用户的记忆绝不能被 B 用户看到。前面提到过的“用户信任设计”，在这一层是底线要求。

第二层：Agent。 同一个用户名下，不同 Agent 各自维护独立的记忆空间。Cursor 记住的代码规范、ChatGPT 记住的闲聊偏好、某个垂直工具记住的领域知识，大家默认互不干扰。写入时自动打上 Agent 标签，读取时默认只查自己的；需要协作时，再主动跨 Agent 检索。

第三层：任务 / 项目。 同一 Agent、同一用户下，还可以按项目或会话进一步分组。比如“Q2 上线冲刺”和“日常运维”是两套上下文，前者里的临时决策，不应污染后者的长期记忆。这一层解决的是：不是“所有记忆一股脑共享或隔离”，而是在合适的粒度上共享。

三层组合起来，就像档案室的编目规则：

用户（谁的档案）
  └── Agent（哪个部门的助理经手的）
        └── 项目 / 任务（哪次合作产生的）

写入时确定归属，检索时按范围过滤——默认窄（只看自己的），需要协作时放宽（跨 Agent、跨项目）。

可见性：在命名空间之上再加一道锁

命名空间解决了“记忆存在哪个抽屉里”，但同一个抽屉里的记忆，也不一定该被所有有权访问的 Agent 看到。这就需要可见性级别：在命名空间之上，再控制“谁能看”。

常见的设计分三档：

可见性	含义	适用记忆
私有	只有写入它的 Agent 能访问	Agent 专属的工作笔记、内部推理中间结果
组内共享	同一用户、同一协作组内的 Agent 可访问	项目组成员共用的技术栈决策、客户背景
用户级共享	该用户所有 Agent 均可访问	稳定的个人画像：角色、语言偏好、核心技能

写入时确定可见性，检索时在命名空间过滤之后再做权限校验。这和前面“给谁看”的用户信任设计是同一枚硬币的两面：对用户透明，对产品可控。

一个完整的产品决策流程

当产品团队设计多 Agent 记忆时，可以按这个顺序做决策：

确定用户边界，多用户场景下，用户之间必须严格隔离。
确定 Agent 边界，默认各 Agent 记忆独立，避免无意串味。
识别可共享的记忆类型，稳定的用户画像可以提升到用户级共享；项目协作用任务/项目命名空间打通。
敏感记忆默认隔离，情绪、健康、财务等话题，除非用户显式授权，不跨 Agent 流通。
提供用户可控的共享开关，让用户决定哪些记忆可以跨工具同步，而不是产品替用户做主。

但有一件事是确定的：无论最终方案是什么，记忆数据的存储和管理架构，必须从设计之初就支持灵活的隔离与共享策略。事后靠补丁打通多个孤立系统，成本极高，而且很难赢得用户信任。

PowerMem 在工程上采用了用户、Agent、任务三层标识加可见性控制的方案，可作为从产品设计落地到技术实现的参考。D4 术篇会进一步展开具体的开发接入方式。

我们的思考

上面这套衰减策略，不是纸上谈兵——业界已有实践验证它的价值。

LOCOMO 基准测试（Shopify 开发的一套 Agent 长期记忆评估标准）提供了一个很有说服力的对比：采用有选择的记忆 + 时效性衰减的系统，准确率达到 78.7%；而把所有历史对话直接塞进上下文窗口的暴力全记方案，只有 52.9%——差距接近一半。

这个对比说明了一件事：把所有信息都记住，效果反而不如有选择地记忆。 就像一个什么都记的人，在关键时刻反而想不起重要的事；而一个善于整理记忆的人，总能在对的时候想起对的信息。

记忆检索不只是存下来再查出来这么简单。写入策略、衰减机制、检索排序的设计质量，三者共同决定了 AI 的记忆质量。 产品团队在设计记忆功能时，与其追问怎么让 AI 记住更多，不如先想清楚什么该忘、怎么忘、忘了之后用户是否还能掌控。

回到那个失忆的同事

让我们回到开场那个每天忘记一切的助理。

如果有一天，他终于有了记忆能力——不仅记得你是谁、做什么，还记得上次帮你做项目时哪些方法有效、你最近的工作重心发生了什么变化、你更喜欢他用什么方式沟通。

更重要的是，他不会机械地翻出你三年前说过的每一句话。他知道哪些信息现在仍然重要，哪些已经过时了。他不会因为你去年说过“我讨厌开会”就帮你拒绝所有会议邀请——他会注意到你最近当上了部门经理，开会已经成为你工作的一部分。

这样的助理，和一个每天失忆的助理，在产品体验上是天壤之别。

而这个天壤之别的背后，不是更强的 AI 模型，而是一个设计良好的记忆数据系统。

这节课要留下的印象

如果这节课的所有内容你只记住一句话，记住这句：

记忆系统是让 AI 从“工具”变成“助手”的分水岭。难的不是“存”——难的是该忘什么、该想起什么、以及用户是否信任你的记忆管理。

课后行动

盘点你当前负责的产品（或你最常用的 AI 工具），完成以下练习：

列出用户重复提供的信息——哪些内容用户每次都要说一遍？（角色、偏好、项目背景、技术栈……）
按 CoALA 框架分类：
- 哪些属于语义记忆？（关于用户的确定事实）
- 哪些属于情景记忆？（过去的交互经验和成功方案）
- 哪些属于程序记忆？（用户期望 AI 遵循的行为方式）
思考五个设计问题：
- 哪些信息值得 Agent 长期记住？
- 哪些信息应该随时间自然降权？（用户的偏好会变吗？）
- 当新旧记忆冲突时，你会采用时间戳优先、置信度加权还是人工介入？
- 用户是否需要看到并管理 AI 记住的内容？你的信任设计方案是什么？
- 如果你负责的产品涉及多个 Agent 或多个 AI 工具，哪些记忆应该隔离、哪些应该共享？你的命名空间怎么划？

把你的分析带到下一期。下一期我们会讲 Skill——Agent 的“操作手册”如何从分散的文件变成可管理、可检索、可复用的结构化知识。你会发现，P3 讲的程序记忆和 P4 讲的 Skill，其实是同一件事的两面。

P3：Agent 记忆系统设计 ​

开场：那个永远记不住你的同事 ​

第一部分：为什么 AI 助手会“失忆” ​

第二部分：Agent 记忆的分类框架 ​

短期记忆：桌上的便利贴 ​

长期记忆：跨越对话的持久存储 ​

三种记忆的对比 ​

第三部分：记忆的读写——什么时候记、怎么想起来 ​

写入：什么时候记？ ​

读取：怎么想起来？ ​

第四部分：记忆系统真正的设计挑战——“忘”比“存”难 ​

记什么：不是所有对话都值得存 ​

忘什么：这才是最难的部分 ​

怎么忘：一套基于艾宾浩斯曲线的记忆衰减策略 ​

艾宾浩斯曲线 ​

遗忘分数 ​

遗忘分数降到什么程度该处置？ ​

一条记忆的衰减生命周期 ​

冲突了怎么办：记忆冲突解决策略 ​

先识别冲突形态 ​

三种常见解决策略 ​

什么时候处理冲突？ ​

给谁看：用户信任比功能完善更重要 ​

多 Agent 的边界：记忆该共享还是隔离？ ​

何时隔离，何时共享 ​

命名空间：给记忆划界 ​

可见性：在命名空间之上再加一道锁 ​

一个完整的产品决策流程 ​

我们的思考 ​

回到那个失忆的同事 ​

这节课要留下的印象 ​

课后行动 ​

延伸阅读 ​