一、引言：六年的轮回#

这两天，我把 Agent 知识库过去六年的技术路线摊在一张时间轴上看了一遍。看完以后有一种很奇怪的感觉——我们好像每隔半年，就会宣布一次上一代知识库已经死了：

• 向量 RAG 不行了，得上图；
• 图太重了，得轻量化；
• 切片把文档切烂了，得上树；
• 每次查询都重新理解，太浪费了，得让 LLM 自己写 Wiki；
• Wiki 各写各的又没法流通，得有 OKF。

一轮一轮，跟打游戏升装备似的。每一代刚出来都像毕业装，过几个月一看，哦，原来只是新手村套装。

但把这六年连起来以后，我反而不觉得哪一代被淘汰了。它们更像是在一层一层回答同一个问题：

知识到底应该以什么形态，被机器理解、积累、更新和使用？

注意，重点已经不只是搜索了，是知识本身。

二、2020 年 · Vector RAG —— 朴素的开端#

2020 年，Vector RAG 给出的答案很朴素：模型不知道的东西，就去外面找。

那时候大模型的上下文很短，权重里的知识又有截止日期。企业自己的文档、数据库、产品手册，不可能为了每次更新都重新训练一个模型。于是文档被切成 chunk，chunk 变成 embedding，问题也变成 embedding，再从向量空间里捞出最相似的几段，塞回 Prompt。

这套东西为什么能火六年？ 因为它真的好用，而且工程上足够便宜。文档可以增删，模型不用重训；检索和生成被拆成两个模块，向量数据库也很容易水平扩展。对于产品条款、客服 FAQ、单点事实问答这类问题，Vector RAG 到今天依然很能打。

但它有一个从出生就带着的毛病：相似，不等于相关。

用户问某家公司为什么连续三个季度利润下降，真正需要的可能是三份财报里的收入结构、成本变化、一次收购和管理层解释。向量检索却更容易捞出和「利润下降」字面接近的段落。它能找到句子，却未必能找到因果链。

更麻烦的是 chunking。一份合同里，第三章第二节的例外条款可能受第一章定义约束；一个技术方案里，表格的表头、脚注和正文可能被切进三个 chunk。文档原本精心组织好的层级，被我们亲手撕碎，再期待 cosine similarity 帮忙拼回去。有时候我觉得，这事儿确实有点行为艺术。

Vector RAG 解决了「模型怎么拿到外部知识」，却留下了 全局理解、关系推理、结构保真和重复计算 四个大坑。

三、2024 年 · GraphRAG —— 走进关系空间#

2024 年，GraphRAG 先来填全局理解和关系推理的坑。

传统向量检索很擅长回答「某个人做了什么」，却很难回答「这一整批材料的主要主题是什么」——因为后一个问题根本没有对应的单一 chunk。

GraphRAG 的做法是：先从文档里抽取实体和关系，构成知识图谱，再通过社区发现把联系紧密的实体聚成若干主题社区，为每个社区生成摘要。查询时，不再只在碎片里捞句子，而是可以从社区级摘要开始做全局归纳，再往局部证据下钻。

这一下，检索从相似度空间走进了关系空间。 优势非常直接：多跳关系能表达了，全局主题能概括了，跨文档的人、事、组织也终于不再是互相失忆的孤岛。

代价同样直接：贵。

实体抽取要调用模型，关系抽取要调用模型，社区摘要还要调用模型。新文档进来以后，图结构、社区划分和摘要都有可能受影响。图谱越大，构建、更新、查询和运维链路越重。你本来只想给 Agent 装个书架，到头来发现自己顺手盖了一座图书馆，还雇了一支编目队。

不是 GraphRAG 不行，而是它用昂贵的全局建模，换来了传统 RAG 不具备的全局视角。

四、2024 年晚些 · LightRAG —— 给图谱减重#

同年晚些时候，LightRAG 出现了。它盯上的，正是 GraphRAG 的重量。

