LLM Wiki：读懂全新的 AI 知识架构

LLM Wiki 会在摄取阶段将您的来源汇编为一个持久、互相链接的知识库，随后基于该知识库进行回答，而不是每次都重新检索原始片段。这样，随着您添加来源，知识会不断累积，而不是在每个问题上从零开始重建。

我将带您了解 LLM Wiki 概念的来源、它与检索增强生成（RAG）的比较，以及它是否在 AI 系统的知识管理方式上带来了真正的转变。

LLM Wiki 概念的起源

LLM Wiki 的想法在 2026 年成形，由Andrej Karpathy 提出，并被一些开源项目采纳，做成了可以实际运行的系统。

理念很简单。2026 年的 AI 系统花了大量时间反复阅读相同文档。您上传一个 PDF，模型检索片段、回答问题，然后继续。下周，您又上传一份同主题的 PDF，模型再做一遍同样的事。没有任何积累。

最大的转变在于：检索与编纂是两项不同的工作。

例如：

• 检索优先系统在查询时查找相关文本片段，并将其作为上下文提供给模型。模型基于检索器提供的内容作答。
• 编纂优先系统在摄取时对每个来源阅读一次，提取要点，并将其写入结构化知识库。模型随后基于该知识库回答问题。

LLM Wiki 属于第二类。当您添加新来源时，模型会阅读它、更新现有页面、在需要时创建新页面，并对与既有内容相矛盾的地方进行标注。随着您添加来源，知识库不断增长，模型回答的基础也越来越扎实。

这是对自RAG 成为标准以来主导的检索优先范式的首次具体突破。RAG 将每次查询视为对原始文档的新一轮查找。LLM Wiki 则把摄取视为完成工作的时刻，而查询阶段只是读取一套已经深思熟虑的基础。

什么是 LLM Wiki？

LLM Wiki 是一个持久的、由 AI 维护的知识库，能够持续将来源文档的信息综合为结构化、互相连接的页面。

它与一个文件夹或向量库的三个不同之处：

• 持久化：页面一经创建，会在新来源到来时持续更新。查询时无需重新推导，因为综合结果已被写下。
• 持续更新：每次摄取来源都会触发对整个 wiki 的编辑，例如为新实体创建新页面、修订现有摘要、在新数据与旧说法矛盾处做注记。
• 双重受众：页面既便于人类阅读，又足够结构化以便 AI 代理进行推理。Markdown、交叉链接与一致的版式可兼顾两端。

关键在于让 wiki 成为主要的知识层。原始文档保存在原样存储中作为审计溯源，但不再被直接查询。聊天系统、代理和研究助手都阅读 wiki，因为那里放着经过编纂与交叉引用的知识版本。

LLM Wiki 的架构

该架构更像是一个三阶段流水线。来源进入，模型将其编纂为 wiki 页面，AI 应用再从这些页面读取内容。

LLM Wiki 架构

下面逐一讲解各阶段。

来源文档

凡是基于文本的内容都可以摄取。例如：

• 文档与 PDF
• 个人笔记与会议记录
• 代码仓库
• 网页内容（剪藏文章或爬取站点）

原始来源被放入不可变存储。摄取完成后，模型只读取不修改它们，这样任何 wiki 论断都能清晰追溯到其来源。

知识编纂

Wiki 在此步骤中生成。新来源到来时，模型会执行一组操作：

• 提取概念：从来源文本中抽取实体、主题、定义与论断。
• 更新现有页面：若某个实体或概念已有页面，模型会用新信息进行修订，并标注矛盾之处。
• 创建新页面：不适配现有页面的内容会生成独立页面。
• 关联相关主题：添加双向交叉引用，确保 wiki 增长的同时页面保持连接。

一次摄取的来源可能会“更新”10 至 15 个页面。这正是要点——将新材料与既有知识连接的工作在摄取时只做一次，而不是像 RAG 那样在每次查询时反复进行。

AI 应用

