谷歌云推出开放知识格式（OKF）：为AI代理提供精心策划上下文的供应商中立Markdown规范

基础模型越来越强大，但它们仍然在同一个问题上停滞不前：上下文。模型可以编写代码或分析数据集，但需要正确的内部知识。这些知识包括表模式、指标定义、运行手册、连接路径，它们分散在目录、维基和一些高级工程师的头脑中。

谷歌云推出了开放知识格式（OKF），这是一个开放规范，将LLM-wiki模式形式化为可移植、可互操作的格式。它是一个供应商中立、代理和人类友好的标准，适用于现代AI系统所需的上下文。

OKF是一种格式，而不是服务或平台。OKF v0.1将知识表示为带有YAML前置元数据的Markdown文件目录。一组小型的约定使由一个生产者编写的维基可以被不同的代理消耗，而无需翻译。

这就是全部想法。没有压缩方案，没有新的运行时，没有必需的SDK。OKF文档的包就是Markdown、文件、YAML前置元数据。它在GitHub上渲染，作为tarball传输，挂载在任何文件系统上。

如果你用过Obsidian、Notion或Hugo，你会觉得这种形状很熟悉。OKF只是形式化了使这些模式可互操作所需的约定。

碎片化的上下文问题

在大多数组织中，模型上下文主要是内部知识。今天它存在于不兼容的孤岛中：带有自己API的元数据目录、维基、共享驱动器、代码注释和文档字符串。

问一个代理：“如何从事件流中计算每周活跃用户？”它必须从分散、互不兼容的表面组装答案。每个供应商都有自己的目录、SDK和知识图谱模式。这些知识都不能跨产品或组织移植。

结果是重复工作。每个代理构建者都从头解决相同的上下文组装问题。每个目录供应商都重新发明相同的数据模型。

Andrej Karpathy在他2026年4月的LLM Wiki要点中阐述了这一基本思想。他的观点：LLM不会感到无聊，不会忘记更新交叉引用，并且可以一次编辑多个文件。使人类放弃个人维基的簿记工作正是LLM擅长处理的。

同样的模式不断以不同的名称出现。例如，连接到编码代理的Obsidian vault、AGENTS.md和CLAUDE.md约定文件，以及“元数据即代码”仓库。每个实例都是定制的，因此它们之间无法互操作。OKF标准化了那个互操作层，使代理能够完成繁重的工作。

OKF的工作原理：一屏设计

一个OKF包是一个表示概念的Markdown文件目录——表、数据集、指标、剧本、运行手册或API。每个概念一个文件，文件路径是其身份。

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

每个概念带有小的YAML前置元数据块，然后是一个Markdown正文。

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

保留的结构化字段是type、title、description、resource、tags和timestamp。概念之间通过普通的Markdown链接相互链接。这些链接将目录变成一个比文件系统父子关系更丰富的图。包可以可选地包含index.md文件用于渐进式披露，以及log.md文件用于变更历史。

设计背后的三个原则

• 最少意见：OKF每个概念只要求一个字段：type。其他一切留给生产者。规范定义互操作表面，而不是内容模型。
• 生产者/消费者独立：人类编写的包可以被代理读取。流水线生成的包可以在可视化器中浏览。格式是合约；两端的工具是可更换的。
• 格式，而非平台：OKF不绑定任何云、数据库、模型提供商或代理框架。它永远不会要求专有账户来读取、编写或服务。

用例

• 数据团队元数据即代码：将BigQuery表和指标定义导出为包。将其提交到它描述的SQL旁边，通过拉取请求审查更改。
• 事件运行手册：将每个运行手册存储为一个概念。值班代理读取index.md，跟随交叉链接，解决它需要的连接路径。
• 跨组织知识交换：供应商将目录导出为OKF。你的代理直接消耗它，无需集成工作。
• 开发者团队维基：用版本控制的Markdown替换陈旧的Notion或Obsidian空间，代理保持最新。

OKF与其他方法的比较

OKF v0.1：存储Markdown + YAML文件，仅需type模式，可移植，无需SDK/注册表，代理可读无需翻译。 Notion：专有数据库，每个工作区模式，仅可导出，需要API，代理通过API可读。 Obsidian vault：Markdown文件，无强制模式，可移植，但约定是定制的。 元数据目录：供应商存储，供应商模式，仅可导出，供应商SDK，供应商特定。 RAG索引：向量存储，嵌入模型，可移植，但需要查询时重新派生，块而非概念。

与RAG的区别对开发者很有用。RAG在查询时从原始块重新派生知识。OKF包存储经过策划、交叉链接的概念，代理直接读取和更新。

最小的OKF消费者

OKF可以用标准工具解析。以下代码读取一个包并构建其链接图。

import pathlib, re, yaml

def load_bundle(root):
    concepts, links = {}, []
    for path in pathlib.Path(root).rglob("*.md"):
        text = path.read_text()
        meta = {}
        if text.startswith("---"):
            _, fm, body = text.split("---", 2)
            meta = yaml.safe_load(fm) or {}
        else:
            body = text
        concepts[str(path)] = meta
        for target in set(re.findall(r"\]\((/[^)]+\.md)\)", body)):
            links.append((str(path), target))
    return concepts, links

concepts, graph = load_bundle("sales/")

不需要后端或安装即可读取或服务一个包。这些文件与它们描述的代码一起存在于版本控制中。

关键要点

• 谷歌的开放知识格式（OKF）v0.1将LLM-wiki模式形式化为可移植、供应商中立的规范。
• 一个包只是一个Markdown文件目录，带有YAML前置元数据——没有SDK、运行时或注册表。
• 每个概念只需要一个字段：type；文件之间的交叉链接形成知识图谱。
• 谷歌发布了参考工具：一个BigQuery丰富代理、一个静态HTML可视化器和三个示例包。
• 与RAG不同，OKF存储经过策划、版本控制的概念，代理直接读取和更新。

更多技术细节请查看原文。