谷歌OKF正式开源：AI时代的“知识版Git”，开发者早看早受益

大多数公司其实不缺数据。

缺的是什么？是能直接拿来用的知识。

不信你试试问AI这几个问题：

• 你们公司那个 order_created 的Kafka Topic里到底存了什么？

• “周活跃用户数”到底怎么算的？

• 客户 onboarding 流程是哪个服务在负责？

• 如果Kafka消费者堆积太多，该怎么恢复？

• 支付交易数据存在哪个DynamoDB表里？

你会发现，AI要么答非所问，要么直接说不知道。

不是AI笨，而是它找不到“上下文”。

这些信息其实都存在——散落在Confluence里、Notion里、数据目录里、Git仓库里、运维手册里，甚至大量只存在于几位资深工程师的脑子里。

当AI代理变得越来越强，最大的瓶颈已经不是模型本身的智商，而是它对你公司的了解几乎为零。

谷歌的发现：大家已经在偷偷建“AI维基百科”了

过去一年里，有个很有意思的现象：

很多技术团队开始自发地在代码仓库里塞一堆 Markdown 文件，比如：

• AGENTS.md

• CLAUDE.md

• README.md

• architecture.md

• runbooks/

• playbooks/

这些文件就像给AI助手准备的“共享记忆卡”，告诉它这个项目的来龙去脉、常见问题、坑在哪里。

这个思路其实很棒。Andrej Karpathy 也提过“LLM Wiki”的概念——用人类和AI都能读懂的 Markdown 来存储知识。

但问题也很明显：每家实现都长不一样。

• 目录结构不同

• 元数据格式不同

• 命名规则不同

• 互相之间完全不兼容

于是谷歌想了个特别朴素的办法：

与其再造一个平台，不如统一一个格式。

OKF 到底是什么？简单到让人意外

OKF 全称 Open Knowledge Format（开放知识格式）。

它不是数据库，不是运行时环境，不是SDK，也不是什么专有存储引擎。

它就是一套规范，告诉你怎么用 Markdown + YAML 来组织知识。

具体长这样：

knowledge/  datasets/    customers.md    orders.md  apis/    payment-api.md    user-api.md  runbooks/    kafka-outage.md  metrics/    weekly-active-users.md

每个文件代表一个知识概念，文件的路径就是它的唯一标识。

比如 datasets/orders.md 就代表 datasets/orders 这个概念。

一份 OKF 文档长什么样？

每个概念文档由两部分组成：

1. 开头的 YAML 元数据

---type:KafkaTopictitle:OrderCreatedEventdescription:新订单成功创建时发布的事件resource:kafka://order-createdtags:  -kafka  -orders  -eventstimestamp:2026-06-22T10:00:00Z---

这里只有 type 是必填的，其他全都可选。

谷歌故意把它设计得很“佛系”——不强加任何分类法、业务模型或存储规则。

2. 正文 Markdown

# 用途由订单服务在创建新订单时发布。# 数据结构| 字段 | 类型 ||------|------|| orderId | String || userId | String || amount | Decimal |# 消费者- 支付服务- 通知服务# 示例{  "orderId": "ORD-123",  "userId": "USR-456",  "amount": 99.99}

正文就是普通 Markdown，没有任何专有语法。

就这么简单。

为什么这种“简单”很重要？

OKF 最核心的设计理念是：

把“知识生产者”和“知识消费者”彻底分开。

生产者可以是：

• 写文档的人

• 数据目录导出的元数据

• 文档生成工具

• AI自动 enrichment 代理

消费者可以是：

• AI助手

• 搜索引擎

• 可视化工具

• 开发者门户

• 知识图谱

两边互不依赖，各自演进，格式就是唯一的契约。

举个实际例子：一个 Spring Boot 微服务系统

假设你有这些服务：

• 用户服务、订单服务、支付服务、通知服务

• Kafka、DynamoDB、AWS基础设施

以前文档可能散落在 Confluence、Jira、GitHub、Slack、架构图、运维手册里。

用 OKF 组织后，目录可能是这样的：

knowledge/  services/    user-service.md    order-service.md    payment-service.md  kafka/    order-created.md    payment-completed.md  runbooks/    consumer-lag.md    payment-failure.md  aws/    dynamodb-orders.md    eventbridge.md

然后AI就能直接回答：

• 哪个服务发布了 Order Created 事件？

• 支付失败会怎样？

• 订单数据存在哪张 DynamoDB 表里？

• Kafka 堆积怎么恢复？

不需要再挨个去翻不同系统了。

OKF 背后的三个设计原则

1. 极简约束（Minimally Opinionated）

只规定最小的互操作边界，不强制：

• 分类法

• 业务领域

• 知识模型

• 存储方式

你怎么组织知识，完全自己说了算。

2. 生产者和消费者独立

知识创建方和消费方可以各干各的。同一份知识包，不管是人写的、元数据系统生成的、还是LLM自动产的，都能被其他LLM、搜索系统、可视化工具、未来AI代理无障碍消费。

3. 是格式，不是平台

这是最关键的一点。

谷歌把 OKF 定位为开放、厂商中立、工具无关、云无关的纯格式。

它的价值来自被广泛采用，而不是被谁“拥有”。

在AI技术栈里，OKF补上了哪一块？

很多人会把 OKF 和 MCP（Model Context Protocol） 放一起比较。

其实它们解决的是不同问题：

• MCP：标准化“代理 → 工具”的交互，比如调用数据库、GitHub、AWS、Jira

• OKF：标准化“知识 → 代理”的输入，比如运维手册、数据目录、指标口径、API架构

一个简单的比喻：

MCP = 动作
OKF = 上下文

未来的AI系统，两者缺一不可。

谷歌还顺带发布了什么？

除了格式规范，谷歌还开源了几样东西：

• 参考富化代理：能自动扫描 BigQuery 数据集，生成 OKF 文档，补充元数据和关系引用

• 静态可视化工具：把 OKF 知识包转成交互式关系图谱，直接在浏览器里看

• 示例知识包：基于 Google Analytics 4、Stack Overflow、Bitcoin 公开数据集做的范例

代码都在 GitHub 上可以找到。

为什么开发者应该关注这件事？

回顾软件开发史上的几次重要标准化：

• Git → 源代码

• OpenAPI → API

• Dockerfile → 容器

• Terraform → 基础设施

• Kubernetes → 部署

但一直以来，组织知识没有统一的通用格式。

今天每家公司存知识的方式都不一样，明天可能大家会像交换源代码一样交换知识包。

OKF 瞄准的正是这个缺口。

我的看法

OKF 的精妙之处不在复杂，而在简单。

谷歌完全有实力推一个新数据库、新目录系统、新图引擎、新AI平台——但他们没有。

他们选了 Markdown + YAML。

这个选择，把门槛降到了最低。

当然，OKF 能不能成为真正的行业标准，还需要时间验证。

但至少，它要解决的问题是真实存在的。

当AI代理逐渐融入日常研发流程，团队必然需要一种可移植、结构化、AI友好的知识表示方式。

OKF 有潜力成为像 OpenAPI 那样的角色——一门通用语言，让知识在工具之间、组织之间、AI系统之间自由流动。

如果真到了那一天，未来每个代码仓库旁边，可能都会有一个专门的“知识层”：

src/tests/docs/knowledge/

谁先把这一层建起来，谁就能在下一波AI浪潮里抢得先机。