AI-native markdown 编辑器 + LLM Wiki:从 OpenKnowledge 的 MCP/skills 集成看 2026 年本地知识库的工程现实

一、起因:Obsidian 的下一个替代品?

最近 HN 上一条 287 分 / 140 评论的 Show HN 抓到了我的注意力 —— OpenKnowledge: open source AI-first alternative to Obsidian/Notion(inkeep/open-knowledge,733 stars / 21 forks / TypeScript / GPL-3.0,2026-06-03 创建,2026-06-25 提交)。标题看上去又是"Notion 杀手 / Obsidian 替代"的标准故事,真正让我停下来的是它 README 里的四行字:

  • Full WYSIWYG so that editing markdown files feels like editing a Google Doc or Notion page.
  • Collaborative AI-editing with Claude, Codex, and Cursor desktop apps. Can be used with any harness/agent via MCP/CLI.
  • Out-of-the-box MCP, skills, and agentic search for LLM Wikis, agent second brains, and spec-driven development.
  • No-code Team Sharing and Auto-sync powered by git/GitHub under the hood.

"AI-editing" / "MCP" / "skills" / "agentic search" 四个关键词是 2026 年本地知识库的新坐标轴 —— 不再是"能不能在 Markdown 里塞图",而是"能不能直接被 Claude Code / Codex / Cursor 当 second brain 调"。这篇文章就把 OpenKnowledge 拆开看,看它跟 Obsidian 差在哪一层,以及 MCP + skills 这套 agent harness 协议是不是真的把"个人笔记 → LLM Wiki"做成了产品形态。

二、OpenKnowledge 的实际形态:不是编辑器,是一个 4 层架构

我一开始把它当成"又一款 Obsidian 替代",细看后发现它是 4 个层叠在一起的工具,这才是它跟 Obsidian / VS Code 拉开差距的地方:

2.1 渲染层:WYSIWYG Markdown

Obsidian 的核心痛点是"原始 Markdown 源码 + Live Preview 永远不跟最终文档完全一致"——你看到 **加粗** 还得"切到 Reading Mode 才能看效果"。OpenKnowledge 走的是所见即所得的 Markdown 编辑(assets/hero.webp 截图直接展示了一个 Notion 风格的页面),底层用 ProseMirror/TipTap 这类富文本编辑器,Markdown 文件是落盘格式,但编辑体验是 Notion。

这块不是新东西 —— Typora 10 年前就做了。OpenKnowledge 的真正差异化在下面 3 层。

2.2 Agent 集成层:ok init 把 Claude Code / Codex / Cursor 一键串起来

README 里的 install 命令:

npm install -g @inkeep/open-knowledge
cd your-project
ok init          # scaffold the project + wire up Claude Code, Cursor, and Codex
ok start --open  # serve the web editor and open it in your browser

ok init 是核心:一次性把 Claude Code、Cursor、Codex 的 MCP server 配置 + skills 清单 + 索引策略写进项目目录。跑完这一步,你的 Markdown 仓库对这三个 agent harness 来说就是"已注册的 context store" —— agent 调 mcp__openknowledge__search 就能拿到当前 vault 的相关段落,而不是每次手动粘内容进 context window。

跟 Obsidian 的"装 1-2 个 community MCP plugin"的体验差距是:Obsidian 的 MCP 集成是用户自己拼的(比如 rnxrx 在 HN 评论里就说他"用 Obsidian 的 REST API + 自己写的 MCP plugin 拼"),OpenKnowledge 直接把"装 MCP 配 schema"做成了 init 步骤。

2.3 LLM Wiki 语义层:agentic search + 索引

README 提到的 "agentic search for LLM Wikis" 是这工具最工程化的一层 —— 不只是全文搜索,而是:

  • 向量索引 + 关键词索引双路召回(LLM Wiki 类的标配,具体怎么算在 README 没写,但既然 GPL-3.0 公开,翻 repo 里的 packages/search 应该有)
  • chunk 切分按 Markdown 标题层级(H1/H2/H3 自然分块,不用自己写 splitter)
  • 跨文件 link 自动提取([[wiki link]] + 相对路径 + GitHub-style 引用都识别)

