OpenKB 开放知识库
把散落文档编译成互相链接的持久化 Wiki，让知识随摄入累积而非每次查询重新推导。
- Star 数
- ★ 4.6k
- 最近更新
- 2 个月前
- License
- Apache-2.0
- 主语言
- Python
- FA 评分
- 59/100 · 缺口较多
30 秒速览
- 可在哪里用
- 通用 · 跨平台Codex · Claude Code · OpenAI API · Claude APIChatGPT（部分支持）
- 开始前需要
- 典型场景
- 研究者在读十几篇论文时，用 openkb add 逐篇摄入，让 LLM 自动维护概念页与实体页，避免每问一次都重新检索原文。
- 主要局限
- 核心流程强依赖 LLM 调用，摄入、查询、技能蒸馏都要消耗模型额度，文档没有给出成本估算或离线兜底方案。
- 源码审查
- 59/100 · 缺口较多
这个 Agent 能做什么，适合哪些场景？
OpenKB 是 VectifyAI 推出的命令行开源系统，用 LLM 把原始文档编译成结构化、互相链接的 Wiki 式知识库，底层检索由 PageIndex 的无向量、基于推理的树索引提供。它分为两层：负责编译与维护的 Wiki 基础层（openkb init/add/list/status/watch/lint/remove/recompile）和把 Wiki 转化为产出的生成器层（query、chat、visualize、skill new、deck new）。短文档经 markitdown 转成 Markdown 后由 LLM 通读，20 页以上的长 PDF 交由 PageIndex 构建分层树索引，LLM 改为读树，同时原生处理图、表、图片。输出是纯 .md 文件组成的 wiki/ 目录，可直接用 Obsidian 打开查看图谱，也可通过内置的 FastAPI 服务与 Knowledge Workbench 网页界面浏览、上传和流式问答。
openkb init 生成 .openkb/config.yaml 与 wiki 骨架；openkb add 接受文件、目录或 URL，短文档走 markitdown 转 Markdown、长 PDF 走 PageIndex 建树，随后 LLM 依次生成摘要页、读取已有概念页与实体页、做跨文档综合并更新概念与实体、最后更新索引与日志。openkb query 给出带引用的答案并可 --save 落到 wiki/explorations/；openkb chat 提供多轮会话，支持 --resume/--list/--delete 管理会话，会话内可用 /add、/skill、/deck、/lint、/save 等斜杠命令。openkb skill new 从 Wiki 蒸馏出可被 Claude Code、Codex、Gemini CLI 安装的 agent skill，配套 validate/eval/history/rollback；openkb visualize 输出自包含的 3D/思维导图/放射状知识图谱 HTML；openkb deck new 生成单文件 HTML 幻灯片，--critique 走质量评审。模型通过 LiteLLM 调用，provider/model 格式写在 config.yaml，密钥放 .env 的 LLM_API_KEY。
- 研究者在读十几篇论文时，用 openkb add 逐篇摄入，让 LLM 自动维护概念页与实体页，避免每问一次都重新检索原文。
- 需要长期跟踪某个领域的分析师，把 openkb watch 挂在 raw/ 目录上，新下载的 PDF 落盘即自动编译进 Wiki。
- 希望在 Obsidian 里已有知识体系的人，直接把生成的 wiki/ 当 vault 打开，用 [[wikilinks]] 与图谱视图浏览概念连接。
- 要把团队知识分发给其他 Agent 的工程师，用 openkb skill new 产出一个可安装到 Claude Code、Codex 或 Gemini CLI 的只读 skill。
- 面向扫描版或超大 PDF 的场景，配置 PAGEINDEX_API_KEY 走 PageIndex Cloud 获得 OCR 与更快的结构生成。
- 需要在自己的应用里查询知识库的开发者，安装 openkb[web] 后启动 openkb-web，通过 FastAPI 服务与 /docs 交互式文档接入。
如何安装或部署这个 Agent？
需要 Python 环境与 pip。基础安装：pip install openkb；也可用 pip install git+https://github.com/VectifyAI/OpenKB.git 装 GitHub 最新版，或 git clone 后 pip install -e . 做可编辑安装。网页界面与 REST API 需额外 extras：pip install "openkb[web]"。模型密钥写在项目目录的 .env 文件里，形如 LLM_API_KEY=your_llm_api_key；使用 chatgpt/*、github_copilot/* 这类 OAuth 设备流订阅制提供方时无需 API key。若要启用 PageIndex Cloud（扫描件 OCR、更快结构生成），在同一 .env 中再加 PAGEINDEX_API_KEY。
如何使用这个 Agent？
mkdir my-kb && cd my-kb 建目录，运行 openkb init 初始化（此时选模型，如 anthropic/claude-sonnet-4-6 或 gpt-5.4）。随后 openkb add paper.pdf、openkb add ~/papers/ 或 openkb add https://arxiv.org/pdf/2509.11420 摄入内容。提问用 openkb query "What are the main findings?"，连续交互用 openkb chat（会话内 /help 看全部斜杠命令）。产出侧可运行 openkb skill new my-expert "Reason like an expert on <your-topic>"、openkb visualize、openkb deck new my-deck "An intro deck on <your-topic>"。网页版：pip install "openkb[web]" 后执行 openkb-web，浏览器打开 http://127.0.0.1:7566/ 进入 Knowledge Workbench；默认本地无鉴权，对外开放前应设置 OPENKB_API_TOKEN。前端二次开发可 cd frontend && npm install && npm run dev。
这个 Agent 有哪些优点和局限？
- 知识以 wiki/ 目录下的纯 Markdown 与 [[wikilinks]] 落地，天然兼容 Obsidian，图谱可视化与文本编辑器都能直接打开，不存在厂商私有格式锁定。
- 长文档走 PageIndex 的分层树索引而非向量库，README 明确宣称不需要 Vector DB，检索是让 LLM 在索引上推理，扫描件还可选 PageIndex Cloud 的 OCR 补足。
- 模型层经 LiteLLM 抽象，README 列出 OpenAI、Claude、Gemini 以及 chatgpt/*、github_copilot/* 等 OAuth 订阅制提供方，切换成本主要体现在改 config.yaml 的 provider/model 字段。
- 生成器与基础层分离，同一份 Wiki 可产出带引用的答案、多轮会话、可视化图谱、可分发 skill 和 HTML 幻灯片，知识只编译一次可反复复用。
- 核心流程强依赖 LLM 调用，摄入、查询、技能蒸馏都要消耗模型额度，文档没有给出成本估算或离线兜底方案。
- 长 PDF 的准确检索依赖 PageIndex，openkb query 的引用质量与建树质量强绑定，扫描件在本地开源版下还需另配云端能力。
- 知识编译时 LLM 会改写概念页，recompile 会覆盖手工编辑，README 用 --dry-run 提示了这一风险，但缺少版本化或人工审核环节。
- wiki/AGENTS.md 是 LLM 维护 Wiki 的指令手册，修改结构约定需要理解该文件，存在一定上手门槛。
- 项目路线图中非 PDF 格式的长文档、嵌套目录、层次化概念索引、数据库存储均未完成，大规模集合场景仍需等待。
这个 Agent 与同类方案有什么区别？
:Karpathy 的手工工作流：短文档由 LLM 直读，长文档遇上下文限制与 context rot，输入靠网页剪藏生成 .md，实体抽取靠手工；OpenKB 用 markitdown 做格式统一的短文档入口，用 PageIndex 树索引处理长文档，输入覆盖 PDF、Word、PPT、Excel、HTML、文本、CSV、Markdown 与 URL，实体（人物、组织、地点、产品）自动抽取并保持同步，输出除 Wiki 外还含 Skill Factory 与 agent CLI 集成。
传统 RAG：README 指出传统 RAG 每次查询都从零重新发现知识、不累积；OpenKB 一次性编译成持久 Wiki，交叉引用预先存在，矛盾会被标记。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|
| OpenKB 开放知识库 当前 | 59 · 缺口较多 | ★ 4.6k | 2 个月前 | Python | Codex · Claude Code · OpenAI API · Claude API |
| DeepTutor 终身个性化辅导系统 | 49 · 缺口较多 | ★ 40k | 今天 | Python | Codex · Claude Code · OpenAI API · Claude API |
| LLM Wiki | 85 · 表现良好 | ★ 1.3k | 8 天前 | Python | Codex · Claude Code |
| SwarmVault | 67 · 存在缺口 | ★ 694 | 2 个月前 | TypeScript | Codex · Claude Code |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
least_privilege：CI 工作流显式设置 permissions: contents: read、checkout 使用 persist-credentials: false，且 wiki 工具对路径逃逸（../outside.png、../../etc/passwd）返回 Access denied，说明有最小权限意识，但未提供完整权限清单，故扣至 2。user_confirmation：README 称 SKILL.md 只读、不会在未要求时执行 add/remove/lint --fix，但这是文档断言，未见代码级确认门控，故仅 1。data_flow_transparency：文档说明文档与查询会经 LiteLLM 发往所选 LLM 提供商，但未系统列出数据流向、留存或第三方处理，故 1。sensitive_data_handling：仅提示用 .env 存 LLM_API_KEY、可用 OPENKB_API_TOKEN 保护服务，缺少密钥轮换、日志脱敏、敏感文档处理策略，故 1。dependency_security：pyproject 对全部直接依赖精确 pin，并注释说明 litellm 供应链事件与 openai 版本上限原因，CI 用 uv sync --locked 锁定传递依赖，证据充分，给 3。external_effects：add/remove/recompile 会改写 wiki 与 .openkb 状态，watch 会持续自动编译，但缺少对破坏性外部影响的显式确认设计，故 1。rollback：测试覆盖编译失败回滚转换产物、长文档仅回滚本次新建 blob、去重命中不误删既有 blob、目录级 DirtyRollbackError 停止，回滚设计有实证，给 3。source_attribution：query 声称带引用、wiki 有 sources 页，但未见引用格式或来源追踪机制的细节，故 2。
self_consistency：README 命令表、pyproject 入口点（openkb、openkb-web、openkb-api 别名）与测试中的 CLI 行为基本一致，但测试夹具 conftest 使用 embedding_model/chunk_size 等旧配置字段，与 README 的 model/language/pageindex_threshold 不一致，存在文档与代码漂移，故 2。dependency_availability：依赖均为 PyPI 上可获取的精确版本，但 pageindex==0.3.0.dev3 为 dev 预发布版本，可用性与长期稳定性存疑，故 2。failure_messages：测试断言了 'No knowledge base found'、'Unsupported file type'、'does not exist'、'SKIP'、'Access denied' 等明确失败信息，但未见对 LLM 调用失败、网络超时等运行时错误的统一提示策略，故 2。
audience_and_scenarios：README 明确面向开发者与知识工作者，给出 CLI、Web UI、Obsidian、Claude Code/Codex/Gemini 集成等场景，覆盖较广，故 2。capability_boundaries：文档说明短文档与长 PDF（≥20 页）的不同处理路径、PageIndex 本地/云差异、Roadmap 未完成项，边界较清楚，但未系统列出不支持格式或规模上限，故 2。trigger_precision：skill eval 声称检查触发提示，但未见触发条件、误触发率或阈值定义，故 1。environment_fit：要求 Python ≥3.10、可选 web extra、Node 20 构建前端，并说明本地 Ollama/LM Studio 超时调优，环境适配有说明但未覆盖全部平台差异，故 2。
information_architecture：README 结构清晰，分 What/Getting Started/How it Works/Usage/Configuration/Integrations/REST API 等章节，命令分两层组织，给 3。install_notes：pip install openkb、GitHub 安装、源码可编辑安装、web extra、前端构建均有说明，给 3。naming_stability：openkb-api 作为历史别名保留、api 作为 web 的兼容别名，显示命名稳定性意识，但项目处于 Alpha 且版本由 hatch-vcs 动态生成，稳定性有限，故 2。examples_and_faq：README 大量链接 examples/ 下真实产物（commands、chat、skills、slides、rest-api 等），但本次证据未包含这些文件内容，无法核实，故 2。known_limitations：仅 Roadmap 列出未完成项，缺少已知缺陷、性能边界、失败模式等专门说明，故 1。license：Apache-2.0 全文存在，pyproject 与 README 一致声明，给 3。versioning_changelog：publish.yml 说明 tag 触发、hatch-vcs 从 tag 派生版本、自动生成 Release notes，但仓库内无 CHANGELOG 文件，故 2。maintenance_responsibility：pyproject 列出作者邮箱与 Issues 链接，但发布者身份未经验证，且无治理、安全响应或维护承诺说明，故 1。
output_usability：输出为 Markdown wiki、带引用答案、HTML 幻灯片、可安装 skill、知识图谱，形式多样且可直接使用，但未提供输出质量评估或格式规范，故 2。marginal_value：相对传统 RAG，编译式 wiki 与 PageIndex 树索引在长文档场景有差异化价值，但缺少与替代方案的量化对比，故 2。cost_benefit：每次 add 触发多次 LLM 调用（单文档可能触及 10–15 个 wiki 页），且长文档依赖 PageIndex 云服务可能产生额外成本，README 未给出成本估算或优化建议，故 1。
claim_traceability：README 的多数能力声明未附可核验证据（如性能数据、基准测试），仅链接 examples/ 但内容不在本次证据中，故 1。cross_source_corroboration：README、pyproject、CI 工作流与测试之间部分相互印证（如依赖 pin、回滚测试），但核心功能声明缺乏多源交叉验证，故 1。fact_inference_separation：文档将设计意图与事实混合陈述（如 'Knowledge compounds'、'accurate and scalable retrieval'），未区分已验证事实与推断，故 1。
- 发布者身份未经验证，维护责任与安全响应路径不明确，企业采用前应自行核实。
- 项目处于 Alpha 阶段，版本由 hatch-vcs 从 tag 动态生成，接口与配置字段可能变动（测试夹具已出现旧配置字段）。
- 依赖 pageindex==0.3.0.dev3 为预发布版本，长期可用性与兼容性存在风险。
- 每次 add 会触发多次 LLM 调用，长文档可能使用 PageIndex 云服务，成本与数据外发范围需自行评估。
- Web UI 默认关闭鉴权（本地优先），暴露服务前必须设置 OPENKB_API_TOKEN。
- README 中大量能力声明与 examples/ 链接未在本次静态证据中提供，无法核实。