开放知识格式（OKF）如何改善数据共享

核心要点

1. Google Cloud 推出开放知识格式（Open Knowledge Format, OKF）——一份将 Karpathy 的 LLM-wiki 模式正式化的开放规范，把现代 AI 系统所需的元数据、上下文与策展知识表示成一种可移植、可互操作的格式。
2. OKF v0.1 = "就是 markdown + 就是文件 + 就是 YAML frontmatter"：知识被表示为一个目录下的若干 markdown 文件，每个文件一个概念（concept），文件路径即概念身份；无压缩方案、无新运行时、无强制 SDK。
3. 解决的痛点是上下文碎片化：表结构、指标口径、事故 runbook、系统间 join 路径等知识散落在各类互不兼容的系统里，每个智能体构建者都在从零重复解决同一个"上下文拼装"问题。
4. 三条设计原则：①最小主张（每个概念只强制要求一个 type 字段）；②生产者/消费者解耦（格式即契约，两端工具可独立替换）；③是格式而非平台（不绑定任何云、数据库、模型厂商或智能体框架）。
5. 配套发布了参考实现：BigQuery 数据集的富化智能体（producer）、把任意 OKF bundle 渲染成交互式图谱的单文件静态 HTML 可视化器（consumer）、以及三套可直接浏览的样例 bundle。规范、代码与样例已在 GitHub 开放。
6. 与本仓库的关联：OKF 本质上就是我们 wiki/ 知识库 + Obsidian vault 一直在实践的"知识即 wiki"模式的标准化版本（参见 Karpathy LLM 知识库）。

原文链接 English Original

随着基础模型（foundation models）不断进步，相关上下文（context）的缺失往往成为限制它们发挥的瓶颈——在它们被用于构建智能体系统（agentic systems）时尤其如此。这些模型固然能帮你写代码、总结文档或分析数据集，但要产出准确、可执行的结果，它们仍然需要正确的信息。

正因如此，我们今天推出开放知识格式（Open Knowledge Format, OKF）——一份将 LLM-wiki 模式正式化为可移植、可互操作格式的开放规范。它是一套厂商中立（vendor-neutral）、对智能体与人类都友好的标准，用于表示现代 AI 系统所需的元数据、上下文与策展知识。

按已发布的形态，OKF v0.1 把知识表示成一个由带 YAML frontmatter 的 markdown 文件组成的目录，再加上一小套约定俗成的规范——使得由不同生产者编写的 wiki，能被不同的智能体在无需翻译的情况下直接消费。

就这么简单。没有复杂的压缩方案，没有新的运行时，也不需要 SDK。一个 OKF 文档包（bundle）就是：

• 只是 markdown——任何编辑器都能读，GitHub 上能渲染，任何搜索工具都能索引
• 只是文件——能打包成 tarball 发出去，能托管在任意 git 仓库，能挂载到任意文件系统
• 只是 YAML frontmatter——用于那一小撮需要可查询的结构化字段：type、title、description、resource、tags 和 timestamp

如果你用过 Obsidian、Notion、Hugo，或过去一年里涌现的任何一种 LLM wiki 模式，这种形态会让你觉得很眼熟。OKF 所做的，就是把让这些模式得以互操作所需的那一小套约定正式化。

下面我们来看看 OKF 能为你的组织解决什么问题、它如何运作、如何上手，以及接下来会怎样。

碎片化的上下文版图

在大多数组织里，基础模型所用的信息绝大部分是内部知识：一张表的 schema、你们业务对某个指标的定义口径、某次事故的 runbook、两个系统之间的 join 路径、某个旧 API 的弃用通知，等等。

如今，这些知识"原子"散落在各种高度碎片化的系统里：

• 各有自己 API 的元数据目录（metadata catalogs）
• wiki、第三方系统，或共享网盘里
• 代码注释、docstring，或 notebook 单元格里
• 少数几位资深工程师的脑子里

当一个 AI 智能体需要回答"如何从我们的事件流计算周活跃用户？"时，它必须从这些零散、互不兼容的载体里把答案拼凑出来。每个厂商都提供自家的目录、自家的 SDK、自家的知识图谱 schema——没有哪份知识能轻松地跨产品或跨组织移植。

结果就是：每个智能体构建者都在从零解决同一个"上下文拼装"问题，每个目录厂商都在重新发明同样的数据模型，而知识本身则被锁死在最初创建它的那个载体背后。

把知识当作一座"活的" wiki

开发团队正在改变构建 AI 智能体的方式。与其反复用模型在同样的文档里搜寻同样的事实，不如给你的智能体一座共享的 markdown 知识库，让它随时间越用越有价值。这让智能体接手了阅读和更新自身文件这种繁琐活儿，而你的团队则负责策展内容、像管代码一样管理它。

知名 AI 研究者与教育者 Andrej Karpathy 在他的 LLM Wiki gist 中把这个理念表达得最为精炼。他写道："LLM 不会无聊，不会忘记更新某条交叉引用，而且能在一遍处理中改动 15 个文件。"——那些让人类放弃维护个人 wiki 的记账式琐事，恰恰是 LLM 所擅长的。

类似的"知识即 wiki"模式正不断以不同的名字反复出现：接入编码智能体的 Obsidian vault、AGENTS.md / CLAUDE.md 这类约定文件家族、满是 index.md 与 log.md 工件、供智能体在真正动手前查阅的仓库，以及数据团队内部的"元数据即代码"仓库。

