memory-wiki 是一个捆绑插件,它将持久知识编译成一个可导航的 wiki:确定性的页面、带有证据的结构化声明、来源、仪表盘以及机器可读的摘要。
它不会取代活动记忆插件。回忆、晋升、索引和做梦仍由已配置的记忆插件(memory-core、Honcho 及其他插件)负责。memory-wiki 与其并行运行,将知识编译到一个受维护的 wiki 层中。
在使用其 CLI、工具或运行时集成之前,启用该插件:
实用规则:
memory_search用于对已配置的任意语料库进行一次宽泛的回忆检索wiki_search/wiki_get用于你需要 wiki 特定排序、来源,或页面级信念结构时- 当活动记忆插件支持语料库选择时,使用
memory_search corpus=all可在一次调用中跨越两层
bridge 模式下使用 memory-wiki 来生成持久化的综合页面。请参阅配置下的桥接模式示例。
如果 bridge 模式报告导出的工件数量为零,则说明活动记忆插件当前没有暴露公共 bridge 输入。先运行 openclaw wiki doctor,然后确认活动记忆插件支持公共工件。
Vault 模式
isolated(默认):自有 vault,自有来源,不依赖于当前激活的 memory 插件。用于构建一个自包含的精选知识库。bridge:通过公开的插件 SDK 接口,读取当前激活的 memory 插件中的公开 memory 产物和事件日志。用于在不接触私有插件内部实现的情况下,汇总 memory 插件导出的产物。unsafe-local:面向本机私有路径的显式逃生通道。该模式有意保持实验性且不可移植;仅在你了解信任边界并且确实需要 bridge 模式无法提供的本地文件系统访问时使用。
vaultMode决定 wiki 输入的来源。vault.scope决定所有 agent 共用一个 vault,还是每个 agent 使用一个子 vault。
vault.scope: "global" 是默认值,并保留现有的单 vault 行为。请在 isolated 或 bridge 模式下将 vault.scope 设为 "agent",当 agent 之间不能共享 wiki 页面、编译后的摘要、搜索结果或写入内容时使用。由于这些已配置的私有路径并不是 agent 拥有的输入,因此 agent 范围不能与 unsafe-local 模式结合。配置校验会拒绝这种组合。
Bridge 模式可以按每个 bridge.* 配置开关索引以下内容:
- 导出的 memory 产物(
indexMemoryRoot) - 每日笔记(
indexDailyNotes) - 梦境报告(
indexDreamReports) - memory 事件日志(
followMemoryEvents)
bridge.readMemoryArtifacts 时,openclaw wiki status、openclaw wiki doctor 和 openclaw wiki bridge import 会通过正在运行的 Gateway 路由,因此它们看到的 active memory插件上下文与 agent/runtime memory 中相同。若 bridge 被禁用,或未开启产物
读取,这些命令将保持本地/离线行为。
库布局
sources/:导入的原始材料以及 bridge/unsafe-local-backed 页面entities/:持久的事物、人物、系统、项目、对象concepts/:想法、抽象、模式、政策(也是 OKF 导入的落脚点)syntheses/:汇总摘要和维护中的汇总表reports/:生成的仪表板。
Open Knowledge Format 导入
memory-wiki 将其转换为 OpenClaw 原生概念页面和编译后的摘要。
- 未保留的
.md文件是概念文档 - 每个导入的概念都要求有一个非空的
typefrontmatter 字段;缺失type会产生missing-type警告并跳过该文件 - 未知的
type值会作为通用概念被接受 index.md和log.md是保留文件,绝不会作为概念导入- 损坏的或外部的 Markdown 链接会保持不变
concepts/ 下扁平化,因此现有的 compile、search、get 和 dashboard 流程无需第二个 wiki 树也能看到它们。每个页面都会保留原始的 OKF 概念 ID、源路径、type、resource、tags、时间戳,以及完整的 producer frontmatter。内部 OKF 链接会重写为生成的 wiki 概念页面,并同时发出结构化的 relationships 条目,kind: okf-link。
结构化声明和证据
页面承载结构化的claims frontmatter,而不只是自由格式文本。每条
claim 都可以包含 id、text、status、confidence、evidence[] 和
updatedAt。每条 evidence 记录都可以包含 kind、sourceId、path、
lines、weight、confidence、privacyTier、note 和 updatedAt。
这使得 wiki 更像一个信念层,而不是一个被动的笔记堆。声明可以被跟踪、评分、争议,并最终回溯到来源得到解决。
面向代理的实体元数据
实体页面承载通用路由元数据,可用于人物、团队、系统、项目或任何其他实体类型:entityType:例如person、team、system、projectcanonicalId:跨别名和导入保持稳定的身份键aliases:可解析到同一页面的名称、处理名或标签privacyTier:自由格式字符串;public视为无需审核,任何其他值(例如local-private、sensitive、confirm-before-use)都会在reports/privacy-review.md中标记bestUsedFor/notEnoughFor:简明路由提示lastRefreshedAt:来源刷新时间戳,与页面编辑时间分开personCard:可选的面向人物的路由卡片(处理名、社交账号、邮箱、时区、分工、ask-for、avoid-asking-for、confidence、privacy tier)relationships:指向相关页面的有类型边(目标、关系类型、权重、置信度、证据类型、隐私级别、备注)
reports/person-agent-directory.md,然后在使用联系方式或推断事实之前,先用
wiki_get 打开该人物页面。
编译管线
编译器读取 wiki 页面,规范化摘要,并将面向机器的快照持久化到 OpenClaw 的共享 SQLite 插件状态中。运行时代码使用由生命周期负责的所有者快照,在异步提示准备期间加载 SQLite;同步提示组装不会抓取 Markdown 或读取缓存文件。 编译后的输出还用于搜索/获取的首轮 wiki 索引、将 claim-id 查回所属页面、紧凑提示补充内容以及报告生成。 源文件编辑和 vault 恢复只有在下一次编译后才会对机器可见。重启或刷新插件生命周期时,会将 vault 中因果链式关联的编译发布与 SQLite 进行比较,并拒绝来自更新但已回滚状态的快照。在回滚之前启动的编译器无法基于已恢复的前置状态发布。提示准备不会轮询 vault,也不会安装文件监视器。 回滚隔离后,运行中的进程执行编译会立即清除所有者;独立的编译器进程则需要刷新插件生命周期,以便守护进程确认新的持久化发布。 ChatGPT 导入回滚会在编译前记录导入后的编辑,并将其恢复路径保存在插件状态中,因此中断的回滚可以协调恢复目录,并在重试时报告相同的已保留页面。目标恢复会在持久化进程重启栅栏之前完成。此后,重试会重建派生索引、仪表板和编译缓存,而不会重写源页面,也不会移动或删除恢复工件。之后的正常编译可能会刷新由机器管理的 Related 块。这涵盖了进程内故障,以及普通文件系统调用返回后发生的进程重启。它不保证在内核或主机断电时的写入顺序。与栅栏持久化同时发生竞争的路径名写入,要么在栅栏成功后仍然存在,要么由栅栏前的重试保存在recovered/ 下。通过在导入所拥有的 inode 被分类并解除链接之前打开的文件描述符进行的写入不在保证范围内,可能会丢失。
编译缓存可以重建:发布时期之前的缓存行会被视为未命中,并由下一次编译替换;它们不会被迁移。
仪表盘和健康报告
当启用render.createDashboards 时,编译过程会在
reports/ 下维护仪表盘:
搜索与检索
两种搜索后端:shared:在可用时使用共享记忆搜索流程local:本地搜索 wiki
wiki、memory、all。
wiki_search/wiki_get在可能时会先使用编译后的摘要作为第一步- claim id 会解析回所属页面
- 有争议/过时/最新的 claim 会影响排序
- 来源标签会保留到结果中
--mode / tool mode 参数):
当某个结果匹配结构化 claim 时,
wiki_search 会在其详情载荷中返回
matchedClaimId、matchedClaimStatus、matchedClaimConfidence、
evidenceKinds 和 evidenceSourceIds。当可用时,文本输出会包含简洁的
Claim: 和 Evidence: 行。
代理工具
插件还注册了一个非独占的记忆语料补充,因此当活动记忆插件支持语料选择时,共享的
memory_search 和 memory_get 也可以访问 wiki。
在控制界面中浏览 Wiki
控制界面可以直接浏览已编译的 Wiki:打开 记忆页面,然后选择 梦境 → 日记 → 记忆 Wiki。该标签页会将综合、实体和概念页面聚合在一起,还包括包含声明、开放问题或矛盾的来源页面和报告页面,并显示每页的计数以及完整知识库的页面明细,同时可在行内打开完整的页面内容。没有这些元数据的原始来源和报告会计入明细,但不会作为卡片列出;请从 已导入的洞见 子标签页中打开它们,该子标签页会审阅外部历史导入在提升之前发现的内容。 插件启用后,两个子标签页都会显示;在按代理划分知识库的设置中,它们会显示所选代理自己的知识库。界面通过插件的网关方法(wiki.overview、wiki.get、wiki.importInsights)读取;行内页面预览使用 wiki.get,代理也可以通过 wiki_get 工具访问同一查找功能。
提示词和上下文行为
启用context.includeCompiledDigestPrompt 后,记忆提示词部分会从插件状态中附加一份紧凑的编译快照:仅包含顶级页面、顶级声明、矛盾数量、问题数量,以及置信度/新鲜度限定信息。此功能默认不启用,因为它会改变提示词结构;它主要影响那些明确使用记忆补充信息的上下文引擎或提示词组装流程。
配置
把配置放在plugins.entries.memory-wiki.config 下:
每个 agent 独立的 vault
将vault.scope 设为 agent,即可为每个已配置的 agent 提供一个独立的 wiki。
在此范围内,vault.path 是父目录,OpenClaw 会追加标准化后的 agent id:
~/.openclaw/wiki/support 和
~/.openclaw/wiki/marketing。如果在 agent 范围内省略 vault.path,
父目录默认是 ~/.openclaw/wiki。因此,默认的 main agent 仍然保持
现有的 ~/.openclaw/wiki/main 路径。
Agent 工具、编译后的提示词摘要,以及通过
memory_search / memory_get 暴露的 wiki 补充内容,都会根据当前 agent 上下文解析 vault。
CLI 调用使用配置的默认 agent,除非命令传入 --agent <agentId>。
在多 agent 设置中,Gateway 调用仍然要求请求包含 agentId。
在桥接模式下,agent 范围的导入仅在公开 memory 制品的 agentIds
包含所选 agent 时才会接受。属于其他 agent、没有所有权元数据或所有者未知的制品都会被跳过。
全局范围则保持现有的共享制品行为。
示例:内置 memory + 桥接模式
当你希望使用内置 memory 进行回忆,并使用memory-wiki 提供持续维护的知识层时,可以使用此配置。每一层各司其职:memory-core 搜索 memory 笔记和符合条件的会话来源,而 memory-wiki 编译稳定的实体、声明、仪表盘和来源页面。
memory-wiki 专注于编译后的页面和仪表盘,并且在你主动启用编译摘要提示词之前,保持提示词结构不变。
命令行界面
wiki okf import、wiki apply metadata、wiki unsafe-local import、
wiki chatgpt import / wiki chatgpt rollback,以及完整的 wiki obsidian
子命令集合。
Obsidian 支持
当vault.renderMode 为 obsidian 时,插件会写入适配 Obsidian 的
Markdown,并且可以选择使用官方 obsidian CLI 来进行状态
探测、vault 搜索、打开页面、调用命令以及跳转到
每日笔记。这个功能是可选的;即使不使用 Obsidian,wiki 仍然可以在原生模式下工作。
面向代理的 vault 仍然可以使用适配 Obsidian 的 Markdown,但配置
验证会在 vault.scope: "agent" 时拒绝 obsidian.useOfficialCli: true。
当前的 obsidian.vaultName 设置是全局性的,无法为每个代理选择不同的
Obsidian vault。请改用 wiki 工具和 CLI 操作,
或者将由 Obsidian 操作的 wiki 保持在全局作用域下。
推荐工作流
1
保留活跃的 memory 插件用于回忆
回忆、推广和梦境仍由已配置的 memory 后端负责。
2
启用 memory-wiki
除非你明确需要 bridge 模式,否则请从
isolated 模式开始。3
在需要来源信息时使用 wiki_search / wiki_get
当你希望获得 wiki 特有的排序或页面级信念结构时,优先使用它们,而不是
memory_search。4
在进行窄范围综合或元数据更新时使用 wiki_apply
避免手动编辑受管理的生成块。
5
在有意义的更改后运行 wiki_lint
它可以发现矛盾、未解决的问题以及来源缺口。
6
开启仪表板以查看过期/矛盾信息
设置
render.createDashboards: true(默认)。