每天一个开源项目#97 LLM Wiki：把RAG结果变成可维护知识资产

Trending 排名：#8｜快照日期：2026-09-12｜Stars：18,739｜今日新增：647｜Forks：2,134｜主语言：TypeScript｜License：GPL-3.0

把文档丢给 RAG，确实能问出答案；但下一次提问，系统往往还要重新检索、重新拼上下文、重新推导。LLM Wiki 走了另一条路：让模型先把资料"编译"为有目录、有来源、有交叉链接的 Markdown Wiki，之后查询面对的是一份持续演进的知识资产，而不是一袋每次临时召回的碎片。

这个差异听起来只像产品包装，源码里却对应着一整套工程约束：原始资料保持不可变，Wiki 页面带 sources[] 追踪来源；摄入拆成分析与生成两次调用；SHA-256 缓存和持久队列避免重复烧 token；检索把关键词、向量和图谱扩展串起来；桌面端再通过本地 HTTP API 与 MCP 把知识库开放给 Claude Code、Codex 等 Agent。

它也不是"RAG 已经过时"的证明。两条路线解决的问题不同：RAG 更适合频繁变化、按需读取的大语料；持久 Wiki 更适合需要人工审阅、长期积累和可编辑结构的个人知识。LLM Wiki 的代价是摄入更慢、更新会产生写放大，而且 LLM 写出的页面仍需审核。

📋 项目概览

项目	内容
项目名	nashsu/llm_wiki
一句话	将文档增量编译为可追溯、可编辑、Obsidian 兼容的持久知识库
GitHub	github.com/nashsu/llm_...
历史快照	2026-09-12 Trending #8，18,739 Stars、2,134 Forks、今日 +647
后续 API 核验	2026-09-14 10:35 CST：19,355 Stars、2,192 Forks
语言	TypeScript 为主，Rust 后端；另含 JavaScript/Python/CSS
License	GPL-3.0；GitHub API 当时未正确识别，但仓库 `LICENSE` 明确是 GNU GPL v3
当前版本	v0.6.11，发布于 2026-08-25
默认分支	main
审计提交	`e8082119649e6a8e1cf85eaf289adcabfdf39d4e`

🔥 为什么值得关注

传统 RAG 的主要产物是"一次回答"。检索到的片段如何组织、不同来源怎样合并、旧结论要不要更新，通常被留给下一轮 prompt。LLM Wiki 把主要产物改成文件：wiki/entities/、wiki/concepts/、wiki/synthesis/ 等目录里的 Markdown 页面，以及 index.md、overview.md、log.md 这些能被人和 Agent 共同读取的控制面。

这让知识第一次生成时更贵，却换来三个长期收益：结果可版本化，来源可追溯，结构可人工修订。尤其对个人研究、项目交接、读书笔记和代码库知识来说，"模型已经得出过什么结论"不再只藏在聊天历史或向量库里。

项目的难点不在三栏 UI，而在维持一致性。导入一个来源可能同时修改摘要页、实体页、概念页、索引、全局概览和日志；失败时不能留下一半新、一半旧的 Wiki。源码因此有摄入提交协调器、持久队列、文件监听、缓存迁移、冲突清理和大量场景测试。这也是它比"把几段 prompt 包进桌面壳"更值得读的原因。

🏗️ 核心特性

1. 三层文件系统把知识所有权留给用户

项目沿用 Karpathy LLM Wiki 方法里的三层结构：不可变资料、模型维护的 Wiki、约束结构的 Schema，同时增加 purpose.md 表达"为什么建这份库"。

text 复制代码

my-wiki/
├── purpose.md              # 研究目标、关键问题与范围
├── schema.md               # 页面类型、目录和生成规则
├── raw/
│   ├── sources/            # 原始文档，摄入后仍保留
│   └── assets/             # 提取图片等资产
├── wiki/
│   ├── index.md            # 内容目录与 Agent 导航入口
│   ├── overview.md         # 全局摘要
│   ├── log.md              # 可解析的操作历史
│   ├── entities/
│   ├── concepts/
│   ├── sources/
│   ├── synthesis/
│   └── comparisons/
└── .llm-wiki/              # 队列、配置、聊天与审核状态

Wiki 页面使用 YAML frontmatter 的 sources: [] 指回原始文件，正文用 [[wikilink]] 建立关系。结果仍是普通 Markdown，整个目录也能作为 Obsidian Vault 打开，不依赖专有数据库才能读取。

2. 摄入不是一次总结，而是两阶段写入

