LLM-Wiki：让知识像花园一样持续生长

发表于 2026-07-27 更新于 2026-07-30 分类于 geek 阅读次数：本文字数： 6.9k 阅读时长 ≈ 25 分钟

自从 Karpathy 提出 llm-wiki 这套理念，我就一直想自己动手搭一个 AI 知识库——用它记录笔记、学习知识，也试着让它指引生活。

几经拖延，最后先让 AI 帮我把 llm-wiki 的生态通盘调研了一遍。结果出乎意料地详实：llm-wiki 为什么出现、解决了什么问题，理念和社区如何发展，有哪些开源实现，又该怎么亲手创建一个——都讲清楚了。

整理成文，分享至此，供君参考。

先用一个比喻理解 llm-wiki

传统 RAG 像一个“临时资料员”：

1	你问问题 → 它去仓库里翻几箱资料 → 抽出几页 → 临时拼一个答案

llm-wiki 更像一个“长期图书管理员 + 研究助理”：

1
2
3

新资料进来 → 它读懂、归档、做索引、写摘要、加交叉引用、标注冲突
你问问题 → 它先查已经整理好的知识图谱 → 必要时再回原始资料核验
好答案 → 继续沉淀回知识库

一句话：

RAG 每次临时找资料；llm-wiki 平时就把资料整理成会复利的知识资产。

为什么需要 llm-wiki？

LLM 已经很会“读”，但它有几个现实问题：

问题	直观表现	后果
上下文会丢	新 session 不知道旧结论	重复解释、重复踩坑
检索是临时的	每次 query 都重新找片段	推理不能复利
资料没有结构	文档、网页、issue、PDF 堆在一起	很难回答全局问题
答案不沉淀	好答案只存在聊天窗口	下次还要重来
冲突不显式	A 文档和 B 文档矛盾但没人记录	知识库越来越不可信
旧事实不失效	过期结论继续被引用	agent 可能自信地说错

llm-wiki 试图解决的不是“怎么搜到更多资料”，而是：

怎么让 LLM 的每次阅读、问答、纠错和总结，都变成可复用、可审计、可维护的长期知识。

一张图看懂 llm-wiki



flowchart TD
    A[Raw Sources\n网页 / PDF / 代码 / issue / transcript] --> B[Ingest\n读取、理解、拆解]
    B --> C[Wiki Knowledge Layer\nMarkdown 页面 + wikilinks + citations]
    C --> D[Query\n基于 wiki 回答问题]
    D --> E{答案有长期价值吗?}
    E -- 是 --> C
    E -- 否 --> F[只返回答案]
    C --> G[Lint / Maintain\n查断链、无引用、冲突、陈旧事实]
    G --> C
    C --> H[Derived Indexes\n全文搜索 / 向量 / 图索引 / backlinks]
    H --> D

这张图的核心循环是：

1	资料进入 → 知识编译 → 问答复用 → 好答案回写 → 定期维护 → 知识继续变好

这就是“知识复利”。

三层架构：原始资料、知识层、操作手册



flowchart TB
    subgraph L1[第一层：Raw Sources 原始事实层]
        R1[网页快照]
        R2[PDF]
        R3[代码仓库]
        R4[会议记录]
        R5[issue / PR]
    end

    subgraph L2[第二层：Wiki 知识编译层]
        W1[概念页]
        W2[实体页]
        W3[决策页]
        W4[冲突页]
        W5[开放问题]
        W6[索引页]
    end

    subgraph L3[第三层：Schema / CLAUDE.md / AGENTS.md 操作手册层]
        S1[页面模板]
        S2[引用规则]
        S3[新建/合并规则]
        S4[Lint 规则]
        S5[审批规则]
    end

    L1 --> L2
    L3 --> L2

Raw Sources：像“证据柜”

这里保存原始资料，尽量不要改。

raw/
  web/
  pdf/
  code/
  transcripts/
  issues/

它的职责是：

保存事实来源；
让 wiki 中的 claim 可追溯；
当模型生成内容可疑时，可以回到原文核验。

