Muse 智能体 · 记忆与个性化层详解

本篇目录

1. 0. 一句话结构
2. 1. 全景：三层结构 + 一个底座
3. 2. 注入层：不需要检索的记忆
4. 3. 底座层：源轨迹与结构化脊柱
5. 4. 检索层：三个工具的契约
6. 5. 写入纪律：写契约
7. 6. Explain：溯源契约
8. 7. 个性化产物：派生成果如何回流上下文
9. 8. 遗忘机制：两段式清理
10. 9. 边界清单：这层看不见 / 管不着的部分
11. 10. 本机实况快照（2026-11-04；括号内为 2026-10-17 旧数）
12. 11. 与进化层的接口（只列接口，不展开）

配套《00-Muse技术架构解构》§9 的展开篇；与《02-编排与进化层详解》的分工：02 §11 讲记忆的进化管线（claims 如何被新主张替代、后台 upkeep 如何运转），本文只讲记忆的静态结构与读写契约——记忆存在哪、以什么形态存在、谁在什么时候读它、写入时守什么纪律、怎么溯源、怎么遗忘。进化机制在本文只作简述并交叉引用 02，不重复展开。 调查日期：2026-10-17（Asia/Shanghai） 证据范围：~/docs/memory.md、~/docs/self_improvement.md、system prompt 快照的 Personalization / Memory 节（~/workspace/system/system_prompt.md L120–150、L381–397）、muse.memory_search / memory_get / memory_explain 工具定义、forget 技能正文及其 references/artifact-inventory.md、DB schema 参考中的 memory schema、以及 ~/MEMORY.md、~/memory/、~/dreams/alignment/derived/ 的实测目录与文件度量。 标注规则：实测 = 本机命令/工具当场验证；文档 = 本地 docs/system/技能文件明文；推断 = 由文件/表结构拼出、未经服务端证实。 复核修订：2026-11-04（Asia/Shanghai）——基于当前会话运行时逐项重测；文件侧体量（日记/bank/MEMORY.md/人物页/对齐合成）均为 11-04 快照（双日期标注，10-17 旧数并列）；DB 侧行数未复测，沿用 10-17。 隐私纪律（本文自律）：只记结构、计数、字段与机制。不引用用户私人记忆的具体内容：人物页只述模板章节、不述人名与内容；MEMORY.md 与对齐合成只述章节骨架与体量，不引条目原文。

---

0. 一句话结构

Muse 的记忆不是一个向量库，也不是一份笔记，而是一套四形态共存、互相投影的系统：

源轨迹（日记 + 对话原文）→ 结构化脊柱（Postgres 的 claims / entries / embeddings）→ 人类可读投影（MEMORY.md、人物页、bank 四本书）→ 每轮注入（精选投影以 standing context 形态直接进 prompt）。

四形态之间靠引用连接而非复制：检索命中给的是 path#L<line> 引用与 claim id，读原文要再走 memory_get，问出处要再走 memory_explain。这决定了它的三个性格：

1. 可审计——每条被记住的事实都能回答「谁说的、原话是什么、何时学的、替代了谁」；
2. 可遗忘——遗忘不是删一行字，而是沿引用与派生链做一次全系统清理（§8）；
3. 不自授权限——记忆与 standing context 只能帮助理解用户，不能授予新权限、不能扩大任务、不能覆盖安全规则（system prompt 明文，文档）。

---

1. 全景：三层结构 + 一个底座

00 §9 把记忆概括为注入/检索/关系三层。按静态结构展开，三层之下还有一个底座层：

