Google 发布 Open Knowledge Format：给 AI Agent 喂知识的标准格式
2026 年 6 月 12 日，Google Cloud 悄悄发布了一个 v0.1 的开放规范——Open Knowledge Format（OKF）。没有大张旗鼓的发布会，只有一篇博客文章和一个 GitHub 仓库。但这个看起来很"朴素"的规范，解决的是 AI Agent 时代最核心的问题：怎么把散落在各处的知识，用一种 AI 和人都能读的格式统一起来。
本文大纲
- OKF 到底是什么
- 一个 OKF Bundle 长什么样
- 它解决了什么问题
- OKF 在 AI 知识栈中的位置
- 社区怎么看
- 现在该不该用
OKF 到底是什么
OKF 的全称是 Open Knowledge Format，由 Google Cloud Data Cloud 团队的 Sam McVeety 和 Amir Hormati 主导开发。它不是一款产品，而是一个开放、厂商中立的文件规范。
核心定义只有一句话：
OKF 是一个开放规范，将知识表示为一个带有 YAML frontmatter 的 Markdown 文件目录，设计目标是让人和 AI Agent 都能读写，无需定制工具。
它的诞生背景是 Google 将 Dataplex（企业数据治理工具）重新定位为 Knowledge Catalog（知识目录），从一个没人关注的企业数据管道产品，变成了一个"面向 AI Agent 的上下文引擎"。OKF 是这次重新定位中开源、可移植的那一部分。
一个 OKF Bundle 长什么样
一个 OKF 知识包（Bundle）就是一个文件夹，里面放的是 Markdown 文件。每个文件代表一个概念（Concept），可以是数据集、API、指标、业务流程、Runbook 等任何东西。
单个概念文件的结构：
---
type: Table
title: users
description: 用户主表，包含所有注册用户的基本信息
resource: bigquery://project/dataset/users
tags: [用户, 核心表]
---
# users## Schema| 字段 | 类型 | 说明 |
|------|------|------|
| user_id | STRING | 主键 |
| email | STRING | 用户邮箱 |
| created_at | TIMESTAMP | 注册时间 |
Frontmatter 放元数据，Markdown body 放 Schema、示例、引用等具体内容。
就这么简单。唯一必填的字段是 type，其余的 title、description、resource、tags、timestamp 都是推荐但可选的。
关键设计决策
概念 ID = 文件路径。文件 tables/users.md 的概念 ID 就是 tables/users。不需要额外的 ID 系统。
Markdown 链接 = 关系图。概念之间用标准 Markdown 链接互相引用，整个目录自动变成一个知识图谱。这比纯文件系统的父子层级关系丰富得多。
两个保留文件。index.md 是整个 Bundle 的目录，Agent 可以先读它来了解全局结构；log.md 记录变更历史。
容错消费。规范明确要求：消费者必须容忍未知的 type 值、缺失的可选字段和断裂的交叉链接。一个文件不合规不影响其他文件的可用性。
它解决了什么问题
Google 在公告里说得很直接：
随着基础模型持续改进，限制它们能力的往往不是模型本身，而是缺乏相关的上下文——尤其是在构建 Agent 系统时。模型可以写代码、总结文档、分析数据集，但它们仍然需要正确的信息才能产出准确且可执行的结果。
现实中，AI Agent 需要的知识散落在各处：
- 数据目录里的表结构
- Wiki 里的业务指标定义
- GitHub 仓库里的 API 文档
- 共享盘里的 Runbook
- 某个人脑子里的"只有老王知道"的潜规则
每次让 Agent 做一件事，它都得先拼凑这些上下文。OKF 的目标是把这些散落的碎片变成一个标准格式的知识包，任何生产者可以写，任何消费者可以读，同一份知识不需要为每个 Agent 重新组装。
Karpathy 的 "LLM Wiki" 模式
OKF 的直接灵感来自 Andrej Karpathy 提出的"LLM Wiki"概念——用 Markdown 维护一个 Agent 可读、可更新、可自维护的知识库。
过去一年来，这个模式已经被无数团队各自实现了一遍：AGENTS.md、CLAUDE.md、Obsidian vault、index.md + log.md 的文件夹……但每种实现都不兼容。OKF 就是要把这种"一百种不兼容的重复造轮"统一成一个规范。
OKF 在 AI 知识栈中的位置
Web 正在悄悄长出"第二层"——一层写给机器而非浏览器的层。OKF 不是要替代现有的任何一层，而是补了一个缺：
| 层级 | 格式 | 解决什么问题 |
|---|---|---|
| 爬虫索引 | sitemap.xml |
告诉爬虫有哪些 URL |
| Agent 入口 | llms.txt |
告诉 Agent 最值得读的几页 |
| 实体声明 | EntityMap | 声明你拥有哪些实体、它们的关系 |
| 知识本体 | OKF | 把内容本身交给 Agent，每个页面都是干净的概念，交叉链接成图 |
它们是堆叠关系，不是替代关系。llms.txt 是路标，EntityMap 是人物关系图，OKF 是图书馆本身。
Google 同时发布了三个参考实现：
- Enrichment Agent：自动遍历 BigQuery 数据集，为每张表和视图生成一个 OKF 概念文档，再用第二轮 LLM 调用补充 Schema、引用和关联路径
- 静态 HTML 可视化器：把任何 OKF Bundle 变成一个交互式图谱页面，单个自包含 HTML 文件，无需后端
- 三个示例 Bundle：GA4 电商数据、Stack Overflow 数据、Bitcoin 公开数据集
社区怎么看
HN 上的讨论（76 赞）观点分裂得很有代表性。
看好的人
"Markdown 是人类和 AI 模型互操作的最低公约数。不是所有东西都能用 Markdown 表达，但这恰恰是重点——它赢在这里。" —— jarym
"我喜欢 OKF 的简洁性。它正式化了 Obsidian vault、AGENTS.md、llms.txt 这些过去一年不断涌现的模式。当 Google 把你已经在赌的方向标准化了，这值得注意。" —— 多位评论者
质疑的人
"Google 发布了……带 YAML frontmatter 的 Markdown，各位请鼓掌。15KB 的规范就为了这个！" —— port11
"RDF/OWL 语义网格式每十年我就会重新看一次。总有一年会成功的！（暗示不会）" —— mrkiouak
"Markdown 的选择很奇怪。嵌套表格渲染不了，如果目标消费者是 AI，为什么要用一种人类读得更好的格式？" —— yladiz
中立但深思的
"不是所有知识都能用'纯 Markdown'表达。空间布局和颜色中隐含的人类语义——比如复杂电子表格或 Miro 白板——还没有找到好的替代方案。但 OKF 是一个好的开始。" —— sadschnitzel
这些批评有一个共同的盲点：它们都在用"完美知识表达"的标准来评判一个 v0.1 的实用主义规范。OKF 的目标不是替代知识图谱，而是让"把知识喂给 Agent"这件事有一个标准形状。
现在该不该用
不是必须。 今天不用 OKF，什么都不会坏。规范才 v0.1，还没有任何爬虫在主动寻找 OKF Bundle。
但成本极低。 一个 Bundle 就是一堆 Markdown 文件，不需要安装任何东西，不需要注册任何服务。最坏的情况是你有了一个结构化的内容审计。
适合现在试用的场景：
- 团队内部 Wiki 正在碎片化，想统一格式
- 你在给 AI Agent 喂上下文，但每次都要手动拼凑
- 你有大量技术文档散落在不同系统里，想让 Agent 能统一访问
- 你想看看自己的内容在 Agent 眼中是什么结构（OKF 的图谱可视化自带这个审计功能）
GitHub 仓库：GoogleCloudPlatform/knowledge-catalog
规范文件：okf/SPEC.md
作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。