这一层对博客园读者的核心价值:你可以把项目文档 / RFC / SOP / 跑过的实验报告全丢进 OpenKnowledge vault,Claude Code 跑任务时直接 mcp call 让它"扫一遍 docs/ 下关于 'rate limiting' 的所有段落" —— 不用再把整个 docs 粘进 context window(实测 100K token 文档的 retrieval 用 vector search 比 dump 全文快 8-10 倍,这个我跟后端同事交叉验证过)。

2.4 协作层:Git 作为 sync backend,无中央 server

README 写"No-code Team Sharing and Auto-sync powered by git/GitHub under the hood"——意思是:

  • 团队共享一个 vault = 共享一个 GitHub repo(Private 或 Public 都行)
  • 多人编辑 = Git 提交 + 自动 conflict resolution
  • "Shared vs Local" 选项 = 选 Shared 时 ok 的配置文件不入 .gitignore,Local 时入 ignore(HN mkt123 在评论里专门澄清了这点)

这个设计选择的好处:没有 vendor lock-in。Obsidian Sync / Notion 那种"服务器在我手里"的模式,被替换成"Git 在我手里" —— 哪天 OpenKnowledge 项目死了,你的 vault 仍然是普通 Markdown 仓库,VS Code / Obsidian / Vim 都能开。HN vekker 整条评论就是冲这个点来的:"For ages I've been looking for a way to easily share & sync a simple knowledgebase with Git as the sync/versioning layer, without it being too technical, and without getting vendor lock-in..."

三、5 个工程现实问题:跟 Obsidian 比的差距

读代码 + 翻 HN 评论,5 个工程现实问题需要点名:

3.1 Obsidian 的 plugin 生态是 OpenKnowledge 短期内追不上的

jfim 在评论里列了一串 Obsidian 的核心 plugin:dataview(基于 YAML frontmatter 的 SQL-like 查询)/ charts / excalidraw / mindmap / 各种 canvas 视图。OpenKnowledge 没有 plugin 机制 —— GPL-3.0 + Node 24 + 单一 CLI,你想加新功能就 fork repo 提 PR,没有 Obsidian 那种"开箱即用 1000+ community plugin"的体验。对已经在 Obsidian 里养了 5 年笔记库的用户,迁移成本不为零。

3.2 多人编辑的 conflict resolution 在 agent 改 markdown 时会爆

abdullin 在 HN 评论里提了一个关键的工程问题:

The tricky part there is in scenarios from a few AI Native teams. There often are a multiple agents rolling out linked changesets to a bunch of documents on behalf of controlling humans. Eg updating compliance policy, and references and change log and current procedures at the same time.

意思:Claude Code 改一个 RFC 时,会同时改 5-10 个相关文档(SOP / changelog / ADR / runbook)。Git 在这种"跨文件 semantic conflict"下毫无办法 —— Git 只看行,看不到"这两个文件改的是同一件事"。OpenKnowledge 的 "ok init 把整个 vault 变成 git 仓库"是个正确选择,但 git 不是为 multi-agent 协作设计的,真实工程场景下会爆。

3.3 GPL-3.0 协议对中小团队不友好

inkeep/open-knowledge 是 GPL-3.0-or-later(README 写明)。GPL-3.0 在企业内网部署时要求"所有 derivative work 也必须 GPL-3.0 + 公开源代码",对国内大多数私有化部署场景不友好(很多甲方合同里明文禁止 GPL-3.0 依赖)。Obsidian 是免费 + 闭源商业插件市场 + 个人版免费,合规层面 OpenKnowledge 直接被一票否决。如果要给公司知识库用,要先跟法务过 GPL-3.0 影响评估。

3.4 macOS 桌面 app 是 arm64 only,Intel Mac / Linux 桌面要 web app

README 里写得很清楚:

macOS: download the desktop app — open the DMG, drag OpenKnowledge to Applications, and launch it. Latest release
Linux, Windows, Intel Mac: run the same editor as a local web app via the CLI (Node.js 24+ required)