Wiki：像“研究员写的知识图谱”

这里不是简单摘要堆，而是结构化知识：

wiki/
  index.md
  concepts/
  entities/
  decisions/
  practices/
  conflicts.md
  open-questions.md

它的职责是：

把资料整理成概念；
把概念互相连接；
记录引用；
标注冲突；
支持后续问答。

Schema / Instructions：像“图书馆馆规”

没有规则，agent 会乱写；有了规则，wiki 才能长期维护。

例如：

每个非平凡 claim 必须有 citation。
无法验证的内容标记 [UNVERIFIED]。
来源冲突标记 [CONFLICT]。
删除或合并关键页面前必须人工审批。

llm-wiki 与 RAG 的区别



flowchart LR
    subgraph RAG[传统 RAG]
        RQ[用户问题] --> RS[检索 top-k chunks]
        RS --> RA[LLM 临时综合答案]
        RA --> RO[答案结束\n通常不沉淀]
    end

    subgraph WIKI[llm-wiki]
        S[新资料] --> I[Ingest 编译]
        I --> K[Markdown 知识图谱]
        Q[用户问题] --> K
        K --> A[带引用答案]
        A --> B{有复用价值?}
        B -- 是 --> K
    end

维度	RAG	llm-wiki
工作时机	问的时候搜	平时就整理，问时复用
知识形态	chunks + embeddings	Markdown pages + wikilinks + citations
是否复利	弱	强
可审计性	依赖检索日志	Git diff、引用、页面历史
冲突处理	临时判断	显式记录 conflicts
人类可读性	较弱	强
适合场景	局部事实查询、大规模原文召回	长期知识沉淀、概念图谱、决策记录、研究综合

更准确地说，二者不是敌人：

RAG retrieves.
llm-wiki compiles.
GraphRAG connects.
MCP exposes.
Git audits.
Lint maintains.
Human arbitrates.

三个核心动作：Ingest / Query / Lint

Ingest：不是“摘要”，而是“入库编目”



sequenceDiagram
    participant U as User
    participant A as Agent
    participant R as Raw Sources
    participant W as Wiki
    participant L as Log

    U->>A: 导入一篇文章 / PDF / repo
    A->>R: 保存原始资料
    A->>W: 读取 index 和相关页面
    A->>A: 提取概念、事实、冲突、引用
    A->>W: 更新多个页面
    A->>W: 添加 wikilinks 和 citations
    A->>L: 记录 ingest log

关键点：一篇资料不应该只生成“一篇摘要”。

更好的做法是：

一篇新文章
  ├─ 更新 concept A
  ├─ 更新 concept B
  ├─ 新建 decision C
  ├─ 给 practice D 加一个反例
  ├─ 在 conflicts.md 记录冲突
  └─ 在 sources.md 记录来源

Query：先查 wiki，再回 raw source

用户问题
  ↓
查 wiki/index.md
  ↓
读相关页面 TLDR
  ↓
沿 wikilinks 扩展
  ↓
必要时回 raw source 核验
  ↓
输出带引用答案
  ↓
有长期价值则回写 wiki

Lint：知识库的“体检”



mindmap
  root((Wiki Health))
    Links
      broken links
      orphan pages
      missing backlinks
    Claims
      uncited claims
      unsupported claims
      stale claims
    Structure
      duplicate pages
      overlong pages
      index drift
    Trust
      unverified facts
      unresolved conflicts
      missing provenance
    Time
      expired facts
      superseded decisions
      stale summaries

没有 Lint，wiki 会慢慢腐化。

2025–2026 的新演化

调研显示，llm-wiki 相关理念正在与多个方向合流。



flowchart TD
    K[llm-wiki\nAgent-maintained Markdown Knowledge Graph]

    A[Basic Memory\nLocal-first Markdown Memory] --> K
    B[DeepWiki\nRepo-to-wiki] --> K
    C[GraphRAG\nGlobal sensemaking] --> K
    D[LightRAG\nGraph + Vector retrieval] --> K
    E[Graphiti\nTemporal agent memory] --> K
    F[MCP\nResources / Tools] --> K
    G[llms.txt\nLLM-facing docs entry] --> K
    H[Docs-as-code\nGit + Markdown + Review] --> K

