LLM Wiki：面向 Agent 工程的知识编译层

Mon, 01 Jun 2026 10:54:03 +0800

如果只先记住一个结论，那么可以记这句：

LLM wiki 不是“让 AI 帮你整理笔记”，而是把项目知识从原始资料提升为 Agent 可消费、可引用、可演化的知识中间层。

这个判断的关键在于，问题并不只是“资料有没有被存下来”，而是“资料是否已经被整理成 Agent 可以稳定工作的形状”。在这件事上，RAG 和 LLM wiki 处理的根本不是同一层问题。Andrej Karpathy 提出的 llm-wiki.md 范式给出的也不是一个笔记软件教程，而是一种把知识从原始材料编译成可维护工作上下文的思路。

本文想讨论的是三个问题：

LLM wiki 到底是什么
它和 RAG 的边界到底在哪里
如果要把它落到工程实践里，最小实现应该长什么样

1. Agent 真正缺的不是“更多文档”，而是知识编译层

很多仓库并不缺文档。

README、ADR、issue、PR、聊天记录、代码注释、发布记录，甚至临时会议纪要，往往已经足够多。问题在于，这些材料大多是围绕“人怎么理解系统”自然长出来的，而不是围绕“Agent 应该如何进入系统、命名概念、定位事实、拼装上下文”组织出来的。

这会带来几个很典型的摩擦：

资料很多，但没有稳定入口
术语存在，但定义分散甚至漂移
同一个问题需要每次重新检索和重新拼接上下文
原始资料适合追溯事实，不适合直接充当工作层

所以 LLM wiki 试图解决的，不是“把一堆东西再存一遍”，而是另一件更具体的事：

它的价值不在存储，而在预编译；不在收集，而在把知识变成可持续复用的中间表示。

Karpathy 在原始 gist 里把这件事描述得很清楚：系统并不直接依赖原始材料回答问题，而是先把原始材料经过整理，沉淀成持续更新的 wiki 层，并由 schema 约束其结构与工作流，再把它作为后续查询和工作的主上下文层。来源

2. 与 RAG 的绝对区分：一个是运行时召回，一个是离线知识编译

很多讨论会把 LLM wiki 和 RAG 混在一起，但这两者并不是同义替换。

RAG 的经典定义来自 Lewis 等人的论文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks：模型在生成前，先从外部知识源检索相关内容，再把检索结果并入生成过程。论文链接

LLM on LinyingBlog

LLM Wiki：面向 Agent 工程的知识编译层

1. Agent 真正缺的不是“更多文档”，而是知识编译层

2. 与 RAG 的绝对区分：一个是运行时召回，一个是离线知识编译