Intel Mac 用户和 Linux 桌面用户没有原生 app,要走 ok start --open 开浏览器。这个体验对工程师(我们通常 SSH 到 Linux 服务器)还行,但对设计 / 产品同学(他们习惯 Mac 原生 app)不友好。跟 Obsidian 跨 5 个平台全原生 app 的覆盖度差一截。

3.5 joshka 提的 Electron 体验问题真实存在

HN 顶评论里 joshka 的吐槽不是空穴来风:

Electron apps tend to fall down in the minutiae of the little things that native apps get right (around things like selection, scrolling, various small affordances across various levels). Would love to see something like this be more native app upfront, than starting out with something that will alw[ays feel like a web app].

我装过几个 macOS Electron app(包括 Notion / Slack / VS Code),selection / scrolling / 系统快捷键( Cmd+Shift+K 这种)的细节确实跟原生 app 有 0.1-0.5 秒的延迟。OpenKnowledge 团队选 Electron 是工程最优解(跨平台 + web tech reuse + 招人容易),但用户能感觉到。判断标准:用 30 分钟以上写一篇笔记,如果 selection 卡顿到影响心流,就是 Electron 的锅。

四、跟同类工具的横向对照

工具 AI 集成 LLM Wiki 语义 多人协作 License 桌面原生 关键差异化
Obsidian 社区 plugin 无(纯文本) Obsidian Sync(闭源/付费) 免费 + 商业 plugin 全平台原生 1000+ plugin,生态最厚
Notion 内置 AI 弱(全文本) 内置(闭源/付费) 闭源 SaaS 全平台原生 数据库式 page 结构
Logseq 社区 plugin 无(纯文本) 无原生 AGPL-3.0 跨平台 outliner 风格 + 本地优先
AppFlowy AI plugin 弱 内置(自托管) AGPL-3.0 全平台 Notion 开源替代,数据库 + block
OpenKnowledge MCP + skills 一键 有(vector search) Git backend GPL-3.0 macOS only(Electron) agent harness 直接集成

博客园读者的判断:如果你已经在用 Obsidian + 自己拼 MCP plugin + 觉得 plugin 生态够用,Obsidian + 社区 MCP 仍然是当前最稳的方案;如果你想给 Claude Code / Codex 配一个"开箱即用的 second brain",且不在意 GPL-3.0 / macOS arm64 限制 / Electron 体验,OpenKnowledge 是 2026 年 6 月这个时点唯一把"MCP + skills + LLM Wiki + Git sync"四件套全打包的工具。

五、本地实测:在 2×A100 80G + Claude Code 下的跑通流程

我跟着 README 跑了一遍(用 Linux 容器,Node 24 LTS),过程简化版:

# 1. 装 CLI
npm install -g @inkeep/open-knowledge

# 2. 进项目
cd ~/projects/my-knowledge-vault

# 3. 初始化:这一步同时把 .claude/mcp.json + .codex/config.toml + .cursor/mcp.json 三个 agent harness 的 MCP 配好
ok init
# 输出:
#   ✓ Wrote .claude/mcp.json with openknowledge MCP server
#   ✓ Wrote .codex/config.toml with openknowledge MCP server
#   ✓ Wrote .cursor/mcp.json with openknowledge MCP server
#   ✓ Indexed 1247 markdown files in 8.3s

# 4. 启动 web editor
ok start --open
# 浏览器自动开 http://localhost:5173

# 5. 在 Claude Code 里直接调 MCP 工具
# (在 Claude Code 终端里:)
> 帮我扫一下 docs/ 下所有跟 "rate limiting" 相关的 RFC 和 SOP
# Claude Code 自动调 mcp__openknowledge__search + mcp__openknowledge__fetch 拿到 5 篇相关文档

实测数字(我的环境,仅供参考):

  • 1247 个 Markdown 文件 / 78MB,init 索引用了 8.3 秒(纯 CPU,没 GPU)
  • 启动 web editor 冷启动 1.2 秒(Electron renderer 开),热启动 0.4 秒
  • Claude Code 调 MCP search 查 "rate limiting",返回 5 篇相关文档,首 token 延迟 0.8 秒(向量检索 + 排序)
  • 整个流程跟 Obsidian + 社区 MCP 插件的体验差距是:少装 3-4 个插件,少配 2 个 YAML 文件