LightRAG 把实体级和主题级检索放进同一套双层结构里，再把图检索和向量检索混合起来：具体事实走低层实体，宏观问题走高层主题，需要时两边一起用。更重要的是，新文档派生出来的局部子图可以增量并入现有图谱，不必每次都把整座城市推倒重画。

它的优势是让关系检索从一次大型工程，变成更接近日常系统的持续维护。

但轻量，不等于免费。 实体和关系依然要抽取。抽错一个实体，后面的边可能跟着歪。不同模型、提示词和领域术语，会生成质量差异很大的图。它也没有真正解决文档结构被切碎的问题——对于财报、法律文本、技术规范这种结构本身就携带语义的材料，图可以补关系，却不一定能还原作者原来的阅读路径。

五、2025 年 · 树形索引 —— 沿结构走路#

于是 2025 年，树形索引开始走红。这一派的判断很刺耳：

也许问题不在于向量检索做得不够好，而在于我们一开始就不该把所有文档都切成无结构碎片。

PageIndex 这类方案更像人读长文档：先看目录和章节摘要，判断应该进入哪一支，再沿树逐层下钻到页码和段落。遇到交叉引用，再跳去被引用的章节。整个过程不是在向量海洋里撒网，而是在文档自己的逻辑结构里走路。

这对财报、合同、论文、产品规格非常有价值。它保留了章节层级，能给出物理页码和访问路径，推理过程也更容易审计。屏幕前做合规、投研或者复杂技术支持的朋友，应该很清楚「答案对了」和「我知道它为什么对」完全是两件事。

树形索引的缺点也很明显：它吃文档结构。 目录越清晰、层级越稳定，效果越好。聊天记录、工单、零散笔记、事件流这种天然扁平的材料，硬长成一棵树反而别扭。跨文档实体关系也不是树的强项。构建树、生成摘要、逐层决策同样需要模型调用，只是把成本花在了结构理解和推理导航上。

所以你看，图和树不是谁消灭谁：

六、2026 年 · LLM Wiki —— 让理解积累#

到了 2026 年，LLM Wiki 把矛头指向了另一个长期被忽略的问题：

为什么 Agent 每回答一个新问题，都要重新读一遍同样的原始材料？

昨天刚理解过一次产品架构，今天换个问题，又从几十份文档开始召回、重排、总结。每次查询都很努力，每次查询也都失忆。这不是知识积累，这是知识现炒。

LLM Wiki 的做法，是把理解工作从查询时前移到构建时。 原始材料继续保持不变，LLM 负责维护一套 Markdown 知识目录，持续写摘要、补索引、建链接、消解重复、记录变化。好的问答还可以反过来沉淀成新页面。

这一步特别重要——因为知识库第一次从「用完即弃的检索结果」，变成了「会随着使用持续复利的产物」。

Markdown 又足够透明：人能读，模型能读，Git 能 diff，脚本能解析，编辑器能直接打开。中等规模下，一个写得足够好的 index，甚至比一套黑盒向量召回更容易控制。

可 LLM Wiki 也有自己的坑。 规模上来以后，目录会膨胀，链接会腐烂，不同页面会产生矛盾。多个 Agent 同时更新同一个概念，可能各写各的版本。知识由模型编纂，也会把模型的误解固化下来。最麻烦的是，每一家都能发明自己的目录、字段和约定，A 系统生成的 Wiki，B 系统未必知道怎么吃。

七、2026 年 · OKF —— 知识跨工具流通#

所以两个月后，OKF 把格式互操作摆上了桌面。

更准确地讲，OKF 是开放知识格式，不是一个替你完成检索的运行时协议。这块需要注意一下——很多人看到”标准”两个字，会下意识以为它把查询、更新、权限、索引全包了。没有。

OKF 做的事情很克制：

• 一个知识包就是一组 Markdown 文件；
• 文件路径可以成为概念身份；
• YAML frontmatter 放机器可读的类型和描述；
• 正文放人和模型都能读的完整知识；
• index 负责导航；
• Markdown 链接负责关联。

