rc-69f36007-0ec9 2026.04.30 47 KB

MER-218 / MER-196 / MER-68 · 自主学习与记忆层 — 路线建议

原始 research campaign 输出，来自 meridian runtime architecture research。这页保留报告结构和运行痕迹，正式文章会在写作区重写。

MER-218 / MER-196 / MER-68 · 自主学习与记忆层 — 路线建议

Campaign: rc-69f36007-0ec9 · meridian-runtime-architecture-research Topic: t03 — memory server / embedding / 向量检索 / 知识图谱 / autoDream 在 Meridian / Vyane 中如何取舍，给出落地建议路线。写作时间：2026-04-30

0. 一句话结论

这三张卡讲的不是同一件事。MER-68 是「评估」、MER-196 是「实做」、MER-218 是「在前两件就绪后做的应用层闭环」，不要捆在一起推。 MER-68 该评的早就在 2026-04-09 调研里答过了：MCP memory server（直接套 mem0/MemPalace 这种）短期不上、Neo4j/Graphiti 这类外部依赖不引入、本地走 SQLite + sqlite-vec + FTS5 的混合检索；这条结论已经通过 MER-274 落地为 tools/memory/，可以直接关掉 MER-68 评估部分。 MER-196 拆成四件事：(1) 把 ADR-010 MemoryProvider 契约合进 main、(2) 给 LocalProvider 接上 tools/memory/ 已有的 sqlite-vec 索引作为 search 后端、(3) autoDream 按 GPT review 的 5 段拆法（Orient → Gather → Validate → Apply → Index）做 MVP0「只产 patch、不写文件」、(4) 知识图谱降级成 Phase 3+ 的可选增量，先不做。 MER-218 的「自主学习」其实是 autoDream 拿到 patch 后的下游：低 confidence 候选 → 进 inbox 让 Maple 选择题；不是另一个独立系统。

1. 任务理解

1.1 三张卡的现状

通过 Linear API 直接拉的字段：

字段	MER-218	MER-196	MER-68
Title	feat: Agent 自主学习能力 — 外部知识获取 + 消化 + 自适应改进	feat: 记忆层升级 — embedding + 跨 session 搜索 + autoDream	知识管理演进评估：MCP memory server / 向量检索 / 知识图谱
State	Backlog	Backlog	Backlog
Priority	3 (Medium)	3 (Medium)	4 (Low)
Created	2026-04-07	2026-04-06	2026-03-09
Comment 里挂的前置 research	—	mempalace / autodream / knowledge-graph 三份	knowledge-graph / pkm-tools 两份
关联	与 MER-196 / MER-216 / MER-217 都有交叉	Vyane Phase 1.5；前置已完成	演进评估，长期

MER-218 描述的能力矩阵是四点：(1) 主动知识获取、(2) 消化沉淀、(3) 自适应改进、(4) 关键节点汇报。MER-196 描述的范围是 “Google embedding 接入 / session summary embedding 索引 / 跨 session 语义搜索 / OpenClaw 知识迁移 / autoDream / 跨设备同步”。MER-68 描述的是 “短期 MCP memory server / 中期本地 RAG / 长期知识图谱” 三段评估。

1.2 为什么要把三张卡放一起调研

它们在 Maple 04-08 的反馈里其实是一个意思：让 agent 不再每次"重新认识 Maple、重新学一遍项目、重新踩同一个坑"。但实现路径上是三层东西：

MER-68 = 选型 / 评估（要不要上 mem0、要不要上 Neo4j、要不要上 KG）
MER-196 = 主存升级（embedding + 跨 session 检索 + 后台整理 = autoDream）
MER-218 = 应用层闭环（agent 自己找资料、自己写沉淀、自己改进、自己阶段汇报）

这次任务要给的不是三张卡分别的方案，是一条把三层串起来的最低成本路径。

1.3 不在范围内

完整 autoDream prompt / SQL schema / 代码（前置调研已经写得很细，本报告只指路）
重做 mempalace / knowledge-graph / pkm-tools 的对比（这三份 2026-04-09 的报告读过了，结论沿用）
决定外部 SaaS（Honcho / Supermemory / Mem0 cloud）要不要用 — 这是 Maple 的判断，不是技术调研问题

2. Evidence — 调研依据

2.1 已经落地的部分（这是关键发现）

很多对话里把 MER-68 / MER-196 当成"还没动"，但仓库里已经有不少东西就位了。

模块	路径	状态	说明
Memory hybrid search 索引	tools/memory/	MER-274 Done	SQLite `files / chunks / chunks_fts / chunks_vec / embedding_cache` 5 表 + FTS5 + sqlite-vec（fallback Python 余弦）+ 加权融合 0.55/0.45 + CLI（status / reindex / search）
Memory provider 契约草案	`vyane/docs/decisions/010-vyane-memory-provider-contract.md`	MER-275 Triage，feature/adr-010-memory-provider-contract 分支 f22e278	5 方法 Protocol + 5 kwargs + 3 provider（Local/Honcho/Supermemory）+ 8 invariant + 13 contract test
Repo 内共享记忆	data/shared-memory/	MER-98 Done	47 份 markdown（feedback / project / reference / user 四前缀）+ MEMORY.md 索引；通过 Syncthing 三端同步；CC CLI 通过 symlink 读写
Auto-memory cross-runtime	MER-98 / `data/shared-memory/feedback_memory_sync.md`	Done	`.claude/memory/` 已经从专属目录 symlink 到 `data/shared-memory/`，Codex / Gemini / Yi 都能读
前置调研报告 6 份	`docs/research/autonomous-2026-04-09/`	完成	mempalace-analysis / mempalace-vyane-integration / autodream-design / autodream-gpt-review / knowledge-graph-survey / pkm-tools-comparison
Hermes 实战参照	data/research/2026-04-24-hermes-insights-round1.md / round2.md	完成	Round 2 §3 是 ADR-010 草案的源

