---
title: "Google Open Knowledge Format (OKF) v0.1：让 AI 知识库有了通用格式"
source: "AI寒武纪"
source_url: "https://mp.weixin.qq.com/s/nhF1cy_lIQukq_niVFvRCA"
ingested: 2026-06-16
sha256: "44b8630e21f4f4805a53d7c816da09485c1c815bcb92c47481bd389a9a8f7d5b"
type: raw
tags: [okf, open-knowledge-format, google-cloud, knowledge-catalog, knowledge-format, knowledge-base, knowledge-management, markdown, frontmatter, agent-knowledge, llm-wiki, karpathy-wiki, agents-md, claude-md, format-standard, 2026, ai-cambrian]
review_value: 8
review_confidence: 8
---

# Google Open Knowledge Format (OKF) v0.1：让 AI 知识库有了通用格式

**作者**：AI寒武纪 | **发布时间**：2026-06-16 09:00

**参考链接**：
- 开源仓库：https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf
- Google Cloud 官方博客：https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/

## 核心信息

| 维度 | 详情 |
|------|------|
| 名称 | **Open Knowledge Format (OKF) v0.1** |
| 发布方 | Google Cloud Platform |
| 性质 | 开放规范（不是服务、不需要 SDK、不绑定云平台） |
| 核心 | 一个 OKF bundle = 一个 Markdown 文件目录 |
| 配套 | 3 个参考实现 + 3 样例 bundle |
| 集成 | Google Cloud Knowledge Catalog 已支持摄入 OKF |

## 序：AI 能力越强，知识碎片化越致命

公司里 AI agent 需要用到的知识大多是**内部知识**：
- 某张数据表的字段含义
- 某个指标的业务定义
- 某个系统的接入路径
- 某个 API 的废弃通知

这些东西现在住在哪？**到处都是**。元数据目录、内部 Wiki、共享文档、代码注释、资深工程师的脑子里。每个系统有自己的 API，每个平台有自己的数据模型，**互不兼容，互不流通**。

结果就是：每个搭 agent 的团队，都在从头解决同一个问题——怎么把这些散的知识拼起来喂给模型。每家厂商都在重新发明同一套数据结构，而知识本身被**锁死在创建它的那个平台里，出不来**。

## 开发者已经摸索出了解法，但各做各的

过去一年，一个模式在开发者中悄悄流行起来：**用 Markdown 文件给 AI agent 建一个知识库，让 agent 自己去读、去更新**。

这个思路被 AI 研究者 **Andrej Karpathy** 表达得最清楚：LLM 不会感到无聊，不会忘记更新交叉引用，一次可以同时改 15 个文件。人类维护个人 Wiki 最终放弃，往往就是败在这些琐碎的更新工作上，而这恰恰是 LLM 最擅长的。

这个模式以不同的名字反复出现：
- 接入编程 agent 的 **Obsidian 知识库**
- **AGENTS.md** 和 **CLAUDE.md** 这类约定文件
- 数据团队用来当代码管理的**元数据仓库**

**但问题在于**：每家做法都是定制的。Karpathy 的 Wiki 和你团队的 Wiki 和某家厂商导出的目录，长得像（都是 Markdown、都有 frontmatter、都有交叉链接），但它们并没有被设计成可以互通的。**没有人约定每个文档应该有哪些字段，也没有人约定文件名代表什么含义**。

知识还是被锁在各自的团队里，每次搭新 agent 都得重新造轮子。

## OKF 给的答案：一个格式，不是又一个平台

OKF 是一个**格式规范**，不是服务，不需要 SDK，不绑定任何云平台。

核心设计很简单：**一个 OKF bundle 就是一个 Markdown 文件目录，每个文件代表一个概念**（可以是数据表、数据集、指标、操作手册、API 等），文件路径就是这个概念的唯一标识。

### 目录结构示例

```
sales/
├── index.md
├── datasets/
│   └── orders_db.md
├── tables/
│   ├── orders.md
│   └── customers.md
└── metrics/
    └── weekly_active_users.md
```

### 文件结构

每个文件有两个部分：
- **顶部一小块 YAML frontmatter**：存储可以被查询的结构化字段
- **下面是 Markdown 正文**：写什么内容完全自由

### 完整概念文件示例

```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). |

# Joins

Joined with [customers](/tables/customers.md) on `customer_id`.
```

**概念之间用普通的 Markdown 链接互相引用**，整个目录就变成了一张关系图，比文件系统的父子层级丰富得多。

整个 v0.1 规范，**一页纸能写完**。

## 三个设计原则（缺一不可）

