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 存储经过整理、受版本控制的概念，智能体可以直接读取和更新这些概念。

---