我们之前给客户做过一个背调系统方案。用 RAG 查企业材料，自动生成背调报告。听起来很成熟，检索加生成，标准管线。
报告出来了，版式漂亮，引用齐全，语气笃定。
不过，财务数字是错的。营业收入、净利润，整段数字对不上材料。有的是编的，有的是把别处的数挪了过来。看起来比真的还真。
关键数字不对，报告就没法用。材料里明明写着数，模型为什么不抄材料。
后来我想明白了，这不是 RAG 做错了什么。恰恰相反，它很好地完成了自己的任务：找到相关材料。问题在于，我们让一个检索系统承担了知识管理系统的职责。RAG 是知识消费层，不是知识生产层。财务数字这种东西，不能靠模型「理解大意」，必须钉死在结构里，带单位，带期间，带口径，带出处。
搜得再好，也只是把原料端上桌。怎么变成可以下锅的知识，是另一件事。
我后来把这个过程叫做「知识编译」。
编译不是总结。写代码的人对这个类比不陌生：
源代码
↓
编译器
↓
机器码
知识这边对应的是：
原始资料
↓
知识编译
↓
实体、关系、规则、约束、证据
总结是给人看的一段话，编译是给系统用的结构。机器码可以在机器上反复执行，编译好的知识可以在 Agent 里反复调用，每次不用重新理解一遍源代码。
这两年大家默认堆 RAG。文档入库，切块，Embedding，进向量库。提问时召回几个分块，模型现场组答案。管线很漂亮。问题是它不保留结果。第 10 次提问和第 1 次一样，从原始分块重新推导。前面九次的理解，一点没剩下。
Karpathy 关于 Agent 上下文管理的一系列讨论，把问法换了一下。别在查询时重新发现知识，把知识编译一次，持续更新，让它成为 Agent 可以长期访问的环境。社区后来把这类做法叫成 LLM-Wiki。
我觉得多数人还是把它当成「又一种知识库产品」。这样看会看丢真正的变化。
它不是产品，是一种知识编译范式。
一，先看生命周期
RAG 是单向的。
原始资料，切块，Embedding，检索，回答，结束。
LLM-Wiki 是个环。
原始资料进来，理解、提取，变成实体、关系、规则、适用条件、证据与冲突。编译成 Wiki 页面。持续增量维护。Agent 与人消费。消费时冒出新证据、新经验。再编译。回到维护那一步。
区别就在这里：RAG 优化的是，这次怎么找到答案。LLM-Wiki 优化的是，这次找到的东西，能不能成为下一次的知识。
知识复利只在闭环里成立。单向管线跑一万次，也不会长出利息。
对照着拆解，知识能力其实分三层。
Knowledge Retrieval，我去哪里找。RAG、搜索、向量库，都停在这。
Knowledge Compilation，找到的东西怎么变成结构化、可复用的知识。这才是 LLM-Wiki 的核心。
Knowledge Evolution，新信息进来后，原知识怎么变。这是复利能不能转起来的关键。
RAG 等于 Retrieval。LLM-Wiki 等于 Compilation 加 Evolution。
二，Compilation 到底在编什么
它不是简单地写摘要完事。而是对着源资料，编译至少要落下这几类东西：
实体。谁是谁。同一项目在不同文档里的别名要并成一条。
关系。谁依赖谁，谁适用谁。客户到产品到规则那条链，以前散在四个目录里。
规则。生效的口径是什么，版本号是多少。
条件。什么情况下适用。地区、时段、服务类型、例外。
证据。每句话来自哪份材料，第几节。
冲突。两份材料不一致时，双方观点都钉住，标明待裁决。
我们库自己就挂着这种冲突。同一晚的 Agent 发邮件事件，团队第一次复盘，把 Code Sandbox 加 smtplib 直连夸成 Plan B 优秀实践。过阵子写修订版，把同一方案降成临时工，答案换成 Agently Mail。两份都是正式材料，但是观点和评价互相冲突了。
这种事没法靠检索消掉。只能在编译时承认冲突存在，双页标注，留下解决方向，等人或等新证据来裁。人类 Wiki 腐化，多半就腐在这一步。修链接、对齐摘要、逐份比对、统一实体，无尽头，无即时回报，团队一忙就扔，扔了就没人再用。
模型正适合干这个。它不会烦，不会跳过某条交叉引用，一次能改十几个文件。
所以定义可以收准一点。
LLM-Wiki，是用模型承担人类无法持续完成的知识编译与维护工作。
编译是前半程，维护是后半程。很多人只抄了「用 Markdown 记笔记」，没抄这两程，那还是检索套壳。
三，Evolution 怎么转
编译一次不够。材料会更新，结论会过期，新的经验会盖掉旧的判断。没有 Evolution，Wiki 会变成一屋子过期档案。
这里有个很容易被略过的判断。Evolution 不等于「自动改文档」。
变更至少要有三样东西：合并策略，出处，可追溯。
合并策略回答的是，新旧冲突时怎么办。是增量追加，还是整体替换；基石事实能不能被覆盖；过期记忆要不要删掉。没有策略的自动改写，等于让实习生拿橡皮擦直接改档案。
出处回答的是，这句话从哪来。可追溯回答的是，上周改了什么，能不能 diff。
所以认真的知识库都会把版本控制写进交付方式，用 git 分发，让每一次知识变更都留下痕迹。知识库不是聊天记录，得有 diff。
一个工程实现给出的合并语义，大致是这几种：
| 操作 | 合并策略 | 用途 |
|---|---|---|
| 增量合并 | 保留旧文，追加或局部修改 | 事实补充 |
| 整体替换 | 新结论覆盖旧结论 | 判断更新 |
| 只创建不覆盖 | 保护基石事实 | 口径、定义 |
| 删除 | 清过期记忆 | 失效信息 |
| 关联 | 记忆之间双向挂钩 | 建立图 |
闭环长这样。对话，完成任务，提取变更，按策略写入，重建导航，下次查询直接用上。每个动作都在给知识库进货。
四，规模上去了，怎么喂给 Agent
编译出几百个页面之后，新问题来了：Agent 怎么读得进去。
靠一份总目录加链接导航，大约撑到一百份源文档、数百个页面。再大，光索引就能把上下文撑爆。
但是撞墙的是导航方式，不是「编译成 Wiki」这件事本身。
工程上的答案是分层供给。不是把整库塞进上下文，而是让 Agent 像翻文件系统一样，从粗到细一层层看。
| 层 | 作用 |
|---|---|
| L0 | 说清这是什么，判断方向 |
| L1 | 核心信息与结构导航，理解脉络 |
| L2 | 原文细节，确认需要才碰 |
Agent 的路径变成：先扫 L0 判断哪些目录相关，再读 L1 看结构，确认需要才下到 L2。Token 从全量读降到按需读。
检索也跟着变成结构化导航。先在粗粒度上定位相关目录，再钻进目录里精查。比在一堆扁平分块里捞 top-k，更不容易把无关目录的零散句子端上来。最近被频繁碰过的知识，理应优先出列——上周的经验不该埋在三年前的文档底下。
这里真正值得记住的不是某家的算法，而是一个原则：知识规模变大后，供给方式要比检索算法先升级。 先解决「Agent 一次该看多少、按什么顺序看」，再谈召回率。
五，形状怎么统一
知识编译完了，长什么样，各家原来各说各话。AGENTS.md、CLAUDE.md、Obsidian 加 Agent、各种 index.md 加 log.md 文件夹，互不兼容。
谷歌云 2026 年 6 月发的 OKF，Open Knowledge Format，想定的就是这个形状。
极度克制。一个 Bundle 就是个普通文件夹，一个概念一份 Markdown，上面 YAML frontmatter，下面正文。强制字段只有一个 type。title、description、resource、tags、timestamp 都可选。路径即概念 ID，tables/orders.md 的 ID 就是 tables/orders。文件之间用标准链接互引，文件夹自己长成图。保留名两个。index.md 管渐进探索，log.md 管变更历史。
合规只要三件事。frontmatter 可解析，type 非空，index 和 log 若存在则结构正确。消费者必须容忍未知 type、缺字段、断链。一个文件不合格，不影响整包。
这套设计我觉得狠的地方在于，它不定义内容模型，只定义互操作最小公约数。type 取值完全由生产者定。要扩展加自定义键，消费者该保留，不该丢。
在更大的栈里，OKF 是内容层。llms.txt 是入口路标，EntityMap 是实体声明，OKF 是图书馆本体。MCP 管实时工具和活数据，在旁边另一条道。一个是知识沉淀层，一个是工具访问层，互补，不抢地盘。
我们自己的 wiki 结构几乎是 OKF 的超集。分层 INDEX、log、frontmatter、双链都有。还多两样 OKF v0.1 没有的。hot.md 当近期上下文缓存。矛盾用 callout 钉在冲突双方页面上。OKF 悬而未决的「冲突没有合并语义」，我们用最小机制先扛住了。
六，分清四层，就不会把产品摆成对打
到这里可以收一张图。
| 层次 | 解决什么 | 代表 |
|---|---|---|
| Paradigm | 为什么要把资料编译成 Wiki | LLM-Wiki |
| Format | 知识怎么表示、怎么流通 | OKF |
| Infrastructure | 大规模知识怎么被 Agent 高效使用 | OpenViking |
| Ownership | 知识如何长期属于一个人或组织 | Molio |
LLM-Wiki 是范式。OKF 是表示与流通规范。OpenViking 是企业规模的基础设施实现。Molio 管的是知识归属。
不在一个维度上竞争。
这里我原先写的是「个人可拥有」，后来觉得不够。真正的差异不是个人，是 Knowledge ownership。
OKF 管形状可交换。OpenViking 管规模可供给——当知识量超出扁平索引的边界，它用分层摘要和结构化导航，让 Agent 像操作文件系统一样渐进读取。Molio 管知识归属：Agent、Wiki、Skill、Memory 四层交在用户手里，本地 vault，入库人在环，页面可读可改。
「属于」比「个人」更大。企业私有知识库同样适用。否则别人会觉得这只是 Obsidian 加了个 AI。实际上的定位是：拥有自己的 AI 知识资产。
底下共同仰赖的，就是 Compilation 加 Evolution。
对做个人或小团队知识系统的人，我的建议其实很朴素。表示层尽量靠 OKF，将来好交换。供给层别急着上向量全家桶，先看有没有过那条百页边界。维护层宁可人在环，也别留下没人认领的自动改写。作答纪律要写死：依据不足，口径冲突，就明说，不要补猜。
知识系统最危险的时刻，从来不是搜不到，是搜到一条错的，穿着正确信息的外衣，被复述十遍。
七 总结
回到开头那份背调报告。
下次再生成财务段落，我不希望它「理解」材料。我希望它从编译好的实体页往上拼。这家公司，这个期间，营收多少，单位是什么，口径是什么，出处在第几页。材料更新了，页面跟着改。模型只负责组织，不负责发明数字。
有实证的直接引用写入。要确认的知道找谁。确认结果写回同一套知识。
RAG 答完就忘，每个答案都是一次性的现场发挥。编译好的 Wiki 会随时间长利息，数字长在结构上，下一次不用再赌模型会不会编。
再往下说一层。
过去的信息系统，解决的是「记录发生过什么」。
搜索系统，解决的是「找到在哪里发生」。
LLM-Wiki 想解决的是：让 Agent 继承过去发生过一切。
从检索走到编译，这是AI系统接下来的方向，核心竞争力，不是检索更多资料，而是把资料编译成可以持续进化的知识。
最后
如果你对 AI Agent、知识工程和 LLM-Wiki 的探索感兴趣，欢迎关注、点赞和转发，一起见证知识系统的下一次演进。