Google 发布 Open Knowledge Format (OKF)：AI Agent 知识库的中立标准

Google 推出 OKF 标准，为 AI Agent 知识库互操作提供统一格式，有望终结企业知识管理“永远过时”的困境。核心内容：1. OKF 如何解决传统 Wiki 知识过时和维护难题2. OKF 极简的、无平台锁定的文件结构与设计理念3. 该标准对实现知识碎片统一表达与互操作的意义

核心结论：2026 年 6 月 12 日，Google Cloud 发布 OKF v0.1——一个厂商中立的结构化知识格式标准。它只有一个强制字段（type），没有 SDK，没有平台锁定，没有注册中心。OKF 的本质是：将 Karpathy（5,000+ GitHub star）和 Obsidian 用户已经发现的模式——"让 LLM 维护 Markdown 知识库比让人维护 Wiki 更可靠"——从实践共识提升为可互操作的标准。它回答的不是"怎么存知识"，而是"不同来源的知识怎么互相理解"。

一、OKF 解决的核心问题1.1 "Wiki 永远过时"的诅咒传统企业知识管理有一个根深蒂固的矛盾：最需要文档的时刻（新人入职、跨团队协作、故障排查）恰恰是文档最可能过时的时刻。维护 Wiki 需要人的持续纪律——而人不可靠。结果就是"Wiki 写了一周，过时了一年"。OKF 的核心假设是：AI Agent 不会厌倦、不会忘记更新交叉引用、可以一次修改 15 个文件、不会跳过"以后再说"的文档任务。 人维护 Wiki 失败的原因不是知识不重要，而是维护太折磨人。Agent 没有这个问题。1.2 知识被锁定在"创建它的表面"当一个 Agent 需要回答"我们怎么从事件流计算周活用户？"时，答案碎片分散在：

知识碎片所在	Agent 能否自动获取
元数据目录（表结构）	需要调用特定 API
Wiki / Notion（指标定义）	需要语义搜索 + 可能过时
代码注释（join 逻辑）	需要扫描代码库
人的脑子里（废弃通知、历史坑）	完全不可获取

每个 Agent 构建者都在独立解决这个"上下文组装"问题。OKF 的赌注是：缺失的不是另一个平台，而是一个格式——让所有这些碎片能被统一表达和互操作。二、OKF 的文件结构：极简到只有一个必填字段2.1 一个 Knowledge Bundle 的真实样子

sales/
├── index.md                   # 目录页——渐进式浏览
├── log.md                     # 变更历史（可选）
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
└── metrics/
    ├── index.md
    └── weekly_active_users.md

2.2 一个概念文档

---
type: BigQuery Table               # ← 唯一的必填字段
title: Orders
description: 一行对应一个已完成的客户订单
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---
# Schema
| 列名           | 类型     | 说明                            |
|---------------|---------|-------------------------------|
| `order_id`    | STRING  | 全局唯一订单标识符                 |
| `customer_id` | STRING  | FK 到 [customers](/tables/customers.md) |
# Joins
与 [customers](/tables/customers.md) 通过 `customer_id` 关联。

Markdown 链接将目录转化为图——比文件系统层级更丰富的知识结构。2.3 核心理念：格式而非平台

维度	OKF	传统元数据目录
存储	Git 仓库 / tarball / 本地目录	厂商数据库
读取	cat 一个文件，任何编辑器	需要 SDK 或 API
互操作	Markdown + YAML——任何 Agent 能读	厂商特定 schema
锁定	无——无需账号、无需平台	强锁定

三、OKF 的生态定位：它不是什么3.1 OKF ≠ 替代 CLAUDE.mdCLAUDE.md 是 Agent 的项目级操作指令——"这个项目怎么构建、怎么测试、代码风格是什么"。OKF 是 Agent 的知识源——"这个表是什么、它和哪个表 join、周活用户的定义是什么"。两者不冲突——CLAUDE.md 可以指向 OKF Bundle 作为结构化知识来源。3.2 OKF ≠ 替代 MCPMCP 提供的是实时工具访问——调用 API、操作数据库、执行命令。OKF 提供的是静态策选知识——表结构文档、指标定义、手册。两者互补——Agent 通过 MCP 执行操作，通过 OKF 理解"为什么这样操作"。3.3 OKF vs 现有模式的对比