因此 MER-68 大部分评估问题已经有答案、MER-196 的"嵌入 + 检索"层也已经有可用代码。剩下的不是从 0 评估，是把已经分散落地的部件接到一起、合一份正式的 provider 契约。

2.2 还没落地的部分

缺什么	影响
`vyane/src/vyane/memory/` Python 模块	ADR-010 还在 feature 分支，实现层不存在；Yi / daemon 没法以 provider 方式写 memory
LocalProvider 实现	上面这件事的具体落地
Memory ↔ index 的桥	tools/memory/ 现在只是个 CLI 工具，不是 daemon 的 provider 后端，写入路径没接通
autoDream 实际运行	4 月 9 号设计稿在，没有代码；GPT review 又指出设计稿有 8 处需要修正
知识图谱	完全没动，前置调研明确说 Phase 3+ 再考虑
自动汇报 / 阶段 sync（MER-218 第 4 项）	Yi 已经有 Discord 通道但没有把"我做到哪"作为 first-class 概念暴露

2.3 tools/memory/ 当前能力（实测自源码）

读了 tools/memory/schema.sql / indexer.py / search.py / embedding.py / README.md，确认：

Schema：5 张表，FTS5 + sqlite-vec 双轨，embedding_cache 按 (provider, model, provider_key, hash) 复用
Embedding：当前是 HashEmbeddingProvider（SHA-256 token bag-of-words → 64 维归一化向量），id="local-hash" model="hash-bow-v1"；这是占位，不是语义模型 — README 明确说这是"在没接真 embedding 之前让 hybrid 排序能跑起来的 dependency-free 兜底"
检索：FTS5 BM25 排序 + 向量余弦（有 sqlite-vec 走 MATCH vec_f32 否则 Python 全扫描）→ 加权 0.55 vec / 0.45 text → top K
CLI：uv run python -m tools.memory.cli {status|reindex|search}，索引文件默认 data/memory-index.sqlite（已 .gitignore）
测试：tests/test_memory_tool.py 三个 test 覆盖 sync / status / sqlite-vec backend probe，全部就位

意味着：search 层（MER-196 第 3 项）在 Meridian 仓库里已经可以工作，欠的只是把 hash embedding 换成真 embedding，以及把 indexer 接到 daemon 的写入路径上。

2.4 ADR-010 草案要点（feature 分支）

读了 vyane/docs/decisions/010-vyane-memory-provider-contract.md 全文（529 行）：

D-1 Protocol：5 个核心方法 initialize / save_memory / recall / list_memories / search_memories / delete_memory / shutdown，Python Protocol + ABC 混合（duck-typing 友好 + 内置共享默认）
D-2 kwargs 契约：5 个 kwarg — agent_context（dict，含 origin / agent_run_id / role / task_id / turn）/ agent_identity（“yi” / “codex” / …，禁空字符串）/ parent_session_id / session_platform（必传）/ visibility（必传，4 档 enum）
D-3 SessionPlatform enum：CLI / CODEX_CLI / GEMINI_CLI / IM_YI / VYANE_DAEMON / CRON / MCP_SERVER / WEB / API / ANY（仅查询用）
D-4 origin × action 决策表：primary 全开；subagent 必标 identity 且 visibility 上限 agent；cron / flush 写入 no-op；review 限 agent visibility
D-5 三 Provider 实现：LocalProvider（MVP，SQLite + FTS5）/ HonchoProvider（可选 SaaS）/ SupermemoryProvider（Phase 3 前不投入）
D-6 Migration：47 文件 dry-run 预览 + 一次性 import；按文件名前缀映射 visibility（user_* feedback_* reference_* → shared，project_* → project）
8 个 invariant：幂等 / identity 非空 / 跨 platform 显式 / memory_id 稳定 / delete identity scope / contract test 强制 / kwargs lifecycle 冻结 / cron skip 留痕
13 条 contract test：覆盖 I-1 ~ I-5 + cron skip + subagent must tag + visibility 上限 + initialize twice

这份契约写得很完整，与 tools/memory/ 的 schema 完全可以对得上。LocalProvider 实现的工作量主要是封装 tools/memory/，加幂等、identity 校验、visibility 过滤这三层语义。

2.5 autoDream 的设计现状

读了三份相关报告：

docs/research/autonomous-2026-04-09/autodream-design.md（CC source 反推 + Vyane 适配，~40 KB，含完整四阶段 prompt + lock.py / sources.py / autodream.py 伪代码）
docs/research/autonomous-2026-04-09/autodream-gpt-review.md（GPT 交叉审查，列了 8 项设计缺陷）
vyane/docs/research/cc-source-autodream.md（直接读 CC CLI 源码 consolidationLock.ts / consolidationPrompt.ts 反推）

关键判断（综合三份）：

三层 gate（time / session-count / lock） 设计精妙，应直接搬
四阶段（Orient / Gather / Consolidate / Prune）压在一次 LLM 调用 是 GPT review 提的最大缺陷 — 抽取和写入互相污染、错抽就直接进长期记忆
应改成 5 阶段：Orient / Gather / Validate / Apply / Index，Validate 产 JSON 变更集，Apply 才落盘
审核单元从"文件"升级到"变更集"：每条新增 memory 必须带 source 锚点（session_id + 摘录），Maple approve 的是 patch 不是 file
回滚策略改 touched-files-only，不要 git checkout -- data/shared-memory/（dirty worktree 会误伤手工改动）
draft / active 状态机要补：“已有 active 文件被 dream 更新” 这条主路径在原设计里没显式覆盖
scope 显式化：避免 session / agent / project / org 的内容被无差别灌进同一个 shared 层
MVP 范围太乐观：1-2 天做完 + Discord approve / reject + 回滚不现实，应分 MVP0 ~ MVP3 四档

