谷歌发布OKF（Open Knowledge Format）规范，它与Karpathy的LLM-wiki是什么关系？

推荐语

谷歌发布开放知识格式OKF，为LLM知识库提供统一标准，解决AI智能体上下文碎片化问题。

核心内容：
1. OKF规范的核心结构与设计理念
2. OKF如何解决企业知识碎片化问题
3. 与现有LLM wiki模式的对比与互操作性

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

• 来源：Google Cloud 博客 ^[1]
• 作者：Sam McVeety — Google Cloud 数据云（Data Cloud）工程团队数据分析技术负责人
• 作者：Amir Hormati — Google Cloud 数据云（Data Cloud）工程团队 BigQuery 技术负责人

随着基础模型持续进步，缺少相关上下文，往往会限制它们的能力，尤其是在这些模型被用来构建智能体系统时。虽然这些模型可以帮助你写代码、总结文档或分析数据集，但它们仍然需要正确的信息，才能给出准确且可执行的结果。

因此，今天我们推出开放知识格式（Open Knowledge Format，OKF）。它是一套开放规范，将 LLM wiki（LLM 知识库）^[2] 模式正式化为一种可移植、可互操作的格式。这是一套与厂商无关、同时面向智能体和人的友好标准，用于表示现代 AI 系统所需要的元数据、上下文和经过整理的知识。

在当前发布的版本中，OKF v0.1 将知识表示为一个由 Markdown 文件组成、并带有 YAML frontmatter（头部元数据）的目录结构，同时约定了一小组通用规范，使不同生产者写出的 wiki（知识库）无需转换就能被不同的智能体消费。

就是这样。没有复杂的压缩方案，没有新的运行时，也不要求必须使用某个软件开发工具包（SDK）。一个 OKF 文档包，本质上就是：

• Markdown —— 可以在任何编辑器中阅读，可以在 GitHub 上渲染，也可以被任何搜索工具建立索引
• 文件 —— 可以打包成压缩包（tarball），可以托管在任何 Git 仓库中，也可以挂载到任何文件系统上
• YAML frontmatter（头部元数据） —— 用来承载那一小部分需要可查询的结构化字段：type、title、description、resource、tags 和 timestamp

如果你用过 Obsidian、Notion、Hugo，或者过去一年里出现过的各种 LLM wiki（LLM 知识库）模式，你会对这种形态感到熟悉。OKF 做的，是把让这些模式具备互操作性所需的那一小组约定正式定义下来。

下面我们来看看，OKF 能为你的组织解决什么问题，它是如何工作的，如何开始使用，以及接下来会发生什么。

碎片化的上下文格局

在大多数组织里，基础模型所使用的信息主要都是内部知识：一张表的 schema（模式）、你们业务里某个指标的含义、一次事故的 runbook（运行手册）、两个系统之间的 join 路径（关联路径）、某个旧 API 的废弃通知，等等。

今天，这些知识单元分散在许多高度碎片化的系统里：

• 拥有各自 API 的元数据目录
• Wiki（知识库）、第三方系统，或者共享网盘
• 代码注释、docstring（文档字符串），或者笔记本（notebook）单元格
• 少数几位资深工程师的脑子里

当一个 AI 智能体需要回答“我们该如何从事件流中计算周活跃用户？”时，它必须从这些分散且彼此不兼容的信息来源中拼出答案。每家厂商都有自己的目录（catalog）、自己的软件开发工具包（SDK）、自己的知识图谱 schema（模式），而这些知识几乎都无法轻松地在不同产品或不同组织之间迁移。

结果就是：每一个智能体构建者都在从零解决同样的上下文组装问题；每一家目录厂商都在重复发明同样的数据模型；而知识本身则被锁在最初创建它的那个系统里。

把知识组织成持续更新的知识库

开发团队正在改变构建 AI 智能体的方式。与其让模型一遍又一遍地在同样的文档里搜索同样的事实，不如给智能体一套共享的 Markdown 知识库，并让它随着时间推移变得越来越有用。这样，你的智能体就可以承担读取和更新自身文件这类繁琐工作，而你的团队则负责整理内容，并像管理代码一样管理它。

知名 AI 研究者和教育者 Andrej Karpathy 在他的 LLM Wiki gist^[2] 里，对这一想法做出了最清晰的表达。他写道：“LLM 不会感到无聊，不会忘记更新交叉引用，而且一次就能改动 15 个文件。” 正是那些让人类最终放弃维护个人 wiki（知识库）的事务性工作，恰好是 LLM 最擅长的事。

类似的“知识即 Wiki（知识库）”模式，正以不同名字反复出现：与编码智能体连接的 Obsidian vault（资料库）^[3]，AGENTS.md / CLAUDE.md 这一类约定文件，包含 index.md 和 log.md 的一整套仓库文件，智能体会在真正开始工作前先去读取它们，以及数据团队内部的“metadata as code（元数据即代码）”仓库。

这种模式很有吸引力，也很强大，但每一个实例都是定制化的。Karpathy 的 wiki（知识库）、你团队的 wiki（知识库），以及某家厂商导出的目录（catalog），表面上看可能都很像（Markdown、frontmatter（头部元数据）、交叉链接），但它们并不是被有意设计成可以协作的。对于“每个文档都应该带哪些字段”或者“哪些文件名代表什么含义”，大家并没有统一答案。结果就是，编码在这些 wiki（知识库）里的知识仍然被困在最初的团队里，每当有人要构建一个新的智能体时，就会产生重复劳动。

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