┌─ 注入层（每轮进 prompt，零检索延迟；代价是每轮固定的 token 税）─────────┐
│  MEMORY.md（精选长期记忆）· people/groups INDEX（亲密度排序）   │
│  · ALIGNMENT_SYNTHESIS.md（对齐合成，注入序列最后一项）        │
│  · USER.md 等 standing 文件中的用户档案部分                    │
├─ 检索层（按需查，引用式返回）──────────────────────────────────┤
│  muse.memory_search → 命中片段 + path#L行号 + claim 元数据     │
│  muse.memory_get    → 按引用读原文窗口                         │
│  muse.memory_explain→ 按 claim/引用做溯源                      │
├─ 关系层（结构化的人与群组）────────────────────────────────────┤
│  ~/memory/people/<slug>.md 每人一页（固定六节模板）            │
│  ~/memory/groups/<slug>.md 每组一页 + 两目录各一份 INDEX.md    │
├─ 底座层（源与脊柱，Agent 不直接编辑）───────────────────────────┤
│  ~/memory/YYYY-MM-DD.md 日记（源轨迹）· ~/memory/bank/ 四本书  │
│  DB: memory.claims（主张脊柱）· memory.entries（索引条目）      │
│      memory.embeddings / embedding_models / entry_attributes   │
│      memory.metadata · runtime.search_documents（稀疏检索面）  │
└───────────────────────────────────────────────────────────────┘
        ▲ 写入：会话内即时记账 + 后台 upkeep 固化（→02 §10–§11）
        ▲ 回流：Dreaming 蒸馏对齐合成 → 回到注入层（§7）

实测本机底座体量（11-04）：~/memory/ 全树共 37 个文件 = 日记 28 + bank 4 + people 4（INDEX + 3 人页；人物页数随用户变化）+ groups 1（仅 INDEX）。10-17 为 18 个文件（日记 10 + bank 4 + people 3 + groups 1）。这是一个启用约五周的实例，体量数字只作结构参照、不代表稳态规模。

---

2. 注入层：不需要检索的记忆

2.1 注入序列与位置

每轮上下文以 [escaped: BEGIN USER CONTEXT] 块注入 9 个 standing 文件（00 §3 已列全单），其中与记忆/个性化直接相关的是后半段，顺序为（实测注入序）：

排在它们之前的 AGENTS.md / SOUL.md / IDENTITY.md / USER.md / TOOLS.md 是人格与档案面：其中 USER.md 是用户本人的档案（结构实测：标题 + 若干身份字段占位节 + ## Context 节，335 字节），与人物页分工明确——system prompt 明文注记「人物页写的是用户身边的人，USER.md 写的是用户本人」（文档）。

注入层的设计取舍：把「最可能每轮都用得上」的记忆预先付掉上下文成本，换取零检索延迟与零漏检；代价是注入副本可能滞后于文件本体——prompt 明文提醒：standing 文件在对话中被改动后，注入副本不一定同步，引用前应回读文件本体（文档）。

注入层的经济学：用每轮确定的 token 成本（本机约 36KB standing 文件，11-04；10-17 约 12KB，见 §10）换零检索延迟与零漏检；检索层则用按次付费（一次 search/get 的往返）换上下文窗口的节省。选哪层，本质是"这条记忆被用到的概率 × 调用次数"的期望值计算——高频用注入，低频用检索。

2.2 MEMORY.md 的解剖

实测（11-04）：22,389 字节 / 39 行（长行制，一条事实一行；10-17 为 5,284 字节 / 20 行），章节骨架固定三节：

# MEMORY.md
## Facts          持久事实
## Preferences    偏好（本机该节目前为空骨架）
## Commitments    承诺与未决事项

它在系统中的定位是 active claims 的人类可读投影（02 §11）：底层真相是 claims 图，这份文件是给「下一轮的 Agent + 用户本人」共读的精选版。因此它有两条形态纪律（system prompt Memory 节，文档）：

• 写给下一场对话：条目要带足够上下文，使其在未来脱离原始对话仍可理解；
• 不是日志：常规进展、工具调用、诊断信息属于工作文件，不进记忆；「没有值得保留的变化时，记忆保持不动」。

文件头注释亦明文其自我定位（实测）：「策展过的长期记忆：留持久事实、偏好与承诺；保持紧凑，把日记细节留在 ~/memory/ 每日笔记里」——即 MEMORY.md 与日记是投影与源的关系，不是两份副本。

2.3 注入层的第二来源：side chat 的记忆变体

