企业官网建设流程全解析

OpenClaw memory-wiki 知识库维护指南：wiki-maintainer 技能实战与源码解析

【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 🦞项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw

导读

本文围绕 OpenClaw 的 wiki-maintainer 技能 展开，系统讲解如何在 memory-wiki 插件维护的记忆 Wiki 知识库（vault）中，以"确定性页面 + 受管区块 + 来源可追溯更新"的方式完成知识管理。你将掌握wiki_status、wiki_search、wiki_get、wiki_apply、wiki_lint五个 Agent 工具的选用策略，理解openclaw wiki ingest / compile / lint默认维护循环的底层机制，以及bridge、unsafe-local两种模式下的导入流程与受管标记（managed markers）的约定，最终能在自己的 OpenClaw 实例中构建出可供 Agent 稳定读写、又不会覆盖人类笔记的自洽知识库。

说明：wiki-maintainer 技能文件位于 extensions/memory-wiki/skills/wiki-maintainer/SKILL.md，本文所有源码引用均以 extensions/memory-wiki 目录内的真实实现为准。

一、技能定位：在什么场景下使用 wiki-maintainer

技能元信息（frontmatter）给出清晰定义：Maintain the OpenClaw memory wiki vault with deterministic pages, managed blocks, and source-backed updates.（以确定性页面、受管区块和来源可追溯更新来维护 OpenClaw 记忆 Wiki 知识库）。

它面向的工作前提是你已经身处一个 memory-wiki vault 之中（Use this skill when working inside a memory-wiki vault）。与仓库内另一个技能 obsidian-vault-maintainer/SKILL.md 不同，wiki-maintainer 关注的是知识库本身的治理纪律：何时用哪个工具、何时跑哪条 CLI、哪些内容归插件管理、哪些内容属于人类笔记、如何避免重复实体和证据污染，而不是单纯面向 Obsidian 客户端的操作。

从插件架构看，memory-wiki 与 active memory（memory-core）是相互独立的两个插件：active memory 继续负责 recall、promotion 与 dreaming；而 memory-wiki 将持久知识编译为可导航的 Markdown 知识库，附带确定性索引、来源追溯、结构化的 claim/evidence 元数据与可选的 Obsidian CLI 工作流（见 extensions/memory-wiki/README.md）。

二、工具选用优先级：先 status，再 search，后 get

SKILL.md 首先给出了一套明确的工具选择纪律，其核心是"先了解环境，再决定检索路径"：

2.1 wiki_status：先摸清 vault 状态

SKILL.md 明确要求"先wiki_status"。其实现位于 src/tool.ts，工具描述为"检查当前记忆 Wiki 的 vault 模式、健康度与 Obsidian CLI 可用性"。其执行前还会触发一次syncImportedSourcesIfNeeded（见 src/tool.ts），确保导入的来源在状态查询前已完成同步。

2.2 memory_search（corpus=all）：一次召回两个记忆层

当 shared 搜索可用时，优先使用memory_search且corpus=all，把 durable memory 与编译后的 wiki 放在一次检索中完成。README 指出：当 active memory 插件暴露共享召回能力时，Agent 可以先用corpus=all单次检索，再在"需要 Wiki 专属排序或来源追溯"时回退到wiki_search/wiki_get（extensions/memory-wiki/README.md）。

2.3 wiki_search → wiki_get：先发现、后精读

wiki_search（src/tool.ts）接受query、maxResults、backend、corpus、mode参数；wiki_get（src/tool.ts）要求非空lookup（页 id 或相对路径），并支持fromLine/lineCount精确读取局部内容。SKILL.md 特别强调：编辑或引用之前务必先用wiki_get查看精确页面；对生成的人物事实（people facts）要先核实联系方式，并要求"source-class provenance"级别的来源分类追溯——这与下文"证据分层"的纪律一脉相承。

2.4 wiki_apply：窄幅变更不要做自由式 Markdown 手术

wiki_apply（src/tool.ts）的定位是"对 synthesis 与页面元数据施加窄幅 Wiki 变更，而无需自由式 Markdown 手术"。其输入 schema（src/tool.ts）支持四种op：create_synthesis、update_metadata、synthesis、metadata，并接受title、body、lookup、sourceIds、claims、contradictions、questions、confidence、status等字段。

值得展开的是claims 载荷：WikiClaimSchema（src/tool.ts）允许为每条 claim 附带evidence数组，每项证据（WikiClaimEvidenceSchema，src/tool.ts）可包含kind、sourceId、path、lines、weight、confidence、privacyTier、updatedAt等字段。这意味着知识库可以存储"声明级证据"而不仅是"页面级散文"，正是 SKILL.md 中"generated people facts need source-class provenance"这一要求的实现底座。

2.5 wiki_lint：信任 vault 之前的最后一道检查