这个问题的答案不是再来一个知识服务。你需要的是一种格式，一种表示知识的方式，它应该满足：

• 任何人都能生产，而不需要软件开发工具包（SDK）
• 任何人都能消费，而不需要专门集成
• 能在系统、组织和工具之间迁移后继续存在
• 能和它所描述的代码一起进入版本控制
• 既能被人阅读，也能被智能体解析：同一份文件，不需要翻译层

从设计上说，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 Tabletitle: Ordersdescription: One row per completed customer order.resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orderstags: [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). |# JoinsJoined with [customers](/tables/customers.md) on `customer_id`.

这些概念项之间通过普通的 Markdown 链接互相连接，使整个目录形成一张关系图，而这张图比文件系统本身隐含的父子关系更丰富。这个文档包还可以选择性包含 index.md 索引文件（用于智能体在层级结构中导航时逐层展开）和 log.md 日志文件（用于记录按时间顺序排列的变更历史）。

完整的 v0.1 规范（包括一致性标准、交叉链接规则以及少量保留文件名）可以放在单独一页里。

设计背后的三条原则

1. 尽量少做预设。OKF 对每个概念项（concept）只强制要求一件事：必须有一个 type 字段。其他一切（比如有哪些类型、是否增加其他字段、正文有哪些分节）都交给生产者决定。规范定义的是互操作表面，而不是内容模型。
2. 生产者与消费者相互独立。OKF 将“谁来写知识”和“谁来消费知识”清晰分开。由人手工写出的文档包（bundle）可以被 AI 智能体消费。由元数据导出流水线生成的文档包可以被可视化查看器（visualizer）浏览。由一个 LLM 合成的文档包也可以被另一个 LLM 查询。格式本身就是契约；两端使用的工具都可以独立替换。
3. 这是格式，不是平台。OKF 不绑定任何特定云、数据库、模型提供商或智能体框架。它永远不应该要求你必须拥有某个专有账户或软件开发工具包（SDK），才能读取、写入或提供服务。我们之所以把它作为开放标准发布，是因为一种知识格式的价值来自有多少参与方会说这种“语言”，而不来自由谁拥有它。

我们随规范一起发布了什么

为了让这种格式更具体，我们在生产端和消费端两侧都发布了参考实现：

• 一个增强智能体（enrichment agent），它会遍历 BigQuery 数据集，为每个表和视图起草一个 OKF 概念项（concept）文档，然后再运行第二轮 LLM 流程，抓取权威文档，并为每个概念项补充引用（citation）、schema（模式）和 join path（关联路径）
• 一个静态 HTML 可视化查看器（visualizer），它能把任意 OKF 文档包（bundle）渲染成交互式图视图，而且只需要一个自包含文件；不需要后端，查看侧不需要安装，也不会有数据离开页面
• 三个可直接浏览的示例文档包（bundle）：GA4 电商示例数据集^[4]、Stack Overflow 公共数据集^[5] 和比特币公共数据集^[6]。它们都由参考智能体生成，并提交到了仓库中，作为持续维护的、符合 OKF 规范的示例。

这些内容是刻意按概念验证来设计的。这个智能体展示的是生产 OKF 的一种方式；格式本身并不要求必须使用某个特定的智能体框架或 LLM。这个查看器展示的是消费 OKF 的一种方式；格式本身也并不要求必须使用 HTML 或图视图。我们期待，也希望，生产者和消费者的生态会远远超出我们这次发布的内容。

接下来怎么走

OKF v0.1 是一个起点，而不是一套已经完成的标准。随着更多生产者和消费者出现，以及我们逐步弄清楚智能体在实践中究竟需要怎样的知识表示，这套格式还会继续演进。

我们从第一天起就选择公开发布，因为一种知识格式只有在开放中才配得上“知识格式”这个名字。无论你是在构建 knowledge catalog（知识目录）、enrichment pipeline（增强流水线）、面向 AI 智能体定制的 wiki（知识库），还是任何属于 AI 知识领域的东西，都是如此。

接下来，我们鼓励你：

• 阅读规范（它很短！）
• 为你的源系统、数据库或文档站点编写一个生产端（producer）
• 编写一个消费端（consumer）：可以是查看器、搜索索引，或者一个能基于文档包（bundle）进行推理的智能体
• 把参考实现拿到你自己的数据上试一试
• 提 issue、发 PR（拉取请求），或者提出扩展方案：这套规范是版本化的，并且明确为向后兼容的演进而设计

仓库、规范和示例文档包（bundle）都已经发布在 GitHub^[7] 上。我们也已经更新了 Google Cloud 的 Knowledge Catalog（知识目录）^[8]，使它能够摄取开放知识格式（Open Knowledge Format，OKF），并把它提供给我们的智能体使用。相关代码和示例见演示目录（demo）^[9]。

这项贡献本身就是格式。我们发布的那些工具，是为了让它真正落地，并降低大家试用它的成本。无论你今天的知识以何种形态存在，OKF 的目标都是成为它明天可以交换成的那种通用语言。

本文由 Google Cloud 数据云（Data Cloud）团队发布。开放知识格式（Open Knowledge Format，OKF）是一套开放规范；我们明确欢迎大家在 Google 产品之外贡献、实现替代方案并推动采用。

除了署名作者之外，这项工作还凝聚了 Google 许多其他同事的关键想法，在此感谢他们的贡献。