Basic Memory：Markdown 是真相层

启发：

Markdown 不只是导出格式，而是 canonical store。

派生索引可以有很多种：

SQLite FTS；
embeddings；
entity/relation table；
backlinks；
temporal facts。

但它们都应该可以重建。

DeepWiki：代码库可以自动长出 wiki

启发：

1	GitHub repo → AI 生成 wiki → 搜索 / 聊天 / 理解架构

这说明 llm-wiki 可以优先支持代码库：

架构图；
模块职责；
调用链；
关键概念；
设计决策；
onboarding guide。

GraphRAG：回答全局问题

传统 RAG 擅长：

“这个函数在哪？”
“这段文档怎么说？”

GraphRAG 更适合：

“整个项目有哪些核心模块？”
“这些概念之间是什么关系？”
“语料中有哪些冲突观点？”

LightRAG：图和向量不是二选一

最佳结构更像：

Markdown canonical store
  + Full-text search
  + Vector search
  + Graph relations
  + Community summaries

Graphiti：事实需要时间维度

旧事实不失效，是 agent memory 的大坑。

所以重要事实最好有：

valid_from: 2025-01-01
valid_until: 2026-03-01
supersedes: old-decision.md
superseded_by: new-decision.md

MCP：让知识库可被 agent 使用

MCP 适合作为暴露层：

list resources
read page
search wiki
get backlinks
get source metadata
propose patch

但 MCP 不解决治理问题。写回仍然需要 review、diff、approval。

llms.txt：给外部 LLM 的入口

llm-wiki 可以导出：

/llms.txt
/llms-full.txt
/wiki/index.md
/wiki/topic-map.md
/wiki/source-map.md

让外部 agent 快速理解这个知识库。

新进场者：从”想法”到”工厂 + 城市规划标准”

Karpathy 的 llm-wiki 是一份想法文件——把规则塞进 CLAUDE.md/AGENTS.md，让 agent 自己长出 wiki。2026 年的新故事是：有人开始专门造工厂（自动生成/维护 wiki 的工具），有人开始写城市规划标准（让不同来源的 wiki 能互通）。下面这张生态图把它们按职能分组。

2026 OSS 实现生态图



graph TD
    Idea["Karpathy llm-wiki<br/>想法文件 (2026-04)"]

    subgraph F1["🏭 制造工具：生成 + 维护 wiki"]
        OW["OpenWiki (LangChain)<br/>repo 文档自动测绘队"]
        OKB["OpenKB (VectifyAI/PageIndex)<br/>多格式知识编译车间"]
        NSU["nashsu/llm_wiki<br/>可视化桌面 app"]
        AS["AutoSci (PKU DAIR)<br/>科研全流程流水线"]
    end

    subgraph F2["📐 交换标准：让 wiki 互通"]
        OKF["OKF (Google Cloud)<br/>城市规划标准 / 知识版 HTTP"]
    end

    subgraph F3["🔍 检索/工具配件"]
        QMD["qmd (Tobi Lütke)<br/>本地混合搜索引擎"]
        AM["AGENTS.md (Linux Foundation)<br/>agent 入场须知"]
    end

    Idea --> OW & OKB & NSU & AS
    Idea -.->|形式化| OKF
    OW -->|注入 pointer| AM
    OKB -->|遵循| OKF
    NSU -->|可选调用| QMD
    OKF -.->|被消费| AM

    classDef idea fill:#fff4e6,stroke:#f59f00,color:#000
    classDef factory fill:#e7f5ff,stroke:#1c7ed6,color:#000
    classDef standard fill:#e6fcf5,stroke:#0ca678,color:#000
    classDef tool fill:#f3f0ff,stroke:#7048e8,color:#000
    class Idea idea
    class OW,OKB,NSU,AS factory
    class OKF standard
    class QMD,AM tool

把这张图翻译成我们一直在用的城市比喻：

