核心结论：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 构建者都在独立解决这个"上下文组装"问题。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 核心理念：格式而非平台
| | |
|---|
| | |
| cat | |
| Markdown + YAML——任何 Agent 能读 | |
| | |
三、OKF 的生态定位：它不是什么
3.1 OKF ≠ 替代 CLAUDE.md
CLAUDE.md 是 Agent 的项目级操作指令——"这个项目怎么构建、怎么测试、代码风格是什么"。OKF 是 Agent 的知识源——"这个表是什么、它和哪个表 join、周活用户的定义是什么"。
两者不冲突——CLAUDE.md 可以指向 OKF Bundle 作为结构化知识来源。
3.2 OKF ≠ 替代 MCP
MCP 提供的是实时工具访问——调用 API、操作数据库、执行命令。OKF 提供的是静态策选知识——表结构文档、指标定义、手册。两者互补——Agent 通过 MCP 执行操作，通过 OKF 理解"为什么这样操作"。
3.3 OKF vs 现有模式的对比
四、Google 实际上交付了什么
4.1 规范本身——极短
完整的 v0.1 规范适用于一页纸。包含：Bundle 结构、Concept 文档格式、交叉链接语义、Index 和 Log 文件约定、合规性标准。
合规性只有三条规则：
- 每个非保留
.md 文件有可解析的 YAML frontmatter - 每个 frontmatter 有非空的
type 字段 - 保留文件名（
index.md、log.md）按约定格式
消费者必须容忍所有其他约束为软性指导——未知 type 值、缺失的可选字段、断开的交叉链接都不应导致拒绝。
4.2 参考实现
| |
|---|
| 遍历 BigQuery 数据集，为每个表/视图起草 OKF 概念文档；第二阶段 LLM 从权威文档中补充引用、结构和 join 路径 |
| 将任意 OKF Bundle 转为交互式图视图——单一自包含 HTML 文件，无后端，无数据离开页面 |
| 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。
| |
|---|
| |
| OKF Bundle（*.md + frontmatter） |
| |
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 文件就可以传输的知识图谱。
粤ICP备14082021号
免费POC，
零成本试错
