Jean's Blog

一个专注软件测试开发技术的个人博客

0%

基于 LLM-Wiki 与 Obsidian 构建个人本地知识库

发表于 更新于 分类于
LLM-Wiki、Obsidian 与 AI Agent 本地知识库方案：架构、安装、目录结构与协作流程。

为什么需要 AI 本地知识库

在日常办公与团队协作中，大量工作信息分散在不同渠道：项目文档和业务规范保存在本地文件夹或网盘中，会议记录散落在各类文档里，临时需求、沟通结论和实践经验则沉淀在聊天软件、邮件与浏览器收藏中。由于缺少统一的归集和管理方式，资料越积越多，信息查找、经验传承和内容维护也会变得越来越困难。

常见问题主要体现在以下四个方面。

1. 信息零散混乱，查找效率低

大量工作资料缺少统一的命名、分类和关联规则。当需要查阅历史方案、业务流程或过往经验时，往往要在多个平台之间切换，再逐层翻找文件夹和聊天记录。信息明明存在，却很难快速定位，最终导致大量时间消耗在“找资料”上。

2. 信息留存不完整，关键经验持续流失

日常工作中的临时沟通结论、操作技巧和踩坑经验，通常没有及时整理成正式文档。随着时间推移或人员流动，这些隐性知识容易出现断层，团队不得不重复踩坑、重复验证，宝贵经验也难以持续复用。

3. 内容迭代缺少追溯，新旧信息容易混淆

业务规则、项目方案和流程规范会持续更新，但传统归档方式往往只能保留多个名称相近的文件，无法清晰说明内容为什么修改、修改了什么，以及当前应该使用哪个版本。新旧资料混杂后，容易造成旧规则误用、理解不一致和协作对接错误。

4. 传统归档偏重文件存储，缺少知识组织能力

文件夹分类和手动归档解决的是“文件放在哪里”，却很难进一步回答“哪些内容彼此相关”“某项结论来自哪里”“当前资料与历史方案有什么变化”。它可以保存原始文件，但通常不具备自动整理、内容关联、语义检索和知识更新能力，因此很难应对高频、复杂的现代办公场景。

大模型为这些问题提供了一种新的处理方式。借助文档解析、语义理解、智能检索和知识提炼等能力，本地知识库可以统一收纳分散的工作资料，并将碎片化内容逐步整理成可留存、可检索、可追溯、可迭代、可复用的知识体系。它不仅帮助个人减少查找和重复整理的时间，也有助于团队积累业务知识、保留实践经验并提高协作效率。

需要注意的是，AI 知识库并不会自动保证资料正确或版本有效。要让这套体系长期可靠，仍然需要明确资料来源、访问权限、写入边界和人工审核流程。

围绕这些目标，RAG 几乎已经成为 AI Agent 构建私有知识库时的常见方案，但真正上手后会发现，一套完整 RAG 的搭建远没有 Demo 看起来那么轻松。

如果要搭建包含多模态解析、重排和图谱扩展的完整链路，通常需要配置文本大模型、多模态模型、Embedding 模型和重排模型，并维护向量索引、业务数据甚至图数据库。同时还要处理文档解析、文本分块、向量化和多路检索调优等细节。组件越多，调试与后期维护成本通常越高。

更关键的一点是，朴素 RAG 通常在“提问时找资料”：每次提问时，从文档切分得到的文本块中检索片段，再交给模型生成答案。它擅长按需查找资料，但不会天然形成结构化知识，也不会自动维护实体、概念和文档之间的关系。新增资料、冲突信息和过时内容，通常还需要额外的更新与审核机制。

有没有更轻量化、更偏向“知识积累”的方案？

Andrej Karpathy 提出的 LLM Wiki pattern 带来新的启发：不再只把大模型当作“问答工具”，而是让它参与知识的预处理和组织。在导入资料时，系统可以先完成信息提炼，尝试整理词条、建立文档之间的关联，再生成一套互相链接、可以持续更新的 Markdown 维基知识库。知识在导入阶段就开始沉淀，更贴合个人日常资料管理的诉求。

开源项目 llm_wiki 借鉴并扩展了这套设计，用于构建本地知识库，并支持多种文档格式、图片描述生成和向量检索等能力。本文先介绍它与 Obsidian 的定位、架构和基本安装方式；具体实操放在后续文章中。

