RAG每次查询重头推导知识 LLM Wiki一次编译实现知识积累

在为 AI 代理配备代码库、设计文档、邮件记录或研究资料时，最标准的做法是 RAG：分块、嵌入、查询时检索 top-k 片段，再让模型生成回答。这套流程跑得通，但存在一个结构性的缺陷——合成永远发生在查询时刻。模型每回答一次问题，都要从原始碎片重新拼凑上下文、重建理解。第十次问同一个代码库的架构逻辑，和第一次一样需要模型重新梳理，没有任何知识沉淀。

LLM Wiki 把这个时间点彻底前移：合成只在摄入时发生一次，之后通过持久的 Markdown 页面实现积累与更新。四个独立团队在几个月内不约而同地验证了同一套架构，这不是巧合，而是对一个底层问题的共同解答。

维护簿记工作如何成为传统 wiki 的隐形杀手

人类 wiki 失败的原因从来不是缺少洞察，而是无止境的簿记。新增一份设计文档后，需要手动更新几十个实体页的摘要、补全交叉引用、检查与已有内容的矛盾。这些工作没有即时反馈，也没有上限。团队一忙起来就自然放弃，wiki 逐渐腐烂，人们不再信任它，它就死了。

模型却不介意做这些 unglamorous 的工作。它不厌倦，不会遗漏交叉引用，能一次性触达多个文件并保持一致。Karpathy 在原始 gist 中直指这一点：普通文档流程的问题在于“模型每次都在从头 rediscover 知识”，而 LLM Wiki 的核心是“编译一次，然后保持新鲜”。

这就像数据库里的物化视图。原始表是不可变的源数据，每次查询都做复杂 join 计算（类似 RAG 的每问重推导）；物化视图则在数据变更时预先计算并维护结果，后续查询直接读视图，速度快且一致。LLM Wiki 做的正是知识层的物化。

LLM Wiki 的三层结构为什么专为代理阅读而设计

整个模式只有三层，极简却极度适配模型的阅读习惯：

• 原始来源层：不可变。论文、仓库、邮件、Notion 页面——模型只读不写。
• Wiki 层：模型完全拥有的 Markdown。包含实体页、概念摘要、交叉引用。页面不是写给人看的，而是写给下一个读取它的模型看的。
• Schema 层：一个配置文件（常见命名 CLAUDE.md、AGENTS.md 或类似）。它定义 wiki 的组织规则、页面模板、以及模型必须执行的工作流。这让模型从“会写文件的聊天机器人”变成“有纪律的维护者”。

三层之间通过三个核心操作闭环运行：摄入（新来源到达时，模型识别受影响实体，更新或创建页面，修订摘要，标记矛盾）、查询（从 wiki 读取上下文，可选地把高质量回答回写为新页面，让探索持续 compounding）、Lint（定期扫描陈旧声明、矛盾、孤儿页并修复）。

下面是这个闭环的逻辑架构建议（Mermaid）：

#mermaid-svg-BPpZVhCHIA50faTP{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-BPpZVhCHIA50faTP .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-BPpZVhCHIA50faTP .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-BPpZVhCHIA50faTP .error-icon{fill:#552222;}#mermaid-svg-BPpZVhCHIA50faTP .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-BPpZVhCHIA50faTP .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-BPpZVhCHIA50faTP .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-BPpZVhCHIA50faTP .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-BPpZVhCHIA50faTP .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-BPpZVhCHIA50faTP .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-BPpZVhCHIA50faTP .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-BPpZVhCHIA50faTP .marker{fill:#333333;stroke:#333333;}#mermaid-svg-BPpZVhCHIA50faTP .marker.cross{stroke:#333333;}#mermaid-svg-BPpZVhCHIA50faTP svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-BPpZVhCHIA50faTP p{margin:0;}#mermaid-svg-BPpZVhCHIA50faTP .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-BPpZVhCHIA50faTP .cluster-label text{fill:#333;}#mermaid-svg-BPpZVhCHIA50faTP .cluster-label span{color:#333;}#mermaid-svg-BPpZVhCHIA50faTP .cluster-label span p{background-color:transparent;}#mermaid-svg-BPpZVhCHIA50faTP .label text,#mermaid-svg-BPpZVhCHIA50faTP span{fill:#333;color:#333;}#mermaid-svg-BPpZVhCHIA50faTP .node rect,#mermaid-svg-BPpZVhCHIA50faTP .node circle,#mermaid-svg-BPpZVhCHIA50faTP .node ellipse,#mermaid-svg-BPpZVhCHIA50faTP .node polygon,#mermaid-svg-BPpZVhCHIA50faTP .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-BPpZVhCHIA50faTP .rough-node .label text,#mermaid-svg-BPpZVhCHIA50faTP .node .label text,#mermaid-svg-BPpZVhCHIA50faTP .image-shape .label,#mermaid-svg-BPpZVhCHIA50faTP .icon-shape .label{text-anchor:middle;}#mermaid-svg-BPpZVhCHIA50faTP .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-BPpZVhCHIA50faTP .rough-node .label,#mermaid-svg-BPpZVhCHIA50faTP .node .label,#mermaid-svg-BPpZVhCHIA50faTP .image-shape .label,#mermaid-svg-BPpZVhCHIA50faTP .icon-shape .label{text-align:center;}#mermaid-svg-BPpZVhCHIA50faTP .node.clickable{cursor:pointer;}#mermaid-svg-BPpZVhCHIA50faTP .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-BPpZVhCHIA50faTP .arrowheadPath{fill:#333333;}#mermaid-svg-BPpZVhCHIA50faTP .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-BPpZVhCHIA50faTP .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-BPpZVhCHIA50faTP .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-BPpZVhCHIA50faTP .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-BPpZVhCHIA50faTP .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-BPpZVhCHIA50faTP .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-BPpZVhCHIA50faTP .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-BPpZVhCHIA50faTP .cluster text{fill:#333;}#mermaid-svg-BPpZVhCHIA50faTP .cluster span{color:#333;}#mermaid-svg-BPpZVhCHIA50faTP div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-BPpZVhCHIA50faTP .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-BPpZVhCHIA50faTP rect.text{fill:none;stroke-width:0;}#mermaid-svg-BPpZVhCHIA50faTP .icon-shape,#mermaid-svg-BPpZVhCHIA50faTP .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-BPpZVhCHIA50faTP .icon-shape p,#mermaid-svg-BPpZVhCHIA50faTP .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-BPpZVhCHIA50faTP .icon-shape .label rect,#mermaid-svg-BPpZVhCHIA50faTP .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-BPpZVhCHIA50faTP .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-BPpZVhCHIA50faTP .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-BPpZVhCHIA50faTP :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

