第 4 章 记忆系统：三层存储与五类内容
「它记得我」。这是用户对 WorkBuddy 最常报告的惊讶，也是最多的抱怨来源——记住了不该记的，忘了该记的，或者记的东西开始干扰新任务。这一章把「记忆」这个词拆开：WorkBuddy 的记忆不是一个东西，是三层存储、五类内容、一套治理规则（限额、蒸馏、覆盖）的总和。理解了结构，「为什么它记得/为什么它乱记」就都有了答案。
读完本章，你应能说出三层记忆各自的位置、读写权限和限额，知道什么内容会进哪层，并能动手查看和清理自己的记忆。
4.1 先看规则原文：一段随每次请求注入的说明书
WorkBuddy 自己的记忆机制说明，写在系统提示词的公共片段里（第 5 章讲过拼装机制）。这段文件的存在本身就很说明问题——记忆系统不只是存储，还包括一份发给模型的使用规则。规则要点如下（据本机 5.3.13 文件归纳）：
三层结构，权限各不相同。第一层云端记忆分两半：一半是服务器生成的用户画像，会话开始时注入，本地只读——文件缓存在 ~/.workbuddy/memory/，你手动改了也会被下次同步覆盖；另一半是历史会话检索工具，需要时向服务器发起搜索，不占请求上下文。第二层是用户级本地记忆，就是那个 MEMORY.md 文件：全项目共享，写入限额每次会话四千字符，由模型在你明确说「记住这个」时更新。第三层是工作区记忆，只在当前项目生效：每天一个日期文件（追加式，不许改历史），加一份精炼的长期笔记（限额三千字符）；超过三十天的日志要求按主题蒸馏进长期笔记后删除。
配套还有官方的内容分类学，来自工程复盘长文：五类记忆——稳定事实、知识背景、行为信号、表达偏好、会话延续。值得注意的不是这五类本身，而是一个刻意的设计：程序性记忆（怎么做事情的方法论）被排除在长期记忆之外。怎么做事归技能系统管（第 9 章），记忆只管「你是谁、你知道什么、你偏好什么」。两个系统泾渭分明，这是很多人配置失败的根源——把该写成技能的方法论塞进了记忆，结果每次召回都不完整。
图 4-1：三层记忆的位置、权限与限额。
4.2 存储位置与文件形态
把三层落到磁盘上：
~/.workbuddy/
├── MEMORY.md ← 用户级本地记忆（第二层）
├── memory/
│ └── <用户ID>_memory.md ← 云端画像的本地只读缓存（第一层A）
└── （各项目内）
└── .workbuddy/memory/
├── 2026-08-15.md ← 工作区每日日志（第三层）
└── MEMORY.md ← 工作区长期笔记（第三层）动手看一眼自己的：
cat ~/.workbuddy/MEMORY.md很多人的这个文件短得出奇——几条偏好而已。这不是坏了，是设计使然：云端的画像记忆承担了大头，本地文件只放「必须逐字遵守的硬规则」。官方文档对记忆的说明是：由模型自动从会话提取、注入系统提示词、每晚整理。
另有一个历史彩蛋：数据目录里还有个拼写成 memery 的目录，装着另一套记忆文件。它是另一条产品线的兼容组件（第 13 章讲这段生态渊源），平时不参与 WorkBuddy 主记忆循环，但它的存在解释了为什么有些老教程会提到两个记忆文件。
4.3 治理规则：限额、蒸馏与覆盖
三层各自的治理逻辑值得细看，因为「记忆失灵」大多栽在这里。
云端画像的治理在服务器侧：自动提取、每晚整理，你不可直接编辑。它最容易出现的问题是「画像过时」——你三个月前的项目偏好还在影响现在的对话。对策不是删文件（删了会重建），而是在对话里明确纠正，让新信号进画像。
用户级 MEMORY.md 的治理是限额制的：四千字符每次会话。这个设计的意图是逼记忆保持精炼——它是硬规则清单，不是笔记本。实践中它的失败模式是「写了但没被读」：模型更新了文件，但下次拼装时这段内容排在请求靠后位置，权重不足。对策是把最关键的规则放在文件开头，且保持每条一行。
工作区记忆的治理最有工程味：日志追加式（不许改写历史，保证据链），长期笔记限额，三十天强制蒸馏。这其实是一套小型的知识管理流水线——日志是流水，笔记是库存，蒸馏是盘点。看懂这套流水线，你就看懂了所有 Agent 记忆系统的通用范式。
4.4 实战：三个高频问题的记忆侧答案
「它总记得我不要的东西」：定位到具体层。问它「你对我的印象是什么」，回答里的内容多半来自云端画像；在对话里明确说「以后不要再用这个信息」，让纠正信号进画像。用户级文件里的过时条目直接编辑删除——这是三层里你唯一能安全手改的。
「我让它记住，它却忘了」：检查三个可能——写入超限（这次会话的四千字符用完了）；写进了工作区层但你在别的项目问（层级不匹配）；内容被判定为会话延续类（只在本会话有效，这是正确行为不是故障）。
「换个项目它就失忆了」：不是故障，是设计。工作区记忆按项目隔离，跨项目的是用户级和云端层。想要跨项目复用的偏好，说「记住，以后所有项目都……」引导它写入用户级文件。
4.5 补充机制：会话检索与双轨对照
第一层记忆还有一个容易漏掉的部件：历史会话检索工具。它不占请求上下文，模型需要时主动调用，由服务端在全量历史会话里做检索排序。使用时机的设计很克制——提示词片段里写明的典型场景是用户明确提到过去的某次讨论（「我们之前聊的那个方案」），且当前上下文里找不到。记忆注入（画像常驻）与记忆检索（按需召回）是两套机制：前者是每次请求的固定成本，后者是按使用的边际成本。理解这个区分，你就明白为什么「它有时记得有时不记得」——常驻的画像过时会失真，按需的检索措辞不当就召不回。想让过去的讨论可召回，当时就把关键结论写进对话明确语句里。
双轨对照也补一笔实测细节：memory 与 memery 两个目录下的文件名都带同一串用户标识，后缀分别是 _memory.md 与 _memery.md，各配一份伴随文件（备份或状态）。两套文件并存且互不引用——一个服务 WorkBuddy 自己的记忆循环，一个保留另一产品线的格式。这是生态兼容在存储层的直接物证，也是你排查「记忆怎么有两份」疑问的答案。
4.6 边界
本章机制的版本边界：三层结构与限额数字来自 5.3.13 本机模板文件，模板随市场更新可能调整；云端画像的提取与整理逻辑在服务器侧，本书只能观测其本地缓存与行为效果，不声称了解其内部实现；memory/ 缓存文件含个人信息，书中示例均已脱敏，你分享截图时同理。
下一章往上走：记忆是通过什么管道进入请求的——系统提示词的拼装机制，全书机制部分的核心一章。