wiki_lint（src/tool.ts）返回按类别归类的issuesByCategory（contradictions、open-questions、provenance），并统计 error/warning 数量、写出报告文件路径。SKILL.md 要求"有意义的更新后运行wiki_lint，以便在信任 vault 之前暴露矛盾、来源缺口与未决问题"。

三、默认维护循环：ingest → compile → lint

SKILL.md 给出的默认维护循环是三条 CLI：

openclaw wiki ingest openclaw wiki compile openclaw wiki lint

这三条命令只是 README 所列 CLI 家族中的核心成员。完整命令族包括：

openclaw wiki status # 查看 vault 状态 openclaw wiki doctor # 审计 vault 设置并给出可操作修复建议 openclaw wiki init # 初始化 vault 目录结构 openclaw wiki ingest ./notes/alpha.md # 将本地文件纳入 sources/ openclaw wiki compile # 刷新生成的 wiki 索引 openclaw wiki lint # 检查 vault 并写出报告 openclaw wiki search "alpha" # 搜索 openclaw wiki get entity.alpha --from 1 --lines 80 # 按 id 读取，指定行范围 openclaw wiki apply synthesis "Alpha Summary" \ --body "Short synthesis body" \ --source-id source.alpha openclaw wiki apply metadata entity.alpha \ --source-id source.alpha \ --status review \ --question "Still active?" openclaw wiki bridge import # 桥接模式：拉取公共记忆产物 openclaw wiki unsafe-local import # 不安全本地模式：显式导入私有路径 # Obsidian CLI 辅助 openclaw wiki obsidian status openclaw wiki obsidian search "alpha" openclaw wiki obsidian open syntheses/alpha-summary.md openclaw wiki obsidian command workspace:quick-switcher openclaw wiki obsidian daily # Agent 作用域 vault openclaw wiki status --agent support openclaw wiki search "refund policy" --agent support

从 src/cli.ts 的实现看，这些命令对应明确的 description：status显示 vault 状态、doctor审计并报告修复项、init初始化布局、compile刷新生成索引、lint检查并写报告、ingest把本地文件纳入 sources、bridge/unsafe-local导入来源、obsidian系列代理官方 Obsidian CLI。

3.1 ingest：来源进入证据层

openclaw wiki ingest把本地文件摄入sources/目录，作为知识库的证据层入口。配置项ingest.autoCompile（默认true）控制摄入后是否自动编译；ingest.maxConcurrentJobs（默认 1）限制并发摄入任务数；ingest.allowUrlIngest（默认true）控制是否允许 URL 摄入（见 src/config.ts 的默认值解析）。

3.2 compile：生成确定性索引与机器可读快照

openclaw wiki compile是维护循环的中枢。它刷新生成的索引（index）、在启用render.createBacklinks时写出确定性的## Related区块，并在render.createDashboards开启时维护reports/下的问题看板（开放问题、矛盾、低置信度页面、过期页面）。此外，compile 还会把机器可读快照持久化到 OpenClaw 插件状态（SQLite）中，使 Agent/运行时消费方不必解析 Markdown 页面（extensions/memory-wiki/README.md）。

一个重要约束是：恢复/编辑 vault 文件后必须先重新 compile，否则生命周期刷新会拒绝"比已恢复 vault 更新的 SQLite 快照"（extensions/memory-wiki/README.md）。

3.3 lint：三类问题的结构化暴露

openclaw wiki lint的检查类别在工具描述中明确为"结构性问题、来源缺口（provenance gaps）、矛盾（contradictions）与未决问题（open questions）"。这与 SKILL.md"让矛盾、来源缺口和未决问题浮出水面"的目标完全对应。

四、两种导入模式的纪律：bridge 与 unsafe-local

SKILL.md 对两种非默认模式给出了严格的触发条件：

• bridge 模式：在依赖搜索结果之前，若需要拉取最新的公共记忆产物，先运行openclaw wiki bridge import。
• unsafe-local 模式：只有当用户明确选择访问私有本地路径时，才使用openclaw wiki unsafe-local import。

4.1 三种 vault 模式对比

对应配置见 src/config.ts 的 schema 与默认值解析（src/config.ts）：bridge.enabled默认false，其子开关readMemoryArtifacts、indexDreamReports、indexDailyNotes、indexMemoryRoot、followMemoryEvents均默认true；unsafeLocal.allowPrivateMemoryCoreAccess默认false，paths默认空数组。

4.2 配置示例：bridge 模式 + Agent 作用域

// 位于 plugins.entries.memory-wiki.config { vaultMode: "bridge", vault: { scope: "agent", path: "~/.openclaw/wiki", }, bridge: { enabled: true, readMemoryArtifacts: true, }, obsidian: { useOfficialCli: false, }, }