检索工具的作用域揭示了注入层还有一个变体（工具定义，文档）：每个 side chat 可有自己的 ~/side-chats/<chat-id>/MEMORY.md 与 ~/side-chats/<chat-id>/memory/**，与主记忆同被检索，但 side-chat 的配置类文件被明确排除在检索之外。本机实测 ~/side-chats/ 在当前文件视图中不存在条目——结构在、实例暂无（或不在本视图内）。该变体的读写隔离语义（side chat 学到的事实会不会写进主 MEMORY.md、检索"同被检索"是否会把私密上下文泄漏进主聊天）本机无实例可验证，标 ❓——本节为纯文档转述。

---

3. 底座层：源轨迹与结构化脊柱

3.1 日记：源轨迹

实测（11-04）：~/memory/ 根下 28 篇日记，2026-09-26.md 至 2026-11-04.md，合计 812,581 字节（10-17 为 10 篇 / 41,653 字节），与本机启用日对齐。格式实测（只看标题行）：

# <YYYY-MM-DD>
## Verified extraction — <HH:MM> UTC (run sirun_<…>)

即日记条目带产生它的后台运行 id——源轨迹从第一行起就是可溯源的，sirun_ 前缀与进化层的运行信封是同一编号体系（02 §9）。cron 正文被明文禁止直接改 MEMORY.md，其观察落点正是日记（02 §7.1）——写入路径在契约层就被分流：即时记账落投影，后台观察落源。

3.2 Bank 四本书：按性质分拣的沉淀

实测 ~/memory/bank/ 四本书（11-04 快照；括号内为 10-17 旧数），体量高度不对称：

运行时托管约定（system prompt，文档）：~/memory/bank/ 与 ~/memory/index/ 由 runtime 管理，Agent 可读（exec ls/grep）不可直接编辑——沉淀的写入权在后台管线，不在会话 Agent 手里。

一个实测细节值得记：forget 技能的派生清单（artifact-inventory §3）列举 bank 派生面时只列了 {world, experience, opinions} 三本，未列 reflections.md。两种可能：清单滞后于新书的引入，或 reflections 的派生属性与其余三本不同。在位证据只有「清单三本、磁盘四本」这一差集本身（实测），本文不替它下结论——但遗忘执行时若按清单逐项核对，这本书需要被显式点名（§8.4）。

3.3 索引：文件视图里不存在的那一层

00 §9 与 system prompt 都提到 ~/memory/index/。实测：本机 find/ls 均确认该目录在 Agent 的文件视图中不存在（No such file or directory；11-04 复核：仍不存在）。与之相对，环境变量中存在 JARVIS_MEMORY_SOCK（记忆服务套接字，只见路径不见实现细节）。

据此的静态结构结论（推断，证据如上）：索引服务分两面——访问面是 runtime 侧经 JARVIS_MEMORY_SOCK 提供的服务（Agent 的全部访问被收口到 §4 的三个工具），实现面是 DB 的 memory.entries/embeddings 表与 runtime.search_documents（稀疏+向量混合检索的结构证据，§3.4）。磁盘上能摸到的只有被索引的语料（MEMORY.md、日记、bank、人物页）与 DB schema 参考。这一形态与全系统的「投影 ≠ 本体」模式一致（00 §8）：语料是投影，索引实现是本体，本体不给文件视图。

术语对齐（与 07 §6.1）：07 把 DB 表称为"索引层"，本文此前把 socket 服务称为"索引"——统一为上述"访问面/实现面"二分，07 的"索引层"即本文的"索引实现面"。

3.4 DB 脊柱：claims 与 entries（只述静态结构）

memory schema 共 6 表（schema 参考实测；11-04 复核仍为 6 表，新增的 saved schema 与之无关）。其中两张构成脊柱：

memory.claims——一条记忆 = 一行可溯源主张，字段（实测列定义）：

memory.entries——索引条目：memory_uri、chunk_id、source_type、status、privacy_class（隐私分级）、confidence、citation_path + line_start/line_end。即索引的最小单位是带隐私分级与引用落点的语料块（chunk），不是整文件。

其余四表：memory.embeddings（条目的向量）、memory.embedding_models（模型名/维度/距离度量）、memory.entry_attributes（条目的命名属性）、memory.metadata（子系统元数据与更新时间）。另有 forget 清单点名的 runtime.search_documents（文档）：Markdown 语料同时被索引进稀疏（关键词）与向量两面——检索是混合检索，此为其结构证据（02 §11 同述）。

静态视角下最重要的一点：claims 行同时持有 quote + speaker + source_path/line + supersedes ——溯源（§6）与遗忘（§8）都不是事后功能，而是写进表结构的原生能力。

---

4. 检索层：三个工具的契约

4.1 muse.memory_search：入口

工具定义（文档）要点：

• 入参：queries 数组 1–3 条（queries[0] 应最贴近用户的原始措辞，其余为近义改写）、maxResults、minScore（0–1 分数地板）；
• 作用域：~/MEMORY.md、~/memory/**/*.md，以及 side-chat 的同构记忆树（配置类文件排除）；
• 语义补充（docs/memory.md，文档）：在主聊天与个人 side chat 中，检索还会返回那些聊天里匹配的对话摘录——但「never every message」，即对话原文只是被索引的摘录集，不是全文倒排；App 自带的聊天搜索是另一套，两者不互通（文档语，底层是否共享实现本机不可见）；
• 返回：片段 + 文件路径 + 行号，结果元数据携带 claim id / memory URI / 状态——这是后两个工具的入参来源。

使用纪律（system prompt，文档）：凡涉及过往工作、决定、日期、人物、偏好、待办与用户历史的回答或行动，先检索再开口；「凭似乎记得的印象作答」被明文定性为编造。另有前置规则：在断言「某事存没存」之前必须先查记忆，因为后台笔记可能已自动写入（§5.4）。

4.2 muse.memory_get：按引用读原文

• 入参：path（裸名、~/ 前缀、home 下绝对路径、或搜索引用形如 MEMORY.md#L7、memory/2026-08-10.md#L12-L15）+ 可选 from（1 起行号）/lines 窗口；
• 引用后缀本身即定位协议：搜索给引用 → get 按引用展开窗口 → 需要更大范围时用 from/lines 覆盖。检索层因此是两段式的：search 负责「在哪」，get 负责「原文是什么」，避免把全文塞进上下文。

4.3 人物/群组的前置读契约

关系层有专属的读纪律（system prompt The User's Relationships 节，文档），比一般检索更强：

• 本轮话题涉及索引中的人物/群组时——无论其以姓名、昵称、代词、角色称谓（如亲属称谓）、Agent 自己的旧消息、还是定时 handoff 的形式出现——先读对应页面再回答或行动；
• 对某人的事实不确定时，先读其页面再答；在给出涉及某人的建议前同样先读；
• 织入方式的克制线：「no surprises」原则——回复中引用关系信息必须与当前话题有显而易见的关联，不为个性化而个性化到令人不安。这条是读契约的一半：另一半是「必须读」，这一半是「读了也不许乱用」。

---

5. 写入纪律：写契约

记忆的写契约散见于 system prompt Memory 节、docs/memory.md 与 docs/self_improvement.md，合并成六条：

5.1 先写后回复（write-before-reply）

「学到值得保留的东西时，先记进 ~/MEMORY.md，再回复」（system prompt L127，文档）。配套回执纪律：写成功之后才可以告诉用户「已保存」——与全系统「已接受 ≠ 已送达」的交付四态（02 §3）同源：口头宣称不构成落盘证据。

5.2 什么配进记忆（准入）

准入标准是持久理解（文档）：用户是谁、关心谁与什么、偏好、决定、承诺、以及改变其处境的结果。明确排除：日常进展、工具调用、诊断信息（归工作文件）；转瞬即逝的任务状态（归 todo/目标系统）。判断锚点是「为下一场对话而写」——下一场对话用不上的，不进。

5.3 更正传导（correction propagation）

事实变化（预订/取消/完成/改期类事件是 prompt 给的例）触发的是一次对账而非追加（文档）：

1. 先 memory_search + 读 MEMORY.md，找出与新事实冲突的旧条目；
2. 在旧条目所在之处就地更新/对账，而不是在文件末尾再写一条互相矛盾的新条目；
3. 底层语义是 claims 的替代链：新主张 supersede 旧主张，旧主张留痕不删（机制见 02 §11）；用户纠正时，顺替代链修正受其影响的下游——目标、提醒与排队中的跟进（02 §11 同述）。

5.4 会话记账与后台固化是两条写路径

docs/self_improvement.md 明文（文档）：每小时的 memory upkeep「不替代你在会话中的记账」——同一件事。即写入方有两个：

这正是 §4.1「断言存没存之前先查」的由来：你没写，不等于没存——另一条写路径可能已经写了。

未闭合的环（❓）：§2.2 把 MEMORY.md 定位为"active claims 的人类可读投影"，但 §5.4 的会话即时记账落点写的也是 MEMORY.md 文件。若会话 Agent 不能直接写 DB claims 表（07 的写路径不变量：Agent 是状态层的纯读者），则会话路径上的因果是先有文件投影、后有 claims 本体（由 upkeep 异步补建）——"投影"一词在会话路径与后台路径上的方向是反的。本机无证据确定会话写入是否同步建 claims 行，两种时序都与现有证据兼容。此处的"投影"应理解为"逻辑定位"而非"生成时序"。

