OKF 是一种格式，而非服务或平台。OKF v0.1 将知识表示为包含 YAML 前置元数据的 Markdown 文件目录。通过一套约定俗成的少量规范，由某一生产者编写的 wiki 可以被不同的智能体直接使用，无需进行格式转换。
这就是核心理念。它没有压缩方案，没有新的运行时环境，也不需要特定的 SDK。一组 OKF 文档本质上就是 Markdown、就是文件、就是 YAML 前置元数据。它可以在 GitHub 上渲染，以 tarball 形式分发，并能挂载到任何文件系统上。
如果你使用过 Obsidian、Notion 或 Hugo，你会对这种形式感到熟悉。OKF 只是将实现这些模式互操作性所需的规范进行了正式化。
碎片化的上下文问题
在大多数组织中，模型上下文绝大部分是内部知识。目前，这些知识分散在互不兼容的孤岛中：拥有各自 API 的元数据目录、wiki、共享驱动器、代码注释和文档字符串。
让一个智能体去问“如何从我们的事件流中计算周活跃用户数？”它必须从分散且互不兼容的多个数据源中拼凑出答案。每个供应商都提供自己的目录、SDK 和知识图谱模式。没有任何知识可以在不同产品或组织之间移植。
结果是重复劳动。每个智能体构建者都要从头解决相同的上下文组装问题。每个目录供应商都在重新发明相同的数据模型。
Andrej Karpathy 在他 2026 年 4 月的 LLM Wiki 要点中阐述了这一核心理念。他的观点是：大语言模型不会感到厌倦，不会忘记更新交叉引用，并且可以一次性编辑多个文件。那些让人类放弃个人 wiki 的簿记工作，恰恰是大语言模型所擅长的。
同样的模式以不同的名称反复出现。例如，连接到编码智能体的 Obsidian 仓库、AGENTS.md 和 CLAUDE.md 约定文件，以及“元数据即代码”仓库。每个实例都是定制的，因此它们之间无法互操作。OKF 将这一互操作层标准化，以便智能体能够承担繁重的工作。
OKF 如何工作：一屏之内的设计
一个 OKF 包是一个 Markdown 文件目录，代表各种概念——表、数据集、指标、操作手册、运行手册或 API。每个概念对应一个文件，文件路径就是它的标识。
sales/
├── index.md
├── datasets/
│ ├── index.md
│ └── orders_db.md
├── tables/
│ ├── index.md
│ ├── orders.md
│ └── customers.md
└── metrics/
├── index.md
└── weekly_active_users.md每个概念都带有一个简短的 YAML 前置数据块，其余内容则使用 Markdown 正文。
---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---
# Schema
| Column | Type | Description |
|---------------|--------|------------------------------------------|
| `order_id` | STRING | Globally unique order identifier. |
| `customer_id` | STRING | FK to [customers](/tables/customers.md). |保留的结构化字段包括：类型、标题、描述、资源、标签和时间戳。概念之间通过普通的 Markdown 链接相互关联。这些链接将目录转化为一个比文件系统父子关系更丰富的图谱。数据包（Bundle）可以可选地包含用于渐进式展示的 `index.md` 文件和用于变更历史的 `log.md` 文件。
设计背后的三大原则
- 最小化意见：OKF 要求每个概念只有一个必填字段：类型。其余所有内容都由生产者自行决定。该规范定义的是互操作接口，而非内容模型。
- 生产者/消费者独立：人工编写的数据包可以被智能体读取；流水线生成的数据包可以在可视化工具中浏览。格式是约定，两端的工具可以互换。
- 格式，而非平台：OKF 不绑定任何云服务、数据库、模型提供商或智能体框架。它永远不会要求使用专有账户来读取、写入或提供服务。
用例及示例
- 数据团队的元数据即代码：将 BigQuery 表和指标定义导出为一个数据包。将其提交到它所描述的 SQL 文件旁边，并通过拉取请求（Pull Request）审查变更。
- 智能体的事故处理手册：将每个操作手册存储为一个概念。值班智能体读取 `index.md`，跟随交叉链接，并解析出它所需的连接路径。
- 跨组织知识交换：供应商以 OKF 格式提供目录导出。你的智能体可直接使用它，无需任何集成工作。
- 开发者团队维基：用版本化的 Markdown 替换过时的 Notion 或 Obsidian 空间，并由智能体保持其最新状态。
OKF 对比
| 方案 | 存储方式 | 是否需要 Schema | 可移植性 | SDK/注册中心 | 智能体可读 |
|---|---|---|---|---|---|
| OKF v0.1 | Markdown + YAML 文件 | 仅需 type | 是 | 否 | 是，无需转换 |
| Notion | 专有数据库 | 按工作区 | 仅支持导出 | 需要 API | 通过 API |
| Obsidian 库 | Markdown 文件 | 无强制要求 | 是 | 否 | 自定义约定 |
| 元数据目录 | 供应商存储 | 供应商 Schema | 仅支持导出 | 供应商 SDK | 供应商特定 |
| RAG 索引 | 向量存储 | 嵌入模型 | 否 | 是 | 是分块，而非概念 |
与 RAG 的区别对开发者很有用。RAG 在查询时从原始文本块中重新推导知识。而 OKF 包则存储经过整理、相互关联的概念，智能体可以直接读取和更新这些概念。
一个极简的 OKF 消费者
OKF 可使用标准工具进行解析。以下代码读取一个包并构建其链接图。
import pathlib, re, yaml
def load_bundle(root):
concepts, links = {}, []
for path in pathlib.Path(root).rglob("*.md"):
text = path.read_text()
meta = {}
if text.startswith("---"):
_, fm, body = text.split("---", 2)
meta = yaml.safe_load(fm) or {}
else:
body = text
concepts[str(path)] = meta # type, title, tags, etc.
for target in set(re.findall(r"\]\((/[^)]+\.md)\)", body)):
links.append((str(path), target)) # markdown cross-links
return concepts, links
concepts, graph = load_bundle("sales/")读取或提供包服务无需后端或安装。这些文件与它们所描述的代码一同存放在版本控制系统中。
关键要点
- 谷歌的开放知识格式（OKF）v0.1 将 LLM-wiki 模式形式化为一个可移植、厂商中立的规范。
- 一个包只是一个包含 YAML 前置元数据的 Markdown 文件目录——无需 SDK、运行时或注册表。
- 每个概念只需要一个字段，即 type；文件之间的交叉链接构成了知识图谱。
- 谷歌发布了参考工具：一个 BigQuery 增强智能体、一个静态 HTML 可视化工具，以及三个示例包。
- 与 RAG 不同，OKF 存储经过整理、受版本控制的概念，智能体可以直接读取和更新这些概念。