Google Cloud 宣布推出开放知识格式（Open Knowledge Format，简称 OKF）v0.1 版本，并同步在 GitHub 上以 Apache 2.0 许可证开源了规范全文、参考实现和示例数据集。这个公告没有引发像新模型发布那样的轰动——它不涉及任何 GPU、推理优化或模型架构突破——但它可能比大多数模型更新更值得被关注。因为 OKF 试图解决的，是当前 AI 智能体（Agent）生态中一个被长期忽视却又最为昂贵的问题：每一支团队都在重复解决"如何让 AI 获得正确的上下文"这个工程难题，而每一次解决方式都是定制的、不可复用的，最终成为一套套彼此隔离的知识孤岛。

OKF 的定义简单到几乎令人失望。它就是一个由 Markdown 文件组成的目录结构，每个文件代表一个"概念"（concept）——可以是一张 BigQuery 表、一个业务指标、一条 API 端点、一份事故 Runbook。每个 Markdown 文件顶部包含一小块 YAML 前置元数据（frontmatter），整个规范对字段的要求只有一个：type（类型）。其他字段——title、description、resource、tags、timestamp——全是推荐项而非强制项。Google Cloud Data Cloud 团队的技术负责人 Sam McVeety 和 BigQuery 技术负责人 Amir Hormati 在联名博文中用三句话概括了 OKF 的本质："就是 Markdown——可以在任何编辑器中阅读，可以在 GitHub 上渲染，可以被任何搜索工具索引。就是文件——可以打成 tarball，托管在任何 git 仓库，挂载到任何文件系统。就是 YAML frontmatter——只为少数需要可查询的结构化字段。"

如果你用过 Obsidian、Notion、Hugo，或者过去一年里各种以"AGENTS.md"或"CLAUDE.md"命名的仓库约定文件，OKF 的形态会立刻让你觉得熟悉。这正是 OKF 设计的出发点——它不是在发明一种新的知识组织方式，而是将一个已经由开发者社区在实践中反复验证过的模式，规范化为一个互操作标准。

这个模式的核心思想，最简洁的表达来自著名 AI 研究者 Andrej Karpathy。他在一篇广为流传的 GitHub Gist 中提出"LLM Wiki"的概念，并写道："LLM 不会感到无聊，不会忘记更新交叉引用，一次可以触碰 15 个文件。"那些让人类放弃维护个人维基的"簿记工作"——更新索引、维护一致性、补充交叉链接——恰恰是 LLM 最擅长的机械劳动。过去一年里，这种"将知识写成 Markdown 维基，让 AI 智能体自动维护和查询"的模式以不同名字反复出现：Obsidian 仓库连接编码智能体、AGENTS.md 和 CLAUDE.md 系列约定文件、数据团队内部盛行的"metadata as code"仓库。问题是，每个团队都在用相同的语法写不同方言的"语言"，没有人对跨团队互操作该怎么做达成共识。

OKF 所做的，就是为这门已经存在但不规范的语言写一部通用的语法书。Google Cloud 在公告中强调了 OKF 与 MCP（模型上下文协议）、RAG（检索增强生成）以及 AGENTS.md/llms.txt 等约定文件的关系：它不是替代者，而是互补者。MCP 是动态的工具调用"插座"，OKF 是从这个插座中流出的知识"电流"；RAG 处理的是大规模动态文档集合的语义搜索，OKF 处理的是稳定的、可策展的结构化知识；AGENTS.md 和 Claude.md 是特定仓库内的自描述约定，OKF 则是这些约定的跨组织标准化版本。

与规范同时发布的三项参考实现揭示了 OKF 的完整工作流程。第一项是一个"知识富化智能体"（enrichment agent）：它遍历 BigQuery 数据集，为每张表和视图生成一份 OKF 概念文档初稿，然后启动第二轮 LLM 处理，爬取权威文档页面并自动为每份概念文档补充引用来源、表结构和表之间的关联路径。第二项是一个静态 HTML 可视化工具：它将任何 OKF 知识包（bundle）渲染为一个交互式的知识图谱，整个工具是一个独立的 HTML 文件，不需要后端、不需要安装、用户浏览的数据不会离开页面。第三项是三套可直接浏览的示例知识包，覆盖了 Google Analytics 4 电子商务数据、Stack Overflow 公开数据集和比特币公开数据集——全部由参考智能体自动生成并提交到 GitHub 仓库。

sales/
├── index.md
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
└── metrics/
│   ├── index.md
     └── weekly_active_users.md

---
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]
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). |

# Joins

Joined with [customers](/tables/customers.md) on `customer_id`.

从设计哲学来看，OKF 遵循三条原则。第一条是"最低限度的意见"（minimally opinionated）：规范只强制要求 type 这一个字段，其余的——允许存在哪些类型、需要什么额外字段、正文段落如何组织——完全留给知识的生产者决定。规范定义的是互操作表面（interoperability surface），而不是内容模型。第二条是"生产者与消费者独立"（producer/consumer independence）：人类手写的知识包可以被 AI 智能体消费，机器生成的元数据导出可以被人类在文本编辑器中浏览，一个 LLM 合成的知识包可以被另一个 LLM 查询。格式本身是契约，两端的工具可以独立替换。第三条是"格式而非平台"（format, not platform）：OKF 不绑定任何云、数据库、模型提供商或智能体框架。规范本身永远不会要求使用专有账号或 SDK。Google Cloud 之所以将它以开放标准的形式发布，正是因为"知识格式的价值取决于有多少方在使用它，而不是谁拥有它"。

一个值得注意的细节是：Google Cloud 在发布 OKF 的同时，已经更新了自己的 Knowledge Catalog（知识目录）产品，使其能够原生摄取 OKF 知识包。这是一种典型的 Google 开源策略——先建立一个开放标准，然后让自己家的产品成为首批兼容者。但与历史上许多类似的"先开放后绑定"策略不同，OKF 的设计本身几乎不给绑定留下空间。一个只有 Markdown 文件加 YAML frontmatter 的格式，门槛低到任何团队都可以用 Git 仓库作为它的分发渠道，用任何静态站点生成器作为它的呈现工具，用任何文本编辑器作为它的创作环境。如果 Google 明天停止维护 OKF，OKF 的知识包依然可读、可用、可迁移。

OKF 的出现也揭示了一个更深层的行业趋势：AI 智能体的瓶颈正在从"模型够不够聪明"转向"模型有没有正确的信息"。当基础模型的能力曲线仍在攀升，智能体系统在实践中遇到的最大障碍往往不是推理能力不足，而是它们被要求回答"如何从我们的事件流中计算周活跃用户"时，答案散落在三个不同的数据目录、两份共享文档和一位资深工程师的脑子里。OKF 为这个问题提供的不是一个更聪明的模型，而是一套让知识变得可结构化、可迁移、可被任意智能体消费的基础设施。在 AI 工具链的分工图谱上，这意味着"知识工程"正在从散兵游勇的个人实践进入标准化和工程化的新阶段。

参考来源：

• Introducing the Open Knowledge Format - Google Cloud Blog
• Google Cloud Announces The Open Knowledge Format - Search Engine Journal
• Google's OKF wants to be the lingua franca for AI agent knowledge - PPC Land