2.6 知识图谱的取舍（MER-68 中的"长期"）

knowledge-graph-survey.md 已经把行业方案（Graphiti / Mem0 / Letta / Cognee / GraphRAG / MemPalace）都对了，结论清楚：

向量检索擅长"找相关的"；KG 擅长"找连接的"、多跳推理、时序事实、矛盾检测、可审计性
不引入 Neo4j：JVM 进程 2-4 GB 内存，本地个人项目过重
不引入 Graphiti：依赖 Neo4j + 实时 LLM 提取，API 成本高
如果要做 KG，用 SQLite entities + triples 表，加 valid_from / valid_to + superseded_by 字段：千级节点 recursive CTE 毫秒级，万级加索引仍可接受
实体提取分三阶段：Phase 1 手动 + handoff 半结构化抽取；Phase 2 session 结束时批量 LLM；Phase 3 实时 + 矛盾检测；宁缺毋滥

hermes-insights-round2.md §2 还提到一条额外路：Holographic HRR phase-vector 代数做矛盾检测（bind / unbind / bundle + 共享 entity 检测向量距离），算力消耗低 + 跨进程 deterministic + 无需 LLM。这个路子实验性强，列为 Phase 4 可探索项，不主线。

2.7 外部生态参考

框架	核心	适合 Meridian？	理由
Mem0	向量 + 摘要	否	LongMemEval E2E 49.0%，时序弱；本地路径已经够
Zep + Graphiti	Neo4j 时序 KG	否	部署重，本地依赖太多
Letta (MemGPT)	多层 + 工具	否	框架侵入大
Cognee	图 + 向量混合	否	开源但生态小
MemPalace	ChromaDB + SQLite KG	借鉴	LongMemEval R@5 96.6%；scope 分层 / Drawer / 时序 KG / Wing-Room 已被 ADR-003 v2 抽象成 MemoryStore 概念
Honcho	peer × session × observation	可选 Phase 2/3	如果 Maple 接受 SaaS（隐私评估）；ADR-010 D-5 已留位
Supermemory	Hermes v0.8 新增	待验证	release note 摘要而已，没实际对接
Obsidian / Notion / Logseq	PKM 工具	否	pkm-tools-comparison.md 明确说"自建核心 + MCP 暴露"，不引入外部 PKM
MCP memory server (官方 / cyanheads obsidian-mcp 等)	MCP 协议暴露	否（不在第一阶段）	CC CLI 已直接读写文件，再加一层 MCP 是反向工程；ADR-010 第 5 个 SessionPlatform enum 留了 `MCP_SERVER`，说明 Vyane 自己作为 MCP server 暴露 memory 是规划中的，但反过来引入外部 MCP server 不是

2.8 Maple 的硬约束

来自 docs/projects/vyane-personal-runtime-plan.md / briefing-current.md / data/shared-memory/ 多份文件：

理解优先于实现：当前不主动写代码，方向先对齐
personal-first：先服务 Maple 自己，对外通用化往后排
daemon 稳定第一：webhook auth / scheduler readiness / hot reload 优先于 memory 新功能
不引入云依赖、不外泄：feedback_memory_sync.md — memory 走本地 + Syncthing
Linear 当日处理：本报告写完应该挂回 MER-218 / MER-196 / MER-68 的 comment

3. 设计原则

把前置调研、ADR-010 草案、Maple 反馈炼成 6 条原则：

先选后存、先存后提。原始数据（data/shared-memory/ 47 文件 / session jsonl / git log）始终是 source of truth，索引和 KG 是衍生物。任何"写到 memory 库"的动作必须能从原始数据再生。
provider 抽象优先于 backend 切换。先把 ADR-010 contract 合并、把 LocalProvider 落地，再考虑要不要换 Honcho / Supermemory。这一条会救我们之后任何选型反复 — 改 backend 不动 caller。
autoDream 的输出是 patch 不是 file。GPT review 说得对：抽取和落盘必须有中间检查点。把 5 阶段中的 Validate 显式产 JSON 变更集，Apply 才动磁盘。
知识图谱不是 Phase 1。先把向量 + FTS5 + autoDream + provider 接口跑顺，再讨论 KG。否则会出现"先做了 KG schema 但没东西可填"的尴尬。
自主学习是闭环不是新系统。MER-218 的"主动找资料 / 消化 / 自适应改进"等于 autoDream 的 Gather → Validate → Apply + 一条到 inbox（MER-229）的兜底。不要为它另起 service。
Yi / daemon / 工具是 memory 的 client，不是 source。Yi 写入要走 ADR-010 contract；daemon scheduler 触发 dream 要走 contract；tools/memory/ CLI 是 power user 工具，不是日常路径。

4. Findings — 推荐架构