Karpathy 的想法文件 = 一份手抄的”怎么自己盖一座城”的施工笔记。
OpenWiki = 自动测绘队：扫一遍代码库就把地图（wiki）画好，还每天派 diff 巡逻队把变化补上。
OpenKB = 编译车间 + 知识炼金炉：把 PDF/Word/PPT/网页统统投进去，炼成互相链接的 Markdown 知识库。
nashsu/llm_wiki = 一座带 3D 地图、社区聚类、观光电梯的现代化知识城（桌面 app）。
AutoSci = 全自动科研流水线：从读论文到做实验、写论文、做海报一条龙。
OKF (Google) = 城市规划标准 / 知识版 HTTP：规定每栋楼（每个概念）必须挂什么门牌（type 字段）、街道怎么命名（文件路径即身份），让不同城市之间能互相读懂地图。
qmd = 本地搜索引擎，相当于城里的”按意义找路”导航仪。
AGENTS.md = 给所有 agent 的入场须知，告诉它们”进城先读哪份地图”。

一句话区分：制造工具解决”怎么把 wiki 长出来”，交换标准解决”长出来的 wiki 怎么互通”。 2026 年的变化是这两件事第一次被分开做。

四位新玩家速写

下面每个小条目都遵守同一格式：是什么 / 与 llm-wiki 的关系 / 一个要小心的坑。

OpenWiki（LangChain）— 自动测绘队

是什么：TypeScript CLI（npm i -g openwiki），基于 LangChain 的 DeepAgents，给代码库生成一份 openwiki/ 目录的 Markdown wiki；再在顶层 AGENTS.md/CLAUDE.md 里只插一小段指路牌（pointer），让已有编码 agent 按需去读 wiki，而不是把整本 wiki 塞进上下文。配套 GitHub Action 每天按 git diff 自动开 PR 保鲜。
与 llm-wiki 的关系：把 Karpathy 的”人类手工 + 通用 agent 维护 wiki”升级为专用生成器 + CI 自维护器；专门解决 Karpathy 留给用户的”wiki 怎么和 agent 接线”和”怎么不腐烂”两个痛点。范围比 llm-wiki 窄——目前只面向代码库（博客说未来可能扩到其他工作流）。
坑：v0.0.1、repo 仅约两周大（2026-06-22 创建）、约 7k 星基本是发布博客带起来的热度，不是耐久度。预设模型清单（constants.ts 核验）实为 GLM 5.2 / Kimi K2.7 Code / Claude Sonnet 5——部分二手报道误写成 K2.6。无 MCP、无 llms.txt、无任何 FTS/向量/图索引——“wiki for agents”的框架下，检索其实只是 agent 直接读 Markdown。

比喻：OpenWiki 是”只在城门口立一块指路牌”的设计——地图（wiki）和指路牌（AGENTS.md 里那几行）分开，既避免上下文爆炸，又让 wiki 可以独立长大。

OpenKB（VectifyAI / PageIndex）— 编译车间 + 知识炼金炉

是什么：Apache-2.0 Python CLI（pip install openkb），把 PDF/Word/PPT/Excel/HTML/CSV/URL 等多格式原料编译成一份结构化、互相链接的 Markdown wiki（summaries/ concepts/ entities/），用 [[wikilinks]] 串联，Obsidian 可直接打开。卖点”无向量数据库“：长 PDF（默认 ≥20 页）走 PageIndex 的无向量、推理式树索引，短文档直接全文喂给 LLM。带 query/chat/skill factory/可视化/deck 等生成器。
与 llm-wiki 的关系：README 明说”基于 Karpathy 描述的概念”，并逐条对比自己比 Karpathy 多做了什么——其中最关键一条是直接解决 Karpathy 自己点名的”长 PDF 难题”（Karpathy 承认长文档会上下文腐烂）。把”丢网页剪报到 .md”的输入扩到 PDF/Office/URL 全家桶；把手工维护概念页换成自动实体抽取（人/组织/地点/产品）。
坑：仍是 Alpha（pyproject 分类器写明 Development Status :: 3 - Alpha）。”长 PDF 质量”完全押在 PageIndex 引擎上，开源版能力有限，进阶功能（扫描版 PDF OCR、更快结构生成）要走付费的 PageIndex Cloud（PAGEINDEX_API_KEY）。PageIndex 树索引目前只支持 PDF，非 PDF 长文仍走全文读取，照样撞上下文墙。

