知识不应被关在笼子里：当 RAG 遇上 Markdown
在过去几年的大部分时间里，让 AI 系统拥有知识意味着搭建基础设施。
你希望你的 Agent 了解关于你的业务、数据、决策的信息。于是你拿出了标准方案：切分文档、选一个 Embedding 模型、搭一个向量数据库、调优召回、用 SDK 封装。如果还有雄心，再在上面建一个图结构。
等这一切做完，公司的知识已经不再是你能够阅读的东西了。它是一个你通过管道查询、藏在服务后面、归属于你碰巧选择的某个框架的东西。
我想论证一个早已悄悄成立、如今愈发明显的事实：那整套方案将原本无需设限的知识关进了笼子里。而纠正的方法简单到令人尴尬——它就是 Markdown。
将知识锁在工具背后的时代
RAG 是一个好想法。我并非来批评它的。
在上下文窗口很小、模型很昂贵的年代，检索增强生成了（Retrieval-Augmented Generation）确实解决了一个真实的问题。你无法将整个知识库塞进一条提示词（Prompt），所以你需要检索相关切片，只喂那部分给模型。Graph RAG 则更进一步，构建了实体与关系的结构化图，让模型能在关联之间而非孤立片段上进行推理。
这些技术确实有效。但看看它们的代价是什么。
要将知识放进 RAG 系统，你必须先把它转换成只有系统能理解的形式。你的文档变成了 Embedding（嵌入向量），你的关系变成了数据库中的边。知识从进入管道的那一刻起就不再可读。如果你想看看你的 Agent 到底"知道"什么，你不能直接打开一个文件，你必须运行一个查询，走一遍当初把它锁起来的同一套机制。
而且每个团队都在从头重建这一切。每一个 Agent 构建者都在解决同一个上下文组装问题。每一个目录供应商都在重新发明相同的数据模型。知识最终被困在了创造它的表面（Surface）背后，以另一种工具不经过翻译就无法读取的格式存在着。
那就是那道门。不完全是付费墙。是一道格式墙。你自己的知识，被那些本应让它变得有用的工具，变得不可读。
我们不断重新发现的事情
就在所有这些基础设施被搭建起来的同时，有一件更安静的事情正在发生——人们与 Agent 日常协作的方式。
他们开始写 Markdown。
如果你用过 Claude Code 或 Codex，你应该写过 CLAUDE.md 或 AGENTS.md，当时并没把它当作架构来思考。你写下了项目如何运作、该遵循什么约定、哪些不能碰，Agent 就变得更好了。没有 Embedding，没有向量存储，只是一个模型在每个会话开始时都会读取的文件。
这种模式以不同的名称反复出现：装满双向链接笔记的 Obsidian 仓库、描述设计方案的 DESIGN.md、让 Agent 在运行之间记住信息的 MEMORY.md。每一个都是同一个直觉：把知识写成纯文本，把各部分链接起来，让模型直接读取。
事实证明，LLM 真正、可靠擅长的格式，恰恰是我们一直认为太原始而不值得标准化的那种。Markdown 有结构但没有仪式感。标题、列表、链接、一点点 Frontmatter（前置元数据）。它给模型提供了刚好够用的导航骨架，同时也刚好少到人类可以阅读同一个文件并瞬间理解。
我们花了数年时间试图把知识压缩成机器可以查询的东西。结果，机器更愿意直接阅读。
Karpathy 说出了那句潜台词
Andrej Karpathy 用他的 LLM Wiki（LLM 维基）模式给它起了个名字，这让我对整个事情豁然开朗。
这个想法是一个三层结构，全部用纯文本文件。一个 sources/ 目录存放原始材料，模型将其视为不可变的、永不编辑。一个 wiki/ 目录存放 Markdown 页面，由模型生成并拥有：摘要、概念页面、实体页面、将它们联系起来的综合文档。以及一个 schema 文件（CLAUDE.md 或 AGENTS.md），告诉 Agent 如何维护整个体系。
它底层的那份洞察，完全重构了 RAG。Karpathy 的原话值得引用："LLM 不会觉得无聊，不会忘记更新交叉引用，一次能处理 15 个文件。那种导致人类放弃个人维基的记账式工作，正是 LLM 所擅长的。"
个人维基的消亡总是同一个原因：保持它们的最新状态很繁琐，而人类讨厌繁琐。但繁琐恰恰是语言模型所免疫的。它们会愉快地跨成百上千个文件重新链接、重新总结、协调矛盾，毫无怨言。
于是，权衡翻转了。RAG 在每次查询时都从头重新发现你的知识——每次重新检索、重新组装上下文。而维基模式则一次性地编译知识，并保持其最新。交叉引用已经在那里了，矛盾已经被标记了，综合文档已经反映了你喂给它的全部内容。你不再为每个问题支付检索税（Retrieval Tax），你是在阅读一件已经被组织好的东西。
而且它全都是文件。你可以打开它们，可以编辑它们，可以把它们放进 Git。知识没有被关在任何人造门之后。
Google 实际发布了什么
这就是开放知识格式（Open Knowledge Format，简称 OKF）登场的背景。今年六月，Google Cloud 发布了 OKF，目前版本为 0.1。用一句话描述，它是"一个开放的规范，将 LLM-Wiki 模式形式化为一种可移植、可互操作的格式。"说得更直白些：它把每个人已经在做的事——Markdown Wiki 的直觉——变成了一种供应商中立的标准。
一个 OKF 包是一个 Markdown 文件的目录。每个文件对应一个概念：一个数据集、一张表、一个指标、一本操作手册、一个 API。它们按合理的层级结构排列：
sales/
├── index.md
├── datasets/
│ └── orders_db.md
├── tables/
│ ├── orders.md
│ └── customers.md
└── metrics/
└── weekly_active_users.md每个文件都带有 YAML 前置元数据（Frontmatter），用于结构化字段：类型（type）、标题（title）、描述（description）、资源（resource）、标签（tags）、时间戳（timestamp）。规范要求且只要求一个字段：type。其余全部是可选的约定，你可以遵循也可以忽略。
我反复回味的是 Google 如何描述它不是什么："就这些。没有复杂的压缩方案，没有新的运行时环境，不需要任何 SDK。"
它"仅仅是 Markdown"，任何编辑器都能阅读，GitHub 上即可渲染。它"仅仅是文件"，可以作为 tarball 分发，托管在 Git 仓库中，挂载到文件系统上。
为什么一个平淡无奇的格式才是最有意思的部分
人们很容易把 OKF 读作一个虎头蛇尾的东西。一个带一个必填字段的 Markdown 文件夹算不上什么技术成就。你完全可以自己花一个下午建好它——而且很多人确实已经这样做了。
但恰恰是这一点让它如此重要。
知识的困难从来不是表达能力的问题。是互操作性的问题。每个人都有自己的 Markdown 文件夹、自己的 Frontmatter 约定、自己的链接方案。每一个在孤立环境下都运作良好，但对下一个工具毫无用处。
一个标准并不会让单个包变得更好。它让所有包都变得可移植。当一条元数据管道、一份手写操作手册和一个 Agent 生成的记忆都用同一种 Markdown 方言交流时，知识就不再是每次穿越边界都要重新编码的东西，而是可以自由流动的东西。这个格式平淡无奇，恰恰是它的特性。平淡，才能传播。
我想在整个演进线索下划一条线：我们试图通过让知识变得复杂来让它变得强大，而复杂正是把它关起来的东西。能让它重获自由的，是一个足够简单的约定——让一个初级工程师、一个高级工程师的笔记、一条数据管道和一个语言模型都能读取同一个文件，并对其所述内容达成一致。
知识不应被关在笼子里。 不应被关在向量数据库后面，不应被关在 SDK 后面，不应被关在供应商的专有目录后面，也不应被关在你自己的精巧工具后面。它应该放在你能打开的文件里，放在机器已经熟练掌握的格式里，组织得足够好——让你和你的 Agent 都能找到所需的东西。
同样的教训，低了一层
我在 Formaly 时一直在思考这一点，因为我们也从事知识行业，只不过是在管道的前端而非后端。
问卷是一个知识收集工具。当有人完成一次 Formaly 访谈时，产出的不是表格行，而是理解：客户为什么流失、用户被什么困扰、产品在哪方面不足。旧的本能会把这些洞察锁在仪表盘后面。
OKF 的教训在这里同样适用。你收集的知识应该与你存储的知识一样可读、可移植。一条回复、一份摘要、一篇跨越一千份访谈的综合报告——这些也是概念，它们应该以你的工具、Agent 和团队成员都能无需经过产生它们的系统许可就能阅读的形式存在。
基础设施时代教会我们把知识关起来才能让它有用。事实证明，真相恰恰相反：当你停止设限时，知识才开始变得有用。Google 只是把它写成了一个规范。我想，很快会有更多的工具跟随这个趋势。
原文出处：formaly.io