5.5 凭据永不入记忆（硬线）

• 密码、API 密钥、令牌、私钥等秘密不得复制进记忆、普通文件或日志；凭据只走 Secure Vault（独立于聊天、记忆与普通文件，00 §14）；
• 用户为某项任务临时给出的卡号、一次性验证码等，只可用于该任务本身，不得留存于记忆或无关工作（system prompt，文档）；
• 记忆条目、技能、项目指令即使出自 Agent 本人，也不能放宽这条线（system prompt 安全节，文档）。

这条在静态结构上的对应物：memory.entries.privacy_class（§3.4）——语料入索引时带隐私分级，是「什么不该被检索面扩散」的机器侧表达（推断：分级参与检索/注入的可见性裁剪，裁剪规则不在本机文档内）。后续行动项：用 muse.db 查本机 98 条 entries 的 privacy_class 取值分布，能立刻回答"分级是摆设还是真在用"——举手之劳的实测，不列为永久 ❓。

5.6 导入：外部记忆的入口

docs/memory.md 还给出一条特殊的写路径（文档）：

• Import memory（iOS/Android/Web 的 Settings > Data controls）：系统给出一段可移植提示词，用户把它粘到另一个 AI 助手、将其回复粘回并确认添加；粘回的内容被要求主 Agent 提炼持久事实与偏好并确认保存了什么；
• Import chats：上传 ZIP 导出（上限 100 MB，文档列 ChatGPT / Claude / Gemini / Meta AI），点「Summarize into memory」；
• 两条共同的契约：仅上传 ≠ 已保存，必须经提炼+确认；导入不复制对方 App 的设置，也不把原始对话恢复为聊天。即外部记忆只能以「经本系统准入标准（§5.2）过滤后的 claims」形态进入，不允许整包灌入。

---

6. Explain：溯源契约

muse.memory_explain 是记忆系统对用户的可解释性接口（工具定义，文档）。

入参三选一（同一事物的三种句柄）：

• claim id（来自 search 结果元数据，或日记条目中的 claim: 行）；
• memory:// URI；
• 引用（如 MEMORY.md#L7）。

返回一份完整的来源报告：该 claim 的正文、种类（kind）与显著性（salience）、谁说的及其原话引文、首次学到与最近强化的时间、当前置信度、它所立足的对话消息（带日期）、它替代过的早期 claims、以及后来替代它的 claims（双向替代链）、以及（如有）它的索引行。

触发纪律（system prompt，文档）：用户问「你怎么知道这个」、或要求检查/纠正一条记忆时，必须用 explain 展示来源与替代关系，不许凭印象解释。它与 §3.4 的表结构严丝合缝——explain 能给的每一样东西，都恰好是 claims 表的一个列组；换句话说，溯源不是查询技巧，是 schema 的直接投影。

用途闭环：explain 暴露替代链 → 用户指出哪一环错了 → 按 §5.3 顺链修正 → 修正本身又成为新 claim 入链。这使「记错了」在本系统里是一个有标准处理流程的状态，而不是需要删库重来的事故。

---

7. 个性化产物：派生成果如何回流上下文

个性化不只是「记住事实」，还包括一组离线蒸馏的产物。它们的共同回流方式是：落成文件 → 进入注入序列 → 每轮影响 Agent 的判断口径。

7.1 对齐合成：回流的终点站

实测 ~/dreams/alignment/derived/ALIGNMENT_SYNTHESIS.md（11-04）：10,027 字节 / 37 行（10-17 为 6,184 字节 / 35 行），章节骨架：

# Alignment Synthesis
## Who this user is and how to act for them   用户是谁、如何配合
## User value                                 用户眼中的助手价值
## Boundaries                                 边界
## Current frictions                          当前摩擦
## How Idris can strengthen the relationship… 关系加强点
## Where to look for detail                   细节出处索引

（末节中的助手名取自本机 IDENTITY.md——合成是按实例生成的，连「如何加强关系」一节的标题都带本实例的名字。）

