Google推出OKF开放格式：AI智能体知识共享的新标准

Google Cloud推出Open Knowledge Format (OKF) v0.1——一个仅采用Markdown + YAML的轻量级开放标准，旨在实现AI agents跨平台、跨企业的知识读取。Google选择了“化繁为简”的路径，这正是我认为值得关注之处。

众多团队在认真部署AI agents后，很快会面临一个无法回避的困境：agent所需知识究竟分布在何处？

元数据目录拥有独立API，wiki位于另一个系统，代码注释在仓库中，还有一些仅存在于资深工程师的脑海中。每个agent项目都在重复同一项工作——将这些零散信息整合起来。

📌 Google Cloud提供的解决方案并非又一个平台或SDK，而是一份仅451行、14.7KB的Markdown格式标准。

2026年6月12日，Google Cloud数据团队技术负责人Sam McVeety与BigQuery技术负责人Amir Hormati在官方博客发布了Open Knowledge Format（OKF）v0.1。

核心理念非常直接：将组织知识编写为带YAML frontmatter的Markdown文件，存放在目录树中。每个文件代表一个“概念”——可以是一张数据库表、一个API端点，也可以是一个业务指标或应急预案。概念之间通过Markdown链接相互关联，整个目录即构成一个知识图谱。

会用cat读取文件，就能读取OKF。会git clone，就能分发OKF。

这不是偷懒。Google刻意将标准精简至极致——整个v0.1仅有一个必填字段：type，一个短字符串用于标识概念类型。其余如title、description、tags等均为可选推荐项。

💡 OKF追求的是一种使知识能在不同系统之间存活和迁移的“表示格式”，而非又一个需要注册账号才能使用的知识服务。

OKF并非无中生有。AI研究者Andrej Karpathy早已提出过“LLM Wiki”模式。

Karpathy在GitHub gist中写过一句话，被Google官方公告直接引用：

“LLMs don’t get bored, don’t forget to update a cross-reference, and can touch 15 files in one pass.”

有趣的是，人类不愿从事的那些繁琐工作——更新交叉引用、保持格式一致、批量修改文件——恰恰是LLM最擅长之事。

过去一年里，这种模式在多个地方反复出现：

• 连接coding agent的Obsidian Vault

• 开发者放入仓库的AGENTS.md和CLAUDE.md

• 数据团队中的“metadata as code”仓库

• 个人知识管理工具中大量涌现的markdown wiki实践

结构惊人地相似：Markdown文件 + YAML frontmatter + 交叉链接。但都是各自为政的“方言”——Karpathy的wiki、你团队的wiki、某供应商的目录导出，看起来相似，却无法协作。

OKF所做的就是为这些方言制定一套最小化的“通用语言”规则。

Google在发布中明确了三条设计原则：

🔧最少意见。仅要求一个type字段。何种类型存在、包含何种额外字段，全部留给生产者决定。

🔧生产者和消费者独立。人类手写的bundle可被agent消费；管线生成的bundle可在可视化器中浏览。格式是合同，两端工具各自可替换。

🔧是格式，不是平台。不绑定任何云、数据库、模型提供商。不要求专有账号或SDK来读写分发。

OKF划定的红线同样重要——它不试图定义固定概念分类法、不规定存储分发基础设施、不替代Avro / Protobuf / OpenAPI等域专用schema。它引用这些schema，但不吞并它们。

OKF不只是一份文档。Google同时发布了：

•一个enrichment agent：遍历BigQuery数据集，为每张表和视图生成OKF概念文档，再用LLM抓取权威文档来丰富引用和schema

•一个静态HTML可视化器：将任何OKF bundle转换为单个自包含的交互式图谱视图，无需后端，数据不离开页面

•三个示例bundle：GA4电商数据、Stack Overflow公共数据集、Bitcoin公共数据集

Google Cloud的Knowledge Catalog（前身为Dataplex）也已更新为可摄入OKF并供agents使用。Knowledge Catalog本身也在向AI方向转型——它支持MCP工具，让agents通过语义搜索直接检索企业级“黄金查询”。

OKF的价值，往小了说，是让开发者少写几个连接器；往大了说，可能改变知识在组织中的流转方式。

🧠对AI agent开发者：若agent需要理解企业内部数据结构，OKF提供了一种标准化表示。无需为每个数据源编写独立连接器——只要对方有OKF bundle，agent就能读取。

🧠对数据团队：“metadata as code”从个人实践转变为可协作的格式。知识包直接放在git仓库中，随代码一起版本管理，人类和agent读取同一份文件。

🧠对AI搜索生态：如果说sitemap.xml告诉爬虫有哪些URL，llms.txt指向agent最想读的几页，那么OKF就是直接将整个知识库以Markdown概念图谱的形式交给agent——而且不需要agent先去爬网页。

OKF的竞争背景比表面看起来更有趣。

Meta在2025年8月就发布过类似的思路：用文件夹结构将数据仓库的层级知识表示为LLM可读的文本。Meta工程师当时的原话是：“LLMs communicate through text so the hierarchical structure of data warehouse nicely mapped to a folder structure.”

OKF将这种直觉正式化为一个版本化的开放标准。关键区别在于，Google选择将其做成开放格式，而非Google Cloud的专属功能。

这几个动作是相互关联的——格式的价值取决于有多少方采用这种语言，而非谁拥有它。

OKF v0.1是初步版本，非最终形态。有几个需要看清的边界：

•版本0.1，仍处于草案阶段。格式本身可能发生变化，目前不适合在生产系统中大规模依赖。

•“开放”不等于“已被广泛采用”。Google发布了标准和参考实现，但第三方生态尚未形成。能否真正成为“通用语”，取决于社区响应速度。

•Knowledge Catalog集成目前仅覆盖Google Cloud生态。标准本身是供应商中立的，但首个生产级集成发生在Google自己的产品中。其他云厂商是否跟进，仍是未知数。

•OKF解决的是知识表示格式，不是知识生成。它不提供从混乱文档中自动提取知识的能力——那仍然需要人工或另一个AI系统。

•断裂链接被允许是务实设计，但也意味着OKF bundle的知识完整性无法由标准本身保证。

如果你正在构建AI agent，知识碎片化问题解决了吗？用的是wiki、代码注释，还是某种自研方案？OKF这种“回到文件”的思路，在你的团队中可行吗？

• Google Cloud Blog官方公告：

https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing

• GitHub仓库：

https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf

• PPC Land深度分析：

https://ppc.land/googles-okf-wants-to-be-the-lingua-franca-for-ai-agent-knowledge