该 wiki 旨在服务多类使用方。例如：

• 聊天系统基于编纂后的知识而非原始文档进行问答。
• 研究助手沿着交叉引用逐步构建对某主题的全貌。
• 软件代理将 wiki 用作跨长期任务的持久记忆。
• 企业级知识系统将 wiki 暴露给内部工具、dashboards，或MCP 服务器。

Wiki 位于中间。一端是来源输入，另一端是应用读取，中间的编纂层让两端保持同步。

LLM Wiki 与传统 RAG 的比较

传统 RAG 与 LLM Wiki 的主要区别在于工作发生的时间点。

传统 RAG

RAG 会在查询时检索文档片段。您提出问题后，嵌入检索会从向量库中拉取前 k 个最相关的片段，并与您的问题一起作为上下文添加到模型中。模型基于这个临时上下文生成答案，响应完成后便将其遗忘。

该上下文是一次性的。

上一问题所用的片段在模型答复结束时就从上下文中移除。若您明天问个相关问题，检索器又会再跑一遍，再拉片段，模型再综合一次。查询之间没有任何积累。

LLM Wiki

LLM Wiki 在摄取期间完成信息编纂。添加来源时，模型读取一次，将要点写入结构化页面，更新交叉引用，并将结果以持久的 markdown 形式存储。查询阶段由此变为读取已编纂的基础，而非从原始片段重新综合。

知识是持久的，并且会演化。

每个新来源都会触发对整个 wiki 的编辑，因此矛盾会被标注，旧的摘要会被修订，主题之间的连接也会随时间变得更加紧密。

权衡

两种方法并非孰优孰劣，它们优化的目标不同。

需要注意几点：

• 新鲜度：RAG 在此上占优，因为它在查询时直接读取来源文档。若基础文档更新，下一次查询会立刻看到变化。LLM Wiki 需要重新摄取来源以更新页面，因此从原始事实到编纂知识之间存在时滞。
• 准确性：当问题需要跨多来源综合时，LLM Wiki 的表现更好，因为综合工作已完成且可复查。若相关片段跨越的内容多于上下文窗口所能容纳，RAG 可能错失关联，因为它在一次传递中从未看到完整全貌。
• 维护：RAG 一旦建立向量库后几乎零维护，因为索引是机械性的。LLM Wiki 需要主动维护，例如通过 lint 扫描捕捉陈旧说法、进行矛盾检查、偶尔审阅以清理孤立页面。权衡在于：维护良好的 wiki 会随时间更丰富，而 RAG 索引则保持平面化。
• 可扩展性：RAG 随文档数量可预期扩展，因为检索是搜索问题。LLM Wiki 的扩展取决于模型在规模增长时保持编纂知识一致性的能力。超出一定规模后，wiki 需要索引文件、搜索工具或嵌入层来保持可导航性。

这里有一张并列总结：

LLM Wiki 与 RAG

在实践中，RAG 与 LLM Wiki 也常相辅相成。一些实现会在 wiki 规模超出索引文件可承载范围后，对 wiki 本身再跑一层 RAG。

为何 AI 代理受益于 LLM Wiki

AI 代理比聊天系统更受“无记忆”问题困扰。一场对话尚可容忍反复检索，但代理可能运行数小时或数天，在数十个任务中一再“重新发现”相同事实。LLM Wiki 为它们提供了存放所学之处，从而避免重复学习。

以下是持久知识最具潜力的几个领域：

• 软件开发：一个在同一代码库上持续数周的编码代理，会累积关于模块、规范、过往缺陷与设计决策的知识。没有 wiki，这些上下文每次会话都得重建；有了 wiki，代理读取编纂页面，直接从上次结束处继续。
• 长期研究：负责跟踪数百篇论文中某一主题的代理无法将一切都放入上下文。Wiki 为其提供归档摘要之处，使其无需重读整个语料就能回看不断演进的全貌。
• 企业助理：部署在公司内部的助理每天都会面对不同员工提出的相似问题。借助 wiki，助理可以基于编纂的内部知识回答，而不是每次都在同一批页面中搜索。
• 组织记忆：当人员变动或会议结束时，团队往往丢失上下文。由会议记录、工单与文档驱动的 LLM Wiki 能保持这些上下文的连贯。

