大多数公司其实不缺数据。
缺的是什么？是能直接拿来用的知识。
不信你试试问AI这几个问题：
你们公司那个
order_created的Kafka Topic里到底存了什么？“周活跃用户数”到底怎么算的？
客户 onboarding 流程是哪个服务在负责？
如果Kafka消费者堆积太多，该怎么恢复？
支付交易数据存在哪个DynamoDB表里？
你会发现，AI要么答非所问，要么直接说不知道。
这些信息其实都存在——散落在Confluence里、Notion里、数据目录里、Git仓库里、运维手册里，甚至大量只存在于几位资深工程师的脑子里。
当AI代理变得越来越强，最大的瓶颈已经不是模型本身的智商，而是它对你公司的了解几乎为零。
过去一年里，有个很有意思的现象：
很多技术团队开始自发地在代码仓库里塞一堆 Markdown 文件，比如：
AGENTS.mdCLAUDE.mdREADME.mdarchitecture.mdrunbooks/playbooks/
这些文件就像给AI助手准备的“共享记忆卡”，告诉它这个项目的来龙去脉、常见问题、坑在哪里。
这个思路其实很棒。Andrej Karpathy 也提过“LLM Wiki”的概念——用人类和AI都能读懂的 Markdown 来存储知识。
但问题也很明显：每家实现都长不一样。
目录结构不同
元数据格式不同
命名规则不同
互相之间完全不兼容
于是谷歌想了个特别朴素的办法：
与其再造一个平台，不如统一一个格式。
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 这个概念。
每个概念文档由两部分组成：
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助手
搜索引擎
可视化工具
开发者门户
知识图谱
两边互不依赖，各自演进，格式就是唯一的契约。
假设你有这些服务：
用户服务、订单服务、支付服务、通知服务
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 堆积怎么恢复？
不需要再挨个去翻不同系统了。
1. 极简约束（Minimally Opinionated）
只规定最小的互操作边界，不强制：
分类法
业务领域
知识模型
存储方式
你怎么组织知识，完全自己说了算。
2. 生产者和消费者独立
知识创建方和消费方可以各干各的。同一份知识包，不管是人写的、元数据系统生成的、还是LLM自动产的，都能被其他LLM、搜索系统、可视化工具、未来AI代理无障碍消费。
3. 是格式，不是平台
这是最关键的一点。
谷歌把 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浪潮里抢得先机。
