holaOS 记忆系统重设计 PRD 解读：树形后端、所有权分类与推理优先检索

本指南基于 docs/plans/2026-05-20-memory-redesign-prd.md 展开，系统讲解 holaOS 将长期记忆（durable memory）重构为"树形原生后端"的目标架构、核心数据模型、写入/检索流程与 Phase 1 落地边界。阅读后你将掌握：记忆根/分类/树的组织规则、source leaf 与 summary node 的职责划分、event→chunk→leaf 生命周期、实体分配决策矩阵，以及 memory_retrieve 检索工具的推理优先契约；文末结合 runtime/api-server/src/interaction-memory.ts 等源码给出已落地的实现佐证。

一、为什么要重设计记忆系统：从"相邻机制"到"一个后端"

PRD 首先点出当前记忆模型的痛点：它把多种关注点混在一起——

• 人类可编辑的 markdown 文件；
• 生成的 MEMORY.md 索引；
• SQLite 元数据表；
• 面向 prompt 的回忆规划（recall planning）；
• 就近存放的会话连续性状态（session continuity state）。

这种结构让"长期记忆"看起来像一堆相邻的机制拼凑，而不是一个连贯的系统。重设计的目标是让它变成：

• 一个记忆根（one memory root）；
• 明确的树分类（explicit tree categories）；
• 每个持久化条目严格的树归属（strict tree ownership）；
• 一个检索层（one retrieval layer），可以跨分类搜索但绝不共享叶子；
• 长期记忆与运行时/会话状态的清晰分离。

