知识不应被设限

背景

过去几年，给 AI 系统注入“知识”几乎等同于搭建一套基础设施。你想让你的智能体了解公司的业务、数据和决策，于是拿起标准剧本：切分文档、选一个嵌入模型、部署向量数据库、调优检索、包上 SDK。如果野心再大一些，还会在上面建一个知识图谱。等这一切做完，公司的知识不再是可以直接阅读的东西，而是变成了通过管道、服务、被某个框架锁定的查询对象。

这套方法曾经合理——当上下文窗口很小、模型很贵时，检索增强生成（RAG）解决了真实问题。你无法把整个知识库塞进提示词，所以就检索相关片段，只喂那一段。Graph RAG 更进一步，构建实体和关系的结构化图谱，让模型能跨连接推理而不是孤立块。但问题在于，这些技术付出了隐秘的代价：知识一旦进入管道，就变得只有系统能理解，人类无法直接读取。

核心内容

原文的核心观点是：知识不应该被“门控”——这里的门控指的不是付费墙，而是“格式墙”。你的文档变成嵌入向量，关系变成数据库中的边，知识在进入管道的那一刻就失去了人类可读性。如果你想看看智能体“真正知道”什么，你没法打开一个文件，而必须用同样的检索机制去查询。而且每个团队都在重复造轮子，每个智能体构建者都在解决同样的上下文组装问题，每个目录产品都在重新发明同样的数据模型。知识最终被锁在了它被创造的那个表面背后，格式不通，下一个工具需要翻译器才能读懂。

然而，在人们日常与智能体打交道时，一个更安静的趋势出现了：他们开始写 markdown。如果你用过 Claude Code 或 Codex，你肯定写过 CLAUDE.md 或 AGENTS.md，没把它当成什么架构——就是记下项目怎么工作、遵守什么惯例、别碰哪些东西，然后智能体就变好了。没有嵌入向量，没有向量存储，只有一个文件，模型在每个会话一开始就读取它。

这个模式在不同的名字下反复出现：Obsidian 里充满链接笔记的库、DESIGN.md 描述某个东西该长什么样、MEMORY.md 记录智能体两次运行之间该记住什么、“元数据即代码”仓库。每一个都是同一个直觉：把知识写成纯文本，用链接串起来，让模型直接读。

结果是，LLM 真正擅长、可靠的格式，恰恰是我们一直认为太原始而不值得去标准化的那个。Markdown 有结构但没有繁文缛节：标题、列表、链接、一点 frontmatter。它正好足够让模型导航，又正好少到人类也能一眼看懂同一个文件。我们花了多年时间试图把知识压缩成机器能查询的东西，结果发现机器更愿意直接阅读。

Andrej Karpathy 给他的 LLM Wiki 模式取了个名字，让这一切更明确了。这个模式是一个三层设置，全部是纯文件：

• sources/ 目录：原始材料，模型视为不可变、从不编辑。
• wiki/ 目录：模型生成并拥有的 markdown 页面——摘要、概念页、实体页，以及将它们联系起来的综合内容。
• 一个 schema 文件（CLAUDE.md 或 AGENTS.md）：告诉智能体如何维护整个系统——页面怎么结构、新源如何接入、交叉引用如何保持最新。

Karpathy 的关键洞察彻底重新定义了 RAG。他说：“LLM 不会感到无聊，不会忘记更新交叉引用，能一次处理 15 个文件。导致人类放弃个人维基簿的那些记账工作，恰恰是 LLM 擅长的。” 个人维基簿总是因为同一个原因消亡：保持更新很枯燥，人类讨厌枯燥。但枯燥正是语言模型免疫的——它们会开心地重新链接、重新总结、在上百个文件间协调矛盾而不抱怨。

于是权衡翻转了。RAG 在每次查询时从零开始重新发现你的知识，每次重新检索并重新组装上下文。而 wiki 把知识编译一次并保持最新。交叉引用已经在那里，矛盾已经被标记，综合内容已经反映你喂过的一切。你不需要为每个问题支付检索税，你读的是一个已经被组织好的东西。而且全是文件——你可以打开、编辑、放 git。知识没有被任何东西门控。

这就是 Google 推出的 Open Knowledge Format (OKF) 的背景。2025 年 6 月，Google Cloud 发布了 OKF 0.1 版。一句话描述是：“一个开放规范，把 LLM-wiki 模式形式化为可移植、可互操作的格式”。更直白地说：它把大家已经在做的 markdown-wiki 直觉变成厂商中立的规范，这样某个工具产生的文件可以被任何其他工具直接读取，无需翻译。

OKF 包是一个 markdown 文件的目录，每个文件对应一个概念：数据集、表、指标、运行手册、API 等等。它们放在合理的层级里，比如 sales/datasets/orders_db.md、sales/tables/orders.md、sales/metrics/weekly_active_users.md 等。每个文件开头有一段 YAML frontmatter 来存放结构化可查询字段：

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?...
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

规范只强制要求 type 一个字段，其余都是可选约定。标准可查询字段是 type, title, description, resource, tags, timestamp。概念之间通过普通的 markdown 链接互相引用（例如 [customers](/tables/customers.md)），这些链接把目录变成一张关系图，比文件夹暗示的父子嵌套更丰富。你得到了图 RAG 的好处——结构化的连接网——却不需要部署图数据库。链接就是图。可选的 index.md 支持智能体在层级中渐进式探索，可选的 log.md 记录变更历史。整个模型就这么简单。

Google 自己描述它不是什么：“没有复杂的压缩方案，没有新运行时，没有必需的 SDK。就是 markdown，任何编辑器都能读、GitHub 能渲染；就是文件，能打包、能放 git 仓库、能挂在文件系统上；就是 YAML frontmatter，处理那几个结构化字段。” 规范清晰地分离了知识的写者和消费者：人可以手动写一个包，也可以由管道生成一个包，而智能体、搜索工具或纯 markdown 查看器都能读。没有锁定，没有 SDK。

关键要点

• 从“查询知识”回归“阅读知识”：过去 RAG 把知识变成嵌入向量和数据库边，人类无法直接读取；现在 markdown/wiki 模式让知识重回纯文本文件，人和模型都能直接读。
• LLM 天然擅长维护结构化纯文本：Karpathy 指出，LLM 不会厌倦更新交叉引用、不会忘记同步，它们一次性处理多个文件的苦活正是人类放弃个人维基的原因。这翻转了 RAG 的权衡——一次性编译知识并保持最新，而不是每次查询都重新检索。
• 社区已经在自然使用 markdown 文件指导智能体：CLAUDE.md、AGENTS.md、DESIGN.md、Obsidian 笔记等，都是同一个直觉：用 markdown 写下来，让模型在读 session 开始时直接读。
• Google 的 Open Knowledge Format (OKF) 把模式标准化：0.1 版本定义一个目录结构、每个 markdown 文件代表一个概念、用 YAML frontmatter 存结构化字段、用普通 markdown 链接构成关系图。不需要向量数据库、图数据库或专用 SDK。
• OKF 的核心设计是“零锁定的格式墙”：它既不是压缩方案也不是新运行时，而是纯粹的文件包。任何工具（agent、搜索工具、markdown 编辑器）都能读取，无需翻译器。知识不会被锁在某一个供应商或框架后面。

意义与影响

这篇文章背后的核心转变，是从“为机器优化”（让知识变成机器查询友好的压缩形式）转向“为人机共读优化”（让知识恢复为人类可读的文本，同时模型也能直接理解）。OKF 的出现标志着一个行业共识的落地：知识不应该被专用基础设施门控。它的影响可能体现在