LLM-Wiki

项目介绍

维度 详情
GitHub nashsu/llm_wiki
Stars 17,334
Forks 2,047
许可证 GPL v3.0
创建时间 2026-04-08
创始人 nash_su
理论基础 Karpathy’s LLM Wiki pattern
语言 TypeScript（主前端）+ Rust（后端）+ Python（脚本）
框架 Tauri v2（桌面壳）+ React + Vite + Tailwind CSS
定位 跨平台桌面端个人知识库，面向 Wiki 的自动构建与维护
主要能力 两阶段知识摄入（分析→生成）+ 4 信号知识图谱 + Louvain 社区检测
提交数 856 commits
贡献者 10+

项目数据是本文记录时的快照（2026 年 9 月 8 日）；Stars、Forks、提交数及文件结构会随项目发展变化，发布前请以仓库页面和当前 Release 为准。

与 Andrej Karpathy 原始模式的关系

LLM Wiki 是 Karpathy 于 2026 年 4 月提出的一种抽象设计模式，相关说明发布在一个 Gist 文件中。开源项目 llm_wiki 是受该模式启发的实现，并结合桌面应用场景进行了扩展。Karpathy 的原始模式强调：

1
2
3
4
5
6
三类要素：Raw Sources（原始来源）、Wiki（LLM 生成知识）、Schema（规则与配置）
三个操作：Ingest（摄入）、Query（查询）、Lint（检查）
核心文件：index.md、log.md、CLAUDE.md（schema）
维基链接语法：[[wikilink]]
YAML frontmatter：每个 wiki 页面
角色分工：人类策展，LLM 维护

nashsu 的 llm_wiki 在此基础上加入了桌面客户端、文档摄入、检索和知识图谱等能力。

核心架构

整体架构图

LLM-Wiki 整体架构图

LLM-Wiki 采用分层、本地优先的架构设计。整套系统从交互界面、应用逻辑、后端服务、本地存储到外部扩展能力逐层协作，兼顾可视化操作与知识检索、提炼和关联分析。

1. 桌面应用层：可视化交互界面（Tauri + React）

LLM-Wiki 基于 Tauri + React 搭建桌面客户端，无需单独部署 Web 服务即可运行。整体界面采用三栏布局，搭配功能侧边栏，覆盖知识库的常用操作：

  • 左侧知识树/文件树：统一管理所有本地文档、知识库词条、资源文件，支持层级查看与快速定位。
  • 中间对话面板（Chat）：提供 AI 问答、知识咨询、内容创作、问题推理等核心交互能力。
  • 右侧预览面板（Preview）：实时渲染 Wiki 词条、Markdown 文档、解析后的结构化内容。
  • 多功能侧边栏：集成 Wiki 主页、资源溯源、全文检索、知识图谱、内容审查、深度研究和系统设置等功能，集中完成知识库的维护与使用。

2. 应用逻辑层：核心能力调度引擎（TypeScript）

应用逻辑层不只是页面展示，还承载文档处理、检索调度、图谱计算和内容审查等核心流程：

文档摄入引擎

负责文档导入、预处理与增量更新，包含任务队列、文件 SHA-256 哈希缓存、两阶段知识摄入和原始素材溯源等机制，用于减少重复处理并提高内容可追溯性。这里的两阶段流程可以理解为“内容分析 → Wiki 生成”，不等同于模型输出 Chain-of-Thought。

智能检索管道

支持将关键词匹配、向量语义检索和知识图谱关联扩展组合成混合检索体系，并通过检索预算控制在召回范围和响应速度之间做取舍。

知识图谱引擎

这是 LLM-Wiki 区别于单纯文本块检索的一项重要能力。系统基于 4 信号模型和 Louvain 社区检测算法，尝试挖掘文档间的关联关系、聚合知识社区并生成全局洞察，让零散文档更容易被组织和导航。

内容 Review 审查系统

支持异步内容审查、人工复核和预定义修正规则，用于识别疑似冲突、过时信息和结构问题，并生成待复核的修订建议。它可以辅助质量治理，但不能替代人工事实核查。

3. 后端服务层：底层能力支撑（Rust）