若实施得当，您会在三个方面看到 LLM Wiki 的效益：

1. 更少重复检索：读取编纂页面的代理无需重复运行昨天的网络搜索或向量查询。
2. 更丰富的上下文：Wiki 页面已包含综合信息，因此相比原始片段，代理每项任务的起点拥有更密集且更紧密相连的基础。
3. 累积式学习：每次会话都会为 wiki 添砖加瓦，下一次会话能受益于上一次的成果。这样，代理会随着时间真正变得更胜任，而不是每次提示都在重置。

构建 LLM Wiki

构建 wiki 的工作流是一个循环。来源进入、页面被写就并反复改写，随着语料增长，整体不断自我打磨。

LLM Wiki 构建循环

• 摄取文档。第一步是将来源放入原样存储。文档读取一次并保持不可变，以便每个下游论断都能追溯到具体来源。摄取可以是单个文件、一批文件，或模型监控文件夹的持续流式输入。
• 识别实体与概念。针对每个新来源，模型提取关键内容——命名实体、核心概念、论断、定义与关系。这是将非结构化文本转化为 wiki 可归档内容的时刻。提取流程还会检查现有 wiki，了解已有覆盖与新增内容。
• 生成或更新页面。新实体获得新页面。现有页面以新信息修订。若新来源与既有论断相矛盾，模型会在页面上标注而非直接覆盖。一次摄取常会修改 10 至 15 个页面，因为来源往往涉及多项内容。
• 维护链接。添加双向交叉引用，确保页面保持连接。若一个关于RAG的新页面提及向量数据库，而vector databases页面已存在，则两者都会互相链接。
• 持续精炼知识。定期的 lint 扫描可捕捉随时间累积的问题。例如，页面间的矛盾、被较新来源取代的陈旧论断、无人链接的孤立页面，以及被顺带提及但缺少独立页面的重要概念。此步骤可在规模化过程中保持 wiki 健康。

具体实现取决于您的技术栈，但整体形态在各实现中相同。摄取、提取、写入、链接、精炼——然后循环往复。

LLM Wiki 系统的常见特性

多数 LLM Wiki 的实现具有类似的特性集合。细节各异，但构件在各项目中是通用的。

自动知识编纂

Wiki 会“自我书写”。当来源被摄取时，模型提取要点并在无人干预下归档到页面。人工维护会“拖垮”传统 wiki，因为人类会厌倦更新交叉引用与摘要；模型不会。这一特性使整个模式得以运转。

链接页面

每个页面通过交叉引用连接到相关页面。当一个关于transformers的页面提到attention mechanisms时，两个页面会互相链接。结果是一个可导航的图谱，您可以沿着引用漫游，从而发现此前未曾意识到的关联。

来源标注

每个页面中的每条论断都可追溯至具体来源。原始文档保持不可变，以便您随时核验信息出处。这很重要，原因有二：当您需要检查准确性时，它提供审计溯源；当来源被移除时，它也让模型能干净地撤回相关论断。

知识图谱

Wiki 的链接结构本身就是知识图谱。节点是页面，边是交叉引用，图的形状说明语料真正关注的是什么。围绕重要概念会自然形成枢纽页面，孤立页面则提示空白区域，稠密簇表明 wiki 最熟悉的领域。

持久记忆

Wiki 可跨会话使用。聊天上下文会在对话结束时消失，但 wiki 页面作为 markdown 存在于磁盘上。正是这一点使聊天模型能够将知识在数日、多个项目与多次代理运行间延续。

持续更新

新来源会触发对现有页面的修订，而不仅仅是追加。如果上月发表的论文与六个月前的内容矛盾，wiki 会进行标注并更新受影响的页面。知识库会随时间更接近正确，而不是累积陈旧论断。

