OpenKB
让 LLM 自动编译和维护个人知识库,告别传统 RAG 的重复推理困境
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
让 LLM 自动编译和维护个人知识库,告别传统 RAG 的重复推理困境
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
想象这样一个场景:你花了三个月整理了一份 200 页的技术报告,里面涉及十几个不同的概念、人物和项目。你把这份 PDF 上传到一个 RAG 系统,问它"这份报告和之前那篇论文有什么关联",结果 RAG 给你返回了四段毫不相干的段落——因为它每次问答都是"从零发现知识",根本不记得之前处理过什么。
OpenKB(Open Knowledge Base) 解决的就是这个问题。它不是又一个传统 RAG,而是把大模型变成了一位图书馆馆员:每次你喂给它一份文档,它会自动生成摘要、建立概念关联、标注实体人物,形成一张不断生长的知识网络。下次你再提问时,它从这张已有的网络里调取信息,而不是临时从文档里大海捞针。
这个思路直接来源于 Andrej Karpathy 在 2025 年的一条推文,他描述了一个让 LLM 自动编译和维护 Wiki 的概念,OpenKB 就是这个概念的开源实现。
OpenKB 由 VectifyAI 团队开发,背后依赖的核心技术是同团队的 PageIndex(一个向量无关的长文档检索方案,GitHub 星标 32,795)。项目于 2026 年 4 月上线,Apache-2.0 开源许可证,主分支为 main,仓库目前有 23 个 open issues,整体处于活跃开发阶段(Alpha)。
项目定位介于"文档管理工具"和"AI Agent 开发框架"之间:它既可以用作个人或团队的知识管理中枢(把论文、文档、网站变成可查询的知识库),也可以作为 AI 应用的知识底座(通过 Skill Factory 将知识编译成可分发的 AI Skill)。
核心作者为 Kylin(quanqi@pageindex.ai)和 Ray(ray@vectify.ai),两位均来自 PageIndex 团队,在文档解析和 LLM 应用领域有深厚积累。
OpenKB 的设计哲学是"编译一次,反复使用"。整个系统分为两层:
这是整个系统的地基。每次运行 openkb add <文档> 时,背后经历了如下流程:
markitdown 转为 Markdown,LLM 读取完整文本,生成摘要 + 概念 + 实体。编译完成后,Wiki 目录结构如下:
wiki/
index.md 知识库总览
log.md 操作时间线
AGENTS.md LLM 指令模板(schema)
sources/ 原始文档转换结果
summaries/ 每篇文档摘要
concepts/ 跨文档综合概念(知识沉淀核心)
entities/ 具名实体(人物/组织/产品/地点等)
explorations/ 查询结果存档
reports/ Lint 报告
概念页面(concepts)是 OpenKB 的精髓所在:当你上传多份文档后,LLM 会综合已有概念,对新文档进行跨文档综合——比如两份报告都提到了同一个框架,LLM 会识别并关联它们,而非各写各的。
Wiki 编译完成后,通过命令行工具从知识库中提取价值:
| 命令 | 输出 |
|---|---|
openkb query "问题" | 带引用的 grounded 回答 |
openkb chat | 多轮交互会话 |
openkb skill new <name> "<意图>" | 编译为可分发的 Anthropic Skill |
其中 Skill Factory 是最具想象力的功能:它可以将你的知识库编译成一个自定义的 AI Skill,并生成 marketplace.json,让他人在自己的 AI 环境中直接使用你整理的知识。

图1:OpenKB 项目 Logo(来源:docs.pageindex.ai)
OpenKB 的核心技术栈:
pageindex==0.3.0.dev1):长文档树状索引与检索,这是项目的核心技术壁垒openkb/agent/ 目录下包含核心 Agent 逻辑:
compiler.py:Wiki 编译引擎,驱动整个文档解析和知识抽取流程query.py:基于 Wiki 的问答 Agentchat_session.py:多轮会话管理skill_runner.py / skills.py:Skill 执行与注册linter.py:知识健康检查openkb/skill/ 目录负责 Skill 生命周期管理:
creator.py:将 Wiki 编译为 Skillevaluator.py:Skill 质量评估validator.py:结构验证(frontmatter、文件大小、wikilinks)marketplace.py:技能市场元数据管理OpenKB 刻意摒弃了传统 RAG 依赖的向量数据库(如 ChromaDB、FAISS)。这是因为向量检索在高维空间中存在"语义相似但事实错误"的问题——两段话 embedding 相似,不代表它们真正相关。OpenKB 通过 PageIndex 的树状索引 + LLM 自身推理能力来实现检索,理论上更可靠,但也更依赖 LLM 的推理质量。
pip install openkb
没有 Docker、没有复杂依赖,一行命令搞定。唯一必需的是 LLM API Key(通过 .env 文件配置)。
# 1. 初始化知识库
mkdir my-kb && cd my-kb
openkb init
# 2. 添加文档(支持本地文件、目录、URL)
openkb add paper.pdf
openkb add ~/papers/
openkb add https://arxiv.org/pdf/2509.11420
# 3. 提问
openkb query "这篇报告的核心发现是什么?"
# 4. 交互式聊天
openkb chat
# 5. 编译成可分发 Skill
openkb skill new my-expert "像某领域专家一样思考"
openkb watch 命令还支持监控目录,新文件自动编译,非常适合持续积累知识的场景。
en,中文场景可能需要手动调整Development Status :: 3 - Alpha,生产环境使用需谨慎OpenKB 是纯本地工具——所有文档处理和 LLM 调用都在本地机器完成,不存在数据上传第三方服务器的风险。但需要注意:
.env 文件,不要提交到 Git项目中无明显的已知安全漏洞(security_issues 列表为空)。
OpenKB 代表了一种新兴的 RAG 演进方向——编译式 RAG(Compiled RAG)。传统 RAG 是"查询时检索",OpenKB 是"编译时积累、查询时推理"。这个方向的核心假设是:知识应该像维基百科一样持续积累,而非每次问答都从零构建。
这个方向的价值在于:
从 GitHub 数据看,OpenKB 上线两个月获得 2028 stars,增长曲线值得关注(结合 PageIndex 的 32k stars 背书)。其核心差异点在于:不是又一个 RAG 框架,而是知识管理 + AI 应用的融合产品。
随着 LLM 应用向纵深发展,OpenKB 这类"知识持久化 + 可分发"的工具,可能会成为 AI 原生应用的数据基础设施。