在 agent 作用域下，vault.path是父目录，OpenClaw 会追加规范化后的 agent id：如support解析为~/.openclaw/wiki/support；默认mainagent 使用<state-dir>/wiki/main；state 目录默认~/.openclaw，可由OPENCLAW_STATE_DIR覆盖（extensions/memory-wiki/README.md）。bridge 模式下，agent vault 只导入agentIds包含该 agent 的公共记忆产物（extensions/memory-wiki/README.md）。

配置校验（superRefine，src/config.ts）会拒绝两种非法组合：

• vault.scope=agent与vaultMode=unsafe-local组合；
• vault.scope=agent与obsidian.useOfficialCli=true组合。

另外，README 明确提示：作用域切换不会复制或拆分已有页面，需要自行备份并按需迁移；agent 路径只是同进程内的知识边界，并非操作系统级安全边界（extensions/memory-wiki/README.md）。

4.3 完整配置参考（isolated 默认形态）

{ vaultMode: "isolated", vault: { scope: "global", // 或 "agent" path: "~/.openclaw/wiki/main", renderMode: "obsidian", // 或 "native" }, obsidian: { enabled: true, useOfficialCli: true, vaultName: "OpenClaw Wiki", openAfterWrites: false, }, bridge: { enabled: false, readMemoryArtifacts: true, indexDreamReports: true, indexDailyNotes: true, indexMemoryRoot: true, followMemoryEvents: true, }, unsafeLocal: { allowPrivateMemoryCoreAccess: false, paths: [], }, ingest: { autoCompile: true, maxConcurrentJobs: 1, allowUrlIngest: true, }, search: { backend: "shared", // 或 "local" corpus: "wiki", // 或 "memory" | "all" }, context: { includeCompiledDigestPrompt: false, // 开启后向记忆提示段落追加紧凑的编译摘要快照 }, render: { preserveHumanBlocks: true, createBacklinks: true, // 写出带 sources/backlinks/related pages 的受管 ## Related 区块 createDashboards: true, }, }

配置默认值解析集中在 src/config.ts：默认vaultMode=isolated、vault.scope=global、renderMode=native、search.backend=shared、search.corpus=wiki。注意默认renderMode为native，而上面示例显式设为obsidian——这与 SKILL.md 最后一条"当 vault render mode 为 obsidian 时保留 Obsidian 友好的 wikilink"的条件相呼应。

五、受管区块（managed blocks）与人类笔记的共存约定

SKILL.md 中有一条贯穿全局的硬性规则：Keep generated sections inside managed markers. Do not overwrite human note blocks.（生成的区块必须待在受管标记内，不得覆盖人类笔记区块。）

5.1 标记体系

从源码中可以看到真实的受管标记常量：

• 索引区块：<!-- openclaw:wiki:index:start -->/<!-- openclaw:wiki:index:end -->（src/vault.ts）
• 相关链接区块：<!-- openclaw:wiki:related:start -->/<!-- openclaw:wiki:related:end -->（src/markdown-links.ts）
• 原始来源声明：<!-- openclaw:wiki:raw-source -->（src/markdown.ts）
• 人类笔记区块：<!-- openclaw:human:start -->/<!-- openclaw:human:end -->（见 vault 初始化生成的 WIKI.md 模板，src/vault.ts）

索引页的生成正是通过replaceManagedMarkdownBlock在起始/结束标记之间替换内容（src/vault.ts），查询层也按标记正则剥离## Related区块（src/query.ts）。

5.2 渲染层面的保护开关

render.preserveHumanBlocks（默认true）控制生成时是否保留人类笔记区块。初始化生成的AGENTS.md模板（src/vault.ts）用四句话固化契约：

• 生成的区块归插件所有（Treat generated blocks as plugin-owned）；
• 人类笔记保存在受管标记之外（Preserve human notes outside managed markers）；
• 优先来源可溯的 claim，避免 wiki 到 wiki 的引用循环（Prefer source-backed claims over wiki-to-wiki citation loops）；
• 优先把关键信念写成带证据的结构化claims，而不是只埋在散文里（Prefer structuredclaimswith evidence over burying key beliefs only in prose）。

5.3 原始来源的豁免通道

未受管的原始 Markdown 可以放在sources/下且不带 OpenClaw 页面 frontmatter，只需在页面正文顶部附近加入<!-- openclaw:wiki:raw-source -->，即可退出 wiki 页面元数据与新鲜度 lint（extensions/memory-wiki/README.md）。这与 SKILL.md"原始来源是证据、wiki 页面不能成为新主张的唯一事实来源"的原则互为补充。

六、证据分层：原始来源 > 记忆产物 > 编译页面

SKILL.md 的另外两条纪律共同构成知识库的"证据金字塔"：

1. Treat raw sources, memory artifacts, and daily notes as evidence. Do not let wiki pages become the only source of truth for new claims.（把原始来源、记忆产物、每日笔记视为证据；不要让 wiki 页面成为新主张的唯一事实来源。）
2. When creating or refreshing indexes, preserve Obsidian-friendly wikilinks if the vault render mode isobsidian.（创建或刷新索引时，若 render mode 为obsidian，保留 Obsidian 友好的 wikilink。）

这一分层在 README 中同样被反复强调：wiki 页面是编译产物，不是终极事实来源（extensions/memory-wiki/README.md）。WIKI.md 模板的 Architecture 段落也写明：原始来源是证据层，wiki 页面是面向人类的综合层，编译后的查询与提示快照存放在 OpenClaw 插件状态而非 vault 文件中（src/vault.ts）。

因此，维护者应遵循的写作姿势是：新主张必须回指原始来源、记忆产物或每日笔记中的证据；wiki 页面只做综合与索引。这正解释了 SKILL.md 为何要求对生成的人物事实做 source-class provenance 核实——WikiClaimEvidence中的kind字段正是承载"证据来源类别"的位置。

七、页面身份稳定性：更新优于新建

SKILL.md 明确要求：Keep page identity stable. Favor updating existing entities and concepts over spawning duplicates with slightly different names.（保持页面身份稳定，优先更新既有实体与概念，避免用略有差异的名字制造重复页面。）

这一条看似是编辑习惯，实则与整套"确定性"设计绑定：确定性索引（deterministic indexes）依赖稳定的页面 id；wiki_get的lookup按 id 或相对路径定位；## Related区块按 source ids 关联邻近页面。若不断用近似名称新建页面，索引、反向链接和 dashboard 都会产生碎片化噪音，最终削弱 Agent 检索的确定性。配合wiki_lint的 provenance/矛盾检查，可以在重复实体失控前及时暴露问题。

八、Gateway RPC 与 Agent 作用域视角（补充）

对于多 Agent 部署，memory-wiki 通过 Gateway RPC 暴露同样一组能力：读方法wiki.status、wiki.doctor、wiki.search、wiki.get、wiki.obsidian.status、wiki.obsidian.search；写方法wiki.init、wiki.compile、wiki.ingest、wiki.lint、wiki.bridge.import、wiki.unsafeLocal.import、wiki.apply、wiki.obsidian.open、wiki.obsidian.command、wiki.obsidian.daily（extensions/memory-wiki/README.md）。agent 作用域下，vault 相关的 RPC 需携带agentId，多 Agent 配置中缺失或未知 id 会失败——这与 SKILL.md"先wiki_status理解 vault 模式/路径"的建议在 CLI 侧（--agent参数）保持一致。

九、维护者快速自查清单

将 SKILL.md 的全部要点收敛为一张可执行清单，适合在任何一次 vault 维护会话中自检：

• 进入 vault 后先运行wiki_status，确认 mode / path / Obsidian CLI 可用性；
• 共享记忆可用时，优先memory_search（corpus=all）一次召回；需要 Wiki 排序/来源追溯再切wiki_search→wiki_get；
• 编辑或引用前用wiki_get查看精确页面；人物联系方式先核实，生成事实标注 source-class provenance；
• 窄幅变更走wiki_apply（synthesis / metadata），带结构化claims与证据，不做自由式 Markdown 手术；
• 有意义的更新后运行wiki_lint，处理 contradictions / provenance gaps / open questions；
• 默认维护循环：openclaw wiki ingest→openclaw wiki compile→openclaw wiki lint；
• bridge 模式依赖搜索结果前，先openclaw wiki bridge import；
• unsafe-local 仅在用户显式同意私有本地路径访问时使用；
• 生成内容只写进受管标记（<!-- openclaw:wiki:index:* -->、<!-- openclaw:wiki:related:* -->），绝不覆盖<!-- openclaw:human:* -->区块；
• 新主张必须回指原始来源/记忆产物/每日笔记，wiki 页面不是唯一事实来源；
• 优先更新既有实体/概念，不制造近似名称的重复页面；
• render mode 为obsidian时，索引创建/刷新保留 Obsidian 友好的 wikilink。

结语

wiki-maintainer 技能的价值不在于提供新命令，而在于把 memory-wiki 插件的能力组织成一套可执行的治理纪律：先wiki_status探明环境、按需组合memory_search/wiki_search/wiki_get完成检索、用wiki_apply做窄幅变更、以ingest → compile → lint作为默认维护循环，同时用受管标记和证据分层守住"插件生成"与"人类笔记"、以及"编译页面"与"原始来源"之间的边界。理解这些约定背后的源码（src/tool.ts、src/cli.ts、src/config.ts、src/vault.ts、src/markdown.ts），你就能把 OpenClaw 的记忆 Wiki 从"会写文件的插件"升级为"可被 Agent 稳定信任的知识基础设施"。

【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 🦞项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw