LLM Wiki：把文档持续编译成可检索知识图谱
一个把文档持续整理成互链Wiki的桌面知识库，区别于每次现查现答的传统RAG。
GitHub nashsu/llm_wiki 更新 2026-09-11 分支 main 星标 18.1K 分叉 2.1K
TypeScript Rust 知识库 RAG LanceDB MinerU 桌面应用

🧭 决策指南

为什么现在热： 无法从材料判断

适合，如果你

  • 你要把PDF、DOCX、Markdown和网页资料持续维护成带来源追踪的Wiki。
    README的Features列出Multi-format Document Parsing、Two-Step Chain-of-Thought Ingest与Source Folder Auto-Watch。
  • 你正在使用Claude Code或Codex，需要通过本地MCP查询项目、文件和知识图谱。
    README的Local HTTP API + MCP Server + AI Agent Skill章节列出127.0.0.1:19828、本地MCP及Claude Code/Codex。
  • 你希望把关键词检索与LanceDB向量检索组合，并使用OpenAI兼容模型端点。
    README的Features列出Vector Semantic Search、LanceDB和OpenAI-compatible endpoint。
  • 你需要检查知识关联、社区和知识缺口，而不只是返回文本答案。
    README列出4-Signal Knowledge Graph、Louvain Community Detection和Graph Insights。

不适合，如果你

  • 你的部署不能提供LLM API key和model配置。
    README的Quick Start第2步要求在Settings中配置LLM provider、API key和model。
  • 你的环境不接受macOS、Windows或Linux桌面安装包。
    README的Pre-built Binaries仅列出macOS .dmg、Windows .msi和Linux .deb/.AppImage。
  • 你的合规评审要求明确的开源许可证条款。
    项目元数据的许可协议为Other，提供材料未给出具体许可文本。
  • 你的检索流程必须完全依赖现查现答，而不保存持续生成的Wiki状态。
    项目描述明确区别于traditional RAG，核心机制是incrementally builds and maintains a persistent wiki。

前置条件

  • 可使用macOS、Windows或Linux预构建包：.dmg、.msi、.deb或.AppImage。
  • Quick Start要求在Settings配置LLM provider、API key和model。
  • 如启用Deep Research，README列出Tavily、SerpApi或SearXNG Web Search提供商。
  • 如使用MCP，需要先运行README中的npm run mcp:build。
  • 如使用本地接口，需要启用API并在Settings → API + MCP生成token。

第一步命令（README 原文）

npm run mcp:build

要注意

  • MCP客户端与桌面端共用同一API面，接口默认JSON不流式，需stream或text/event-stream才返回SSE。
    README的Local HTTP API + MCP Server章节明确说明chat接口的stream与SSE行为。
  • API的未认证访问由Settings → API + MCP控制，默认设计仍包含token-protected与127.0.0.1-only限制。
    README的Local HTTP API + MCP Server章节明确列出token-protected、127.0.0.1-only及未认证开关。
  • 大上下文配置范围是4K到1M tokens，且内容按60/20/5/15分配。
    README的17. Configurable Context Window章节给出4K到1M tokens和60/20/5/15 split。
  • Wiki索引可从已有页面重建，但外部更新页面也提供单页embed接口，处理方式不同。
    README列出Project Management & Migration的rebuild Wiki index，以及POST /api/v1/projects/{id}/pages/embed。

材料未说明

  • README材料未说明各LLM provider的完整兼容性、价格影响和认证方式。
  • README材料未说明PDF、Office、EPUB/MOBI等格式的解析准确率与最大文件规模。
  • README材料未说明本地MinerU运行所需的硬件、依赖版本和资源消耗。
  • README材料未说明4K到1M上下文窗口对应模型的实际可用范围。
  • README材料未说明10位贡献者、5个版本和10个最近提交分别对应的维护频率与发布计划。
  • README材料未提供Other许可证的具体条款，也未说明商业分发限制。
  • README材料未列出与本项目功能直接对比的替代方案。

💡 深度解析

6
适合 我已经在使用 Claude Code 或 Codex，希望 Agent 能调用 LLM Wiki 的 Wiki、来源和图谱检索，并把生成的 Markdown 或 HTML 放进工作区；这个项目能否直接接入，而不需要我自己重写一套 API 适配层？
适合读者： 使用 Claude Code 或 Codex 的自动化开发者，希望让 Agent 通过本地 MCP 或 Agent Skill 访问个人 Wiki、执行混合搜索并生成工作区文件。

适合，README 明确提供本地 HTTP API、MCP Server 和面向 Claude Code/Codex 的 Agent Skill，且这些能力覆盖你的调用和输出需求。

  • “Local HTTP API + MCP Server + AI Agent Skill”列出混合搜索、文件读取、图谱遍历和来源重扫，不需要把基础检索逻辑重新实现到客户端。
  • 同一章节给出内置 API 地址 127.0.0.1:19828，并说明 bundled MCP server 可用。
  • README 的“Rust Backend Chat Agent & Skills”说明 Agent 能调用 wiki/source/graph/web retrieval、workspace file tools 和 approved shell commands。
  • “Generated Outputs Preview”支持预览 Agent 创建的 Markdown、HTML、图片及其他工作区文件；外部 shell 命令仍要求明确批准。

因此它适合作为本地知识服务接入 Claude Code 或 Codex。但本地 API 默认面向本机，README 没有说明远程多用户访问、MCP 客户端兼容矩阵或 API 在异常退出后的恢复行为。

  • Local HTTP API + MCP Server + AI Agent Skill：built-in `127.0.0.1:19828` JSON API
  • Local HTTP API + MCP Server + AI Agent Skill：ready-made agent skill installs into Claude Code / Codex
  • Rust Backend Chat Agent & Skills：wiki/source/graph/web retrieval；workspace file tools；approved shell commands
  • Generated Outputs Preview：Agent-created Markdown, HTML, images, and other workspace files
npx skills add …
材料未说明：README 未列出 Claude Code、Codex 及其他 MCP 客户端的具体版本兼容性；未说明多个外部 Agent 同时访问同一项目时的并发和锁机制；未说明本地 Token 的生成、轮换和失效流程
不适合 我处理的技术资料会持续更新，回答必须尽量只依据已导入的原始材料；我希望同时使用 Chat、Read Sources Only、Review 和 Lint。这个项目能否替代需要严格事实准确性的权威知识库？
适合读者： 需要对技术资料回答保持证据约束的工程师，使用 Chat、Read Sources Only、Review 和 Lint 管理一个持续更新的 Wiki。

不适合把它直接当作权威知识库，但适合充当带来源追踪的资料理解和维护层；Read Sources Only 能收紧回答范围，却不能保证原始材料或模型解释绝对正确。

  • “Source-grounded Retrieval”提供 Read Sources Only，要求回答仅基于原始导入材料，适合减少无依据扩展。
  • “Async Review System”让 LLM 标记需要人工判断的项目，并提供预定义动作和预生成搜索查询；Quick Start 还要求检查 Review。
  • Quick Start 建议定期运行 Lint 维护 Wiki 健康，说明项目包含持续维护闭环，而不是只生成一次页面。
  • 项目洞察明确指出自动生成内容可能遗漏、误判或过时；来源追踪能回溯证据，但不能自动消除幻觉。资料分析还指出系统不保证专业、法律、医学或高风险技术内容的可靠结论。

因此，它适合检索、组织和发现资料，不适合作为唯一事实源、合规数据库或高风险决策依据。

  • Features：Source-grounded Retrieval — Read Sources Only mode
  • Features：Async Review System；Quick Start：Check Review；Run Lint periodically
  • 项目洞察：来源追踪不能自动消除模型误读、遗漏或幻觉
  • 项目洞察 usage_limitations：不能保证专业、法律、医学或高风险技术内容提供可靠结论
材料未说明：Review 项是否会阻止未经审核的页面进入 Chat 检索；Lint 的规则、错误等级和是否支持自定义校验；来源更新后旧 Wiki 页面、嵌入和图关系的最终一致性时间
适合 我需要把 PDF、DOCX 和递归目录一次性导入，并且导入期间可能中断；我还希望源文件在 `raw/sources/` 外部修改或删除时能同步处理。LLM Wiki 是否比一次性 RAG 工具更适合？
适合读者： 拥有大量 PDF、Office 文档和递归文件夹的个人知识库维护者，希望导入过程可取消、可重试，并能跟踪源文件外部变更。

适合，项目的持久化摄取队列、增量缓存和源目录监听正好覆盖中断恢复与持续同步，而不是每次提问时临时重建上下文。

  • “Persistent Ingest Queue”明确支持串行处理、崩溃恢复、取消、重试和进度显示，适合导入过程可能被打断的资料库。
  • “Folder Import”支持递归导入并保留目录结构，还会把文件夹上下文作为 LLM 分类提示。
  • “Source Folder Auto-Watch”监听 raw/sources/ 的外部变化，并同步 ingest/delete cleanup。
  • 项目总览和 “What is this?” 都强调知识被增量构建、持久保存和持续维护；另有完整项目归档与从既有页面重建 Wiki 索引的能力。

因此，如果目标是长期积累并维护 Wiki，它比一次性问答式 RAG 更匹配。不过 README 没有给出导入规模上限、单机性能、队列持久化文件位置，或复杂扫描 PDF 和 Office 版式的解析成功率。

  • Features：Persistent Ingest Queue — serial processing with crash recovery, cancel, retry, and progress visualization
  • Features：Folder Import；Source Folder Auto-Watch
  • Source Folder Auto-Watch：detects external changes in `raw/sources/` and keeps ingest/delete cleanup in sync
  • What is this?：incrementally builds and maintains a persistent wiki；Quick Start：Activity Panel、Review、Lint
材料未说明：单项目可支持的来源数量、文件大小和队列长度上限；扫描 PDF、复杂 Office 表格和多媒体文件的实际解析覆盖率；自动删除和级联清理在中断或重复事件下的精确行为
适合 我已经在使用 Tavily、SerpApi 或 SearXNG，希望从知识图谱发现的知识空白生成多查询 Web Research，并把搜索结果自动摄取回 Wiki；LLM Wiki 是否能覆盖这条闭环？
适合读者： 希望把本地 Wiki 与 Tavily、SerpApi 或 SearXNG 结合的研究型工程师，需要从知识空白出发自动开展 Web Research 并把结果回灌 Wiki。

适合，README 同时提供知识空白发现、Deep Research、多查询 Web Search 和结果自动摄取，能够覆盖你描述的闭环。

  • “Graph Insights”列出 surprising connections 和 knowledge gaps，并支持一键 Deep Research，入口来自持久化知识图谱。
  • “Deep Research”会生成面向 LLM 的搜索主题，通过 Tavily、SerpApi 或 SearXNG 执行多查询搜索。
  • 同一功能说明搜索结果会 auto-ingest into wiki，因此研究结果不只是当前对话上下文，而能成为后续检索对象。
  • “Rust Backend Chat Agent & Skills”还把 web search 作为 Agent 工具，与 wiki、source 和 graph retrieval 并列。

这适合需要外部资料扩展个人 Wiki 的研究工作流。但 README 没有说明搜索结果的去重、版权或质量过滤策略，也没有说明 Web Research 是否默认发送已有原文上下文给外部搜索服务；网络可用性和第三方 API 配额同样未定义。

  • Features：Graph Insights — surprising connections and knowledge gaps with one-click Deep Research
  • Features：Deep Research — Tavily, SerpApi, or SearXNG；auto-ingest results into wiki
  • Rust Backend Chat Agent & Skills：wiki/source/graph/web retrieval
  • 项目洞察：深度研究依赖外部搜索服务和网络可用性
材料未说明：Tavily、SerpApi 和 SearXNG 的配置字段、认证方式及配额处理；Web Research 结果是否有去重、来源可信度和版权过滤；搜索结果摄取失败后的重试、回滚和来源标记行为
适合 我的资料以图片丰富的 PDF 和技术文档为主；我不仅要搜索正文，还要让视觉模型描述嵌入图片，并能从搜索结果跳回原始页面。LLM Wiki 是否能满足这种多模态检索需求？
适合读者： 维护技术论文、工程文档和图片丰富的 PDF 集合的工程师，希望搜索图片内容并从 Wiki 页面回溯到原始来源。

适合，README 明确把 PDF 内嵌图片提取、视觉模型事实性描述、图片感知搜索和来源跳转放在同一条功能链路中。

  • “Multimodal Image Ingestion”说明系统会从 PDF 提取嵌入图片，并使用 vision LLM 生成 factual captions。
  • 同一条功能还列出 image-aware search results、lightbox preview 和 jump-to-source，与你要求的图片检索和原页回溯直接对应。
  • “Multi-format Document Parsing”同时覆盖 PDF、Office、EPUB/MOBI、图片和媒体文件，资料入口不局限于纯文本。
  • 项目洞察指出原始来源、Wiki 页面、嵌入向量和图关系会被持久化，且来源追踪支持查询阶段回溯证据。

但这不等于图片描述必然准确。README 没有说明支持哪些视觉模型、扫描 PDF 是否走同一流程、表格和图表的识别边界，也没有给出图片索引的存储成本或搜索排序细节。

  • Features：Multimodal Image Ingestion — extract embedded images from PDFs；vision LLM；image-aware search results；jump-to-source
  • Features：Multi-format Document Parsing
  • 项目洞察：LLM 生成事实性图片描述，并在搜索结果展示图片预览和来源跳转
  • 项目洞察：Wiki 内容、原始来源、嵌入向量、图关系和审核状态持久化
材料未说明：支持的具体 vision LLM、图像大小限制和费用模型；扫描 PDF、表格、图表和复杂版式是否能被可靠识别；图片描述是否会进入 LanceDB 或其他可持久化索引
视情况 我主要处理 PDF、Office 文档和本地目录，想在 macOS 或 Windows 桌面上持续维护个人知识库；如果部分资料需要本地处理、部分模型使用 OpenAI 兼容接口，LLM Wiki 是否适合我？
适合读者： 管理 PDF、Office 文档和本地目录的研究人员，希望在本地桌面环境中建立可持续更新的个人知识库，并尽量控制敏感资料的数据流向。

视情况，项目适合多格式、本地优先的个人知识库，但不能仅凭 README 断定所有内容都会留在本机。

  • README 的“Features”列出 PDF、Office、EPUB/MOBI、图片、媒体、网页剪藏和 URL 批量导入，并支持内置、云端或本地 MinerU PDF 处理。
  • “Flexible Model Configuration”允许按项目配置模型，并分别路由 Chat 与 Ingest；“Vector Semantic Search”支持 LanceDB 和 OpenAI 兼容嵌入接口。
  • “Quick Start”要求先配置 LLM provider、API key 和 model，说明外部模型服务可能是运行前置条件。
  • 项目提供来源追踪、Read Sources Only、项目归档导入导出，适合长期维护和回溯原始材料。

但 README 没有说明不同处理路径下哪些原文、图片或嵌入会发送给云端，也没有给出本地模型支持范围、加密方式或企业级权限控制。

  • Features：Multi-format Document Parsing；Flexible Model Configuration；Vector Semantic Search
  • Quick Start：Configure your LLM provider (API key + model)
  • Features：Source-grounded Retrieval；Project Management & Migration
  • 项目洞察：本地 HTTP API 默认绑定 127.0.0.1；数据可能流向不同模型或搜索提供商
材料未说明：本地 MinerU、Chat 模型和 Ingest 模型各自支持哪些具体模型及硬件要求；云端模型、嵌入服务和 Web Search 是否会接收原文、图片或元数据；项目归档和本地索引是否提供加密或访问控制

✨ 核心亮点

  • Two-Step Ingest先分析再建Wiki，保留来源追踪与增量缓存
  • 4-Signal图谱结合链接、来源重叠、Adamic-Adar与类型亲和度
  • 支持PDF、Office、EPUB/MOBI及MinerU本地解析
  • 内置127.0.0.1:19828 API、MCP与Claude Code接入

🔧 工程化

  • 桌面端将PDF、DOCX、Markdown等来源持续生成互链Wiki页面
  • Read Sources Only模式限定回答只使用原始导入材料
  • LanceDB提供可选向量检索，并支持OpenAI兼容端点
  • Rust Backend Chat Agent支持Wiki、图谱、网页检索与流式工具事件

⚠️ 风险

  • README要求在Settings配置LLM API key与model，未配置无法完成Quick Start
  • Deep Research依赖Tavily、SerpApi或SearXNG等Web Search提供商
  • 本地API虽仅监听127.0.0.1:19828，仍涉及token与未认证访问开关
  • 许可协议元数据为Other，README未提供具体许可条款

👥 适合谁？

  • 需要管理PDF、Office和网页资料的个人知识库用户
  • 使用Claude Code或Codex并需要本地MCP检索的开发者
  • 希望用Rust Agent生成Markdown、HTML或图片文件的用户
  • 需要4K到1M tokens可调上下文窗口的LLM应用试验者