比喻：OpenKB 是”只炼不埋”的炼金炉——知识在 ingest 时就被炼成结构化页面，query 时只是去取成品，而不是每次重新淘金（这正是它对标 RAG 的核心论点）。

nashsu/llm_wiki — 一座可视化桌面知识城

是什么：跨平台 Tauri v2 桌面 app（macOS/Windows/Linux），把文档变成互相链接的 Markdown wiki，配 GUI、4 信号知识图谱（直接链接 ×3.0 / 来源重叠 ×4.0 / Adamic-Adar ×1.5 / 类型亲和 ×1.0）、Louvain 社区检测、可选 LanceDB 向量搜索、深度研究、Chrome 剪藏扩展、本地 HTTP API + MCP server + 可装 agent skill。仓库自带一份 llm-wiki.md，把 Karpathy 的模式文字逐字收录。
与 llm-wiki 的关系：README 写明”based on Karpathy’s LLM Wiki pattern”，忠实保留三层架构（raw 不可变 / wiki LLM 生成 / schema 规则）、Ingest/Query/Lint 三操作、index.md/log.md/[[wikilinks]]/YAML frontmatter/Obsidian 兼容；大幅扩展为产品化 app：两步思维链 ingest（先分析后生成）、purpose.md（wiki 的方向意图，每次 ingest/query 都读）、SHA256 增量缓存、持久化 ingest 队列、文件夹监听、深度研究、异步 review 队列、级联删除等。
坑：GPL-3.0（copyleft，商用嵌入要留意）。仓库仅约 3 个月大（2026-04-08 创建）就有 1.37 万星，增速惊人但长期维护未经验证。README 自报的”recall 58.2%→71.4%”是自测，无第三方复现。本地 PDF 解析实际用 pdfium-render（README 误标为 “pdf-extract”）；可选的 MinerU 云端 PDF 解析（默认关闭，失败回退本地）会把文件传第三方云，与 “local-first” 叙事略有张力。

比喻：nashsu/llm_wiki 是”带观光电梯的现代化知识城”——你既能像 Obsidian 一样在地上走，也能坐电梯（GUI + 图谱）从空中看全城分区。

Google OKF — 城市规划标准 / 知识版 HTTP

是什么：Google Cloud 在 2026-06-12 发布的开放规范 v0.1 Draft。一个”知识包”就是一目录 Markdown 文件（一个概念一个文件），唯一必填 frontmatter 字段是 type；推荐字段 title/description/resource/tags/timestamp。文件路径（去掉 .md）就是概念身份。保留文件名 index.md（渐进式目录）和 log.md（按日期分组的变更史）。交叉链接用普通 Markdown 链接，把目录变成比父子层级更丰富的图。显式不规定存储/服务/查询基础设施，不定义 FTS/向量/图索引——这些全部留给消费端。
与 llm-wiki 的关系：Google 博客直接引 Karpathy 原话（”LLMs 不会无聊、不会忘记更新交叉引用、一次能改 15 个文件”），把 OKF 定位为”把 LLM-wiki 模式正式化为可移植、可互操作的格式”。SPEC 第 10 节把”用 Markdown + frontmatter 做 agent 可读知识库的 LLM wiki 仓库”列为最近的同类模式，区别在于 OKF 是被规范化的——钉死了最小互操作约定（必填 type、保留文件名、链接语义、宽容一致性）。可看作 Karpathy 模式的”最小公约数超集”：任何已有 wiki 只要加一个 type 字段就合规。
坑：v0.1 Draft，会变。仓库挂 GoogleCloudPlatform 名却自带”not an official Google product”免责声明。发布会现场唯一确认的生产消费者是 Google 自家的 Knowledge Catalog（前 Dataplex）——跨生产者/消费者的真实互操作尚未被证明。规范本身不含 MCP/llms.txt/任何运行时协议；它只是一份文件格式契约。

