Google Cloud 推出 OKF v0.1：供应商中立的 Markdown 规范，为 AI 智能体提供结构化上下文

OKF 是一种格式，而不是一项服务或一个平台。OKF v0.1 将知识表示为一个由带 YAML frontmatter 的 markdown 文件组成的目录。一小组约定俗成的规范，使得由一个生产者编写的 wiki 可以被另一个不同的智能体直接消费，而无需翻译。

这就是全部理念。没有压缩方案，没有新的运行时，也没有必需的 SDK。一组 OKF 文档就只是 markdown、只是文件、只是 YAML frontmatter。它可以在 GitHub 上渲染，可以作为 tarball 分发，也可以挂载到任何文件系统上。

如果你用过 Obsidian、Notion 或 Hugo，这种形态会让你感到熟悉。OKF 只是将这些模式实现互操作所需的约定正式化。

上下文碎片化问题

在大多数组织中，模型上下文绝大多数是内部知识。如今，这些知识散落在互不兼容的孤岛中：带有各自 API 的元数据目录、wiki、共享驱动器、代码注释和 docstring。

问一个智能体“如何从我们的事件流计算周活跃用户？”它必须从分散且互不兼容的各个界面中拼凑出答案。每个供应商都提供自己的目录、SDK 和知识图谱 schema。没有任何知识可以跨产品或跨组织移植。

其结果是重复劳动。每个智能体构建者都从零开始解决同一个上下文组装问题。每个目录供应商都在重新发明同样的数据模型。

Andrej Karpathy 在 2026 年 4 月的 LLM Wiki gist 中阐述了这一底层理念。他的观点是：LLM 不会感到厌倦，不会忘记更新交叉引用，并且能够一次性编辑多个文件。那些让人类放弃个人 wiki 的繁琐维护工作，恰恰是 LLM 所擅长的。

同样的模式不断以不同的名称反复出现。例子包括接入编码智能体的 Obsidian 库、AGENTS.md 和 CLAUDE.md 约定文件，以及“元数据即代码”仓库。每一个实例都是定制的，因此它们之间无法互操作。OKF 将这一互操作层标准化，让智能体能够承担繁重的工作。

OKF 如何运作：一屏看懂其设计

一个 OKF bundle 是一个由 markdown 文件组成的目录，代表各个概念——表、数据集、指标、playbook、runbook 或 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 front-matter 块，其余内容则放在 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 链接相互连接。这些链接将目录转变为一张比文件系统父子关系更丰富的图。Bundle 可以选择性地包含 index.md 文件以实现渐进式披露，以及 log.md 文件以记录变更历史。

设计背后的三大原则

最小化主观约定：OKF 对每个概念只要求一个字段：type。其余一切交由生产者决定。该规范定义的是互操作性接口，而非内容模型。
生产者/消费者独立：人工编写的 bundle 可以被智能体读取。流水线生成的 bundle 可以在可视化工具中浏览。格式即契约；两端的工具均可替换。
是格式，而非平台：OKF 不绑定任何云、数据库、模型提供商或智能体框架。它永远不会要求专有账户才能读取、写入或提供服务。

用例与示例

数据团队的元数据即代码：将 BigQuery 表和指标定义导出为一个 bundle。将其提交到它所描述的 SQL 旁边，并通过 pull request 审查变更。
面向智能体的事故运行手册：将每份运行手册存储为一个概念。值班智能体读取 index.md，沿着交叉链接，解析出它所需的连接路径。
跨组织知识交换：供应商以 OKF 格式交付目录导出。你的智能体直接消费它，无需任何集成工作。
开发者团队 wiki：用一个由智能体持续维护、带版本管理的 markdown 空间，取代陈旧的 Notion 或 Obsidian 空间。

OKF 对比

方案	存储	是否需要 Schema	可移植	SDK/注册表	智能体可读
OKF v0.1	Markdown + YAML 文件	仅 `type`	是	否	是，无需转换
Notion	专有数据库	按工作区	仅导出	需要 API	通过 API
Obsidian 库	Markdown 文件	未强制要求	是	否	定制约定
元数据目录	厂商存储	厂商 schema	仅导出	厂商 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            # type, title, tags, etc.
        for target in set(re.findall(r"\]\((/[^)]+\.md)\)", body)):
            links.append((str(path), target))  # markdown cross-links
    return concepts, links

concepts, graph = load_bundle("sales/")

读取或提供包服务无需后端或安装。这些文件与它们所描述的代码一起存放在版本控制中。

核心要点

Google 的 Open Knowledge Format（OKF）v0.1 将 LLM-wiki 模式形式化为一个可移植、厂商中立的规范。
一个包只是一个包含带 YAML frontmatter 的 markdown 文件的目录——无需 SDK、运行时或注册表。
每个概念只需要一个字段，type；文件之间的交叉链接构成知识图谱。
Google 发布了参考工具：一个 BigQuery 富集智能体、一个静态 HTML 可视化器，以及三个示例包。
与 RAG 不同，OKF 存储经过整理、受版本控制的概念，智能体可以直接读取和更新。