OpenKB
VectifyAI/OpenKB加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象这样一个场景：你花了三个月整理了一份 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 原生应用的数据基础设施。