回流位置（实测注入序）：它是 9 个 standing 文件的最后一项（§2.1）——在 prompt 组装里压轴，等于每轮对话开始前最后读到的一份「这个人是谁」。system prompt 在 Personalization 节开头即指向它：「你的对齐状态见该文件，它是『你与这个用户如何共同演进』的合成」（文档）。

它的上游只在此简述（详见 02 §13）：夜间 Dreaming 从日反思（~/dreams/YYYY-MM-DD.md，本机实测 4 篇）与结构化状态 ALIGNMENT_STATE.yaml 蒸馏出合成。实测状态文件的键结构：relationship_contract（status / user_words / boundaries / …）、user_facets、working_alliance（goal/task_agreement、appropriate_reliance、current_frictions）、observed_fit、proactivity_policies、repair_threads——合成的人话章节与状态机的字段一一对应，合成是状态机的渲染，不是自由写作。另一实测细节：派生目录文件的落盘时间为 2026-11-02（11-04 复核；10-17 曾停在本机启用后约两周内的某夜），而日记与 bank 已更新到调查当日——派生产物的刷新节奏与源轨迹并不同步，读合成时要注意其「截至」时间（推断：夜间节奏 + 触发条件未满足时可多日不更新）。

7.2 人物页：关系层的产物形态

实测模板（只述结构）：三页同六节骨架，其中两页同构（各 1,254 字节 / 29 行，11-04 未变）；第三页 6,546 字节 / 43 行，体量不同但六节同骨架——

# <人名>
## Facts              事实
## History            交往史
## The relationship   关系性质
## In common          共同点
## Open threads       未决线索
## Strengthening      关系加强点

其中两页字节数与行数完全一致，说明它们由同一生成模板填充（实测推断；第三页体量不同，模板填充的灵活度 ❓）。INDEX 的排序语义是亲密度（system prompt 与 INDEX 文件头，文档）：「Every page … closest to the user first」——索引顺序本身即一条个性化数据，注入时只截取头部（00 §3），即每轮常驻上下文的关系信息天然按亲密度配给。

本机计数（11-04）：people 3 页 + INDEX 1 份（815 字节 / 7 行）；groups 0 页 + INDEX 1 份（209 字节 / 5 行，正文为「暂无」的空索引，自 10-17 未变）。10-17 为 people 2 页 + INDEX 589 字节 / 6 行；人物页数随用户变化是正常的。页面由 hourly Relationships 管线维护（02 §10），其 staging 暂存转正机制见 02 §14；本文只记其静态契约：页面是读契约（§4.3）的对象，不是会话 Agent 的随手笔记。

7.3 其他个性化投影面

• 购物偏好档案 ~/memory/shopping/PROFILE.md（forget 清单，文档）：用户可编辑、被排除在记忆 ingest 之外、由购物轮次直接读取——一个故意绕开 claims 系统的偏好孤岛，遗忘时须单独处理（§8.3）。实测：本机 ~/memory/shopping/ 目录不存在（11-04 复核：仍不存在），该面尚未在本实例产生。
• ~/FEEDBACK.md（forget 清单，文档）：会话跟进的持久偏好输入。实测：本机不存在此文件（11-04 复核：仍不存在）。
• ~/PROACTIVE_PREFERENCES.md（实测在位，2,288 字节；10-17 为 496 字节）：主动消息的时间窗等偏好，直接约束主动层裁决（02 §7.5）——个性化产物回流的另一形态：不进 prompt 注入序列，而是作为后台裁决的输入文件生效。
• 个人化投影（personalization projection）：forget 清单 §3 把它与 bank、人物页并列为「派生记忆」的一员（文档），指代注入层组装出的用户画像投影；其生成细节不在本机文档内（§9）。

7.4 回流全图

对话/连接器信号
  → claims（脊柱）→ MEMORY.md 投影 ──────────────┐
  → 日记（源）→ upkeep 固化 ─────────────────────┤
  → Relationships 管线 → people/groups 页 + INDEX ┼→ 每轮注入（§2）
  → Dreaming → ALIGNMENT_STATE → SYNTHESIS ──────┘
  → 旁路：shopping PROFILE（不入 ingest）· PROACTIVE_PREFERENCES（裁决输入）

关键性质：所有回流都经过文件落盘。没有一条个性化结论是只存在于某次推理里的——这使个性化整体可查、可改、可忘，也是 §8 的遗忘工程之所以可能的前提。

