知识库标准来了：谷歌发布 Open Knowledge Format (OKF)

GitNoob

874人浏览 · 2026-06-16 17:03:26

GitNoob · 2026-06-16 17:03:26 发布

谷歌发布 Open Knowledge Format (OKF)：AI 时代的知识库通用语，会成为下一个 Markdown 吗？

2026 年 6 月，Google Cloud 悄悄发布了一份名为 Open Knowledge Format (OKF) 的开放规范。它没有华丽的发布会，也没有铺天盖地的营销，但当我读完整篇博客时，意识到这可能是过去几年里 AI 工程领域最值得关注的"基础设施级"提案之一。

这篇文章会带你完整理解：OKF 是什么、它想解决什么真实痛点、技术细节长什么样、与现有方案的关系，以及为什么我觉得它值得每一个做 AI Agent、数据平台、企业知识管理的人认真看一眼。

一、先抛一个真实场景：你的 Agent 真的"懂"你的业务吗？

假设你是一家电商公司的数据工程师，老板让你搭一个"销售分析 Agent"，自然语言进、SQL 出、报告自动生成。听起来很美好，但你真正动手时会发现一个尴尬的事实：

表 schema 在 BigQuery / Snowflake 的元数据里
"周活跃用户"的精确口径在 Confluence 的某个 Wiki 页
历史上某次脏数据修复的原因写在 Slack 的某条消息
一个被废弃的字段，注释藏在 GitHub 仓库的 dbt 模型里
还有一些"只有老王知道"的隐性知识，根本没写下来

Agent 想回答"上周华东区订单 GMV 异常下跌的原因"，它需要把上面所有这些上下文拼起来。于是你开始写一堆胶水代码：调元数据 API、爬 Wiki、Embedding 搜索、prompt 拼接……

然后下一个团队做另一个 Agent，又重新写了一遍。再下一家公司，再来一遍。

这就是 OKF 想终结的事情。

二、OKF 是什么？一句话不够，那就三段话

第一段 —— 它的本质
OKF 是一个文件格式标准，不是平台、不是 SaaS、不是 SDK。形式上就是一个 Markdown 文件目录，每个 .md 文件代表"一个知识概念"，文件顶部用 YAML frontmatter 标注元信息，文件之间用普通 Markdown 链接互相引用。

第二段 —— 它的定位
你可以把 OKF 理解为"AI 知识库领域的 OpenAPI / Markdown"——一个最小、开放、厂商中立的约定，让不同的工具、不同的 Agent、不同厂商的产品，都能用同一种方式生产和消费知识。

第三段 —— 它的姿态
v0.1，刚发布，规范极简（只有一个字段是强制的：type），明确欢迎社区贡献和扩展。Google 自己也只是"使用者之一"——Google Cloud Knowledge Catalog 已经支持摄入 OKF，但格式本身和 Google 解耦。

三、为什么是现在？Agent 时代的"上下文碎片化危机"

OKF 博客里有一段话我觉得点破了关键：

过去十年，我们把"数据"标准化了（Parquet、Iceberg、Arrow），但我们从来没有把**“关于数据的知识”** 标准化。

在 LLM 出现之前，这件事不要紧——人类有耐心去四处翻 Wiki、问同事。但当 Agent 成为知识消费的主力时，碎片化的代价被指数级放大：

知识载体	对人友好度	对 Agent 友好度	可移植性
元数据目录（DataHub/Atlas）	中	需专属 API	差
Wiki / Confluence	高	需爬虫+清洗	差
代码注释 / dbt docs	中	需解析	中
Slack / 邮件历史	低	几乎为零	极差
老员工大脑	—	—	零

每个 Agent 框架都在重新发明"上下文组装层"；每个数据目录厂商都在重新定义自己的元数据模型；每次换工具，知识就要重新迁移一遍。

OKF 的赌注是：用一种极简、人类可读、Agent 可直接消费的格式，把这些知识"原生"地写下来，从此不再需要中间翻译层。

四、技术细节：OKF 到底长什么样？

4.1 目录结构

一个典型的 OKF Bundle 就是一个普通文件夹：

sales/
├── index.md                    # bundle 入口，给 Agent 做渐进式导航
├── log.md                      # 变更历史
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
├── metrics/
│   ├── index.md
│   └── weekly_active_users.md
└── runbooks/
    └── gmv_anomaly_response.md