这个模式很有吸引力、也很强大，但每一个实例都是定制的。Karpathy 的 wiki、你们团队的 wiki、某厂商导出的目录，外观可能都长得很像（markdown、frontmatter、交叉链接），但它们没有一个是被刻意设计成能彼此协作的。对于"每份文档应携带哪些字段""哪个文件名代表什么含义"，并不存在一个公认的答案。其结果是：编码进 wiki 里的知识仍被孤立在最初的团队内部，每构建一个新智能体都要重复一遍同样的工作。

缺的是一种格式，而不是又一个服务

这个问题的答案不是又一个知识服务。你需要的是一种格式——一种表示知识的方式，它能做到：

• 任何人都能生产，无需 SDK
• 任何人都能消费，无需做集成
• 在系统、组织与工具之间迁移时依然存活
• 与它所描述的代码一起存放在版本控制里
• 对人可读、对智能体可解析：同一个文件，没有翻译层

从设计上讲，OKF 就是这样一种格式。

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

一个 OKF bundle 就是一个由 markdown 文件组成的目录，每个文件表示一个概念（concept）：任何你想捕获的东西，包括表、数据集、指标、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 frontmatter 承载结构化字段，再用 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    | 全局唯一的订单标识。                       |
| `customer_id` | STRING    | 指向 customers 的外键。 |

# Joins

通过 `customer_id` 与 customers 关联。

概念之间用普通的 markdown 链接互相引用，从而把整个目录变成一张关系图谱（graph）——它比文件系统隐含的父子链接要丰富得多。bundle 还可以选择性地包含 index.md 文件（用于智能体在层级中导航时的渐进式披露）和 log.md 文件（用于变更的时间线历史）。

完整的 v0.1 规范（含符合性标准、交叉链接规则，以及少量保留文件名）只有一页纸。

设计背后的三条原则

1. 最小主张（Minimally opinionated）。 OKF 对每个概念只强制要求一件事：一个 type 字段。其余一切（例如存在哪些类型、还要包含哪些字段、正文有哪些章节）都交给生产者自行决定。规范定义的是互操作的接口面，而非内容模型。

2. 生产者/消费者相互独立。 OKF 干净地把"谁写知识"与"谁用知识"分离开来。人手写的 bundle 可以被 AI 智能体消费；由元数据导出流水线生成的 bundle 可以在可视化器里浏览；由一个 LLM 合成的 bundle 可以被另一个 LLM 查询。格式即契约，两端的工具可以各自独立替换。

3. 是格式，不是平台（Format, not platform）。 OKF 不绑定任何特定的云、数据库、模型厂商或智能体框架。它永远不会要求专有账号或 SDK 才能读、写或提供。我们将其作为开放标准发布，因为一种知识格式的价值来自有多少方"说"它，而不是来自谁"拥有"它。

我们随规范一起交付了什么

为了让这种格式落到实处，我们在生产端与消费端都发布了参考实现：

• 一个富化智能体（enrichment agent）：它遍历一个 BigQuery 数据集，为每张表和视图起草一份 OKF 概念文档，然后再跑第二遍 LLM——爬取权威文档，用引用、schema 和 join 路径来丰富每个概念。
• 一个静态 HTML 可视化器：把任意 OKF bundle 变成一个单一、自包含文件里的交互式图谱视图；无后端、查看端无需安装、且没有任何数据离开页面。
• 三套可直接浏览的样例 bundle：GA4 电商、Stack Overflow 和 Bitcoin 公共数据集，均由参考智能体生产并提交到仓库，作为符合规范的 OKF 的"活样例"。

这些刻意只是概念验证（proofs of concept）。智能体演示了生产 OKF 的一种方式，但格式本身并不要求特定的智能体框架或 LLM；可视化器演示了消费它的一种方式，但格式本身也并不要求 HTML 或图谱视图。我们预期（也希望！）生产者与消费者的生态会远远超出我们已交付的这些。

接下来的方向

OKF v0.1 是一个起点，而非一份已完成的标准。随着更多生产者与消费者出现，以及我们共同摸清智能体在实践中究竟需要什么样的知识表示，这套格式还会持续演进。

我们从第一天起就公开发布，因为这是一种知识格式赢得"名副其实"的唯一途径——无论你是在构建知识目录、富化流水线、为 AI 智能体量身打造的 wiki，还是 AI 知识领域里的任何东西。

从这里出发，我们鼓励你：

• 读规范（很短的！）
• 为你的源系统、你的数据库、你的文档站点写一个生产者（producer）
• 写一个消费者（consumer）：一个查看器、一个搜索索引，或一个能在 bundle 上做推理的智能体
• 拿你自己的数据试一试参考实现
• 提 issue、发 PR 或提议扩展：规范是有版本的，并被明确设计为可向后兼容地生长

仓库、规范与样例 bundle 都在 GitHub 上。我们也已更新 Google Cloud 的知识目录（Knowledge Catalog），使其能够摄入开放知识格式并提供给我们的智能体。相关代码与示例可在这里找到。

格式本身才是真正的贡献。我们交付的工具，存在的意义是让它变得真实可用、并降低试用它的成本。无论你的知识今天是什么形态，OKF 都被设计成那种"明天可以拿来交换"的通用语（lingua franca）。

^{由 Google Cloud Data Cloud 团队发布。开放知识格式是一份开放规范；明确欢迎贡献、替代实现，以及在 Google 产品之外的采用。}

Related Documents

• English Original
• Karpathy LLM 知识库（中文）
• LLM Wiki 模式详解（中文）
• AI 技术博客索引