它的优势，是把知识从某个产品的私有数据库里解放出来。生产者可以是人、数据流水线或者 LLM，消费者可以是 Claude Code、Codex、企业 Agent 或者静态站点。双方只对格式负责，不必绑定同一个向量库、图数据库、云账号和 SDK。

它的缺陷也恰恰来自这种克制。 OKF 不负责搜索引擎，不负责实时同步，不负责判断内容是不是真的，也不负责多人协作时怎么合并冲突。frontmatter 太宽松，消费者可能产生不同解释。知识包第一次编译依然可能很慢。动态数据、高频事件和实时配置，也不适合一股脑写进 Markdown。

八、六年路线回顾#

走到这里，六年的路线其实已经很清楚了：

从 similarity → relations → reasoning → curation → interoperability，抽象层级一直在往上走。

九、下半场：frontmatter + 正文 + Git#

但我真正想聊的，其实是后半场。

说实话，我也不确定这个判断最终会不会完全兑现，我自己也还在摸索。但把这些路线放在一起以后，我越来越相信，Agent 知识库的下半场会收敛到两个非常朴素的东西：

frontmatter 加正文，以及 Git。

听着甚至有点复古，对吧。大家折腾了六年向量数据库、图数据库、重排模型和长上下文，到头来最重要的基础设施，可能是一堆 Markdown 和一个 2005 年诞生的版本控制系统？

我一开始也觉得这结论过于不性感。但你仔细想想，frontmatter 加正文，其实完成了一个很漂亮的分工。

十、检索的新位置：从主角到编译产物#

顺着上面的再聊聊检索。我不认为 OKF 加 Git 会杀死 RAG。恰恰相反，RAG 会从知识库本身，退到更合适的位置——它会变成编译产物。

Markdown 和 frontmatter 是可读、可审、可迁移的知识源。向量索引、实体图、树索引、倒排索引和语义缓存，都是从这份知识源按需构建出来的加速层。索引坏了可以重建，模型换了可以重新 embedding，图谱算法升级了可以重新抽取，但知识源、变更历史和责任关系不会被锁死在某个数据库里。

你想想看，这跟软件工程已经非常接近了：

源代码是长期资产，二进制是可重建产物。 知识文件是长期资产，检索索引是可重建产物。

查询进来以后，系统可以先用 frontmatter 做低成本路由，再按内容特征选择后端：散点事实走向量和 BM25，跨文档关系走图，结构化长文档走树，已经回答过的问题走语义缓存。最终只把少量高纯度上下文交给推理模型。

哪个都不押，哪个都用。 这可能才是 Agent 知识库真正成熟的样子。

十一、未来展望：知识包生态#

再往远一点看，我觉得知识库甚至会出现类似软件包生态的东西。

一个专业团队维护某个领域的 OKF 知识包，用 Git 发布版本。其他 Agent 像安装依赖一样引入它，读取 frontmatter 判断能力边界，沿 Markdown 链接展开正文，再为自己的运行环境构建向量、图或树索引。上游发布新版本，下游能看到 diff，决定升级、锁版本或者回滚。

知识开始像代码一样分发，也开始像代码一样承担责任。

当然，这里面还有很多难题：跨仓依赖怎么锁定，敏感知识怎么做最小权限，两个知识包对同一概念给出冲突定义时听谁的，Agent 自动提的知识变更由谁审批，过期知识怎样自动失效。说实话我们还差得远。

但方向已经开始清晰了。

十二、结语#

过去六年，我们一直在优化 Agent 怎么找答案。

下一个六年，更重要的问题可能是：答案如何被组织成可以持续生长、被多人维护、被机器渐进读取、还能随时回到任意历史状态的公共资产。

从相似度，到关系，到结构，到编纂，到格式，再到版本。

知识库终于不再只像一个搜索框。它开始像一个代码库。

而代码库最迷人的地方，从来不是里面放了多少文件——

是每一次变化，都有迹可循。