这些特性并非彼此独立。这意味着：缺少来源标注的 wiki 不值得信任；同理，没有持续更新的 wiki 会陈旧，而没有链接页面的 wiki 只是摘要的文件夹。价值来自所有特性共同发挥作用。

LLM Wiki 的真实应用场景

上述模式具有通用性，下面列举一些现实世界中 LLM Wiki 能发挥作用的场景，甚至比 RAG 更有用。

研究文献

凡是跟踪一个主题、涉及数十到数百篇论文的人都会遇到同样的问题——论文堆积速度超过处理速度。LLM Wiki 会在论文到来时逐篇阅读，提取论断，按相关概念归档，并与已读内容进行矛盾标注。结果是与领域保持同步的“进行式综合”，而非永远不会再读的一堆 PDF。

工程文档

代码库往往存在文档欠账，并且通常每个冲刺都在增加。设计决策常在 Slack 线程中做出，架构笔记则躺在某人的 Notion 里。唯有实际代码能保证最新。由代码库、注释、拉取请求与内部文档共同供给的 wiki 能编纂出与代码相连的系统全貌。工程师可以向 wiki 提问，而不是去找三年前写该模块的人。

企业知识库

公司会在工单、会议记录、产品规格与内部 wiki 中积累知识。LLM Wiki 可以从这些渠道摄取，并编纂为一层保持最新的统一知识层。员工可以一次查询，而不是在四个不同工具里各自搜索。

个人知识管理

笔记应用解决了“存放”问题，却没有解决“综合”问题。您依然有上百条笔记、文章与高亮，且大多数不会再看。比如，借助您的 Obsidian 库驱动的 wiki，可以将这堆笔记转化为可实际查询的编纂知识体系。

AI 代理记忆

运行数小时或数天的代理需要一个存放所学之处。Wiki 为它们提供可跨会话使用的持久记忆——哪些方法有效、哪些无效、已读过哪些文件、尝试过哪些路径。这对基于 Claude Code 或类似工具构建的代理尤其有用，因为同一代码库需要跨多次会话持续开发，而过往运行的上下文能显著提升当前运行的效率。

当前的 LLM Wiki 实现

截至 2026 年，LLM Wiki 领域仍处早期。现有大多为开源项目，由个人或小团队构建。距离 RAG 的成熟度还有很大差距。

Karpathy 的原始gist是许多实践者的起点。它对该模式的描述足够详细，任何拥有 LLM 代理的人都能将文档粘贴进 Claude Code 或类似工具，自行搭建一个版本。当前多数 wiki 都是在共享理念之上搭建的个人项目。

开源探索是理念不断打磨的主阵地。诸如 llm-wiki.net 之类的项目会以宽松许可发布代码，便于他人 fork、扩展或适配到自有工作流。其优势在于您可以清楚了解 wiki 在做什么，并在默认不符合需求时进行调整。

本地优先方案完全在您的机器上运行。来源保存在磁盘，wiki 是一组 markdown 文件，模型通过本地代理进行读写。Obsidian 是最常见的前端，因为它天生支持 markdown 与交叉引用。这样您能拥有最大控制权：来源不离开您的机器，且您可以检查模型写下的每一页。

托管实现开始出现，但尚不常见。与 RAG 相比，该模式与 SaaS 的契合度较低，因为 wiki 理应属于您——您的来源、您的页面、您决定归档什么。托管版本更适用于团队 wiki，在共享知识的价值高于将来源托管在他人基础设施成本的场景中表现更佳。

但截至 2026 年 7 月，这些都未臻完善。很多问题仍待探索，现存的大多数项目还只是原型。

优势与局限

LLM Wiki 模式既有优势也有成本。在决定是否构建之前，了解两者都很重要。

优势