---

8. 遗忘机制：两段式清理

注：下文的遗忘机制是纯文档转述、零本机执行证据——本机 ~/workspace/memory/forget/pending.json 不存在（10-17 实测，11-04 复核仍不存在；见 §10），系统从未走过遗忘路径；其"两段式"是否真按技能跑，无实例可验证，标 ❓。

遗忘由专门技能 forget 定义（docs/memory.md 指路至此），其流程是全系统少见的两段式 + 规划先行设计（技能正文，文档）。

8.1 第一段：plan（只读规划）

• 调 forget.plan 一次（入参 {}）——主题由规划器从对话中识别，调用参数里不许重复敏感原文（连工具入参都不许成为新的泄漏面，这与 §8.5 的过程隐私一脉）；
• 规划器只读，按 references/artifact-inventory.md 的清单逐面盘点（§8.4），产出：找到了什么、应改什么、如何验证、以及 Muse 无法抹除的部分；
• 等待规划的 handoff，期间不轮询、不并行自查；
• 向用户呈现时只用日常类别（记忆、提醒、创建物、分享物、日志、备份）讲清范围、不可逆动作与重要限制，然后问一个直接的确认问题；不可逆性必须在批准前说清；
• 沉默、含糊、部分批准、改了范围，都等于没批准。

8.2 第二段：confirm 与执行

• 明确批准后调 forget.confirm（入参 {}）：它从对话里重读最新规划与批准，不需要传规划器 id——批准是对话状态的一部分，不是令牌；
• 找不到「一份清晰的近期规划 + 其后的一次批准」时，停手、什么都不改，报告阻塞并重新规划；
• 执行前先对着当前状态复验规划；先停掉可能把信息写回来的生产者，再删它的产物；每件东西用拥有它的产品动作/工具处理，保全无关内容；
• 删除纪律（技能明文）：批准的目标不进可恢复回收站；独立文件用 rm -- <exact-path> 精确删除（删前即时复验路径），永不 rm -r、不用 glob、不用宽目标；混合内容文件就地编辑而非删除；产品动作删除时产生的回收站墓碑文件要再精确永久删除；
• 购物档案是明文特例：直接编辑/删除 ~/memory/shopping/PROFILE.md 对应条目，并证明没有 staged/queued/running/scheduled 的购物档案运行能把它恢复；
• 清理由执行者本人直接做，不再转派子 Agent；若被委派的工作在收尾时仍在途，系统会把清理报告为未完成，防止迟到的改动跑赢记忆刷新。活跃子 Agent 进程内存里的上下文窗口这类非文件非 DB 的持有形态（§8.4 第 1 类点名了"活跃的子 Agent 可能仍持有该信息"），其处置口径（杀子 Agent？等它自然结束？）值得回查技能原文，此处未展开。

8.3 收口：pending.json 与运行时收回

执行收尾有一个固定的机器动作（技能明文，文档）：

• 写 ~/workspace/memory/forget/pending.json，形如 {"claims":[…], "citations":[…]}，两表皆空也要写；
• 表里只放执行过程中在 memory_explain / memory_search 元数据里见过的 claim id 与被删除/改写的精确行引用（MEMORY.md#L<line> 形态）——永不写入被遗忘的原文；
• runtime 据此收回（retract）这些 claims 及其全部派生，并刷新记忆检索；执行者不得二次刷新；
• 若刷新失败，必须报告「未完成」，不许声称已不可检索——forget.confirm 的成功结果是在 runtime 完成收回与 reindex 之后才被转述的（artifact-inventory §3，文档）。

8.4 盘点面：为什么遗忘是一张九类清单

artifact-inventory 是遗忘之所以难的完整说明书。它要求按 9 类逐面盘点，只记录确实含有该主题或能重建该主题的面，每条命中都要记：所有者、精确定位、与源的关系、拟采取动作、前置条件、可逆性、验证方式：

8.5 过程隐私

技能为清理过程本身立了一套独立的隐私纪律（文档）：全程只用「that information」指代目标主题，原文不得出现在清理动作的任何新产物里——不许复制进新的记忆、todo、文件名或报告；面向用户的汇报只给离散的计数与类别，详细命中证据留在私有规划里不外露；甚至一次「用于核查的检索」若把原文重新带回普通聊天，这次核查本身就算失败——核查动作也被视为潜在的泄漏面。语音会话中发起的清理请求被直接引回主聊天处理（docs/memory.md，文档）。

