夜雨聆风上一篇讲了 Memory Search 怎么把文件变成可搜索的 chunk。这篇讲 Memory-Wiki——它在 chunk 检索之上加了什么，以及整个系统怎么运转。
Memory Search 解决了"搜得到"的问题。你问 Agent 一个问题，它能从几百个 .md 文件里找到相关的 400 token 碎片返回给你。
但碎片就是碎片。它没有置信度和生命周期：这条结论现在的场景还成立吗？它的源头在哪里，经历了怎样的演变过程？它们之间是什么关系？三个月前的结论在现在的场景下是否过时？
Memory-Wiki 的目的是补充这些问题，它不替代 Memory Search，而是在旁边多建一层结构化的知识库。
这里说的 wiki 不是维基百科。它是借用了 wiki 的组织方式——每个知识单元是一个独立页面，页面之间通过链接互相关联，有索引和目录——但维护者是 Agent，Agent负责从原始材料中提炼知识、创建页面、标注关系。落到实现上，它就是一个目录里的一堆 Markdown 文件，用任何文本编辑器都能打开。如果配合 Obsidian（一个本地 Markdown 知识库管理工具）使用，还能通过 Graph View 可视化页面之间的关系网络。
下面这张图是整个系统的运转流程。
定位：一个附加层，不能独立运行
Memory-Wiki 是 OpenClaw 的一个插件（extensions/memory-wiki），必须搭配底层 memory 插件（memory-core 或 QMD）一起运行。官方文档说得很明确：
It does not replace the active memory plugin. Recall, promotion, indexing, and dreaming stay owned by whichever memory backend is configured.
开启后，它在磁盘上创建一个 vault 目录（默认 ~/.openclaw/wiki/<agent-id>），里面都是 Markdown 文件。
数据怎么进来
Memory-Wiki 通过 vaultMode 配置决定数据从哪导入。
1. bridge 模式自动从当前 memory 插件桥接内容。它调用 listActiveMemoryPublicArtifacts获取 MEMORY.md、daily notes、dreaming reports，批量导入为 source 页面（就是把原文全文包装成 wiki 可管理的格式，后面细讲）。但当前版本有一个坑：它桥接的是所有 workspace 的内容，不做 agent 级别隔离。
源码 src/plugins/memory-state.ts:320
补充一下背景：OpenClaw 支持配置多个 agent，每个 agent 有独立的 workspace 目录和独立的 SQLite 索引。Memory Search 是按 agent 隔离的——agent A 搜索时只能命中自己 workspace 下的日记和自己配的 extraPaths，看不到 agent B 的内容。但 bridge 模式的 wiki 不做这个隔离，它把所有 agent 的日记和 dreaming 报告全部导入同一个 vault。wiki和memory两边的隔离模型不一致。
2. isolated 模式 vault 从空白开始。通过 openclaw wiki ingest ./path/to/file.md 手动导入指定文件。每次导入一个文件，是单次命令；文件更新后 wiki 里的 source 不会自动同步，需要再 ingest 一次。你可以完全控制什么内容进 wiki。
3. unsafe-local 在配置里写死一组目录路径（unsafeLocal.paths），运行 import 时批量扫描这些目录下所有文本文件（.md/.json/.yaml/.txt），一次性全部导入，已存在的按 hash 判断是否需要更新。跟 isolated + ingest 的区别是：ingest 每次手动导一个文件，unsafe-local 每次 import 批量扫描整个目录。之所以叫 unsafe，是因为它绕过了 memory 插件的公开接口直接读本地文件，没有做权限和安全校验。
不管哪种模式，导入的文件都落入 sources/ 目录——原文全文保留，外面套上一层 YAML 元数据（来源路径、agent、时间戳），变成 wiki 可管理的 source 页面。下面看一个实际例子。
Source 页面
以我本地用于学习主流 Agent 框架的 deepframe-study Agent 为例，一个导入后的 source 页面长这样：
---pageType: sourceid: source.bridge.workspace-deepframe-study.memory-2026-07-13title: "Memory Bridge (deepframe-study): 2026-07-13"sourceType: memory-bridgesourcePath: /Users/dapeng/.openclaw/workspace-deepframe-study/memory/2026-07-13.mdbridgeAgentIds: - deepframe-studystatus: activeupdatedAt: 2026-07-13T13:39:21.761Z---## Content```markdown# 2026-07-13## OpenClaw Dreaming 功能深度研究完成了对 OpenClaw "梦境 (Dreaming)" 功能的完整源码研究...
YAML frontmatter 标注了来源路径、关联 agent、时间戳。正文里，原文全文包在 code fence 中。这就是 wiki 里的原始材料——它知道内容从哪来、属于哪个 agent、什么时间产生，但还没有任何结构化的知识提炼。---## 从原始材料到结构化知识：Agent 提炼这一步是整个系统里唯一需要 LLM 介入的环节。不是自动的——需要 Agent 通过 `wiki_apply` 工具手动创建。Agent 阅读 source 页面的内容，理解后创建三种类型的知识页面：**Entity** 是具体实体——一个人、一个项目、一个模块。比如"DocPilot"、"memory-core 插件"。**Concept** 是抽象概念——一个设计模式、一个原理、一类技术。比如"混合搜索"、"记忆巩固"、"三阶段睡眠模型"。**Synthesis** 是综合分析——跨多个 source 的总结和提炼。比如"OpenClaw Dreaming 机制分析"、"OpenClaw vs Claude Code 记忆机制对比"。为什么不自动提取？因为从原始材料到结构化知识的"提炼"本质上是一个判断过程——什么值得记、什么关系成立、置信度多高。这些判断需要语义理解能力，靠代码逻辑做不了。所以这一步交给 Agent。---## 结构化页面的核心：Claims 和 Relationships提炼出的知识页面跟普通 Markdown 笔记的区别在于 YAML frontmatter 里的结构化数据：```yamlclaims: - text: Dreaming 模拟人类 Light/Deep/REM 三阶段睡眠进行记忆巩固 status: supported # supported / contested / stale confidence: 0.95 # 0~1 evidence: - kind: source-code path: extensions/memory-core/src/dreaming-runner.ts note: 三阶段串行执行逻辑relationships: - targetId: synthesis.openclaw-memory-search kind: depends-on confidence: 0.9 note: Dreaming 的 promote 写入 MEMORY.md 后通过 Memory Search 索引被召回 - targetId: synthesis.claude-code-memory-system kind: competes-with confidence: 0.8 note: 两者都是记忆巩固机制，设计思路不同
claim 是知识断言。每条带 status（supported 成立 / contested 有争议 / stale 过时）、confidence（0~1 置信度）、evidence（证据来源，指向源码路径或笔记行号）。这让每条知识都可追溯——不是"我记得好像是这样"，而是"这条结论来自 dreaming-runner.ts 的三阶段串行执行逻辑，置信度 0.95"。
relationship 是页面间的显式关系。kind 标注关系类型（depends-on / competes-with / part-of），confidence 标注确定程度，note 解释为什么存在这个关系。Agent 搜到一个页面时，同时能知道它跟其他知识的关联。
这些结构化数据不是给人看，系统会读取所有页面的 claims 和 relationships，自动汇总生成报告——比如哪些结论之间有矛盾、哪些页面缺乏证据、哪些内容已经过时。下面讲 compile 时会展开说。
Compile：编译出全局视图
Agent 创建和修改知识页面后，系统需要把散落在各个 .md 文件里的 claims 和 relationships 汇总起来，生成索引和报告。这个过程叫 compile。
compile 首先扫描 sources/、entities/、concepts/、syntheses/ 目录，解析每个 .md 文件的 frontmatter，构建全局页面列表。
拿到所有页面后，下一步是发现关联。如果两个页面共享相同的 sourceId，或者一个页面的 linkTargets 指向另一个页面，自动在两边生成 ## Related 块。这一步不需要手动声明，系统根据已有数据自动推断。比如 deepframe-study 的 OpenClaw Dreaming 页面底部，compile 自动生成了这样的关联：
## Related- [[syntheses/claude-code-memory-system|Claude Code Memory System]]- [[syntheses/openclaw-memory-search|OpenClaw Memory Search]]
因为这三个 synthesis 页面都引用了同一个 source（sources/2026-06-18.md），系统自动把它们关联起来。[[...]] 是 Obsidian 的 wikilink 格式，在 Graph View 里能看到连线。
关联发现之后，compile 把所有页面的结构化数据压缩成检索索引——生成 agent-digest.json 和 claims.jsonl（存放在 .openclaw-wiki/cache/ 目录），后续 wiki_search 查询时直接查这个索引，不需要逐个读 .md 文件。实际内容长这样——这是前面提到的 OpenClaw Dreaming 那个 synthesis 页面被编译进索引后的样子：
{ "id": "synthesis.openclaw-dreaming", "title": "OpenClaw Dreaming", "kind": "synthesis", "relationshipCount": 2, "topRelationships": [ { "targetId": "synthesis.openclaw-memory-search", "kind": "depends-on", "confidence": 0.9 } ], "claimCount": 4, "topClaims": [ { "text": "触发机制：cron 注入特殊 token → before_agent_reply 钩子拦截 → 多 workspace 串行执行", "status": "supported", "confidence": 0.95 }, { "text": "Dreaming 模拟人类 Light/Deep/REM 三阶段睡眠进行记忆巩固", "status": "supported", "confidence": 0.95 } ]}
每个页面的 claims、relationships、置信度都被压缩成 JSON 条目。wiki_search 匹配 query 时就是在这些条目上做搜索，命中后返回对应页面的结构化信息。
最后，compile 基于所有页面的 claims 和 relationships 生成一组 Dashboard 报告。比如 reports/relationship-graph.md 的实际内容：
- Structured relationships: 6- [[syntheses/openclaw-dreaming|OpenClaw Dreaming]] -> [[syntheses/openclaw-memory-search|OpenClaw Memory Search]] (depends-on, confidence 0.90, Dreaming 的 promote 写入 MEMORY.md 后通过 Memory Search 索引被召回)- [[syntheses/openclaw-dreaming|OpenClaw Dreaming]] -> [[syntheses/claude-code-memory-system|Claude Code Memory System]] (competes-with, confidence 0.80, 两者都是 Agent 记忆巩固机制，设计思路不同)
如果所有 claim 都健康，reports/claim-health.md 就是一句 "No claim health issues right now."。但一旦有 claim 缺乏证据或存在争议，报告会具体指出哪个页面的哪条结论出了什么问题。下面是 deepframe-study 的 wiki 中出现问题时，compile 实际生成的 reports/claim-health.md：
- Claims missing evidence: 1- Contested claims: 1- Stale or unknown claims: 0### Missing Evidence- [[syntheses/openclaw-memory-search|OpenClaw Memory Search]]: extraPaths 默认索引模式 **/*.md，不索引源码文件 (status supported, confidence 0.90, missing evidence, fresh)### Contested Claims- [[syntheses/openclaw-memory-search|OpenClaw Memory Search]]: 混合搜索：向量 0.7 + FTS 0.3，最低阈值 0.35，最多返回 6 条 (status contested, confidence 0.95, 1 evidence, fresh)
Missing Evidence 那条在说：这个 claim 的结论是"extraPaths 只索引 .md 文件"，status 标为 supported（结论成立），但没有挂任何 evidence 来源——系统不知道这个结论的依据从哪来，报出来要求补充证据。
Contested Claims 那条在说：这个 claim 的结论是"混合搜索权重 0.7/0.3"，status 被标为 contested（有争议）——可能是新版本改了权重，也可能是有另一条 claim 跟它矛盾。系统提醒去确认这条结论是否还成立。
Agent 看到这个报告就知道下一步该做什么：给缺证据的 claim 补上 evidence 引用，给有争议的 claim 去源码确认后更新 status。
其他报告各管一个维度。reports/contradictions.md 检测 claim 之间的矛盾——如果两个页面对同一件事给出了相反结论，这里会列出来。reports/low-confidence.md 汇总置信度低于阈值的 claim 和页面。reports/stale-pages.md 列出超过 30 天未更新的页面。
reports/provenance-coverage.md 比较有意思，它统计证据溯源的覆盖情况。deepframe-study 当前的实际内容：
- Evidence entries: 11- Claims missing evidence: 0### Evidence Classes- source-code: 11### Top Evidence Sources- extensions/memory-core/src/dreaming-scoring.ts: 2- code/claude-code-analysis/src/memdir/findRelevantMemories.ts: 1- packages/memory-host-sdk/src/host/internal.ts: 1- src/agents/memory-search.ts: 1
11 条 evidence 全部来自 source-code 类型，没有缺失证据的 claim。如果将来有 claim 没有挂 evidence，这个报告会标红提示。
compile 在每次 wiki_apply 或 ingest 之后自动触发。但如果直接手动编辑 vault 里的 .md 文件，不会自动触发——没有文件监听机制，需要手动跑 openclaw wiki compile。
源码 apply.ts:377：const compile = await compileMemoryWikiVault(params.config)，ingest 默认 autoCompile: true
查询：实际怎么用
memory-wiki 插件启用后，会通过 registerMemoryCorpusSupplement把自己注册为 memory search 的附加语料库。注册后，Agent 调用 memory_search 时可以通过 corpus 参数决定搜索范围：
memory_search(query) 默认只走 SQLite 混合搜索，返回 chunk 片段。跟没开 wiki 时行为一致。 memory_search(query, corpus="all") 同时查 SQLite 索引和 wiki 的 compiled digest，合并返回。Agent 一次调用就能同时命中文件碎片和结构化知识页面。 wiki_search(query) 专门查 wiki 的 compiled digest，只返回结构化页面（带 claim status、confidence、evidence）。适合 Agent 明确要查知识库时使用。
源码 extensions/memory-wiki/index.ts:40
实际运行时，系统提示词引导 Agent 优先使用 memory_search。当 wiki 注册为 corpus supplement 后，corpus="all" 是最常走的路径——一次调用覆盖两个数据源，不需要分别调两个接口。wiki_search 更像是"你明确知道答案在 wiki 结构化页面里"时的快捷入口。
本质区别：memory_search 返回的是无结构的文本碎片（一个 400 token chunk），wiki_search 返回的是有结构的知识页面（带 claims、relationships、provenance）。前者是检索引擎，后者是知识库。
使用流程
开了 wiki 之后，bridge 模式下的 source 导入是自动的——memory 插件有新文件就自动桥接进来。compile 也是自动的——每次 wiki_apply 或 ingest 之后，关联发现、索引生成、Dashboard 报告都会自动更新。查询也不用额外配置，wiki 注册为 corpus supplement 后 memory_search 自动覆盖。
唯一不自动的是从 source 到结构化知识页面的提炼。系统不会自动读一篇 source 然后生成 synthesis——这一步需要 Agent 调用 wiki_apply，而 Agent 需要有人让它做这件事。每次有新的 source 进来，如果你想让它变成带 claims 和 relationships 的结构化知识，都需要再触发一次提炼。
这一步也可以自动化。给 Agent 配一个 cron 定时任务，比如每天凌晨扫描最近新增的 source 页面，自动阅读并提炼。OpenClaw 的 cron 支持 agentTurn 类型的定时任务，prompt 写"扫描最近 24 小时新增的 source，提炼出 entity/concept/synthesis"，Agent 就会定期自动维护知识库。配合 Dreaming 每天生成新的 memory 内容、bridge 自动导入为 source、cron 定期触发提炼，整条链路就能无人值守运转。
