kimi-code-memory-mcp-server 0.1.1 → 0.2.0

package/docs/4.kimi-code-native-evolution-roadmap.md

@@ -0,0 +1,559 @@
+> 本文档基于此前向 kimi-code 提交的架构建议：
+> - `memory-system-proposal-for-kimi-code.md`：三层模型 + Markdown 优先 + 主题追溯
+> - `memory-architecture-overview.md`：原生集成四层架构
+> - `memory-skill-prompt-design.md`：Memory Skill Prompt 设计
+>
+> 本文性质：架构建议 / 讨论稿，与具体项目无关。
+
+---
+
+## 一、从最小入侵到原生内化
+
+此前向 kimi-code 提交的建议采用了一种**最小入侵**路线：不改动核心代码，通过外部工具层 + Skill Prompt 提供记忆能力，以 Markdown 为载体，以 `wire.jsonl` 做对话追溯，以 `themes/` 做主题关联。
+
+这条路线的价值在于**可逆、可实验、低风险**。但它的天花板也很明显：复杂流程压在 Prompt 上，检索与生成脱节，无法利用 kimi-code 主进程的计算和存储优势。
+
+如果 kimi-code 将记忆能力原生内化，最值得深入探讨的是两个方向：
+
+1. **记忆蒸馏服务化**：用 Orchestrator + 权重机制，把 `organize_memories` 从 Prompt 驱动升级为规则驱动的服务
+2. **主题检索基础设施化**：在 compaction 时预计算 refined turns 和 buckets，让主题追溯从 LLM 驱动变为基础设施驱动
+
+这两个方向共享同一个底层目标：**让 LLM 负责语义判断和语言生成，把规则化、可缓存、可索引的工作交给 kimi-code 原生基础设施**。
+
+> 关于主题检索低成本化后可能催生的决策守卫机制，详见 [`decision-guard-design-notes.md`](./decision-guard-design-notes.md)。
+
+---
+
+## 二、方向一：记忆蒸馏服务化
+
+### 2.1 当前困境：Prompt 在同时做太多事
+
+当前 `organize_memories` 的工作方式是：
+
+```text
+memory/ (N 个文件，可能远超上下文窗口)
+    │
+    ▼
+Prompt: "在 15KB 内重新组织，不丢失语义，自己决定权重"
+    │
+    ▼
+LLM 一次性输出 essence.md
+```
+
+LLM 被迫同时承担：理解、筛选、压缩、改写、格式控制。这导致：
+- 不可解释：为什么这条进了 essence，那条没进？
+- 不可复现：换模型结果不同
+- 不可优化：用户说"这条很重要"，系统无法响应
+- 容量受限：记忆量大时无法一次处理
+
+### 2.2 核心思想：把蒸馏拆成"评分"与"编排"
+
+未来的 `organize_memories` 应该分为两层：
+
+```text
+memory/
+    │
+    ▼
+Scoring Engine（Orchestrator 内部）
+    │
+    ├── 统计工具调用次数
+    ├── 读取用户显式反馈
+    ├── 评估 folder/tag/age/update 频率
+    └── 输出每条记忆的 score
+    │
+    ▼
+Tiering
+    │
+    ├── core-memory   (score > 0.9)
+    ├── essence-tier  (score 0.5-0.9)
+    ├── memory-only   (score 0.15-0.5)
+    └── archive-tier  (score < 0.15)
+    │
+    ▼
+LLM 负责语言编排
+    │
+    ▼
+候选 essence.md → diff → commit
+```
+
+**关键转变**：LLM 不再决定"留什么"，只决定"怎么表达"。
+
+### 2.3 实现方式：权重从何而来
+
+权重由三类信号共同决定：
+
+| 信号类型 | 具体维度 | 采集方式 |
+|---------|---------|---------|
+| 行为信号 | recall_count、search_hit、bootstrap_exposure、trace_theme_hit、tag_theme_association | 每次工具调用时计数 |
+| 用户信号 | user_rating、pinned、archived | 用户显式操作 |
+| 结构信号 | folder、tag、age、update_frequency、cross_reference | 文件元数据和引用关系 |
+
+**计数实现**：
+
+```text
+每次记忆工具调用
+    │
+    ▼
+更新内存热计数器（零 IO）
+    │
+    ▼
+触发 flush 条件时写入 index.json：
+  - 累计 N 次调用
+  - 经过 M 分钟
+  - 调用 organize_memories 前
+  - 进程关闭前
+```
+
+`index.json` 中每条记忆增加 `weights` 字段，成为 organize 时的一站式来源。
+
+### 2.4 演化可能性
+
+#### Stage 1：轻量权重
+只统计 recall_count 和 folder/tag 类型，作为 organize 的提示线索。
+
+#### Stage 2：完整评分
+引入多维度权重公式：
+
+```
+score = log1p(recall_count) * 0.25
+      + log1p(search_hit_count) * 0.10
+      + (user_rating / 5) * 0.20
+      + (pinned ? 0.30 : 0)
+      + folder_weight * 0.10
+      + content_type_weight * 0.15
+      + exp(-age_days / 90) * 0.10
+      + log1p(update_frequency) * 0.05
+      + log1p(cross_reference_count) * 0.05
+```
+
+#### Stage 3：动态学习
+根据 organize 后的实际效果反馈，自动调整权重系数。例如：
+- 某条记忆被组织进 essence 后频繁被 recall → 提升其 folder_weight 或 content_type_weight 的系数
+- 用户经常手动把 archive-tier 记忆恢复 → 降低 age 衰减速度
+
+#### Stage 4：个性化权重
+不同用户/团队对同一类记忆的重视程度不同。系统可以学习：
+- 某团队非常重视 `rules/`
+- 某用户经常忽略 `knowledge/`
+- 自动微调个人/团队的权重模型
+
+### 2.5 想象空间
+
+**想象一：记忆健康仪表盘**
+Agent 可以告诉用户：
+> "你的 memory/ 里有 12 条 archive-tier 记忆，3 个月未被访问，建议归档。"
+
+**想象二：自动记忆手术**
+每周自动生成一份"记忆诊断报告"：
+- 这 5 条记忆重复了，建议合并
+- 这条决策已 6 个月未更新，但最近被频繁引用，建议 review
+- 这条知识与 essence.md 中的结论矛盾
+
+**想象三：协作记忆治理**
+多人协作时，不同成员对同一决策的评分可以聚合：
+- 3 人 pinned → 权重显著上升
+- 1 人 archive → 权重轻微下降
+- 形成团队共识驱动的记忆优先级
+
+### 2.6 与方向二的衔接
+
+权重机制不仅影响 `memory/` 的蒸馏，也影响 `refined/` 和 `buckets/` 的处理：
+- 高频引用的 refined turn 应该被优先保留和索引
+- 与用户高评分 memory 相关的 bucket 应该在主题追溯时优先返回
+
+---
+
+## 三、方向二：主题检索基础设施化
+
+### 3.1 Turn Cluster：主题追溯的基本单位
+
+主题追溯不是对单条 turn 的检索，而是对**决策/事件/争论单元**的检索。
+
+对话中的基本单位是 **turn**（一轮对话），但一个真正的决策或讨论往往不是一条 turn 能说完的，而是由一小波连续或相关的 turns 组成。我们把这样的一小波 turns 称为 **Turn Cluster**。
+
+```text
+Turn 12: "我觉得 Auth 应该走 JWT 方案"
+Turn 13: "但 refresh token 怎么存？"
+Turn 14: "我们决定用 httpOnly cookie 存 refresh"
+Turn 15: "好的，前端只存 access token"
+    │
+    ▼
+Turn Cluster: "JWT + httpOnly cookie 方案确定"
+```
+
+基于这个基本认识，主题追溯涉及四层材料：
+
+| 层级 | 本质 | 作用 |
+|------|------|------|
+| **Turn** | 单轮对话 | 原始记录 |
+| **Turn Cluster** | 语义单元，对应一个决策/事件/争论 | 主题追溯的基本单位 |
+| **Bucket** | 相似 cluster 的集合 | 主题候选材料 |
+| **Theme** | 命名的长期概念 | 跨 session 的主题追踪结果 |
+
+一个 Theme 通常由多个 Turn Clusters 组成。例如 "auth-flow" 主题可能包含 "JWT 方案确定"、"refresh token 存储"、"登录页面改造"等 clusters。
+
+### 3.2 当前实现：LLM 驱动下的约束与问题
+
+当前主题追溯的工作方式是：
+
+```text
+User: "auth 主题怎么发展的？"
+    │
+    ▼
+search_context("auth") 粗筛 candidate turns
+    │
+    ▼
+refine_session_turns（LLM 逐条提炼）
+    │
+    ▼
+tag_theme + trace_theme（LLM 聚类、命名、生成主题）
+    │
+    ▼
+（数秒后）返回结果
+```
+
+`search_context` 已经能基于简单关键词做粗筛，用户不需要一开始就给出精准关键词。
+
+**为什么当前实现会这样设计**：
+
+这主要是由客观条件决定的。当前方案依赖 LLM 进行语义理解，而 LLM 调用成本高、延迟高。在这种约束下，系统把语义加工尽可能延后到用户查询时，只做一次性的 turn 原子级别提炼，而把 cluster 发现、bucket 归桶、theme 生成这些更上层的语义加工合并到同一个 LLM 调用中完成。
+
+换句话说，不是设计上的疏忽，而是在 LLM 作为唯一语义处理工具的前提下，为了控制成本和复杂度而做出的合理折中。
+
+**这种设计带来的问题**：
+
+- **提炼发生在查询时**：每次主题追溯都要重新调用 LLM 提炼 turns
+- **延迟高、成本高**：涉及多次 LLM 调用（粗筛理解 + 逐条提炼 + 主题聚合/生成）
+- **提炼结果难以跨主题复用**：按需提炼时，LLM 会在当前主题上下文中生成摘要，导致同一条 turn 的提炼产物带有主题倾向。例如一条同时涉及 auth-flow 和 security 的 turn，为 auth-flow 提炼时会突出 JWT 方案，为 security 提炼时会突出 secret 存储约束
+- **关键词质量仍影响召回上限**：关键词太宽泛会召回大量噪声 turns，增加提炼负担
+- **无法预计算 cluster 和 bucket**：由于 LLM 成本高，无法在 compaction 时就把 turns 组织成语义单元，导致查询时必须从零开始做聚类判断
+
+### 3.3 原生实现：语义分析预计算 + LLM 主题生成
+
+如果 kimi-code 原生引入一个低成本的语义分析服务，上述约束就可以被打破。
+
+**触发时机**：
+
+语义分析服务在 **Context Compaction** 时触发，而不是在用户查询时触发。每次会话 compaction 时，系统都会对本次会话的 turns 进行 native 语义加工。
+
+**会发生什么**：
+
+```text
+Turn 产生
+    │
+    ▼
+Context Compaction
+    │
+    ├── 提炼 turn        → refined/<sessionId>.jsonl
+    ├── 语义分析发现 cluster → clusters/
+    └── 相似 cluster 归桶   → buckets/
+              │
+              ▼
+User: "auth"
+    │
+    ▼
+nativeQuery("auth")（毫秒级）
+    │
+    ▼
+返回 candidateBuckets / clusters
+    │
+    ▼
+LLM 做主题生成：
+    ├── 并桶 / 拆桶
+    ├── 剔除不相关 clusters
+    ├── 从 cluster 中提取关键 turns
+    ├── 命名主题
+    └── 生成 theme 内容
+```
+
+**怎么做**：
+
+语义分析服务可以采用分层实现：
+
+- **规则层**：关键词共现、决策信号词、争论-收敛模式
+- **模型层**：small model 判断讨论单元边界、生成 cluster summary
+- **向量层**：embedding + 聚类，用于 bucket 归桶
+
+这些方法的共同特点是成本远低于 LLM（毫秒级、本地运行），因此可以在 compaction 时频繁调用。
+
+**达到什么效果**：
+
+- **turn、cluster、bucket 三层都预计算完成**，用户查询时不需要再提炼和聚类
+- **nativeQuery 毫秒级返回候选材料**
+- **LLM 只在最后一步介入**，做语义判断、编辑筛选和主题内容生成
+- **同一条 turn 的中性摘要可以被多个主题复用**，避免主题偏向性
+
+**与当前方案的对比**：
+
+| 阶段 | 当前方案（LLM 驱动） | 原生方案（语义分析 + LLM） |
+|------|---------------------|---------------------------|
+| Turn 提炼 | 查询时 LLM 提炼 | compaction 时 native 提炼 |
+| Cluster 发现 | 查询时 LLM 一并完成 | compaction 时 native 语义分析 |
+| Bucket 归桶 | 查询时 LLM 一并完成 | compaction 时 native 聚类 |
+| Theme 生成 | 查询时 LLM 完成全部工作 | 查询时 LLM 做最终主题生成（编辑、命名、关联 memory） |
+
+**关键转变**：主题不是"查询时临时提炼"出来的，而是"从预计算材料中生成"出来的。
+
+### 3.4 核心概念：四层材料模型
+
+主题追溯涉及四层材料，每层职责清晰：
+
+```text
+Layer 0: 原始会话记录
+┌─────────────────────────────────────────────────────────────┐
+│  sessions/                                                  │
+│  ├── session-A/wire.jsonl  ──► 原始 turns（含完整对话）      │
+│  ├── session-B/wire.jsonl                                    │
+│  └── session-C/wire.jsonl                                    │
+└─────────────────────────────────────────────────────────────┘
+                            │
+                            ▼  Context Compaction
+Layer 1: 单轮摘要
+┌─────────────────────────────────────────────────────────────┐
+│  refined/                                                   │
+│  ├── session-A.jsonl                                       │
+│  │     ├── turn-12: "我觉得 Auth 应该走 JWT 方案"            │
+│  │     ├── turn-13: "但 refresh token 怎么存？"              │
+│  │     ├── turn-14: "我们决定用 httpOnly cookie 存 refresh"  │
+│  │     └── turn-15: "好的，前端只存 access token"            │
+│  ├── session-B.jsonl                                       │
+│  └── session-C.jsonl                                       │
+└─────────────────────────────────────────────────────────────┘
+                            │
+                            ▼  语义分析
+Layer 2: 语义单元（决策/事件/争论）
+┌─────────────────────────────────────────────────────────────┐
+│  clusters/                                                  │
+│  ├── cluster-3.json   ──►  turns: [A-12, A-13, A-14, A-15]  │
+│  │                         summary: "JWT + cookie 方案确定"  │
+│  │                         decision: true                   │
+│  ├── cluster-8.json   ──►  "登录错误处理"                    │
+│  └── cluster-12.json  ──►  "token 过期策略"                  │
+└─────────────────────────────────────────────────────────────┘
+                            │
+                            ▼  机器归桶
+Layer 3: 候选材料桶
+┌─────────────────────────────────────────────────────────────┐
+│  buckets/                                                   │
+│  └── bucket-7.json  ──►  [cluster-3, cluster-8, cluster-12] │
+│                          keywords: ["auth", "jwt", "cookie"] │
+└─────────────────────────────────────────────────────────────┘
+                            │
+                            ▼  用户触发 + LLM 生成主题
+Layer 4: 长期主题
+┌─────────────────────────────────────────────────────────────┐
+│  themes/                                                    │
+│  └── auth-flow.json  ──►  clusters: [3, 8, 12]              │
+│                          memories: [memory/decisions/...]   │
+│                          createdAt: ...                     │
+└─────────────────────────────────────────────────────────────┘
+```
+
+**生成链路**：
+
+```text
+wire.jsonl
+    │
+    ▼  compaction
+refined/<sessionId>.jsonl
+    │
+    ▼  语义分析（发现决策/事件单元）
+clusters/<clusterId>.json
+    │
+    ▼  机器归桶（相似 cluster 分组）
+buckets/<bucketId>.json
+    │
+    ▼  用户触发主题追溯 + LLM 生成主题
+themes/<theme>.json
+```
+
+**四层定位表**：
+
+| 层级 | 本质 | 生成方式 | 作用 |
+|------|------|---------|------|
+| **Refined Turn** | 单轮摘要 | compaction 时 native 提炼 | 保留 turn 关键信息，保持主题中性 |
+| **Turn Cluster** | 语义单元，对应一个决策/事件/争论 | 语义分析从 turns 中发现 | 避免单条 turn 孤立，呈现"一波一波"的讨论节奏 |
+| **Bucket** | 机器归桶，无名字 | 按 cluster 语义相似度分组 | 主题候选材料集合 |
+| **Theme** | LLM/用户命名的长期概念 | 用户触发时 LLM 生成 | 跨 session 的长期主题追踪 |
+
+### 3.5 LLM 的角色：主题生成者
+
+native query 返回的是**候选材料**，不是最终主题。LLM 在生成 theme 时既做编辑判断，也做内容生成：
+
+| 操作 | 说明 | 例子 |
+|------|------|------|
+| **并桶** | 两个 candidate buckets 其实讲的是同一个主题 | 把 "jwt" bucket 和 "auth" bucket 合并 |
+| **剔簇** | 某个 cluster 与主题无关，予以排除 | bucket 里有 "登录错误处理"，但主题是 "jwt 方案"，剔除 |
+| **抽 turn** | 一个 cluster 里只有部分 turns 真正相关 | 从 cluster 中提取 turn-14、turn-15 写入 theme |
+| **拆簇** | 一个 cluster 其实包含两个独立决策 | 把 "JWT 方案 + 登录页面改造" 拆成两个 clusters |
+| **命名** | 给 theme 一个准确、稳定的名称 | 命名为 `auth-flow` 而非 `jwt-stuff` |
+| **生成内容** | 把筛选后的 clusters/turns 组织成可读的主题时间线 | 输出 theme 文件，含摘要、时间线、关联 memory |
+
+预计算时的 turn 摘要不知道未来会被哪个主题引用，因此会尽量保持**中性、全面**，覆盖 turn 中的多个关键信息点。查询时 LLM 只需要基于这个中性摘要，按当前主题角度做**精修与组织**，而不是从头提炼。这样同一条 turn 可以服务于 auth-flow、security、frontend 等多个主题，而不会因主题偏向性损失信息。
+
+### 3.6 实现方式：两档预计算模式
+
+#### 轻量模式（默认）
+
+- **Turn 摘要**：关键词提取 + 命名实体识别 + 关键句抽取
+- **Cluster 发现**：规则匹配连续 turns、决策信号词、争论-收敛模式
+- **Bucket 归桶**：TF-IDF / 关键词共现 / 简单规则
+- **LLM 最终生成**：并桶、剔簇、抽 turn、命名主题、关联 memory
+- **资源开销**：+5 MB RAM，+0.5 KB/turn
+- **延迟**：< 2ms per turn
+
+适合大多数 coding agent 场景。
+
+#### 语义模式（可选）
+
+- **Turn 摘要**：轻量 seq2seq 模型
+- **Cluster 发现**：small model 判断讨论单元边界
+- **Bucket 归桶**：small embedding 模型 + 向量聚类
+- **LLM 最终生成**：并桶、剔簇、抽 turn、命名主题、关联 memory
+- **资源开销**：+200 MB RAM（lazy mmap），+1.5 KB/turn
+- **延迟**：< 5ms per turn
+
+适合术语复杂、历史对话量大、对召回质量要求高的场景。
+
+**性能指标**：
+
+| 指标 | 轻量模式 | 语义模式 | 备注 |
+|------|---------|---------|------|
+| Per-Turn Latency | < 2ms | < 5ms | 远低于 LLM |
+| RAM Overhead | +5 MB | +200 MB (Lazy) | mmap 按需加载 |
+| Disk Usage | +0.5 KB/turn | +1.5 KB/turn | `.emb.bin` 可 gitignore |
+| LLM Calls (Cold Start) | 1 | 1 | 仅最终主题生成 |
+
+### 3.7 演化可能性
+
+#### Stage 1：基础预计算
+compaction 时生成：
+- `refined/<sessionId>.jsonl`：每条 turn 的摘要、关键词、时间戳
+- `clusters/<sessionId>/`：语义分析发现的决策/事件单元
+- `buckets/<sessionId>/`：相似 cluster 的归桶
+
+#### Stage 2：跨 session 聚合
+把多个 session 的 buckets / clusters 合并成 workspace 级别的主题候选池：
+- 相似 clusters 跨 session 合并
+- 识别跨 session 的同一个决策/争论的延续
+- 生成 workspace 级别的 term → clusters 倒排索引
+- 支持毫秒级 `nativeQuery(keyword)`
+
+#### Stage 3：主动主题发现
+系统不再等用户说"追溯主题"，而是自动发现值得关注的主题：
+- "最近 3 个 session 都在讨论 Auth，是否生成 auth-flow 主题？"
+- "PlayerState 相关讨论在增加，是否需要整理？"
+
+#### Stage 4：主题演进分析
+不仅返回主题时间线，还能分析：
+- 主题什么时候开始热起来？
+- 主题下有哪些争论和决策转折？
+- 哪些 memory 决策与这个主题相关？
+
+### 3.8 想象空间
+
+**想象一：对话搜索引擎**
+用户可以随时问：
+> "我们之前在哪次讨论里提过 factory pattern？"
+
+系统毫秒级返回相关 turns，而不是让用户翻历史。
+
+**想象二：主题自动归档**
+某个主题下的讨论已经 3 个月没有更新，系统可以提示：
+> "auth-flow 主题已稳定，是否归档到 memory/decisions/auth-flow？"
+
+**想象三：冲突预警**
+当用户新提出的方案与某个历史主题的结论矛盾时：
+> "你现在的方案与 2 个月前 auth-flow 主题中的决策冲突，是否查看？"
+
+**想象四：项目回忆录**
+项目 milestone 时，自动生成：
+> "这是 Auth 模块从提出到定案的完整演进：…"
+
+### 3.9 三个关键设计点
+
+#### 三层材料：Bucket / Turn Cluster / Theme
+
+生成顺序：`turns → 语义分析 → clusters → 归桶 → buckets → 用户触发 → theme`。
+
+一个 Theme 可能是 "auth-flow"，它下面有 "JWT 方案确定"、"refresh token 存储"、"登录页面改造"等多个 Turn Clusters。
+
+#### 关键词从"召回条件"变为"导航入口"
+
+预计算之前，关键词既要负责召回，又要帮助 LLM 理解主题范围。预计算之后，关键词只负责"指向哪个方向"，native query 通过同义词扩展、cluster 摘要和 bucket 归桶自动召回相关材料。即使用户只说 `auth`，系统也能把 `login`、`jwt`、`token`、`refresh` 等相关 clusters 一起带回。
+
+#### LLM 是主题生成者
+
+native query 返回的是**候选材料**，不是最终主题。LLM 在生成 theme 时既做编辑判断（并桶、剔簇、抽 turn、拆簇），也做内容生成（命名主题、撰写时间线、关联 memory）。这种设计让 LLM 专注于**语义判断、编辑筛选和语言生成**，而不用从零整理材料。
+
+---
+
+## 四、两个方向的协同
+
+```text
+                    memory/
+                       │
+                       ▼
+            Orchestrator + 权重评分
+                       │
+                       ├──► essence.md
+                       │
+                       └──► core-memory
+                                  │
+                                  ▼
+                          指导 refined turn 的保留优先级
+                                  │
+                                  ▼
+              compaction 预计算 refined + clusters + buckets
+                                  │
+                                  ▼
+                      nativeQuery 毫秒级返回材料
+                                  │
+                                  ▼
+                    LLM 编辑主题（并桶/剔簇/抽 turn）+ 命名 + 关联 memory
+                                  │
+                                  ▼
+                              themes/
+                                  │
+                                  ▼
+                    反馈更新权重（recall_count、trace_theme_hit）
+```
+
+**协同点**：
+- 权重机制决定哪些 memory 会影响主题生成时的上下文
+- 主题追溯的命中次数会反过来提升相关 memory 的权重
+- 高频主题可以沉淀为新的 memory/ 条目
+- 形成"记忆使用 → 权重更新 → 蒸馏优化 → 主题更准确"的正循环
+
+---
+
+## 五、结论
+
+最小入侵方案已经验证了记忆系统对 coding agent 一致性的价值。原生内化后的下一步，不是堆砌更多功能，而是把两个核心流程做深：
+
+1. **记忆蒸馏服务化**：让 `organize_memories` 从"Prompt 压榨 LLM"进化为"Orchestrator 基于权重做材料准备 + LLM 做语言编排"
+2. **主题检索基础设施化**：让主题追溯从"查询时 LLM 提炼"进化为"compaction 时预计算材料 + 查询时 native 召回 + LLM 做主题生成"
+
+这两个方向共同指向一个目标：**让 LLM 负责语义判断和语言生成，把规则化、可缓存、可索引的工作交给 kimi-code 原生基础设施**。
+
+主题检索基础设施化也为更高阶的能力（如决策守卫）提供了数据基础。关于决策守卫的深入探讨，详见 [`decision-guard-design-notes.md`](./decision-guard-design-notes.md)。
+
+最现实的落地路径：
+
+```text
+现在：      最小入侵方案（Prompt 驱动）
+            │
+Phase 1：   Orchestrator + 权重评分 + 热计数器
+            │
+Phase 2：   compaction 预计算 refined turns + clusters + buckets（轻量模式）
+            │
+Phase 3：   语义模式可选 + 跨 session bucket 聚合 + 主动主题发现
+            │
+Phase 4：   记忆健康仪表盘 + 主题演进分析 + 协作记忆治理
+```
+
+---
+
+*文档性质：架构建议 / 讨论稿*  
+*生成时间：2026-06-23*  
+*与任何具体项目无关*