### 1. 最小约束
OKF 对每个文件只强制要求一件事：**必须有 type 字段**。其他字段、文件体的内容和结构，全由使用者决定。规范管的是**互通的边界**，不是内容本身。

### 2. 生产者和消费者彼此独立
- 人手写的知识文件，可以被 AI agent 读取
- 元数据导出流水线生成的 bundle，可以在可视化工具里浏览
- 一个 LLM 生成的 bundle，可以被另一个 LLM 查询
- **格式是契约，两端的工具可以独立替换**

### 3. 格式本身，不是平台
- OKF 不绑定任何云服务、数据库、模型厂商或 agent 框架
- 读写它不需要任何专有账号或 SDK
- 谷歌选择把它作为开放标准发布，因为**知识格式的价值来自有多少人在用它，不是来自谁拥有它**

## 三个参考实现（同步发布）

光有规范不够，谷歌同时发布了配套工具，降低试用门槛。

### 1. 数据丰富 agent
自动扫描 BigQuery 数据集，为每张表和每个视图起草一份 OKF 概念文档，**然后再跑一遍 LLM，爬取权威文档，补充 schema、引用和关联路径**。

### 2. 静态 HTML 可视化工具
把任意 OKF bundle 转成一个可以交互的图视图，**单个自包含文件，不需要后端，不需要安装，数据不离开本地**。

### 3. 三个样例 bundle
- GA4 电商数据集
- Stack Overflow
- 比特币公开数据集

都是用上面那个参考 agent 生成的，提交在 repo 里作为格式合规的活示例。

**谷歌特别说明**：这三个工具是概念验证，不是唯一实现方式。格式对工具没有要求，生产者和消费者的生态系统可以自由生长。

## 现在能做什么

- 谷歌已更新 **Google Cloud Knowledge Catalog**，支持摄入 OKF 格式并把它提供给 agent 使用
- 规范、参考实现和样例 bundle 都在 GitHub 上开放
- 目前是 **v0.1**，显式为向后兼容扩展而设计
- **行动建议**：
  1. 读规范（很短）
  2. 给你的数据源写一个生产者
  3. 给你的使用场景写一个消费者
  4. 对着自己的数据跑一下参考实现
  5. 有问题就提 issue 或 PR

## OKF 与现有 LLM Wiki 范式的关系

OKF 不是要替代 Karpathy Wiki / Obsidian Wiki / GBrain，而是**给它们之间的互通性提供一个格式契约**。

| 范式 | 关系 | OKF 互补点 |
|------|------|-----------|
| Karpathy LLM Wiki | 个人第二大脑（自组织） | OKF 提供标准 frontmatter 字段和目录约定 |
| Obsidian Wiki | 接入编程 agent | OKF 的 `type` + Markdown 链接兼容 Obsidian 双链 |
| AGENTS.md / CLAUDE.md | 单文件约定 | OKF bundle 是这些文件的"扩展到目录"版本 |
| GBrain | Postgres 持久化 + 知识图谱 | GBrain 可消费 OKF bundle 作为输入源 |
| Hermes Wiki | 9 步自动生长 | OKF 可作为其输出格式 |

**核心洞察**：OKF 抓住了"长得像但互不通用"的痛点——之前的范式都是**单团队、单平台、单格式**的实践，OKF 把"互通边界"从"私有约定"提到"开放规范"。

## 关联引用

→ [[entities/llm-wiki-obsidian-wiki-gbrain-self-organization-self-evolution|LLM Wiki / Obsidian Wiki / GBrain 自组织自进化]] — 同领域不同项目对比
→ [[entities/karpathy-llm-wiki-second-brain-awkthole|Karpathy LLM Wiki 第二大脑 (awkthole)]] — Karpathy Wiki 详细解析
→ [[entities/karpathy-llm-wiki-v2-2026|Karpathy LLM Wiki v2 (2026)]] — Karpathy Wiki 2026 更新
→ [[entities/llm-wiki-architecture|LLM Wiki Architecture]] — LLM Wiki 架构
→ [[entities/obsidian-llm-wiki-local-kytmanov|Obsidian + LLM Wiki 本地化 (kytmanov)]] — Obsidian 集成 LLM Wiki
→ [[entities/knowledge-mgmt-is-moat|知识沉淀是护城河]] — 知识管理护城河论述
→ [[entities/tencent-knowledge-harness-practice|腾讯知识 Harness 实践]] — 腾讯系知识管理
→ [[entities/create-custom-mcp-catalogs-and-profiles|Create Custom MCP Catalogs and Profiles]] — MCP 目录 vs OKF bundle 关系
→ [[raw/articles/google-okf-open-knowledge-format-v0-1-2026|原文存档（本篇）]]