src/lib/ingest.ts 是前端侧最大的运行时文件之一，负责把解析、模型调用、页面计划、写入和后处理连起来。README 对两次调用的分工描述得很清楚：

text 复制代码

源文件
  -> 解析文本、图片与元数据
  -> 第一次 LLM：分析实体、概念、矛盾、已有 Wiki 关系
  -> 形成结构化分析结果
  -> 第二次 LLM：生成或更新具体 Wiki 文件
  -> 提交 index / overview / log / 页面
  -> 更新缓存、Embedding 与审核队列

第一步不急着写页面，先识别"应该写什么"；第二步再基于已有目录和分析结果生成文件。这会多付一次调用成本，但能把内容理解与文件操作拆开，减少模型一边推理一边随意改结构的问题。

src/lib/ingest-cache.ts 使用内容哈希跳过未变化来源；src/lib/ingest-queue.ts 负责串行队列、重试和重启恢复；src/lib/ingest-commit-coordinator.ts 集中协调一次摄入产生的多文件提交。对应测试覆盖队列恢复、路径碰撞、sanitize、prompt、推理结果解析和提交冲突。

3. 检索是关键词、向量与图谱三段式

项目没有因为生成了 Wiki 就放弃检索。src/lib/search.ts 先做词法搜索，英文过滤停用词，中文使用 CJK 二元组，标题匹配额外加权；可选向量检索通过 OpenAI 兼容 Embedding API 生成向量，Rust 端用 LanceDB 保存；随后以命中页面为种子做图谱扩展。

text 复制代码

query
  ├─ 词法通道：wiki + raw/sources，标题加权
  ├─ 向量通道：Embedding -> LanceDB ANN
  └─ 融合结果
         -> 图谱 2 跳扩展
         -> 按相关度衰减
         -> 组织最终上下文与引用

图谱相关度不是只数双链。README 给出的四个信号是：直接链接 ×3、共同来源 ×4、Adamic-Adar ×1.5、页面类型亲和 ×1。src/lib/graph-relevance.ts、wiki-graph-analysis.ts 和 graph-insights.ts 分别处理相关度、社区与洞察。UI 使用 graphology、Louvain 与 ForceAtlas2 展示社区、桥接节点和稀疏区域。

4. Tauri/Rust 后端承担能力边界

React/TypeScript 负责知识工作流与界面，Rust 后端承担本地文件、向量存储、HTTP 服务和 Agent 运行时。关键实现包括：

模块	职责
`src-tauri/src/commands/fs.rs`	项目文件读写、路径和权限边界
`src-tauri/src/commands/search.rs`	本地检索命令
`src-tauri/src/commands/vectorstore.rs`	LanceDB 向量索引
`src-tauri/src/api_server.rs`	本地 JSON API
`src-tauri/src/agent/runtime.rs`	聊天 Agent 的工具循环与流式事件
`src-tauri/src/agent/tools.rs`	Wiki、Source、Graph、Web、workspace、shell 等工具
`src-tauri/src/agent/provider.rs`	模型 Provider 适配

本地 API 默认使用 127.0.0.1:19828。源码还区分 loopback 与 LAN：局域网客户端要携带同一个 API token，避免公开项目路径和写入接口。shell 工具带审批而不是默认静默执行，这一点对"知识库 + Agent"组合尤其重要。

5. MCP 把桌面知识库变成 Agent 工具

仓库的 mcp-server/ 是独立 Node 包。它不复制知识库，而是把 MCP 调用转换为本地 API 请求，暴露项目、搜索、页面、图谱、审核和聊天等能力。这样桌面程序保持数据与索引的单一事实源，外部 Agent 只拿到受控接口。

本次实际运行 npm run mcp:test：先完成 TypeScript 构建，再执行 Node TAP 测试，结果 22 pass、0 fail。覆盖 bearer token、search 请求体、跨项目 pin、防止越界 override、API 错误转换和版本读取。

🔬 技术架构深度解析

从原始资料到可持续知识

text 复制代码

PDF / Office / EPUB / 网页 / 音视频 / 文件夹
             │
             ▼
      解析与多模态提取
  pdfjs / Office parser / OCR / vision
             │
             ▼
      持久摄入队列
  hash 去重 -> 串行 -> 重试 -> 恢复
             │
             ▼
       两阶段 LLM
   分析已有知识 -> 规划页面 -> 生成补丁
             │
             ▼
      多文件原子式提交
 source summary / entity / concept
 index / overview / log / review
             │
             ├── Markdown + YAML + wikilink
             ├── LanceDB embedding
             └── 图谱、社区与知识空白