比喻：OKF 不盖楼，只发布”城市规划标准”——只要每栋楼挂对门牌（type），任何城市的地图（不同生产者产出的 wiki）都能被任何游客（agent）读懂。它是知识界的 HTTP：一个最小约定，换最大互通。

我该选哪个？一张决策表

下面这张表把本章出现的新工具按”最适合干嘛”排成一列，帮你按场景对号入座。重要前提：它们大多数非常年轻（几周到几个月大），star 数 ≠ 耐久度；任何生产采用前请回源核对最新状态。

你的场景	优先考虑	为什么	一句话 caveat
想给一个 GitHub 代码库自动生成并 CI 自维护一份给 agent 用的文档	OpenWiki	自动测绘队 + 每天按 git diff 开 PR，AGENTS.md 只插 pointer 不撑爆上下文	v0.0.1、仅 ~2 周大，无向量/FTS/图索引，检索靠 agent 直读 Markdown
有长 PDF / Word / PPT / 网页混合资料，想编译成 Obsidian 可读的知识库	OpenKB	多格式 ingest + 无向量 PageIndex 树索引，专治 Karpathy 点名的长 PDF 难题	Alpha 阶段；长 PDF 质量押在 PageIndex，进阶功能走付费云；非 PDF 长文仍撞上下文墙
想要一个带 GUI / 图谱 / 可视化的桌面”第二大脑”，跨平台	nashsu/llm_wiki	Tauri 桌面 app，4 信号图谱 + Louvain 社区 + 可选向量 + 深度研究 + Chrome 剪藏	GPL-3.0（copyleft）；3 个月大 1.37 万星但长期维护未证；自测 recall 未第三方复现
要做科研全流程：读论文→点子→实验→写论文→海报	AutoSci	30+ Claude Code 技能覆盖全生命周期 + 双模型交叉评审 + 远程 GPU + arXiv 配套论文	仅 Claude Code 耦合；README 自承”No native MCP”是错的（实际含 llm-review MCP）；3 个月大、internal beta
你已经有 wiki，想让不同工具/团队/agent能互相读懂对方的 wiki	OKF（给所有页面加 `type` 字段）	最小公约数换最大互通，知识版 HTTP；Google Knowledge Catalog 已 ingest	v0.1 Draft；唯一确认生产消费者是 Google 自家；跨组织互操作未被证明
你只想给 agent 一个本地混合搜索（BM25 + 向量 + 重排），不换 wiki 形态	qmd（Tobi Lütke）	完全本地、GGUF 模型、CLI + MCP server，Karpathy gist 亲自推荐	首跑下载 ~2GB 模型；Node.js ≥22；默认 glob 是 `*/.md`
你只想给 agent 一份入场须知，让它知道”进城先读哪份地图”	AGENTS.md（Linux Foundation）	跨厂商事实标准，60k+ 项目在用，MCP 同基金会托管	不是知识库，只是单文件约定；60k 数字是自报营销；托管方是 Linux Foundation（非 OpenAI）

三条决策捷径

要 CI 自维护的 repo 文档 → OpenWiki。 它是唯一一个把”git diff 驱动每日 PR”做成头等公民的。
要长 PDF / 多格式知识库 → OpenKB。 它是唯一一个把”无向量长文档检索”当核心卖点的。
要让多个工具互通 → 给所有输出加 OKF 的 type 字段。 这是成本最低的”未来兼容”保险。



flowchart LR
    Q1{"要给代码库<br/>做文档?"}
    Q2{"有长 PDF/<br/>多格式资料?"}
    Q3{"要可视化<br/>桌面端?"}
    Q4{"要让多个工具<br/>互通?"}

    Q1 -- 是 --> OW[OpenWiki]
    Q1 -- 否 --> Q2
    Q2 -- 是 --> OKB[OpenKB]
    Q2 -- 否 --> Q3
    Q3 -- 是 --> NSU[nashsu/llm_wiki]
    Q3 -- 否 --> Q4
    Q4 -- 是 --> OKF[给页面加 OKF type 字段]
    Q4 -- 否 --> RAW[继续用 Karpathy 原版<br/>+ AGENTS.md 指针]

    classDef pick fill:#d3f9d8,stroke:#2f9e44,color:#000
    class OW,OKB,NSU,OKF pick