优质回答可选回写

修复矛盾/陈旧

原始来源层不可变

摄入操作

Schema 配置层组织规则与工作流

Wiki 层LLM 拥有的 Markdown实体页 + 摘要 + 交叉引用

查询操作

定期 Lint 操作

四团队不约而同的选择揭示了什么底层正确性

四家团队解决的问题不同（公开代码库、CI 构建、私人知识、生活记录），却在几个月内收敛到几乎相同的形状：

收敛点清晰：Markdown 存 Git + Schema 文件 + 摄入时合成 + 变更时刷新。分歧主要在“如何保持新鲜”——Factory 把 staleness 当成构建问题用 CI 解决，其他团队则依赖按需触发。这正是成熟度的信号：当独立团队在不同约束下走到同一架构时，这个形状大概率是对的。

它不是用户记忆 而是语料的持久编译产物

这里有一个容易混淆但必须区分的边界。LLM Wiki 解决的是语料知识：把一堆文档/仓库/邮件“说了什么”编译成可查询、可维护的页面。它回答“这个材料集合包含哪些事实和关系”。

它不解决用户与体验记忆：某个具体用户上周改变了供应商决策、某个方法在某个 App 里已经试过失败、用户的偏好随时间演变。这些是按 user_id 绑定的、从交互中积累、需要支持矛盾与删除的记忆。

把 wiki 当成“给代理加了记忆”是一种常见的误判。Wiki 给你的是编译后的语料资产，而不是跟随用户的长期个人记忆。两者是互补的，前者让代理能高效读取稳定知识，后者让代理真正记住“你”。

规模、忠实度与陈旧性构成的真实边界

这个模式不是万能的，它有清晰的适用范围：

• 规模：Karpathy 自己指出，无 embedding 的 index-first 方式在中等规模（约 100 个来源、几百页）表现惊人。超过这个量级，就需要引入混合搜索（BM25 + 向量 + LLM 重排），正如原 gist 推荐的 qmd 那样。
• 忠实度：摄入时编译意味着早期摘要可能悄无声息地丢失源细节，后续所有回答都会继承这个损失。纯检索原始 chunk 不存在这个压缩风险。
• 陈旧性：编译页面的正确性只等于上次刷新的时刻。过时的 wiki 比没有 wiki 更危险，因为它以权威格式自信地给出错误信息。Factory 用 CI 解决这个问题，其他方案则依赖人工触发。
• 编译成本：你需要 upfront 支付 token 来构建可能永远不会被查询的页面，以及定期 lint。

在生产环境落地前必须权衡的编译与检索边界

当语料稳定且被频繁重读时，优先编译成 wiki，能把后续查询的合成成本降到极低，并让知识真正积累。
当语料快速变化或规模已经很大时，纯编译的忠实度与陈旧风险会上升，需要在关键路径上保留检索能力，或采用混合策略（小规模编译 + 大规模混合搜索）。

我起初以为这只是文档自动生成的又一次迭代，后来对比 Karpathy 的原始表述和四团队的实际工程差异后才意识到：这是在重新定义代理持有知识的方式——从“每次都重新教育模型”变成“模型负责维护一个活的知识资产”。

知识的积累不是检索的自然副产品，而是编译的主动结果。维护从来不是写的问题，而是持续更新的簿记问题。而模型恰好是唯一不怕做这些工作的存在。

当你的语料规模从几十页增长到几百页时，你会如何在纯编译 wiki 和混合检索之间动态切换？这个选择对长期 token 效率和回答一致性的影响，值得每位构建生产级 AI 代理的工程师认真思考。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。