后端采用 Rust 语言构建，承担模型调用、文档解析、向量存储和接口服务等底层能力：

  • Chat Agent 智能代理：支持工具调用、流式问答输出、自定义技能加载和 Shell 安全审批，可执行知识查询与自动化处理任务。
  • 多格式文档解析引擎：支持 PDF、DOCX、PPTX、EPUB、MOBI、Org mode 等多种格式，并提供图片解析与图文内容提取能力。具体格式支持情况以当前版本文档为准。
  • LanceDB 向量存储：本地轻量化向量数据库，用于保存向量、建立索引并执行相似度检索。向量由配置的 Embedding 模型或兼容 API 生成。
  • HTTP API 与 MCP 服务：提供外部工具和 Agent 程序调用本地知识库的接口，并支持 Token 鉴权。端口和接口以当前版本配置为准。

4. 本地存储层：结构化的文件体系

LLM-Wiki 以本地文件系统作为知识内容的主要存储方式，原始资料和生成的 Wiki 页面都可以直接查看、编辑、迁移和备份。同时，系统仍可能使用 LanceDB 保存向量索引，并使用应用目录保存聊天历史、缓存和审查状态：

  • 核心配置文件：purpose.md 定义知识库目标与研究范围，schema.md 统一 Wiki 结构规范，约束知识生成规则。
  • raw 原始资源目录：保存上传的原始文档和本地图片素材，便于知识溯源和后续重新处理。
  • wiki 结构化知识目录：系统自动生成并持续迭代，包含全局目录、操作日志、全局摘要、实体词条、概念词条、来源摘要、问答记录、跨源分析、内容对比等结构化知识体系，实现知识从碎片化到体系化的沉淀。
  • 配置缓存目录：兼容 Obsidian 知识库格式，保存应用配置、聊天历史、内容审查记录，支持环境迁移与数据备份。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
my-wiki/
 ├── purpose.md          ← 目标、关键问题、研究范围
 ├── schema.md           ← Wiki 结构规则、页面类型
 ├── raw/
 │   ├── sources/        ← 上传的原始文档（不可变）
 │   └── assets/         ← 本地图片
 ├── wiki/
 │   ├── index.md        ← 内容目录（LLM 入口）
 │   ├── log.md          ← 操作日志（可解析格式）
 │   ├── overview.md     ← 全局摘要（自动更新）
 │   ├── entities/       ← 人物、组织、产品
 │   ├── concepts/       ← 理论、方法、技术
 │   ├── sources/        ← 来源摘要
 │   ├── queries/        ← 保存的问答 + 研究
 │   ├── synthesis/      ← 跨源分析
 │   └── comparisons/    ← 并排比较
 ├── .obsidian/          ← Obsidian vault 配置（自动生成）
 └── .llm-wiki/          ← 应用配置、聊天历史、Review 项

5. 外部扩展能力：扩展知识采集与调用

LLM-Wiki 还可以通过外部工具扩展知识采集和调用能力：

  • Chrome 网页剪藏插件：抓取网页内容，将 HTML 转换为 Markdown 后导入知识库，简化网页资料的收集流程。
  • MCP Server 服务：对外提供混合搜索、文件读取和知识图谱遍历能力，使第三方 AI 程序可以调用本地知识库。
  • Agent 技能体系：适配 Claude Code、Codex 等 AI 编程或推理 Agent，使本地知识库可以作为 Agent 的私有知识来源。

三层架构详解

LLM-Wiki 三层知识架构

LLM-Wiki 可以理解为一个由原始资料、结构化知识和规则配置组成的知识系统。它的核心思想不是让 LLM 直接修改原始资料，而是保留原始信息，同时让 LLM 在规则约束下持续构建和维护 Wiki。

第一层是 Raw Sources（原始来源层）。
这一层保存未经修改的原始资料，例如用户上传的 PDF、DOCX、Markdown，浏览器通过 Web Clipper 捕获的网页，以及研究过程产生的资料等。它的核心原则是尽量保持原始来源不变：原始资料不直接被 LLM 改写，方便后续重新分析和追溯。

第二层是 Wiki（知识层）。
LLM 根据第一层的原始资料进行理解、提取、总结和关联，并生成结构化的 Markdown 知识。这里包括 entities/、concepts/、sources/、queries/、synthesis/、comparisons/ 等内容。其中，index.md 用于描述当前 Wiki 的整体内容，overview.md 提供全局摘要，log.md 记录知识库的演进过程。这一层主要由 LLM 生成和维护，人类负责最终策展和审核。