一句话总结这一节：2026 年的变化不是”又有了一个新 llm-wiki”，而是生态开始分工——有人专做制造（OpenWiki/OpenKB），有人专做标准（OKF），有人专做配件（qmd/AGENTS.md）。你不再需要在”一个工具搞定一切”和”从零手搓”之间二选一。

一个页面应该长什么样？

---
type: concept
title: Agent-maintained wiki
status: draft
confidence: medium
sources:
  - raw/web/karpathy-llm-wiki.md
  - raw/web/basic-memory.md
valid_from: 2025-01-01
valid_until:
generated_by: claude
reviewed_by:
---

# Agent-maintained wiki

## TLDR

Agent-maintained wiki 是由 LLM 持续维护的 Markdown 知识图谱，用于把阅读、问答、纠错沉淀为长期可复用知识。

## Key Claims

- 它与传统 RAG 的区别在于：知识不是只在 query-time 临时检索，而是在 ingest/maintenance 阶段持续编译。[source: raw/web/karpathy-llm-wiki.md]
- Markdown 适合作为 canonical store，因为它可读、可 diff、可迁移。[source: raw/web/basic-memory.md]

## Relations

- related_to: [[RAG]]
- contrasts_with: [[Vector Database]]
- enables: [[Knowledge Compounding]]
- exposed_by: [[MCP Resources]]

## Open Questions

- 如何自动判断页面粒度？
- 哪些 agent 写回可以自动合并？

## Conflicts

- [CONFLICT] 某些实践主张纯 Markdown 足够，GraphRAG 路线主张额外构建图索引。

失败模式：知识花园也会长杂草



flowchart TD
    F[失败模式]
    F --> A[幻觉固化\n生成内容被当事实]
    F --> B[引用漂移\ncitation 不支持 claim]
    F --> C[旧事实不失效\nstale knowledge]
    F --> D[结构腐化\nindex 和页面不同步]
    F --> E[图抽取错误\n实体重复/关系错]
    F --> G[写回污染\nagent 无审查改 wiki]
    F --> H[粒度失控\n页面太粗或太碎]

    A --> M1[claim-level citation]
    B --> M2[source quote / provenance]
    C --> M3[valid_from / valid_until]
    D --> M4[lint / health report]
    E --> M5[entity resolution / graph diff]
    G --> M6[propose patch + review]
    H --> M7[evolve workflow]

最重要的原则：

生成内容不是事实，带来源、可核验、可审计的内容才逐渐接近事实。

评估指标：怎么知道 wiki 真的在变好？

回答质量

指标	含义
answer groundedness	答案是否被来源支持
citation coverage	关键 claim 是否有引用
unsupported claim rate	无来源 claim 的比例
query success rate	用户问题是否被有效回答
source fallback rate	回 raw source 的频率

Wiki 健康

指标	含义
broken link rate	断链比例
orphan page rate	孤儿页比例
duplicate entity rate	重复实体比例
stale claim count	过期 claim 数量
unresolved conflict count	未解决冲突数量
source coverage	raw source 被 wiki 表达的比例

Agent 写回治理

指标	含义
proposed patch count	agent 提议修改数
accepted patch rate	被接受比例
rejected patch rate	被拒绝比例
revert rate	回滚比例
human edit latency	人工审查延迟
high-risk write attempts	高风险写入尝试

成本

指标	含义
ingest cost per source	每个 source 的导入成本
query token cost	每次回答 token 成本
index rebuild cost	重建索引成本
graph extraction cost	图抽取成本
source-to-wiki compression ratio	原文到 wiki 的压缩比例

最终心智模型

如果把知识系统比作城市：