这里最值得借鉴的是"模型输出不是最终答案，而是受 Schema 约束的增量补丁"。purpose.md 提供任务方向，schema.md 提供结构规则，已有 Wiki 提供当前状态，原始资料提供证据。模型的自由度被夹在四层上下文之间。

一致性和写放大

持久知识的代价是一次摄入可能触及多个文件。假设一份资料贡献了两个实体、一个概念和一个跨来源结论，那么系统至少可能写摘要页、三类知识页、目录、概览和日志。相比把一个 chunk 写进向量库，它有明显写放大。

项目用三种办法控制风险：

内容哈希避免相同资料重复摄入；
队列串行化，避免两个任务同时重写 index.md；
提交协调器将多文件变更按一个摄入事务管理。

但它仍不等于数据库事务。用户在应用外直接编辑文件、同步盘制造冲突、模型生成不合法 frontmatter，都需要清理与恢复逻辑。选择这套架构时，应该把"人类可编辑"视为收益，也视为并发输入源。

源码规模

我用 git ls-files -z 获取 tracked 清单，再由 Python 逐文件统计，避免 shell 分词和输出截断：

指标	数值
tracked files	465
生产代码/配置/文档类文件	289 个，116,598 物理行
测试文件	145 个，33,201 物理行
TypeScript	293 文件，67,696 行
TSX	61 文件，23,144 行
Rust	41 文件，33,853 行
`src/lib`	231 文件，57,188 行
`src-tauri/src`	40 文件，33,847 行
`mcp-server`	11 文件，2,765 行

最大运行时文件是 src-tauri/src/agent/runtime.rs（5,775 行），其次是 agent/tools.rs（3,722 行）、src/lib/ingest.ts（3,529 行）和 api_server.rs（3,472 行）。这说明复杂度已经集中到 Agent 运行时、工具面与摄入主链，后续维护最需要继续拆边界。

本地验证

审计提交上执行了以下确定性验证：

bash 复制代码

npm ci
npm run typecheck
npm run test:mocks
npm --prefix mcp-server ci
npm run mcp:test
npm run build

结果：

npm ci 安装 820 个 package 成功；npm audit 同时报出 21 个依赖漏洞（3 low、8 moderate、10 high），这是需要升级或逐项确认的供应链风险；
TypeScript typecheck 退出码 0；
mock 测试 132 个文件、1,876 个测试全部通过；
MCP 测试 22 pass、0 fail；
Vite 生产构建完成，转换 4,242 个模块；
构建警告指出主 JS chunk 约 1.34 MB，并有几个动态导入同时被静态引用，代码分割尚有优化空间；
没有运行 test:llm，因为它调用真实模型，结果会依赖外部凭据、Provider 与网络，不能当成确定性验证。

📖 README 核心内容摘要

README 的核心判断是：知识应该"编译一次并持续维护"，而不是每次查询都重新推导。它保留 Karpathy 方法里的 Ingest、Query、Lint 三个操作，再扩展成完整桌面产品。

支持的输入覆盖 PDF、Office、EPUB/MOBI、Org mode、图片、音视频、网页剪藏、URL 与文件夹。PDF 可以使用内置解析，也可接云端或本地 MinerU；图片可交给视觉模型生成事实描述。能力很全，但不同格式最终质量仍取决于解析器和模型，特别是扫描 PDF、复杂表格与音视频不能因为"支持导入"就默认高保真。

模型配置允许 Chat 与 Ingest 分开路由，并支持自定义 OpenAI 兼容 Provider、请求头和流式输出。这个设计很实用：摄入需要长上下文和结构化生成，聊天更在意延迟与成本，不必强迫两条链使用同一模型。

🚀 快速上手

对普通用户，最简单的方式是从 Release 下载 v0.6.11 桌面包。若要审计或二次开发：

bash 复制代码

git clone https://github.com/nashsu/llm_wiki.git
cd llm_wiki
npm ci
npm run dev

先创建项目并配置 purpose.md、schema.md，再导入资料。建议从一个主题清晰的小目录开始，不要第一次就把整个硬盘扔进去；先检查页面类型、来源路径与语言是否符合预期，再扩大规模。

如需让 Agent 访问，启动桌面应用提供的本地 API，然后构建 MCP server：

bash 复制代码

npm --prefix mcp-server ci
npm run mcp:build

公开到局域网前要配置 API token，并确认防火墙、项目目录权限和 shell 审批策略。默认 loopback 是更稳妥的部署边界。

📊 增长速度与社区热度

Star 增长