第三层是 Schema（规则与配置层）。
这一层决定 LLM 应该如何构建和维护 Wiki。其中 purpose.md 定义知识库的目标、研究范围和需要回答的核心问题；schema.md 定义页面类型、命名规范、Frontmatter、目录结构以及知识更新流程。也就是说，Schema 不是知识本身，而是知识库的规则和操作规范。人类定义规则，LLM 按照规则执行。

严格来说，Schema 更像是作用于整个知识处理流程的控制层，而不是位于 Wiki 之后的线性数据层：

Schema 定义规则 → Raw Sources 提供资料 → LLM 进行理解和整理 → 生成或更新 Wiki → 人类策展和审核。

因此，LLM-Wiki 的核心并不是简单地“让 LLM 总结文档”，而是尝试建立一个原始资料可追溯、知识可以持续演化、结构由规则控制的本地知识系统。

可以用一句话概括：

Raw Sources 保留原始资料，Wiki 承载生成的知识，Schema 负责约束知识的组织和更新。

这也是 LLM-Wiki 与单纯“文档 + 文本块检索”方案的一个重要区别：它试图把一次性的文档问答，进一步变成一个能够持续积累、组织和演化的知识库。它更适合作为 RAG 的补充，而不是对所有 RAG 方案的替代。

安装

平台 要求
macOS 11.0+ (Apple Silicon / Intel)
Windows 10/11 (x64)
Linux 主流发行版 (x64)

方式一：下载预编译版本（推荐）

从 GitHub Releases 下载对应平台的安装包：

以下文件名和安装方式可能随版本变化，发布前请以当前 Release 页面和项目 README 为准。

  • macOS: .dmg
  • Windows: .msi 或 .exe
  • Linux: .AppImage 或 .deb

方式二：从源码构建

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 1. 克隆仓库
git clone https://github.com/nashsu/llm_wiki.git
cd llm_wiki

# 2. 安装依赖
npm install

# 3. 构建 MCP 服务器
npm run mcp:build

# 4. 开发模式运行
npm run tauri dev

# 5. 生产构建
npm run tauri build

初始配置

  1. 启动应用后，创建新项目或选择场景模板
  2. 配置 LLM：
    • Settings → Model → 配置 Chat 模型和 Ingest 模型
    • 支持 OpenAI 兼容 API、自定义 Provider、自定义 Headers
  3. （可选）配置向量搜索：
    • Settings → Search → 启用 Vector Search
    • 配置 Embedding 端点（支持 OpenAI 兼容）
  4. （可选）配置 Web 搜索：
    • Settings → Web Search → 配置 Tavily / SerpApi / SearXNG

数据隐私提示

“本地知识库”主要表示知识库目录和生成的 Markdown 文件保存在本地，并不代表模型推理一定在本机完成。如果配置的是云端 LLM、Embedding、重排或 Web Search 服务，相关文档内容或查询内容可能会发送给第三方服务。导入敏感资料前，应确认模型 Provider 的数据使用政策、日志策略和服务端部署位置。

Obsidian

Obsidian 官方网站

从官网下载对应平台的安装包，按提示完成安装即可。

Obsidian 知识库界面

介绍

Obsidian 是一个本地优先的 Markdown 知识工作台。

Obsidian 的核心功能是以 Markdown 文件的形式保存、组织、连接和可视化知识。它本身不提供完整的 AI 知识库或 RAG 流程，但可以通过社区插件或外部 AI 工具扩展能力。

核心能力包括：

  • Markdown：本地文件存储
  • WikiLink：建立知识之间的关联
  • Backlinks：查看反向引用
  • Graph View：可视化知识关系
  • Properties：结构化管理知识
  • Search：快速检索知识

Obsidian 的核心概念

Obsidian 可以理解为由 Vault、Note、WikiLink、Properties、Backlinks、Graph 等几个核心概念组成。