Raw Sources 是档案馆
Wiki Pages 是城市街区
Wikilinks 是道路
Index 是地图
Citations 是门牌和产权证明
Lint 是城管和质检
MCP 是城市 API
llms.txt 是游客指南
GraphRAG 是城市规划图
Temporal Memory 是历史档案
Human Review 是市政审批
Agent 是图书管理员 + 城市维护工

真正的 llm-wiki 不是“自动写几篇 Markdown”，而是：

一个由 agent 持续维护、由 human 审查裁决、以 Markdown 为真相层、以引用和时间维度保证可信、以索引和协议连接外部工具的知识基础设施。

可以直接对外讲的版本

30 秒版本

llm-wiki 是一种让 LLM 长期维护知识库的方法。它不是每次问问题时临时 RAG，而是把资料提前整理成带引用、带链接、可审计的 Markdown 知识图谱。每次导入资料、回答问题、发现冲突，都会让知识库变得更好。

2 分钟版本

传统 RAG 像临时翻资料：用户问问题，系统检索几个片段，然后让 LLM 拼答案。问题是，每次推理都不一定沉淀，冲突和纠错也很难长期保留。

llm-wiki 的做法是把 LLM 变成长期图书管理员。新资料进入时，agent 把它保存为 raw source，然后更新多个 Markdown wiki 页面，添加引用、交叉链接、冲突标记和开放问题。用户提问时，agent 先读已经整理好的 wiki，必要时回原始资料核验。好的答案还可以回写进 wiki。

现代版本的 llm-wiki 还可以叠加全文搜索、向量检索、图索引、MCP、llms.txt 和 temporal memory。但核心原则不变：Markdown 是可读、可 diff、可迁移的真相层；索引是可重建的派生层；agent 写回必须受治理约束。

一句话项目宣言

llm-wiki is an agent-maintained, source-cited, Markdown-native knowledge graph with rebuildable search, graph, and vector indexes. It turns reading, reasoning, Q&A, and corrections into a persistent, auditable, temporally aware compounding artifact.

Sources

主要参考：

Karpathy Gist：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
Karpathy Gist raw：https://gist.githubusercontent.com/karpathy/442a6bf555914893e9891c11519de94f/raw/llm-wiki.md
Basic Memory：https://github.com/basicmachines-co/basic-memory
DeepWiki：https://cognition.com/blog/deepwiki
Graphiti：https://github.com/getzep/graphiti
Microsoft GraphRAG：https://github.com/microsoft/graphrag
GraphRAG paper：https://arxiv.org/abs/2404.16130
LightRAG paper：https://arxiv.org/abs/2410.05779
LightRAG repo：https://github.com/HKUDS/LightRAG
MCP Resources：https://modelcontextprotocol.io/docs/concepts/resources
llms.txt：https://github.com/AnswerDotAI/llms-txt
Claude Code memory docs：https://code.claude.com/docs/en/memory

2026-07-07 增量（§6.8–6.10）新增来源

OpenWiki（LangChain）：https://www.langchain.com/blog/introducing-openwiki-an-open-source-agent-for-repo-documentation、https://github.com/langchain-ai/openwiki
OpenKB（VectifyAI）：https://github.com/VectifyAI/OpenKB、https://pageindex.ai/blog/introducing-openkb
nashsu/llm_wiki：https://github.com/nashsu/llm_wiki
AutoSci（PKU DAIR）：https://github.com/skyllwt/AutoSci、arXiv 2505.31468：https://arxiv.org/abs/2505.31468
Karpathy 衍生实现：https://github.com/Astro-Han/karpathy-llm-wiki、https://github.com/SamurAIGPT/llm-wiki-agent、https://github.com/nvk/llm-wiki、https://github.com/lucasastorian/llmwiki
qmd（Tobi Lütke）：https://github.com/tobi/qmd
AGENTS.md：https://agents.md/
Google Open Knowledge Format：https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing、SPEC https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
GitHub 话题：https://github.com/topics/karpathy-llm-wiki、https://github.com/topics/llm-wiki