整体形态四层。每一层都尽量复用已有组件。

                Maple ↔ Yi (主对话) / Codex (后台 worker) / 其它 AgentRun
                                │
                ┌───────────────┴───────────────┐
                ▼                               ▼
              写入                            读取
   save_memory / write_conclusion     recall / list / search
                │                               │
                └───────────────┬───────────────┘
                                ▼
                Layer 1 · Provider 契约层（ADR-010）
                MemoryProvider Protocol + 5 kwargs
                LocalProvider / HonchoProvider / Supermemory
                                │
                                ▼
                Layer 2 · 存储 + 索引层
                ┌───────────────┬───────────────┐
                ▼               ▼               ▼
         MarkdownStore   sqlite-vec/FTS5    KnowledgeGraph
         data/shared-     index.sqlite       (Phase 3+)
         memory/*.md      (= tools/memory)   triples + valid_*
                                │
                                ▼
                Layer 3 · 后台整理层 (autoDream)
                Orient → Gather → Validate → Apply → Index
                产 JSON patch；Maple approve 才落 markdown
                                │
                                ▼
                Layer 4 · 自主学习闭环（MER-218）
                外部知识获取 → autoDream Validate → inbox
                aphasia 项目摘要 → 进 MER-229 inbox
                自适应改进 → lessons / patterns 入 memory
                关键节点汇报 → Discord (通过 Yi)

4.1 Layer 1 · Provider 契约层

核心动作：把 feature/adr-010-memory-provider-contract 分支 review、合 main，落 vyane/src/vyane/memory/。

为什么先做这一层：因为它是其他所有事情的瓶颈。LocalProvider 不写出来，autoDream 没法写 memory，Yi 没法用 provider 写 conclusion，Codex worker 没法 save。这一层的 ROI 最高、阻塞最多。

LocalProvider 实现工作（≤500 行 Python）：

封装现有 tools/memory/MemoryIndexer + MemorySearch 作为 search 后端
在索引之上加 ADR-010 的语义层：memory_id 稳定（hash content + identity + ts）/ 幂等（同三元组 upsert 不新建）/ visibility / identity 过滤
save_memory 写两份：一份进 data/shared-memory/<topic>.md（保持 CC CLI 兼容），一份进索引；MarkdownStore 是 source of truth
cron/flush origin 直接 no-op + log（I-8）
contract test 13 条（ADR-010 §4 已经把测试清单给齐了，跟着写）

这一步的副产品：tools/memory/ 的 hash embedding 可以保留作 dev fallback，真 embedding 不在 LocalProvider 里做选型，而是做成可注入的 EmbeddingProvider：

class LocalProvider:
    def __init__(self, root: Path, embedding: EmbeddingProvider | None = None):
        self.embedding = embedding or HashEmbeddingProvider()  # dev 兜底
        # Phase 1 后接 Google embedding-001 / Qwen / sentence-transformers

这样 embedding 选型可以单独迭代，不阻塞 provider 层。

4.2 Layer 2 · 存储 + 索引层

沿用前置结论，三件子事：

4.2.1 MarkdownStore（已有）

data/shared-memory/*.md 47 文件不动；保持 Syncthing 同步、保持 CC CLI symlink 直读、保持人工可读可编辑。这一层是兜底。

4.2.2 sqlite-vec + FTS5 索引（已有 + 升级）

tools/memory/ 已经能跑。需要做的是：

工作	工作量	触发时机
把 `HashEmbeddingProvider` 替换成 `GoogleEmbeddingProvider`（embedding-001）	1 天	LocalProvider 接通后
增量 reindex hook：daemon 监听 `data/shared-memory/` 变化 → 调 `MemoryIndexer.sync()`	1 天	LocalProvider 接通后
Session jsonl 索引扩展：把 `data/sessions/` 也喂进 indexer（MER-187 一旦落地）	0.5 天	MER-187 完成后
`model` 字段处理：从 hash-bow-v1 切换时清空 chunks 重索引	0.5 天	embedding 切换时一次性

embedding 选型上，knowledge-graph-survey.md 推荐过 all-MiniLM-L6-v2（MemPalace 验证 R@5 96.6%）；MER-196 描述里说 “Google embedding 模型接入（已有 API key）”，那就 Google embedding-001 优先 — 不要双轨，选一个就好。Maple 决定。

4.2.3 KnowledgeGraph（Phase 3+，先不做）

如果未来要做：

直接搬 knowledge-graph-survey.md §三/五给的 SQLite schema（entities + triples + valid_from / valid_to + superseded_by + confidence）
不上 Neo4j、不上 Graphiti
实体提取走 Phase 1 → Phase 3 渐进（手动 → 批量 LLM → 实时）
触发面：session handoff 完成、autoDream Validate 阶段产副产品

判断为什么不进 Phase 1-2：当前 47 个 memory + ~100 个 research file 规模下，“找相关的” 比 “找连接的” 有用得多；KG 给的多跳推理 / 矛盾检测在数据量上来之前 ROI 很低。GPT review 也提了类似观点。

4.3 Layer 3 · autoDream

关键修订：按 GPT review 把 4 阶段拆成 5 阶段；首版只做 MVP0。

5 阶段：

阶段	输入	输出	工具权限
Orient	shared-memory 索引 + dream-state.json	现状摘要（内部）	Read
Gather	session jsonl + git log + worker logs	候选 memory list（内部）	Read + Grep
Validate	候选 list	JSON 变更集 + 每条 confidence + scope + source 锚点	计算（无 IO）
Apply	JSON 变更集	实际 markdown / index 修改	Write 限于 shared-memory
Index	修改后的 shared-memory	MEMORY.md 更新	Edit 限于 MEMORY.md

MVP 分四档（GPT review 给的拆法）：

MVP0 · 只产 patch：Orient / Gather / Validate 三步，输出 ~/.local/share/vyane/dream/<run_id>.patch.json，不动文件。Maple 看 patch、决定要不要 apply。这一档是建议的实际起点。
MVP1 · 只新建 draft：Apply 阶段允许写 data/shared-memory/<new>.md 但 frontmatter 必含 status: draft；不改已有 active 文件；不做 Index。
MVP2 · 引入变更集审批 + per-file rollback：autoDream 完成后通过 Yi 推送 patch 摘要到 Discord，!dream apply <run_id> / !dream reject <run_id>；apply 前对 touched files 做内容快照。
MVP3 · 增量 source（git / Linear / worker logs）+ Index 自动维护 + 已有 active 文件的增量 Edit。

触发链（沿用 CC autoDream 三层 gate + 加配置门）：

FeatureGate (config enabled)
  → TimeGate (>= min_hours since last dream)
  → ScanThrottle (>= 10 min since last scan)
  → SessionGate (>= min_sessions since last)
  → DaemonLock (mtime + PID)
  → 跑 5 阶段

锁策略直接搬 vyane/docs/research/cc-source-autodream.md §三的 mtime + PID 设计，已经被验证过。

接 Provider 而不是直接读写 markdown（GPT review 第 2 项 + ADR-010 集成）：

async def _apply(self, patch: dict, provider: MemoryProvider):
    for change in patch["changes"]:
        if change["op"] == "add":
            provider.save_memory(
                content=change["content"],
                agent_identity="autodream",          # 显式 identity（I-2）
                scope=change["scope"],               # 来自 Validate 阶段判断
                metadata={
                    "source_session": change["source_session"],
                    "excerpt": change["excerpt"],
                    "confidence": change["confidence"],
                    "draft": True,                   # 等 Maple approve
                },
            )
        elif change["op"] == "update":
            ...

这样 autoDream 不直接知道底层是 LocalProvider 还是 Honcho — 写入语义统一。

4.4 Layer 4 · 自主学习闭环（MER-218）

重新表述 MER-218：它不是另一个独立子系统，是 autoDream + 已有几个组件的组合，绑成一条自反馈闭环。

四个能力对应到现有组件：

MER-218 能力	对应已有组件	缺什么
1. 主动知识获取	smart-search skill / Tavily / WebSearch / context7 / Yi 调研模式	不缺。Yi 已经会调用
2. 知识消化与沉淀	autoDream Gather / Validate / Apply	autoDream 落地（4.3）
3. 自适应改进	autoDream 抽取的 lessons / patterns 写到 memory	autoDream 落地后免费拿到
4. 关键节点汇报	Yi 主动 push Discord、Linear comment	缺一个 “checkpoint signal” 概念

第 4 项的具体落地：

不重做汇报系统。在 AgentRun lifecycle 里加一个 checkpoint(reason, summary) 调用约定：

任何 long-running AgentRun（autoDream / research campaign / 大 worker）在 phase 切换、关键决策、blocker 出现时调用 checkpoint
daemon 的 checkpoint 实现：写 worker_registry 的 metadata + 通过 Yi（或当前活跃 channel）push 一条 markdown 摘要
频率限流：默认 ≥ 30 min 一次 / phase 切换时强制；防 Maple 被刷屏
这件事在 t01（MER-229）的 “Layer 4 Human-in-loop” 里已经有类似设计，可复用

与 MER-229 的边界：

MER-229 inbox 处理"分支 idea"
MER-218 “知识获取消化” 处理"调研产出 / 学到的事实"
两者的载体不同：idea inbox 是 idea-inbox.jsonl（待审议素材），知识沉淀是 memory provider（已审议事实）。autoDream Validate 阶段如果遇到"这是新方向"而不是"这是新事实"，应该 emit 到 idea inbox，不入 memory。

5. 阶段方案

Phase A · 不阻塞 daemon 稳定 / 当前可做（≤ 当周）

任务	目的	阻塞
把本报告挂回 MER-218 / MER-196 / MER-68 三张 issue 的 comment	收口三张卡当前的实际状态	无
关 MER-68：在 Linear comment 里说明评估已完成（结论沿用 knowledge-graph-survey.md + pkm-tools-comparison.md + MER-274 Done），状态可改为 Done 或 Cancel	减少卡片噪音	Maple 拍板
ADR-010 review：把 feature/adr-010-memory-provider-contract 分支跑一遍（读 529 行 + 跟踪 13 contract test 是否能写出来）	准备合并	—
把 tools/memory/ 跑一次真实 reindex（喂 data/shared-memory/ + docs/research/ + 47 + ~107 文件），看 status / search 输出	验证 hash embedding fallback 是否够用作 dev	无
写一个 t02 / t04 联动 RFC：把 MER-218 第 4 项的 checkpoint 概念形式化（也许走 ADR）	解锁 MER-218 自主学习的最后一项	无

Phase B · daemon 稳定后 / 2-4 周内

前置：webhook auth 收紧、scheduler shadow → 验证完毕、hot reload 稳定。

任务	工作量估计
合并 ADR-010 到 vyane main	0.5 天 + review
落地 `vyane/src/vyane/memory/` 模块（Protocol + LocalProvider + tests）	3-4 天
LocalProvider 接到 tools/memory/ 作为 search 后端	1 天
Migration 脚本：47 文件按 D-6 规则一次性 import index	0.5 天，含 dry-run
Yi 改造：sync_turn / 关键决策 → save_memory（非阻塞 / async writer 队列）	1-2 天
autoDream MVP0：Orient + Gather + Validate，输出 patch JSON 不写文件	3-4 天
daemon `vyane status` / dashboard 加 memory panel（pending patch 数 / 索引 chunks 数 / 最近 dream 时间）	0.5 天

这一阶段验收：

LocalProvider contract test 13 条全绿
Yi 跑一周，每天能在 data/shared-memory/ 看到 sync_turn 副产品（自动新建的 conclusion 文件）
autoDream MVP0 产出的 patch JSON 能用 vyane memory dream-show <run_id> 打开看，确实能识别出 session 里的"决策 / 偏好 / 经验"

Phase C · MVP1 → MVP2（autoDream 写入 + 审批，6-10 周内）

任务
autoDream MVP1：Apply 阶段允许新建 draft 文件，不动 active 文件，不做 Index
Yi 推送 patch 摘要到 Discord + `!dream apply / reject <run_id>` slash
Per-file 内容快照 + apply 失败回滚（不依赖 git stash）
Embedding 切换：HashEmbeddingProvider → Google embedding-001
索引扩展：纳入 data/research/ + 历史 data/sessions/
LocalProvider sync_turn 自动生成的 conclusion → 自动绑 source 锚点（source_session + 摘录范围）

这一阶段的关键不确定项是 patch 审批的 UI/UX：Yi 推送的格式、Maple 怎么快速看 diff、如果 patch 太长怎么折叠 — 等 MVP0 跑过两周再决定。

Phase D · MVP3 + 知识图谱探索（远期）

任务	触发条件
autoDream MVP3：增量 source 接 git / Linear / worker logs；Index 自动维护；允许 Edit 已有 active 文件	MVP2 跑稳
KG schema 上线（SQLite triples + valid_from / valid_to + superseded_by）	memory 数据量 ≥ 200 文件，且 Maple 想要 “Vyane 用过哪些模型” 这种时序查询
实体抽取 Phase 2：session handoff 结束时用廉价模型（Haiku / Flash）批量提取三元组	KG schema 上线
Holographic HRR 矛盾检测实验	数据量 ≥ 300 文件 + Maple 显式想做 memory hygiene
Honcho / Supermemory 可选 backend 评估	Maple 评估隐私后决定
Vyane 自己作为 MCP server 暴露 memory（让外部 IDE / Claude Desktop 直接调）	Yi / 自研 IM 都稳定后
跨设备并发写：当前 data/shared-memory/ Syncthing 模式 OK；若 daemon 双端都写 SQLite index，需要按设备分文件 + 周期合并（参考 t01 R8）	daemon 双端都跑后

6. Risks & Uncertainty

按对推进的影响排。

6.1 高优先级

R1 · provider 抽象先于实现的反向风险 ADR-010 草案写得很完整，但 LocalProvider 没实现过；contract test 13 条有可能在实现时发现某条语义和现实需求对不上（例如 visibility 上限规则被觉得过严）。应对：MVP 阶段允许 contract test 反推 ADR — 改 ADR 比改代码便宜。Maple review 时不要把 ADR 看成最终态。

R2 · embedding 选型悬空 tools/memory/ 用的是 HashEmbeddingProvider 占位，MER-196 又说有 Google embedding API key，knowledge-graph-survey.md 推 all-MiniLM-L6-v2，三方没合一。应对：Phase B 锁定单一选型 — 推荐 Google embedding-001（已有 key、网络可用、维度合适）；本地兜底用 sentence-transformers MiniLM（≈85 MB，本地推理）。不要 dual-track。

R3 · autoDream 写入主路径的安全性 GPT review 列了 8 处需要修。如果 MVP 直接走原 4 阶段 + 一次 LLM 调用 + Edit shared-memory，第一次出错就会污染长期记忆。应对：MVP0 严格"只产 patch、不写文件"；MVP1 严格 “只新建 draft、不改 active”。两道闸门。

R4 · Markdown ↔ Index 的双源一致性 LocalProvider 写两份（markdown + sqlite-vec），如果只写一份成功，下次 reindex 才能恢复。应对：write-then-index 顺序固定（先 markdown 后 index）；index 失败不视为整体失败，下次 sync 会捞回；定期 vyane memory verify 检查两边一致性。

6.2 中优先级

R5 · 跨 agent identity 污染 ADR-010 的 visibility / origin 规则是写在 contract 里的，但当前唯一活跃的 persistent agent 是 Yi；其他 AgentRun 用 agent_identity="system" 还是各 role 名（Developer / Reviewer）？应对：Phase B 实现时定一份 default identity 表（持久 Agent 用名字 / 一次性 AgentRun 用 system-{role}）；Maple 决定。

R6 · cron / flush guard 漏写 ADR-010 D-4 + I-8 要求 cron / flush origin 写入 no-op，但 daemon 哪些路径属于 cron 没显式列。应对：在 Phase B daemon scheduler 改造时同步加 origin 标注（scheduler 触发 → cron；用户主动 → primary；subagent spawn → subagent）；这是 ADR-007 grant 体系的延伸。

R7 · sqlite-vec 跨机/跨 Python 版本兼容 MER-274 描述里就提到这个未实测点。Mac mini 上的 sqlite 可能没编译 vec 扩展，fallback 到 Python 余弦扫描在数据量上来后会变慢。应对：Phase B 在两端跑一次 vyane memory status，确认 vector backend 状态；如果 Mac mini 走不了 sqlite-vec，至少 indexer / searcher 仍然能用 Python fallback；不阻塞 LocalProvider。

R8 · autoDream 的 origin = “review” 还是 “primary” autoDream 是 daemon 起的 forked agent，写 memory 时 origin 算什么？应对：定 origin="review"（D-4 决策表里 review 允许写但 visibility 上限 agent，且建议标 review=true）；这条要 ADR-010 §D-4 加一句明确把 autoDream 列入 review。

R9 · MER-218 第 1 项"主动知识获取"的边界 Agent 跑 web search 是已有能力（smart-search / Tavily），但"主动决定何时搜"会变成 Yi 在主对话里频繁中断 — 反 ENFP-A 节奏。应对：Phase D 再考虑，并和 MER-229 的"被动 idea 检测"保持同样保守原则（漏检好过误报）。

6.3 低优先级 / 概念性

R10 · 知识图谱真做时的 schema 演进 knowledge-graph-survey.md 的 schema 是好起点，但 superseded_by / confidence / source_episode 三个字段需要在 Phase D 跟 ADR-010 和 autoDream 同步演进。判断：往后放，等 KG 真上线再改。

R11 · Honcho / Supermemory 隐私评估 两个都是 SaaS。Maple 的 feedback_memory_sync.md 隐含"memory 不外泄"。判断：Phase D 才考虑，且默认 NO，除非 Maple 显式开口。

6.4 暂时无法回答的

47 文件是否够 LongMemEval-style 测一次 baseline 召回率？（数据量太小，可能数字不可信）
autoDream 用 Sonnet / Haiku / Opus 哪个跑？（成本 vs 质量，需要 MVP0 跑过几次才能看数据）
跨 agent 写到同一个 LocalProvider 时，两个 daemon 进程（MacBook / Mac mini）会不会撞 sqlite WAL 锁？（两端都跑 daemon 才会暴露）
autoDream “session 摘要 + embedding 索引”（MER-196 第 2 项）和 tools/memory/ 的 indexer 是同一件事还是两件？（看上去是同一件事但路径不一样，Phase B 实现时统一）
Maple 想要的"OpenClaw 历史知识迁移"（MER-196 第 4 项）具体是迁移哪些资产？已停用 OpenClaw，runtime/openclaw/ 里 1053 个 session — 需要 Maple 选一批"值得搬过来的"

7. Recommended follow-up work

7.1 立即（不阻塞 daemon 稳定）

本报告挂 MER-218 / MER-196 / MER-68 三个 comment（每张卡补一句"调研已合并到 t03，结论详见报告"）
MER-68 状态调整：评估部分已结束、长期 KG 路线明确，建议 close 或转 Cancel（结论已被 knowledge-graph-survey.md + MER-274 落地覆盖）
MER-275 review：把 feature/adr-010-memory-provider-contract review 一遍，决定是否合 main；如果合，开 MER-276（暂用，落地 LocalProvider 的子任务卡）
t04 / 后续 RFC：把 MER-218 第 4 项 “checkpoint” 形式化（这件事和 MER-229 / MER-267 / 自主学习都相关，最好独立 ADR 不混进 ADR-010）

7.2 daemon 稳定后

ADR-010 合并 + vyane/src/vyane/memory/ 模块落地（Provider Protocol + LocalProvider + 13 contract test）
LocalProvider 接 tools/memory/ 索引；47 文件 dry-run import + 落 baseline
Yi sync_turn 钩子 + 关键决策 save_memory
autoDream MVP0（Orient + Gather + Validate，patch JSON 不写文件）
embedding 切换 hash → Google embedding-001
vyane memory status / dashboard panel

7.3 实验 / 拓展

autoDream MVP1（draft 文件落盘）+ Discord patch 审批
Index 增量 hook（fsnotify / inotify 监听 data/shared-memory/）
session jsonl 入 index（搭 MER-187）
KG schema Phase 1（手动 + handoff 半结构化）
Holographic HRR 矛盾检测（实验性）

7.4 不推荐 / 反对的方向

直接接 mem0 / Mem0 cloud / Zep cloud / 外部 PKM tool 当主存：违反 personal-first + memory 不外泄
同时做 vector + KG + embedding-001 + sentence-transformers + Honcho + Supermemory：选型贪心，后面会改回去
autoDream MVP 直接 4 阶段一次 LLM 调用写 shared-memory：GPT review 已经讲了 8 处会出问题
把 tools/memory/ 直接当 daemon 的 memory backend：它是 CLI 工具，没有 contract 语义；LocalProvider 包它，但不要让 Yi / scheduler 直接调
把 47 文件迁移成 SQLite-only：markdown 是 source of truth，CC CLI 直接读、Maple 直接编辑、Syncthing 同步，迁了反而麻烦
在 MER-218 之上再起一个"learning agent"独立 service：autoDream + AgentRun 已经够覆盖
承诺自动召回率指标：当前数据量太小，给数字会反弹

8. 附录

8.1 关键文件清单

路径	说明
tools/memory/	MER-274 Done：sqlite-vec + FTS5 索引 + CLI
tools/memory/schema.sql	5 表 schema
tools/memory/embedding.py	hash embedding 占位
tools/memory/indexer.py	reindex / sync 实现
tools/memory/search.py	混合排序检索
tests/test_memory_tool.py	索引 / 检索 / sqlite-vec backend 测试
data/shared-memory/	47 文件 + MEMORY.md（CC auto-memory + 跨 runtime 共享）
`vyane/docs/decisions/010-vyane-memory-provider-contract.md`	MER-275 Triage，feature 分支 f22e278
docs/research/autonomous-2026-04-09/mempalace-vyane-integration.md	MemPalace → Vyane 整合方案
docs/research/autonomous-2026-04-09/autodream-design.md	autoDream 完整设计稿（4 阶段）
docs/research/autonomous-2026-04-09/autodream-gpt-review.md	GPT 交叉审查（8 处缺陷）
docs/research/autonomous-2026-04-09/knowledge-graph-survey.md	向量 vs KG / SQLite 方案
docs/research/autonomous-2026-04-09/pkm-tools-comparison.md	Obsidian / Notion / Mem.ai 对比
data/research/2026-04-24-hermes-insights-round2.md	Hermes 实战 + ADR-010 草案源
vyane/docs/research/cc-source-memory-extraction.md	CC CLI extractMemories 反推
vyane/docs/research/cc-source-autodream.md	CC CLI autoDream 三层 gate / 锁
data/shared-memory/feedback_memory_sync.md	memory 跨端同步约定
docs/projects/vyane-personal-runtime-plan.md	当前优先级（daemon 稳定第一）

8.2 三张 Linear issue 的状态总结

Issue	当前 State	实际状态判断	建议下一步
MER-218	Backlog (P3)	第 1 项有现成能力（smart-search）；第 2-3 项 = autoDream MVP；第 4 项 = checkpoint 概念待形式化	等 Phase B autoDream MVP0 落地后重新审视；本身可以拆成 4 个子 issue
MER-196	Backlog (P3)	第 1 项 embedding 待选型；第 2-3 项已部分由 tools/memory/ 提供；第 4 项 OpenClaw 迁移待 Maple 选范围；第 5 项 autoDream 设计稿在；第 6 项跨设备同步已有 feedback_memory_sync.md	这张卡应作为 Phase B / C 的伞型 issue，里面派生 ≥ 4 个子任务
MER-68	Backlog (P4)	评估部分（短期 MCP / 中期向量 / 长期 KG）已被 MER-274 + 前置调研覆盖	建议 Done 或 Cancel + 在 comment 留指针

8.3 名词速查

名词	定义（本报告口径）
MarkdownStore	data/shared-memory/ 47 markdown 文件 + MEMORY.md，是 memory 的 source of truth
Memory Index	tools/memory/data/memory-index.sqlite — sqlite-vec + FTS5 双轨索引
MemoryProvider	ADR-010 定义的 Protocol，5 方法 + 5 kwargs
LocalProvider	MemoryProvider 的本地 SQLite 实现，封装 tools/memory/
autoDream	后台 forked agent，从 session / git / worker logs 抽取候选 memory，5 阶段（Orient → Gather → Validate → Apply → Index）
KG / Knowledge Graph	SQLite entities + triples 表 + valid_from/valid_to，Phase D+，本期不做
Memory server	误用容易：本报告里特指 ADR-010 的 Vyane 自身（暴露 MCP MemoryProvider 接口），不是指引入外部 mem0 / Honcho 之类的 SaaS

8.4 与 t01 / 其他 topic 的边界

t01 (MER-229) Idea 裂变 vs 本报告：t01 处理"未审议素材"（idea-inbox.jsonl），本报告处理"已审议事实"（MarkdownStore + Index）。autoDream Validate 阶段如果遇到分支 idea，应 emit 到 idea-inbox 而不是写 memory。
MER-187 session 数据回流 vs 本报告：MER-187 是 session jsonl 提取脚本，是 autoDream Gather 的数据源之一；MER-187 落地后本报告的 Phase C 工作量项 13 自然顺接。
MER-214 跨 session 通信 / parent-child vs 本报告：MER-214 提供 parent_session_id 字段（已经在 ADR-010 D-2 列入 kwargs），本报告不重复设计。
MER-267 LogicalSession vs 本报告：LogicalSession 已存在；ADR-010 D-2 把 parent_session_id 关联到 LogicalSession，这是"读取链路"；本报告关心的是"读写记忆链路"，两者并行不冲突。

8.5 评估 LongMemEval / 召回率怎么办

不在 Phase A/B 做。理由：

47 文件规模太小，召回率数字不可信
MemPalace 公布的 96.6% R@5 是在 LongMemEval 标准集上，不是在 data/shared-memory/ 上
本地金标集需要 Maple 标注（每条问题 → 该返回哪几个文件），是非常高的人力成本

替代方案：Phase B 跑通后做"主观体感测试" — Yi 在 Discord 接到 Maple 问题，自己 search 一次，让 Maple 当场打分（1-5），积累 100 条样本后看 median。这是行业通行做法。

8.6 与 ADR-010 的 7 条开放问题对应

ADR-010 §6（草案最后一节）列了 7 条 Maple 决策待定项。本报告对其中相关项的态度：

SupermemoryProvider 实现 — Phase D 再说，默认不做
agent_identity 缺失时 strict / lenient — strict（None vs 非空字符串），Maple 已隐含同意
visibility=shared 写入是否需要额外 grant — 不强制，由 D-4 origin 控制
是否要 audit log — 是，I-8 已要求 cron skip 留痕；Phase B 同步加全量 save / delete 的 audit
memory_id 算法 — 用 sha256(content + identity + ts) 前 16 hex
provider 多实例并发 — 走 SQLite WAL；多 daemon 写需要 R7 / 6.4 第 3 项处理
visibility 是 enum 还是字符串 — enum

9. Evidence quality 自评

主题	证据强度	备注
MER-218 / MER-196 / MER-68 issue 描述	High	Linear API 直接拉到，包括三张卡的关联 issue
MER-274 已 Done	High	git log + tools/memory/ 源码 + tests 全读
MER-275 ADR-010 草案	High	feature 分支 f22e278 全 529 行读完
前置调研报告 6 份	High	全文读完
Hermes 实战借鉴	Medium-High	round2 §1+§2 读了，§3 是 ADR-010 源已经在 ADR-010 里精炼
autoDream 设计 + GPT review	High	两份全文读完 + CC source 反推确认
知识图谱选型	High	survey 全读 + 行业方案表
Vyane daemon 现状	Medium-High	CLAUDE.md / personal-runtime-plan / vyane/CLAUDE.md 已读，但 vyane/src/vyane/daemon/ 仅扫目录没全读源码（参考 t01 已做过）
Maple 当前节奏	Medium	来自 MEMORY.md / personal-runtime-plan / briefing；不可避免有解读
外部生态 (mem0/Zep/Letta/…)	Medium	来自 PKM/KG 两份 survey 的二手综述 + Hermes round1/2，没逐个 fact-check upstream 文档
召回率 / benchmark 数字	Low-Medium	96.6% R@5 / 49.0% / 63.8% 来自 survey 引用，未独立验证；本报告没基于这些数字做选型，所以风险可控
Phase 工作量估计	Low-Medium	推断为主；当真实 LocalProvider 写时会有偏差

10. 一段总结

MER-218 / MER-196 / MER-68 三张卡的实质问题不是"还差什么组件"，而是"已经各自落地的部件没串成 provider → store + index → autoDream → 自主学习闭环这一条主线"。MER-274 把检索层做完了；ADR-010 草案把 provider 契约写完了；mempalace / autodream / KG 的前置调研把架构争论收口了。剩下的三步是：合 ADR-010 → 落 LocalProvider → autoDream MVP0。

最该警惕的不是技术风险，是让 memory 系统反过来挤占 Maple 的注意力。autoDream 写到 active 文件之前必须有 patch 审批；KG 不在第一阶段做；外部 SaaS 不在第一阶段做；embedding 选型不要双轨。第一版的目标只有一个：让 Yi 跑一周，Maple 在 data/shared-memory/ 看到几条新写进来的 conclusion，并觉得"这条真的对"。