关键设计：

文件路径即概念身份（/tables/orders.md 就是 orders 表的"URI"）
index.md 让 Agent 可以一层一层往下"探"，不必一次性吃下全部内容
log.md 记录知识本身的演化——这点对 RAG 场景非常重要

4.2 单个文件的样子

---
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, core]
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). |
| `gmv_cny`     | NUMERIC| 已扣除退款的实付金额，单位人民币元.       |

# Joins

通常与 [customers](/tables/customers.md) 通过 `customer_id` join。
口径细节见 [周活跃用户指标](/metrics/weekly_active_users.md)。

# 常见坑

- 2025 年 11 月之前的 `gmv_cny` 包含运费，之后不包含（见 [log.md](/log.md#2025-11-15)）
- 退款是异步回写的，T+1 才稳定

注意这份文档同时满足三件事：

人能读（GitHub 渲染就是一份漂亮文档）
Agent 能直接吃（Markdown + YAML，几乎所有 LLM 都原生理解）
关系是图状的（通过链接形成知识图谱，不只是父子目录）

4.3 规范的"极简主义"

整个 v0.1 规范里，只有 type 字段是强制的。其他常见字段都是约定但非必须：

字段	是否必填	用途
`type`	✅ 唯一必填	描述这是什么类型的知识（表/指标/runbook/API…）
`title`	推荐	人类可读标题
`description`	推荐	简短摘要，给 Agent 做候选筛选
`resource`	推荐	指向底层资源的 URL（BigQuery 控制台、API 文档等）
`tags`	可选	标签，便于检索
`timestamp`	可选	最后更新时间

这种"极简强制 + 丰富可选"的设计哲学，和早期 Markdown、JSON Schema、OpenAPI 如出一辙——先让所有人都能上车，再让生态自然长出约定。

五、三大设计原则

OKF 博客里反复强调三个词，值得拆开讲：

5.1 Minimally Opinionated（最小化约束）

只规定"骨架"，把"血肉"留给使用者。你可以用 OKF 描述数据表，也可以用它描述运维 playbook、API 弃用通知、甚至你公司的人力流程。

5.2 Producer / Consumer Decoupled（生产者与消费者解耦）

写入者和读取者完全独立——

生产者可以是：人手写、LLM 抓取生成、ETL 管道导出、IDE 插件
消费者可以是：另一个 Agent、搜索引擎、可视化工具、QA 系统

二者之间不需要任何协议协商，只要都遵守 OKF 格式即可。

5.3 Format, Not Platform（是格式，不是平台）

不需要注册账号、不需要专属 SDK、不依赖任何云。一个 .tar.gz 压缩包 + git clone 就能流转。这一点是 OKF 与 DataHub、Atlas、Collibra 这类"平台型"方案的根本区别。

六、Google 同时开源的参考实现

光有规范不够用，Google 配套放出了三件套：

6.1 Enrichment Agent（自动生成器）

一个 Agent，自动遍历你的 BigQuery 数据集：

第一轮：为每个表/视图生成 OKF 文档骨架
第二轮：抓取你的内部 Wiki、dbt 文档、PR 历史，丰富 schema 描述、join 路径、常见坑

这意味着你不需要"先手写一堆 Markdown"才能用上 OKF——可以从存量元数据自动 bootstrap。

6.2 静态 HTML 可视化器

一个单文件、无后端的 HTML，把任意 OKF bundle 渲染成交互式图谱视图。数据完全留在浏览器里，不上传任何地方。对内部敏感数据特别友好。

6.3 三个公开示例 Bundle

GA4 电商
Stack Overflow 公开数据集
Bitcoin 区块链公开数据集

可以直接 clone 下来跑，5 分钟就能看到效果。

仓库地址：github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf

七、和你已经在用的东西什么关系？

OKF 不是凭空冒出来的，它形式化了过去两年社区里自发涌现的多种相似模式：

已有实践	与 OKF 的关系
Karpathy 的 “LLM-wiki” gist	思想原型
Obsidian vault 接编码 Agent	同构，但缺约定字段
`AGENTS.md` / `CLAUDE.md`	OKF 是其超集（更结构化）
dbt docs / Schema YAML	可被 OKF 包装/转换
DataHub / Atlas	互补：可作为 OKF 的导入源或导出目标
Notion / Hugo 的 frontmatter 文件	形式高度相似