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优质回答可选回写修复矛盾/陈旧原始来源层不可变摄入操作Schema 配置层组织规则与工作流Wiki 层LLM 拥有的 Markdown实体页 摘要 交叉引用查询操作定期 Lint 操作四团队不约而同的选择揭示了什么底层正确性四家团队解决的问题不同公开代码库、CI 构建、私人知识、生活记录却在几个月内收敛到几乎相同的形状团队主要语料货币性处理核心工程特点Cognition DeepWiki任意 GitHub 公开仓库按需刷新公共服务已索引 5 万 仓库Devin 的检索基础设施Factory AutoWiki代码库CI 每次 push 自动刷新两阶段专项代理分析文档作为构建产物LangChain OpenWiki代码 个人来源Gmail/Notion/X 等按需刷新从代码扩展到 Personal Brain输出专为模型优化的结构化 MarkdownGarry Tan GBrain个人知识库Git 按需最简实现纯文件 schema无向量库依赖收敛点清晰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和系统实验。感兴趣可以关注我们下期见。