模式	范围	互操作
CLAUDE.md	项目 Agent 记忆	Claude 生态约定
AGENTS.md	仓库指令（Codex 等）	逐工具采纳
Obsidian + Agent	个人/团队 Wiki	自定制
Karpathy LLM Wiki	Agent 维护的 markdown	模式，非标准
OKF v0.1	组织级知识图谱	厂商中立标准

四、Google 实际上交付了什么4.1 规范本身——极短完整的 v0.1 规范适用于一页纸。包含：Bundle 结构、Concept 文档格式、交叉链接语义、Index 和 Log 文件约定、合规性标准。合规性只有三条规则：

1. 每个非保留 .md 文件有可解析的 YAML frontmatter
2. 每个 frontmatter 有非空的 type 字段
3. 保留文件名（index.md、log.md）按约定格式

消费者必须容忍所有其他约束为软性指导——未知 type 值、缺失的可选字段、断开的交叉链接都不应导致拒绝。4.2 参考实现

组件	功能
BigQuery 丰富 Agent	遍历 BigQuery 数据集，为每个表/视图起草 OKF 概念文档；第二阶段 LLM 从权威文档中补充引用、结构和 join 路径
静态 HTML 可视化器	将任意 OKF Bundle 转为交互式图视图——单一自包含 HTML 文件，无后端，无数据离开页面
示例 Bundle	GA4 电商、Stack Overflow、Bitcoin 数据集——直接在 GitHub 上可浏览

4.3 与 Cloud Knowledge Catalog 的集成Google 已将 Knowledge Catalog 更新为接收 OKF Bundle 并为其 Google Cloud Agent 提供服务——这是在 GCP 上的企业部署路径。五、Karpathy 的 LLM Wiki 与 OKF 的继承关系Andrej Karpathy 的 LLM Wiki gist（5,000+ GitHub star）在 2025 年提出了一个已经在小范围实践但缺乏标准化的想法：让 LLM 维护一个 Markdown 知识库——Agent 自动读取、更新、交叉引用——取代人手动维护的 Wiki。

Karpathy 层	OKF 对应
原始来源（不可变）	外部数据集、文档、API——OKF 从它们编译
Wiki（LLM 维护）	OKF Bundle（*.md + frontmatter）
结构（CLAUDE.md）	生产者/消费者约定 + okf/SPEC.md

OKF 的贡献不是发明了 LLM Wiki 模式——社区已经发现了这个模式。OKF 的贡献是商定每一个文档应该携带哪些字段、哪些文件名有固定含义——让你的 Wiki 和我的 Wiki 和一个目录导出在无需翻译的情况下协作。六、对 AI Agent 生态的长期影响6.1 知识可移植性——首次标准化在 OKF 之前，每个使用 LLM Wiki 模式的团队都在采用略微不同的约定。两份"LLM Wiki"即使内容相似，也无法被同一个 Agent 消费而无需定制的解析器。OKF 将这种差异标准化到了一个易实现的最小公约数——只有一个必填字段，整个规范不到一页纸——让"符合 OKF"的门槛极低，故意让广泛采纳比深度采纳更容易。6.2 企业知识管理的去平台化当知识以 OKF Bundle 的形式存储——一个 Git 仓库里的 Markdown 文件——它对平台是中立的。今天用 Google Cloud Knowledge Catalog 消费 OKF，明天可以换到另一个兼容 OKF 的消费者。没有数据迁移，没有导出格式兼容性问题，没有平台锁定。6.3 Agent 之间知识共享的标准载体OKF 不仅让 Agent 能读知识。它最被低估的特征是：两个 Agent 可以通过交换一个 OKF Bundle 来共享知识，而不需要共享数据库、不需要通过同一个 API、不需要在同一个组织中。这是一个 Zip 文件就可以传输的知识图谱。