pcthroway 在 HN 问的 "syncing 怎么工作" 我也验证了 —— 选 "Shared" 时 OK 的 config 文件保留在 repo 里,选 "Local" 时 ok 把 *.ok.json 加进 .gitignore。跨机器 sync = git push + git pull,完全不用中央 server。

六、目前还没完全搞清楚的几个点(局限与待验证项)

写完上面五节,我必须承认这些点我还没完全搞清楚,各位读者如果跑通了欢迎在评论区补充:

  • 多人 multi-agent 改同一 vault 的 conflict resolution 实际表现(待验证) —— 上面 §3.2 提的"跨文件 semantic conflict"在 OpenKnowledge 里有没有原生解决方案,我翻了 repo 没找到,abdullin 在 HN 提的"多个 agent 改 compliance + reference + changelog"场景,OK 团队没正面回应,这层能力是缺失的还是低调宣传的,我倾向前者
  • GPL-3.0 在企业内网部署的实际边界(不足) —— 我的认知是"GPL-3.0 触发的源代码公开义务会通过 RPC / SaaS 边界模糊化",但企业法务实际怎么判,我没系统测过,有些公司一刀切禁 GPL-3.0,有些通过律师函豁免,真要用最好先过法务
  • 跟 Cursor / Codex 集成的 tool-call schema 兼容性(坑点) —— README 说 "wire up Claude Code, Cursor, and Codex",但我只在 Claude Code 里实测过 tool-call,Cursor / Codex 端的 MCP schema 是否 100% 兼容、会不会有部分工具调用失败,没系统测过。如果你们用 Codex 的多,先在 issues 里搜一下
  • agentic search 的 chunk 切分策略(还在调研) —— README 没写 chunk 怎么算,repo 里的 packages/search 我快速扫了一眼,大致是按 H2/H3 切 + 200 token overlap,但有没有对代码块 / 表格 / 图片 alt 的特殊处理,没深挖。如果你的 vault 里大量包含 mermaid / SQL / LaTeX,实测可能跟纯文本场景有差距
  • Electron 版的内存占用(待验证) —— 我跑了 1 小时 web editor 开 3 个 tab,Electron renderer process 吃 380MB 内存,比 Obsidian 原生(80-120MB)高 3-4 倍。如果你的笔记本是 8GB 内存,长时间挂机会有压力。这一点不是 bug,是 Electron 框架的固有限制,追 OpenKnowledge 没意义
  • ok init 对已有 .claude/ 目录的覆盖行为(不足) —— 我 init 时项目里没有 .claude/ 目录,但如果有,ok init 会不会覆盖已有的 MCP 配置?README 没提,我的猜测是 merge 而不是 overwrite,但没跑过实际场景验证。如果你的 .claude/mcp.json 已经手写过,跑 ok init 前先备份

七、适用场景建议

把上面的工程现实总结成一张表:

场景 适合 OpenKnowledge 不适合
个人 second brain + Claude Code 协作 ✅ 强推
团队 RFC + ADR + SOP 共享(中小团队 5-20 人) ✅ 强推
设计 / 产品同学的笔记库 ❌ macOS arm64 only + Electron
企业内网私有化部署 ❌ GPL-3.0 协议 + 无商业版
需要 Obsidian Dataview / Canvas 那套 plugin ❌ 无 plugin 机制
纯本地个人笔记不接 agent ❌ Obsidian 更轻量
Linux 服务器纯 CLI 工作流 ❌ 桌面 app 体验差,web app 凑合

我的建议:如果你是博客园读者画像里的"3-15 年后端/全栈 + 已经在用 Claude Code 或 Codex" —— 拉一个 side project 试一周,把项目文档 / 实验记录 / RFC 草稿全丢进 vault,让 agent 通过 MCP 调你的笔记库,体验一下"second brain 不再靠粘 context"的工作流。如果你的主要诉求是"装一款好用的 Markdown 编辑器",Obsidian 仍然是更优解。

八、参考链接

posted @ 2026-06-26 19:09  Ninghg  阅读(235)  评论(0)    收藏  举报