值得强调的是，本次重设计只作用于长期记忆（durable memory）。会话检查点（session checkpoints）、会话恢复上下文（session resume context）、AGENTS.md（仅作为工作区指令）、最终 /api/v1/memory/* 的公开 HTTP 契约、v1 的每日摘要树、以及 Phase 1 中的 integration-tree 实现，都被明确划在范围之外。Phase 1 的实现范围严格限定为：仅交互记忆（interaction memory）、交互实体分配、交互树构建、交互检索工具、仅由 seal 阈值触发的摘要生成，且不含热度子系统（hotness subsystem）。

二、核心设计原则：八条规则

1. 一个记忆根（One memory root）

后端只有一个持久记忆根。根之下，树按所有权分类分组：

memory root -> tree category -> tree

v1 的分类只有两个：interaction（来自用户/Agent 与工作区的交互）与 integration（从外部系统抓取/同步）。注意：记忆根与分类层只是组织容器，不是摘要节点。

2. 分类是所有权域（Categories are ownership domains）

• interaction：由用户或 Agent 与工作区的交互推导出的持久记忆；
• integration：从外部系统获取或同步的持久记忆。

分类不是对同一叶子的不同视图，而是所有权域。同一个概念如果需要跨分类可达，由检索层合并多个树的结果，而不是复制叶子或让叶子多归属。

3. 树是严格的所有权层级（Trees are strict ownership hierarchies)

每个持久叶子恰好属于一棵树。叶子绝不跨树共享。

4. Markdown 仍是正文格式（Markdown remains the body format）

每个持久化节点的正文都以 markdown 存储在磁盘上。持久化节点只有两类：

• source leaves（源叶子）：底层规范记忆文档，没有子节点；
• summary nodes（摘要节点）：由子节点推导出的 markdown 文档，可摘要 source leaves 或更低层级的 summary nodes。

数据库是索引、拓扑、检索与任务控制平面，但不是长篇正文的主要存储——正文以 markdown 文件为准（这与 workspace-bundle-paths.ts 中 WORKSPACE_MEMORY_DIRNAME = "memory" 的目录约定相呼应）。

5. 日期是元数据，不是所有权（Date is metadata, not ownership）

每个持久化节点携带日期/时间元数据，用于新鲜度过滤、时间范围检索和未来的 recap 功能；日期在 v1 中不定义独立的树族。

6. 长期记忆不是会话记忆（Durable memory is not session memory）

压缩产物（compaction artifacts）、检查点、会话恢复材料都是独立的运行时关注点，不应建模为持久树的叶子。

7. 检索应该是树原生的（Retrieval should be tree-native）

检索不依赖生成的 MEMORY.md 文件。运行时通过树感知的数据库查询检索，需要时再从磁盘水合完整 markdown 正文。

8. Agent 检索应该是推理优先的（Agent retrieval should be reasoning-first）

主检索边界不应被塑造成树浏览器。系统应暴露：

• memory_retrieve：面向推理的上下文解析工具（默认路径）；
• memory_browse：可选的面相浏览的检查工具（调试、UI 或显式导航）。

默认检索路径应返回：检索意图（retrieval intent）、结构化检索包（structured retrieval pack）、支撑证据（supporting evidence）、未解决缺口（unresolved gaps）、推荐的下一步验证来源（recommended next verification source）。Agent 应从该检索结果继续规划，而不是事后处理一列原始命中。

三、核心模型：从根到叶子的完整对象体系

记忆根与树分类

后端有一个根容器，树按分类分组。示例树标识：

• interaction/interaction:response-style
• interaction/interaction:project-alpha
• integration/gmail:account-primary
• integration/github:repo-holaos-oss

该层级是组织性的，需与树内部的摘要层级（summary hierarchy）区分理解。

检索产品契约（Retrieval product contract）

存储模型是树原生的，但面向 Agent 的主检索契约是"问题解决导向"的。预期检索流程：

query -> intent classification -> hybrid candidate retrieval -> rerank -> retrieval pack -> agent reasoning -> optional live verification

关键产品规则：树结构留在存储层；不要让面向 Agent 的检索契约镜像树导航原语。

树结构

每棵树自上而下为：

root summary node -> intermediate summary nodes -> source leaves

每棵物化树顶部至多有一个 L1 根摘要节点，较低摘要层级可以有很多节点。

event、chunk、leaf 的区分

后端必须严格区分三个单元：

单元	含义	示例
event	进入规范化之前的原始记忆信号，仅作为入站单元	一条用户消息、一个助手回合、一条抓取的集成记录、一次导入的文档修订、一次周期性同步结果项
chunk	由单个 event（或其一部分）推导出的规范化摄入阶段单元，是评估"是否入册"的单位	长文档的一个段落组、长交互的一个逻辑片段、集成负载的一个规范化记录正文
source leaf	被接纳（admitted）的 chunk 持久化进树后形成的底层 markdown 文档	——

关系为：event -> chunk(s) -> admitted source leaf/leaves。并非每个 event 都会产生叶子，也并非每个 chunk 都会成为持久记忆。

Source leaves（源叶子）

源叶子是原子级的规范记忆条目，总是满足：markdown 文档、底层节点、无子节点、恰好被一棵树拥有、接纳后视为不可变。每个叶子存储的字段（PRD 原文完整列出）：

• leaf_id、workspace_id、tree_category、tree_id
• origin_kind、title、summary
• body_path、body_sha256
• observed_at、created_at、updated_at
• confidence、verification_policy、staleness_policy、status、supersedes_leaf_id
• 抽取的标签与实体（extracted labels and entities）

Summary nodes（摘要节点）

摘要节点是树内部节点，同样恰好被一棵树拥有，不是规范持久条目，但也是持久化的 markdown 文档。它总是有子节点（source leaves 或更低层级的摘要节点）。字段包括：summary_id、workspace_id、tree_category、tree_id、level、parent_id、child_ids、body_path、body_sha256、observed_at、time_range_start、time_range_end、created_at、sealed_at，以及为检索合成的标签。

交互树（Interaction trees）

交互树存储源自用户/Agent 与工作区交互的持久记忆，包括：运行时推导的工作区知识、被接受的用户偏好记忆、被接受的用户身份记忆。规则：

• 每个交互叶子恰好属于一棵交互树；
• 树分配基于叶子的主要交互主体（primary interaction subject），次要概念只作为检索元数据，不构成额外的树成员资格；
• 树内含一个内部根摘要节点、可选的中间摘要节点、底部 source leaves；
• Phase 1 中：交互实体一旦收到第一条被接纳的叶子，立即成为一棵树；摘要层仅由结构 seal 阈值控制，与热度无关。

v1 交互实体分配（LLM 驱动 + 后端护栏）

Phase 1 的实体分配以 LLM 驱动为主，流程为：

1. 后端向模型提供：chunk 文本、chunk 元数据、允许的实体类型、现有候选实体短名单（shortlist）；
2. 模型返回结构化输出：是否匹配现有实体、是否创建新实体、恰好一个主实体选择、可选次要实体、置信度；
3. 后端校验并规范化结果；
4. 得出的主实体成为被接纳交互叶子的所有者。

后端保留如下护栏：

• 每个被接纳的交互叶子恰好一个主实体；
• 若模型选择现有实体，必须来自提供的短名单；
• 若模型请求新实体，由后端代码生成规范的 entity id 与 slug；
• 若置信度过低，叶子路由到回退交互桶（fallback interaction bucket），而不是创建不稳定的新实体。

v1 交互实体决策矩阵

PRD 强调：记忆接纳（admission）与实体分配是两个独立的决策，存在三个不同的置信度问题——接纳置信度、现有实体匹配置信度、新实体创建置信度。v1 决策矩阵：

1. 低接纳置信度：不创建 source leaf，不分配实体；
2. 高接纳置信度 + 高现有实体匹配置信度：创建叶子并分配给该现有实体；
3. 高接纳置信度 + 低现有实体匹配置信度 + 高新实体创建置信度：创建叶子、创建新实体、将叶子分配给新实体；
4. 高接纳置信度，但现有匹配与新实体置信度都不高：创建叶子，分配给回退桶（如 interaction:uncategorized）。

核心规则是：匹配现有实体失败，不足以成为创建新实体的理由。创建新实体需要正向证据——chunk 围绕一个清晰、稳定、可复用的主体。否则叶子保持持久，但暂时住在回退桶下，等待后续重分类。

集成树（Integration trees）

集成树存储来自外部系统的持久记忆（周期性同步任务、集成抓取、导入的外部记录）。规则：每个集成叶子恰好属于一棵集成树，分配基于来源血统（source lineage）。集成树是目标架构的一部分，但实现推迟到 Phase 1 之后。

四、树构建：生命周期与阶段模型

生命周期模型

event -> chunk -> source leaf -> summary node 是生命周期区分，不只是命名：

• events：仅入站单元；
• chunks：规范化与接纳单元；
• source leaves：持久规范底层节点；
• summary nodes：持久推导内部节点。

Chunk 生命周期

1. 接收一个 event；
2. 规范化为一个或多个 chunks；
3. 对每个 chunk 打分/评估持久接纳；
4. 从持久树路径中丢弃非持久 chunk；
5. 将接纳的 chunk 提升为 source leaves。

Source leaf 生命周期

1. 从接纳的 chunk 创建 source leaf；
2. 分配恰好一个分类与恰好一棵树；
3. 持久化为一个 markdown 正文 + 一个元数据行；
4. 放在其树的底部；
5. 随着树向上生长，纳入未来的摘要封存（sealing）。

叶子终身是叶子，不会变成摘要节点。当新信息细化、修正或替换旧叶子时，系统优先创建新叶子并将旧叶子标记为 superseded 或 inactive，而不是原地改写旧正文。

摘要节点生命周期

1. 累积足够子节点达到封存阈值；
2. 对子节点合成一个摘要节点；
3. 持久化为 markdown + 元数据；
4. 更高层级可封存时向上重复。

摘要节点摘要其直接子节点，同时语义上代表其下整个子树。摘要节点是被封存的派生产物，封存后不应手动原地编辑；子树变化时由后端创建替换摘要并更新树指针/父链接。

交互叶子接纳与集成叶子接纳

交互叶子接纳四步：归类到 interaction 分类 → 分配恰好一个主交互实体 → 基于该实体分配恰好一棵树 → 持久化为 markdown 正文 + 元数据行。集成叶子接纳三步：归类到 integration 分类 → 基于集成血统分配一棵树 → 持久化。

日期处理与树封存

每个被接纳的节点携带时间元数据：叶子必须有 observed_at；摘要节点记录其子树覆盖的时间范围。Phase 1 交互树的封存机制：叶子追加到低层缓冲区 → 满足 seal 阈值时产出高层摘要 → 持续向上直到树根可刷新。Phase 1 没有基于热度的树创建或摘要物化——第一条被接纳的交互叶子创建树，只有 seal 阈值控制摘要何时出现。

五、检索模型：推理优先、树原生、有界返回

检索系统基于查询意图与可用过滤条件在分类间选择。Phase 1 检索实现仅限交互记忆，但目标架构为集成检索预留了空间。持久记忆应作为工具暴露给 Agent，而不是裸文件访问，也不是 prompt 内的盲目树遍历——树后端是检索实现，Agent 与返回"有界、已排序记忆结果"的检索工具交互。

Agent 检索工具：memory.retrieve

主访问路径是检索工具（如 memory.retrieve），支持的输入包括：

• query
• category / categories
• tree_id（Agent 已知属主树时）
• time_range
• mode（如 broad_summary 或 exact_evidence）
• max_results
• include_leaves

返回内容：排序的摘要命中、排序的叶子命中、节点 id 与树 id、引用/来源路径、以及支持后续下钻请求的足够元数据。工具向 Agent 隐藏内部树遍历机制——Agent 问"相关记忆"，后端决定如何遍历与排序。

在 holaOS 运行时中，该工具已经以 memory_retrieve 能力的形式落地：检索器的能力注册位于 agent-capability-registry.ts，并在 agent-runtime-prompt.ts 中被设定为非 UI 问题的硬性检索顺序："当前轮上下文/直接工具结果 → memory_retrieve → 最窄的权威本地/连接源 → 最后才是浏览器或 Web"，且明确要求"不要因为浏览器表面已打开就跳过 memory_retrieve"（对应 agent-runtime-prompt.test.ts 的断言）。

交互检索与集成检索

• 交互检索：查询主要关于工作区行为、用户偏好、身份或交互历史推导的知识时使用交互树，如沟通偏好、项目特定操作约定、通过既往用户交互学到的事实；
• 集成检索：查询主要关于外部来源信息时使用集成树，如最近同步的客户记录、导入的仓库上下文、抓取的邮件/日历信息。

跨分类检索与时间范围检索

查询横跨两类记忆时，运行时可在查询层合并两类的命中——不需要共享叶子。时间范围检索利用节点元数据限制或排序结果，例如"这周学到了什么""2026-05-20 发生了什么变化""最近的集成数据中哪些提到了项目 alpha"。

检索算法

所有检索遵循：

1. 将查询分类为 interaction、integration 或两者；
2. 先应用显式过滤：分类、树 id、时间范围、可用时的标签/实体；
3. 查询数据库获取候选树与候选节点；
4. 先对高层与中间摘要节点排序；
5. 选择最有希望的分支；
6. 仅下钻所选分支；
7. 需要精确证据时在该分支内对叶子排序；
8. 从磁盘水合选中的 markdown 正文；
9. 为 Agent 组装有界结果集。

优先"摘要优先遍历"回答宽泛问题，仅当查询需要精确细节时采用"叶子优先证据"。

摘要优先遍历与叶子下钻

宽泛/模糊问题先查候选 L1、L2 及中间摘要节点，用元数据、嵌入、词法/实体匹配排序，挑选少量分支，仅在需要时下钻——即使记忆语料增长，也能限制文件读取数与 token 量。精确问题仍先用树收窄范围，再在分支内搜索叶子，只返回少量顶级候选的完整叶子正文，避免对整个工作区记忆语料做全局叶子扫描。

嵌入策略

后端应同时嵌入 source leaves 与已封存的摘要节点（含中间摘要节点）。中间摘要节点嵌入的价值：提供分支层的粗粒度语义路由、无需读取所有后代叶子即可短列出相关子树、减少每次查询的全局叶子级语义搜索需求。叶子仍须嵌入，因为叶子嵌入更适合精确证据检索与精确事实匹配。预期分工：摘要节点嵌入用于分支选择，叶子嵌入用于证据选择。摘要嵌入只为已封存的摘要节点生成；子树变化、摘要被替换时，替换摘要获得全新嵌入，旧嵌入随节点一起退役。

六、存储模型：磁盘与数据库的分工

磁盘布局

文件系统存储 source-leaf markdown 正文与 summary-node markdown 正文。树后端拥有磁盘布局，生成的 MEMORY.md 索引不在新模型中。PRD 给出一个具体的 v1 布局：

<workspace>/.holaboss/memory/
  interaction/
    <tree_id>/
      leaves/
        <leaf_id>.md
      summaries/
        L1/
          <summary_id>.md
        L2/
          <summary_id>.md
          <summary_id>.md
        L3/
          <summary_id>.md

  integration/
    <tree_id>/
      leaves/
        <leaf_id>.md
      summaries/
        L1/
          <summary_id>.md
        L2/
          <summary_id>.md

要点：叶子住在拥有它的树内、没有共享叶子存储、L1 每树至多一个文件、更深的层可以有多个摘要文件。

数据库职责

数据库存储：source-leaf 元数据、summary-node 元数据、树定义、父子关系、根摘要指针、叶子嵌入、摘要节点嵌入、标签与实体索引、后台任务、内容哈希等完整性元数据。数据库对"存在哪些叶子、存在哪些树、哪棵树拥有某叶子、哪些摘要属于哪些树、应考虑哪些检索候选"拥有权威；markdown 文件对长篇正文内容拥有权威。

七、写入与任务流程：异步化与确定性的 upsert

持久写入路径：

1. 抽取/接受一个持久记忆条目；
2. 归类为 interaction；
3. 依据分配的主实体选择或创建属主交互树；
4. 持久化叶子 markdown 正文；
5. 持久化叶子元数据行；
6. 抽取标签、实体与时间元数据；
7. 将叶子追加进属主树；
8. 结构阈值满足时，后台执行封存与摘要生成；
9. 计算并持久化叶子与摘要的嵌入。

后端应尽可能将摄入与摘要作为异步工作，使对用户可见的运行时延迟保持有界。

Phase 1 交互 upsert 算法（12 步）

PRD 给出了完整确定性 upsert 路径，此处逐条继承：

1. 接收一个交互事件（用户消息、助手回合、被接受的偏好/身份记忆）；
2. 规范化为一个或多个 chunks（规范化文本、附加工作区/会话/时间戳元数据、计算稳定 chunk 指纹）；
3. 评估每个 chunk 的接纳（低于阈值则停止该 chunk，不创建叶子）；
4. 构建实体分配 prompt 输入（chunk 文本、chunk 元数据、允许的实体类型、现有候选实体短名单）；
5. 对被接纳的 chunk 运行 LLM 实体分配（选择：匹配现有实体 / 创建新实体 / 回退；产出恰好一个主实体决策）；
6. 后端校验 LLM 结果（拒绝短名单中不存在的实体 id、为获批新实体生成规范 id 与 slug、现有匹配与新实体置信度均不足时使用 interaction:uncategorized）；
7. 解析去重或取代（同一 chunk 指纹 + 同一属主已有活跃叶子：no-op；同一持久主题有活跃叶子但新 chunk 实质性更新：创建新叶子、设置 supersedes_leaf_id、标记旧叶子 superseded；否则创建新活跃叶子）；
8. 确保属主交互树存在（Phase 1：实体首条被接纳叶子立即创建该实体树）；
9. 持久化叶子（写入树属主的叶子路径、插入 DB 元数据行、插入实体链接与检索元数据）；
10. 更新树结构（将叶子挂到属主树底部、使受影响的未封存缓冲区或父摘要血统失效）；
11. 入队后台任务（封存、摘要生成、需要的摘要替换、叶子嵌入、封存后摘要嵌入）；
12. 返回 upsert 结果（leaf id、属主树 id、实体决策、操作类型：noop_duplicate / created / superseding）。

在源码中，这一流程的核心实现是 interaction-memory.ts 的 persistInteractionCandidate：它先调用 assignEntityWithModel 做实体分配，再计算内容指纹 sha256(candidate.content) 做指纹级去重，随后通过语义去重决策（semanticDuplicateShortlist + semanticDuplicateDecision）识别 same_memory 与 supersedes_existing，最终用 store.upsertInteractionLeaf 写入叶子并调用 syncNodeEmbedding 同步嵌入，返回值正是 outcome: "noop_duplicate" | "created" | "superseding" 三态。

实体分配实现（interaction-memory.ts 的 assignEntityWithModel）与 PRD 完全对应：模型 prompt 要求返回严格 JSON（{"action":"match_existing|create_new|fallback", ...}），且用两个显式阈值把关——ENTITY_MATCH_CONFIDENCE_THRESHOLD = 0.6、ENTITY_CREATE_CONFIDENCE_THRESHOLD = 0.68；选择现有实体必须命中短名单 id，创建新实体要求类型合法、名称非空且置信度达标，否则走确定性回退，最终回退到 ensureUncategorizedEntity（interaction:uncategorized）。短名单大小上限为 MAX_ENTITY_SHORTLIST = 24。

Phase 1 去重与取代规则

• 同属主树下精确 chunk 指纹匹配：no-op；
• 同一持久主题、同属主树、但正文实质性不同：创建取代叶子（superseding leaf）；
• 不同属主树：视为不同叶子（除非后续增加重分类流程）。

Phase 1 倾向保守去重策略，而非激进合并。

Phase 1 摘要失效与重建

新叶子创建或旧叶子被取代时：受影响叶子缓冲区变脏、受影响分支之上的父摘要链变陈旧、陈旧摘要保持可读直到替换摘要封存完成、替换摘要就绪后根指针与父链接在数据库中原子更新。这让检索在后台摘要再生期间保持可用。

八、公共接口影响与 v1 非目标

PRD 的立场是：现有持久记忆后端应被替换在当前记忆表面之下。当前 /api/v1/memory/search|get|upsert|status|sync 路由作为后续要适配的兼容面保留；持久 Agent 访问应收敛到由树查询引擎支撑的检索工具；被移除的 proposal 与 bridge 记忆 API 不回归；后端是最终 API 形态重审之前的主要设计目标。

v1 不需要：跨树共享叶子、单叶多树成员资格、每日摘要树作为一等树族、独立的记忆提案评审表面、以手动文件路径语义作为核心持久抽象、会话派生状态与持久记忆共用一个存储、将旧 MEMORY.md 索引行为迁移进新后端。

九、成功标准与刻意推迟的决策

成功标准

重设计成功当且仅当：

• 持久记忆有一个后端根，其下是按分类组织的树；
• interaction 作为第一个所有权分类落地，integration 留给后续阶段；
• 每个 source leaf 恰好属于一棵树；
• 每个持久化节点正文都是 markdown；
• 运行时持久回忆不再依赖生成的 MEMORY.md 索引；
• 跨分类检索无需共享叶子即可工作；
• 会话连续性保持可用，但不属于持久树模型的一部分。

刻意推迟的开放产品决策

以下留给后续技术设计而非本 PRD：各层精确的树 seal 阈值、选择主交互树的精确规则、集成树阶段的精确粒度、精确的嵌入模型与重排策略、记忆 API 的最终 HTTP 请求/响应 schema、以及后端切换时采用遗留数据迁移还是冷重启。

十、仓库现状：PRD 理念的落地对应

本 PRD 虽标注为 draft，其核心理念在 holaOS 仓库中已有成体系实现，可作为深入阅读的路线图：

• 交互记忆后端：interaction-memory.ts 覆盖实体分配、指纹/语义去重、叶子持久化、树重建（rebuildInteractionEntityTree）、检索（retrieveInteractionMemory，支持 mixed/summaries/leaves 三种 mode）与召回上下文组装；其中 INTERACTION_BRANCH_FACTOR = 8、MAX_RETRIEVE_RESULTS = 12、RETRIEVAL_CANDIDATE_POOL_LIMIT = 320 等常量给出了检索预算的具体默认值；
• 工作区记忆检索：workspace-memory.ts 的 retrieveWorkspaceMemory 演示了向量首轮（vector first pass）与词法支撑（lexical support）的混合检索组装，再交给 memory-hybrid-retrieval.ts 的 buildMemoryHybridRetrievalResult 完成意图推断、LLM 重排、检索包（retrieval pack）与覆盖率（coverage）构建；
• 推理优先的召回契约：memory-retrieval-pack.ts 定义了 AgentRecalledMemoryContext——包含 intent、retrieval_pack（known_facts / recent_high_signal_items / constraints / blockers / open_questions / recommended_next_source / recommended_next_step）、evidence、gaps、coverage，并通过 renderRecalledMemoryPromptSection 渲染为 prompt 片段，正是 PRD"检索意图 + 结构化检索包 + 证据 + 缺口 + 下一步来源"的直接落地；
• Agent 工具暴露：agent-capability-registry.ts 与 agent-runtime-prompt.ts 将 memory_retrieve 注册为运行时工具，并在非 UI 问题中确立"先记忆、后浏览器/Web"的硬性检索顺序；
• 磁盘目录约定：workspace-bundle-paths.ts 提供 workspaceMemoryDir 与遗留目录迁移逻辑，对应 PRD 的 .holaboss/memory/ 布局设想。

结语

本 PRD 的价值在于把"记忆"从一组互不相干的文件与表，重构成一棵"有所有权、有生命周期、有推理契约"的树。对读者而言，最值得带走的三件事：一是event/chunk/leaf 三层语义决定了什么该进树、什么该丢弃；二是实体分配决策矩阵保证了"宁可进回退桶也不乱建实体"的保守默认；三是检索层把树藏起来、把推理包交给 Agent——存储保持树原生，产品保持推理优先。Phase 1 只做交互记忆，但这条骨架已为 integration 分类与更丰富的召回能力预留了明确的生长点。