2026-09-12 公开历史快照记录 18,739 Stars、今日 +647，新增量约占快照总量的 3.45%。两天后的 GitHub API 核验为 19,355 Stars，比历史快照高 616；这个差值跨越了不同采样时刻，不能反推为某一天的"今日新增"。

快照 Forks 为 2,134，约为 Stars 的 11.39%。9 月 14 日 API 核验为 2,192。当前仓库有 176 个 open issues、87 个 open PRs；热度带来了反馈，也形成了不小的维护队列。

贡献者 API 前十中，维护者 nashsu 有 731 次贡献，之后是 22、20、9 次等，贡献集中度较高。项目当前可用，但关键架构与发布节奏仍明显依赖主维护者。

本机当天的定时任务在抓取前因脚本导入错误失败，没有留下可用榜单。下表采用 SegmentFault 在目标日期发布的历史快照，共保留 16 项；排名、总 Stars、Forks 与"今日新增"都只按该页面记录，不用 9 月 13 日或 9 月 14 日数据回填。原页面后六项未展示 Forks，因此保留为"---"。

Rank	Repository	Language	Stars	Forks	今日新增 Stars
1	ayghri/i-have-adhd	Python	41,838	2,367	3,463
2	bilawalsidhu/gods-eye-view	JavaScript	27,120	5,553	3,680
3	nab138/iloader	TypeScript	2,908	203	50
4	melgarafael/DeskcommCRM	TypeScript	1,346	496	152
5	vastsa/PI-Desktop	TypeScript	2,778	217	552
6	armory3d/armorpaint	C	4,721	533	350
7	alsk1992/CloddsBot	TypeScript	2,153	282	626
8	nashsu/llm_wiki	TypeScript	18,739	2,134	647
9	obra/superpowers	Shell	285,380	25,521	729
10	Sonarr/Sonarr	C#	15,736	1,949	191
11	jihe520/MathModelAgent	Python	4,858	---	129
12	p1neappleXpress/OpenFlux	Go	1,148	---	198
13	jordan-gibbs/hyperresearch	Python	2,615	---	153
14	alphaXiv/OpenResearch	Rust	1,277	---	120
15	github/spec-kit	Python	135,770	---	1,015
16	pascalorg/editor	TypeScript	23,602	---	106

数据来源：

目标日历史快照：segmentfault.com/a/119000004...
仓库与源码：github.com/nashsu/llm_...
后续 API 核验：api.github.com/repos/nashs...
Release：github.com/nashsu/llm_...

🎯 适用场景

场景	适合程度	原因
个人研究与读书知识库	高	Markdown、来源追踪、Obsidian 兼容，适合长期整理
多轮项目调研与交接	高	结论写回 Wiki，后续 Agent 不必从零恢复背景
私有文档的本地管理	中到高	数据目录在本机，但模型与搜索 Provider 可能把内容发往外部
高频变化的大型企业语料	中	持久页面的写放大和冲突治理比纯检索更重
强审计、零幻觉知识库	低到中	有来源字段不等于每句话都自动逐句引用，仍需审核
临时问一个 PDF	低	直接 RAG 或长上下文通常更快，没必要先建完整 Wiki
Agent 的长期项目记忆	高	本地 API、MCP、Skill 与普通文件系统都便于接入

💡 总结

LLM Wiki 真正有价值的不是"再做一个知识库"，而是把 LLM 产生的中间知识从聊天缓存提升为一等资产：有文件、有目录、有来源、有关系，也允许人直接修改。它用两阶段摄入、持久队列和提交协调器，为这种资产化付出了工程成本。

如果资料只是临时问答，传统 RAG 更省事；如果知识需要积累数月、反复修订并交给多个 Agent 使用，持久 Wiki 会逐渐显出复利。部署时要重点检查真实模型调用的数据边界、GPL-3.0 义务、依赖漏洞、主维护者集中度，以及摄入生成内容的人工审核流程。

每天一个开源项目#97 LLM Wiki：把RAG结果变成可维护知识资产

📋 项目概览

🔥 为什么值得关注

🏗️ 核心特性

1. 三层文件系统把知识所有权留给用户

2. 摄入不是一次总结，而是两阶段写入

3. 检索是关键词、向量与图谱三段式

4. Tauri/Rust 后端承担能力边界

5. MCP 把桌面知识库变成 Agent 工具

🔬 技术架构深度解析

从原始资料到可持续知识

一致性和写放大

源码规模

本地验证

📖 README 核心内容摘要

🚀 快速上手

📊 增长速度与社区热度

Star 增长

2026-09-12 GitHub Trending 完整榜单

🎯 适用场景

💡 总结