• 持久知识：Wiki 能在任何单次会话结束后继续可用。模型上个月得出的结论今天仍在页面上，新工作在此基础上推进，而无需从头开始。
• 可复用的综合：连接来源的工作在摄取时完成一次。此后每次查询都读取编纂结果，而非从原文重做综合。这既节省算力，又能产出更好的答案，因为“思考”已先行完成。
• 更少重复检索：已有主题页面的 wiki 无需在每次出现该主题时都去搜索原始语料。这对长时间运行、否则会反复执行相同搜索的代理尤为重要。
• 结构化组织：页面与交叉引用构成可浏览、可推理的载体，尤其相较于一堆 PDF 文件夹更具可用性。

局限

• 保持信息最新：当来源变化时，wiki 需要重新摄取。若文档已更新而您未重新摄取，wiki 仍会引用旧版本。RAG 没有这个问题，因为它在查询时读取实时来源。
• 验证挑战：wiki 页面上的每条论断都由模型写就。来源标注有所帮助，但仍需信任模型是否正确概括了来源。
• 维护成本：矛盾检查与重新摄取并非免费。未经维护的 wiki 会变陈旧，即便由模型执行，维护也需要时间与算力。
• 可能的知识漂移：每次摄取都可能引入模型的小错误。经过数百次摄取，这些误差会累积。一个起初准确的页面，经过足够多的修订后可能会出现细微偏差。

关于 LLM Wiki 的常见误解

尽管 LLM Wiki 是个新概念，但已经出现了一些误解。下面是它们的偏差所在。

LLM Wiki 会取代 RAG

并不会。两者解决的问题不同。RAG 用于对频繁变化的语料进行快速查找；LLM Wiki 则用于随着时间构建起一套知识体系。许多实际系统会同时使用二者——RAG 负责读取原始来源以保证新鲜度，wiki 负责在其之上进行编纂综合。

这只是另一个向量数据库

向量数据库用于索引文本以便检索。LLM Wiki 则写出经模型阅读、理解与重组后的文本。向量数据库返还的是您放入的片段；wiki 返还的是在您摄取来源之前并不存在的页面。输出完全不同。

知识库永远不需要更新

不对。来源会变化、新来源会到来，模型也会犯错需要纠正。未经维护的 wiki 会像任何文档一样变陈旧。不同之处在于多数维护由模型完成，而非维护工作会消失。

它只对 AI 代理有益

代理是最明显的用例，因为它们运行时间长，最能从持久记忆中受益，但人类同样能从 wiki 中获得价值。比如跟踪某个主题的研究者，或在代码库上工作的工程师。实际上，任何构建个人知识库的人都能享受同样的复利式综合。

LLM Wiki 会成为新的 AI 架构吗？

现在下结论还为时过早，但大致路径是清晰的：持久知识不会取代检索优先系统，而是与之并存，由 RAG 处理实时查找，wiki 处理编纂的、长期的上下文。更大的未解问题在于验证与规模——尚无人彻底解决如何发现写入 wiki 页面的模型错误，也没人对超大规模 wiki 的模式进行过压力测试。MCP 看起来很适合将 wiki 暴露给代理，不过企业采用会更晚一些，因为需要额外的信任保障。

该模式尚未定型。能否推进，取决于维护与验证问题是否得到解决。更多相关问题见下方常见问答。

结语

LLM Wiki 是 2026 年迄今较为有趣的理念之一，因为它改变了当您交给 AI 一个来源时，AI 系统在做什么。模型不再在每次查询时反复阅读相同文档，而是读一次便将其归档到一个会随时间变得更好的知识库中。

该概念仍在萌芽阶段，当前实现也较早期，但它很有前景，并指向一个更宏观的趋势：AI 系统正在从“一次性上下文”走向“持久知识”，而 LLM Wiki 是将这一愿景在实践中落地的首批严肃尝试之一。

如果您想紧跟新发展但感到困惑，欢迎报名我们的 AI Fundamentals 学习路径。您将掌握相关术语，并能高效地将 AI 用于工作。