概念 简单理解 作用
Vault 知识库容器 一个本地文件夹，存放整个知识库
Note 知识节点 一篇 Markdown 文件，就是一个知识单元
WikiLink 知识连接 用 [[xxx]] 把不同 Note 连接起来
Backlinks 反向链接 查看“哪些知识引用了当前知识”
Properties 知识属性 给 Note 增加类型、标签、日期等结构化信息
Graph View 知识地图 将 Note 和 WikiLink 可视化成知识网络
Canvas 知识画布 在无限画布上组织 Note、图片、网页等内容

最核心的关系

1
2
3
4
5
6
7
8
9
10
11
Vault
  │
  ├── Note ────── Note
  │    │            │
  │    └── WikiLink ─┘
  │
  ├── Properties
  │
  ├── Backlinks
  │
  └── Graph View

其中最重要的是：

Note 是知识节点，WikiLink 是知识关系，Vault 是知识空间，Graph View 是知识网络的可视化。

所以 Obsidian 的核心思想并不是简单地“存文件”，而是：

Markdown 文件 + WikiLink + Backlinks → 构建可连接、可导航、可持续演化的知识网络。

最重要的一个概念：Vault

Obsidian 里面最核心的概念叫 Vault（知识库目录）。它并不是一个特殊数据库，也不是 Git 仓库。

实际上就是：

1
2
3
4
5
一个本地文件夹
        ↓
Obsidian Vault
        ↓
Markdown + 图片 + PDF + 配置 + 其他文件

例如：

1
2
3
4
5
6
7
8
9
AI-Knowledge/
│
├── .obsidian/
│
├── 00-Inbox/
├── 10-Projects/
├── 20-Knowledge/
├── 30-Sources/
└── 90-Index/

Vault 本质上是本地文件系统中的文件夹，Obsidian 将笔记以 Markdown 文件保存其中；外部文件管理器和其他编辑器也可以直接操作这些文件。

对于本文的本地知识库方案，可以简单理解为：

1
2
3
4
5
6
7
8
          同一个 Markdown Vault
                  │
    ┌─────────────┼─────────────┐
    ↓             ↓             ↓
Obsidian       LLM-Wiki      Codex
    │             │             │
 阅读/编辑      AI 生成       AI 处理
 连接/导航      整理知识      自动化

前提是将 LLM-Wiki 实际生成 Wiki 的目录作为 Obsidian Vault 打开，并确保 Obsidian、LLM-Wiki 和 Codex 指向同一个本地目录。满足这个前提时，它们不是三个知识库，而是三个不同角色共同操作同一份 Markdown 知识。

为了避免文件覆盖或内容冲突，批量导入和生成 Wiki 期间，尽量不要同时手工编辑同一批文件；重要目录建议使用 Git、Time Machine 或其他方式定期备份。

文档处理流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
原始资料
PDF / DOCX / Web / Markdown
        ↓
原始资料归档
        ↓
AI 知识处理
LLM-Wiki / Claude Code / Codex
        ↓
Markdown 知识库
        ↓
Obsidian
阅读 · 编辑 · 连接 · 可视化
        ↓
人工审核与持续维护

构建本地知识库时，可以简单理解为：

LLM-Wiki 负责“理解和构建知识”，Obsidian 负责“管理和使用知识”。

组合成一套本地知识库工作流

综合前面的内容，可以将 LLM-Wiki、Obsidian 与 AI Agent 组合成一套本地知识库工作流。三者并不是互相替代的产品，而是分别承担不同角色：

  • LLM-Wiki：负责摄入原始资料，提取实体、概念和关系，并生成结构化的 Markdown Wiki 页面。
  • Obsidian：负责人工阅读、编辑、链接、检索和可视化，是日常使用知识库的主要界面。
  • AI Agent：负责跨文档分析、批量整理、内容校验和自动化操作，可以按个人习惯选择 Claude Code、Codex、Hermes Agent 等工具。

LLM-Wiki、Obsidian 与 AI Agent 组成的本地知识库工作流

这套方案的关键不是绑定某一款 Agent，而是让所有工具在明确的权限和写入边界下使用同一份 Markdown 知识。LLM-Wiki 负责生成和更新，Obsidian 负责人工管理，AI Agent 则按需提供分析与自动化能力。

为了避免多个工具同时修改同一文件，建议明确各自的工作目录和写入规则，并为重要内容保留版本记录。后续实战文章将基于这套组合，演示从资料导入、Wiki 生成到 Obsidian 管理和 Agent 调用的完整流程。