OpenKB 评测：把文档编译成会自我维护的 Wiki，而不是每次重新检索
OpenKB: Open LLM Knowledge Base
秒懂
- 它是什么？
- OpenKB 是一个把 PDF、Word、网页等原始文档编译成结构化、互链 Wiki 的 CLI 工具，底层依赖 PageIndex 的无向量检索。它适合知识需要沉淀的场景，但代价是每次编译都要消耗 LLM 调用，且对文档更新频率敏感。
- 适合谁用？
- OpenKB 适合这样的团队：有大量长文档需要反复查询，且愿意为每次文档更新支付 LLM 编译成本，而不是在每次查询时都做向量检索。它尤其适合个人研究者或小团队，因为 Wiki 是纯 Markdown 文件，可以直接用 Obsidian 打开，知识资产不锁定在某个数据库格式里。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 56 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是 RAG 的重复劳动问题
传统 RAG 的流程是每次提问都把文档切成块、做向量化、检索、再让 LLM 生成答案。OpenKB 的出发点不同，它引用 Andrej Karpathy 的一个概念：让 LLM 把文档编译成摘要、概念页和交叉引用，并且自动维护这些内容。知识在一次编译后沉淀下来，而不是每次查询都从头推导。这个思路的差别在于，传统 RAG 是无状态的，OpenKB 则试图建立一个有状态的、持续更新的知识层。它面向的读者是那些需要反复查询同一批长文档的人，比如读论文的研究者、整理产品文档的工程师、维护内部流程手册的团队。如果你只是偶尔问一次某个文档的内容，编译成本可能不划算。
短文档与长文档走两条完全不同的路径
README 里的架构表把处理方式分得很清楚。短文档用 markitdown 转成 Markdown，图片用 pymupdf 提取，LLM 直接读全文。长文档，特指 PDF 超过 20 页的，则交给 PageIndex 做 tree indexing，生成树状索引和摘要，LLM 读的是文档树而不是全文。这个区分是合理的，因为让 LLM 直接读 100 页 PDF 的 token 成本太高，而 PageIndex 的树结构可以让检索先定位到相关子树，再深入读取。但这里有一个没说清的权衡：短文档的图片是内联提取的，长文档的图片则由 PageIndex 抽取，两种方式对图片中文字和表格的识别质量是否一致，README 没有给出任何对比数据。
安装和初始化都是命令行操作，配置集中在 .openkb/config.yaml
安装很简单，pip install openkb 即可。初始化流程是 mkdir my-kb && cd my-kb，然后 openkb init。之后用 openkb add 添加文件、目录或 URL，用 openkb query 提问，用 openkb chat 交互。模型配置在 init 时或 .openkb/config.yaml 里设置，格式是 LiteLLM 的 provider/model，比如 anthropic/claude-sonnet-4-6，OpenAI 模型可以省略前缀直接写 gpt-5.4。API key 放在 .env 文件里，变量名是 LLM_API_KEY。这里有个细节值得注意，订阅制提供商比如 chatgpt/* 和 github_copilot/* 走 OAuth device flow，不需要 API key，OpenKB 会跳过缺失 key 的警告。Web UI 需要额外安装，pip install "openkb[web]" 然后运行 openkb-web，服务默认跑在 127.0.0.1:7566。
Wiki 是纯 Markdown 文件，输出格式兼容 Obsidian 和 Google OKF
编译产物不是存在数据库里，而是普通的 .md 文件，带交叉链接。这意味着你可以直接用 Obsidian 打开知识库目录，看它的图谱视图。README 还提到 Wiki 页面遵循 Google Open Knowledge Format 规范，这是一个面向数据共享的格式标准。另外有 Entity Pages 功能，能把人物、组织、地点、产品自动抽取成独立的 Wiki 页面，并且保持同步。这个设计有一个实际好处：知识库不依赖 OpenKB 本身才能读取，即使项目停止维护，你的知识资产仍然是可读的文本文件。但反过来说，如果你需要结构化查询或者权限控制，纯 Markdown 文件的方式就有些原始，得自己处理。
Skill Factory 和 generator 层是它区别于纯知识库的地方
OpenKB 分成两层，底层是 wiki foundation，负责编译和维护知识，上层是 generators，包括 query、chat 和 Skill Factory。Skill Factory 能从你的 Wiki 里蒸馏出可分发的 agent skill，命令是 openkb skill new my-expert "Reason like an expert on <your-topic>"。还有 openkb visualize 生成交互式知识图谱，openkb deck new my-deck 生成单文件 HTML 幻灯片。这些 generator 的存在意味着 OpenKB 不只是检索工具，它试图成为知识的上游供应者，让下游的 agent 或演示直接消费编译后的成果。但 README 对 Skill Factory 产出的 skill 格式、如何被其他 agent 加载、是否遵循某种标准，都没有展开说明，这部分只能等实际使用才能验证。
无向量检索是卖点，也是需要警惕的黑盒
OpenKB 的宣传语里明确写了 No Vector DB，检索完全依赖 PageIndex 的 reasoning-based 方法。这避免了向量数据库的运维和 embedding 模型的选择问题，但代价是检索质量完全取决于 PageIndex 的树索引算法和 LLM 的理解能力。README 说它能处理长文档中的图片、表格和图像，但没给任何准确率或延迟数据。另一个隐患是成本，每次 add 一个文档，LLM 都要做一次编译，长文档的 tree indexing 会消耗多少 token，README 同样没有提及。如果文档频繁更新，编译成本会持续累积。相比之下，传统 RAG 虽然每次查询都重新检索，但向量化通常是批处理且成本较低。OpenKB 的思路是编译一次、多次受益，这个模型只有在查询次数远多于更新次数时才成立。
维护成本和许可边界需要单独确认
项目采用 Apache-2.0 许可，允许商用和修改。版本更新活跃，最近一次发布是 v0.4.5，距离 v0.4.4 只有十天，说明项目处于快速迭代期。这意味着接口可能变动，升级时要注意 changelog。OpenKB 通过 LiteLLM 接入多家模型提供商，README 特别提到 LiteLLM 被固定在一个安全版本上，对应 2026 年 3 月的一次安全更新，这说明依赖供应链是项目关注的点，但反过来也意味着你不能随意升级 LiteLLM，得等 OpenKB 自己跟进。PageIndex 是独立项目，它的许可和 OpenKB 不一定相同，如果要商用，需要单独去查 PageIndex 的 LICENSE 文件。Web UI 的认证默认关闭，README 明确说这是 local-first 设计，暴露到公网前必须设置 OPENKB_API_TOKEN。
编辑结论
OpenKB 适合这样的团队：有大量长文档需要反复查询，且愿意为每次文档更新支付 LLM 编译成本，而不是在每次查询时都做向量检索。它尤其适合个人研究者或小团队，因为 Wiki 是纯 Markdown 文件，可以直接用 Obsidian 打开，知识资产不锁定在某个数据库格式里。不适合的场景是：文档高频变动且查询延迟敏感，因为每次 add 或更新都要触发 LLM 编译，这个过程的耗时和费用在 README 里没有给出任何基准数字，需要你自己实测。采用前先验证三件事：第一，你的 LLM 提供商在 LiteLLM 的 provider/model 格式下能否稳定工作，特别是长文档的 tree indexing 会消耗多少 token；第二，PageIndex 对图片和表格的抽取质量是否满足你的文档类型，README 只说支持，没给准确率；第三，OpenKB 的 API 默认无认证，如果部署到非本机环境，必须先设置 OPENKB_API_TOKEN。Apache-2.0 许可允许商用和修改，但 PageIndex 作为独立项目，其许可条款需要单独确认，README 没有说明。
社区笔记