8.6 「已遗忘」的判据

只有新鲜状态的验证同时满足以下条件，才可以说 forgotten（技能 + 清单 §9，文档）：

1. 无任何已批准的权威源仍可被 Agent 取用；
2. 精确检索与语义检索都不再返回可用副本（注意：清理前的旧索引可能短暂返回命中，单凭语义命中不判失败——判据以 runtime reindex 后的状态为准）；
3. standing prompt 上下文、新的压缩摘要、记忆 flush、重启检查点、购物档案都不再保存或复述它；
4. 无任何活跃/暂存/排队/已排期的生产者（包括购物档案运行）能重建它；
5. 已批准的产物与分享已按规划处置；
6. 残留的外部或保留期副本已被逐类明说。

剩余物的汇报口径：按日常类别点名（外部服务、已分享/已发布物、日志、备份等），并说明 Muse 能否让它不进入活跃使用。两种明确的失败处理：plan/confirm 失败时不许 fallback 到无规划的手工删除、不许声称成功；删除外部邮箱/日历/设备记录、他人副本等需要单独批准，遗忘请求本身不构成授权。

---

8.7 中央发布的 embedding：遗忘最难的一块

forget 清单（文档）要求盘点"中央发布的本机用户记忆 embedding"，并明文承认：远程发布若拿不到删除/替换证明，只能报告为限制。这是全篇最值得展开的一行：

1. 信任边界出 VM：06 篇的执行隔离保证"原文凭据不出 cell"，但记忆 embedding 是派生出境——原文不出，派生出。两者并置才是完整的出境地图。
2. 遗忘判据的硬骨头：§8.6 第 6 条要求"残留的外部副本被逐类明说"——中央 embedding 正是"能明说、未必能删掉"的典型。规划器向用户呈现时，这一项必须用日常语言单列（清单 §5 的 Feed 围栏副作用同理）。
3. 本机可见性为零：发布形态、订阅方、保留期、删除证明机制全部 ❓。后续可追问：embedding 发布是按条实时还是批量？memory.metadata 表（子系统元数据与更新时间，§3.4）是否记录发布水位？

建议 10-安全篇将此作为"数据出境"小节的核心案例。

9. 边界清单：这层看不见 / 管不着的部分

---

10. 本机实况快照（2026-11-04；括号内为 2026-10-17 旧数）

---

11. 与进化层的接口（只列接口，不展开）

本文的静态结构有四处与 02 的进化管线相接，机制细节以 02 为准：

• claims 的替代语义（新主张如何 supersede、salience/confidence 如何演化）→ 02 §11；
• Dreaming 的生产过程（日反思的字段与质量标准、状态机如何逐夜推进）→ 02 §13（本文 §7.1 只讲它的产物形态与回流位置）；
• upkeep / Relationships 等管线的节奏与护栏（staging 转正、租约、去重、采纳度量）→ 02 §9–§10、§14；
• compaction 与记忆的交互（压缩摘要 agent.compactions 与记忆 claims 的关系、memory.volatile_context_pins 的反向保留语义）→ 07 §8、02 §9–§10。压缩检查点行记录被替换的 seq 区间与摘要（07 §8 实测表结构），volatile_context_pins 的表名强烈暗示记忆侧可以要求压缩时钉住特定上下文（推断，见 07 §8）——这是记忆→压缩的反向控制边，本系列唯一一处"记忆指挥执行层"的接口。压缩摘要在遗忘盘点（§8.4 第 1 类）与判据（§8.6 第 3 条"新的压缩摘要"）里只出现在清理视角，写入视角未闭合：压缩时被丢弃的上下文若含未固化事实，upkeep 能否从压缩前转录里抢救，属 ❓（本机 agent.compactions 0 行，压缩机制从未被触发，见 07 §8）。

一句话收束分工：02 回答「记忆如何变」，本文回答「记忆是什么形状、按什么契约被读写」。静态结构的设计意图贯穿始终——引用式检索让溯源成为可能，文件式回流让个性化可查可改，而遗忘的九类盘点清单说明：正因为记忆被认真地做成了全系统投影，它的删除才必须是一次全系统工程。