Open Knowledge Format：为什么一个文件夹也能胜过向量数据库

当整个行业用数年时间收敛到一套方案，随后又突然重新发现“一个文本文件夹”的价值时，真正值得追问的不是它是不是更简单，而是它到底改变了什么。

Open Knowledge Format（OKF） 的关键点，并不是向量数据库突然失去价值。更重要的是：在越来越多与 AI agent 记忆 相关的场景里，问题已经不只是如何检索信息，而是应该在什么时候、以什么位置把知识先组织起来。

在 Devsplainers 关于 OKF 的那期视频里，核心判断非常清晰。过去两年，AI 行业普遍把“记忆”理解为一个需要通过 chunk、embedding 和重复 retrieval 来解决的问题；但另一种路径正在变得更有说服力：与其在每次提问时重新拼装上下文，不如提前把知识整理成一个由 Markdown 文件组成、彼此链接的知识包，让模型像开发者阅读代码库一样去阅读它。

从 RAG 到预先组织好的记忆

RAG 的逻辑大家已经很熟悉。文档被切成片段，每个片段转换成 embedding，存入向量数据库。到了查询时，系统再把最相关的片段取出来交给模型。

这套方法有效，但有一个结构性问题：每一次提问几乎都要从头开始。模型拿到的是一组新的、相互割裂的片段，它必须再次推断关系、依赖和上下文，哪怕这些判断在一小时前已经做过一次。

视频中提到并可追溯到 Andrej Karpathy 的思路，正好反过来。与其让模型一遍遍重建同样的结构，不如把知识提前整理成一种活的 wiki：由文本文件组成、文件之间有链接、结构可以持续演化。这里并不是要人手工把所有内容都写完，而是让 AI 参与总结、交叉引用、归档和维护，人则负责提供新材料与提出正确的问题。

这个差异非常重要，因为它改变了 AI 的角色。AI 不再只是一个“检索后回答”的组件，它同时也成为了记忆的维护者。

Google 真正标准化的是什么

按照视频里的解释，Google 做的事情，是把这种原本带有社区实验色彩的想法整理成一个正式规范。OKF 的结构被设计得非常克制：

• 一个 bundle 本质上就是一个文件夹；
• 每个文件对应一个概念、一张表、一项指标或一个 playbook；
• 文件之间的链接构成图结构；
• 有专门用于索引和变更记录的特殊文件；
• 每个文件至少要声明自己是什么类型的内容。

有意思的地方不在于规范有多复杂，而恰恰在于它有多轻。这个格式要求很少、容错很高，重点不是强迫团队采用一套沉重基础设施，而是让知识能被不同工具稳定读取。

从这个角度看，OKF 的意义不在于它发明了新的复杂性，而在于它试图把一种正在回归的操作性简洁标准化。

为什么一个文件夹可能会赢

从提取出的内容里，可以总结出三条很强的理由。

第一条是认知工作发生的时点不同。传统 RAG 把大量解释性工作放在提问时完成；而在一个维护得当的知识 bundle 里，关系、摘要、矛盾和结构，已经有一部分被提前写进文本本身了。

第二条是上下文规模的管理方式不同。模型无法一次性把所有内容都装进上下文，但如果每个文件夹都有简洁目录、每个文件都清晰映射一个概念，模型就可以先读结构，再打开真正需要的文件，而不是在大量碎片里迷失。

第三条是操作上的可移植性。Markdown 文件天然适合进入 Git，可以 diff、可以做 pull request review、可以打包、复制、离线读取。要阅读它们，不一定需要一个持续在线的检索服务，也不一定需要专门的数据库层。

对于很多内部 agent 架构来说，这种简洁并不只是“优雅”，而是现实优势。

视频为什么有理由给热情降温

这段内容最有价值的部分，也许反而是它的克制。视频并没有把 OKF 讲成一种万能解法，而是点出了至少三个严肃问题。

第一个问题是陈旧化（staleness）。有时间戳字段，不等于有更新机制。一个文件夹在“单一所有者”场景里很好维护；但到了多人协作场景，如果没有明确流程，它很快就会过时。

第二个问题是模型生成 Markdown 的质量。把 LLM 想象成一个不知疲倦且准确无误的图书管理员，很吸引人，但并不稳妥。模型会写坏结构、搞乱标题、制造不存在的链接、输出混乱的编辑习惯。如果格式规范必须对这些问题保持高度宽容，那就说明问题没有消失，只是被推迟到了后面。

第三个问题更深：OKF 标准化的是容器，不是意义。如果一个团队把某个对象写成 table，另一个团队写成 metric asset，第三个团队再写成别的名称，那么语法也许都合法，但语义互通依然很弱。也就是说，盒子可以通用，语言未必通用。

在大型企业、多团队协作和治理要求很强的环境里，这个限制尤其关键。

它不是 RAG 的普遍替代品

更准确的结论并不是“OKF 将替代 RAG”，而是：OKF 让另一类架构开始显得更可信。

如果知识相对稳定、主要面向内部、适合被评审，并且可以被组织成“活文档”，那么一个维护良好的文件夹可能比每次都通过 retrieval 重新拼上下文更有效。相反，如果问题本身依赖动态来源、文档异构性很高、需要实时更新，或者要面对大规模未整理语料的语义检索，那么 RAG 仍然会有非常强的位置。

所以这不是范式被取消，而是工具分工开始变得更成熟。

真正的 moat 不在格式本身

视频里有一个隐含但非常重要的判断：真正的价值不在“文件夹”本身，而在于文件夹是如何被维护的。

两个 knowledge bundle 表面上看起来可以完全一样。一个可以在生产环境里稳定工作数月，因为它清楚规定了哪些内容允许 agent 改写、哪些内容必须锁定、更新如何校验、漂移如何控制。另一个则可能在形式上遵守同一规范，却很快腐烂。

这意味着，竞争优势并不来自“用了 OKF”这件事本身，而来自：

• 稳健的编辑规范；
• 可靠的更新流程；
• 自动写入与人工校验之间清晰的边界；
• 足够稳定的共享语义层。

真正的 moat 不在 Markdown，而在于让 Markdown 长期可信的操作纪律。

值得观察的战略层含义

视频还提示了另一个值得注意的层面：OKF 并不是在真空里出现的。如果这个格式天然可以与 Gemini、BigQuery 以及 Google 自己的知识产品更顺畅地衔接，那么这场标准化就不仅仅是技术动作，也是一种平台定位。

这并不否定 OKF 的价值，但它提醒我们：在 AI 领域，标准往往诞生在架构、工具链和商业策略相互重叠的地方。

结论

Open Knowledge Format 之所以重要，是因为它把 AI agent 的记忆问题重新落回到一个更具体的问题上：你真的需要在每次查询时都重新构造意义，还是更应该提前把一部分意义显式写进一个可读的知识库里？

这套思路的价值，不在于一句“有个文件夹就够了”的口号，而在于它指出：在很多场景下，一种可读、可版本化、像代码库一样被维护的记忆形式，可能比一条不断重复同样工作的复杂流水线更有用。

OKF 本身并不能解决更新、内容质量和语义一致性问题。但它让一个重要的架构方向变得更清楚：对于 AI agent 来说，记忆不只是 retrieval，它也是知识组织、上下文维护，以及长期运营纪律。

而恰恰是在这里，一个设计得当的简单文件夹，确实可能胜过向量数据库。