SkillPkg Logo
Google 推出开放知识格式（Open Knowledge Format）

Google 推出开放知识格式（Open Knowledge Format）

Ironben/
实践指南

随着基础模型不断进步，真正限制它们发挥作用的，往往是缺乏相关上下文，尤其是在构建智能体（agentic systems）时。虽然这些模型已经可以帮你写代码、总结文档或分析数据集，但它们依然需要获取正确的信息，才能产生准确而可执行的结果。

因此，今天我们推出 Open Knowledge Format（OKF），一个将「LLM-wiki」模式形式化的开放规范，使之成为一种可移植、可互操作的格式。它是一个与厂商无关、既适合智能体也适合人类阅读的标准，用来表示现代 AI 系统所需的元数据、上下文和经人工整理的知识。

在目前发布的 OKF v0.1 中，知识被表示为一组带 YAML 头部（frontmatter）的 Markdown 文件目录，并配有一小套约定，让不同生产方写出的 wiki，能够被不同的智能体无需转换地消费使用。

就是这样。没有复杂的压缩方案，没有新的运行时，没有必须使用的 SDK。一包 OKF 文档具备以下特点：

  • 就是 Markdown —— 任何编辑器都能读，在 GitHub 上能直接渲染，任何搜索工具都能索引
  • 就是文件 —— 可以打包成 tarball 传输，可以放在任意 git 仓库里，可以挂载到任何文件系统
  • 就是 YAML 头部 —— 只为那一小部分需要可查询的结构化字段：type、title、description、resource、tags 和 timestamp

如果你用过 Obsidian、Notion、Hugo，或者过去一年里出现的各种 LLM wiki 模式，你会觉得这种形态非常眼熟。OKF 做的事情，就是把这些模式中那一小套、真正需要达成共识的约定抽取出来并加以标准化，让它们能够互通。

下面我们会看看 OKF 能帮你的组织解决什么问题，它是如何工作的，如何开始使用，以及下一步计划。

支离破碎的上下文版图 

在大多数组织里，基础模型真正需要用到的信息，绝大部分都是内部知识：一张表的 schema，你们业务对某个指标的定义，一份事故处理手册，两套系统之间的关联路径，一个旧 API 的废弃说明等等。

今天，这些「知识原子」分散在许多彼此割裂的系统里：

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

当一个 AI 智能体要回答「我们要怎么从事件流里计算 Weekly Active Users？」这样的问题时，它得从这些零散且互不兼容的界面上，把答案拼凑起来。每家厂商都有自己的目录产品、自己的 SDK、自家的知识图谱 schema，而这些知识都牢牢锁在生成它们的那个界面背后，很难在不同产品或组织之间迁移。

结果就是：每个智能体开发者都在从零解决同一个「上下文组装」问题，每个目录厂商都在重复造相似的数据模型，而知识本身被困在各自的系统里，只要换个产品或组织，就很难复用。

把知识当作一个「活的 wiki」 

开发团队正在改变他们构建 AI 智能体的方式。与其让模型一遍遍去同样的文档里搜索同样的事实，不如给智能体一座共享的 Markdown 知识库，让它随时间不断变得更有用。这样一来，你可以让智能体来承担阅读和更新文件的繁琐工作，而你的团队只需像管理代码一样来策划和维护内容。

著名 AI 研究者和教育者 Andrej Karpathy 在他的 LLM Wiki gist 中对这个想法有非常精炼的表述。他写道：“LLM 不会觉得无聊，不会忘记更新交叉引用，而且可以在一次遍历中修改 15 个文件。”那些让人类放弃维护个人 wiki 的「记账式」琐事，恰恰是 LLM 擅长的事情。

类似的「知识即 wiki」模式不断以不同名字出现：
接上编码智能体的 Obsidian 仓库、AGENTS.md / CLAUDE.md 这一类约定文件、充满 index.md 和 log.md 的仓库（让智能体在执行真正任务前先查阅），以及数据团队里的「元数据即代码」仓库。

这种模式很有吸引力，也非常强大，但目前每一个实现都是「手工定制」的。Karpathy 的 wiki、你们团队的 wiki，以及某个厂商目录导出的结果，也许在形式上很像（Markdown、frontmatter、交叉链接），但它们从一开始就没有被设计成可以互相配合。没有任何共识：每个文档应该都有哪些字段？不同文件名代表什么含义？结果就是，编码在 wiki 中的知识依然被局限在各自的原始团队内部。每当要为一个新智能体构建知识库时，大家都要重复投入大量精力。

我们缺的是一种「格式」，而不是另一个服务 

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

  • 任何人都能生产，不依赖 SDK
  • 任何人都能消费，不需要集成适配
  • 能在不同系统、不同组织、不同工具之间流转
  • 能和它描述的代码一起存放在版本控制系统里
  • 对人类可读、对智能体可解析：同一份文件，不需要中间翻译层

OKF 正是基于这样的设计目标而来。

OKF 如何工作：一屏就能说清的设计 

一个 OKF bundle（包）是一个 Markdown 文件目录，目录里的文件代表各种概念（concept）：你想记录的任何东西，比如表、数据集、指标、操作手册、故障处理手册、API 等。每个概念就是一个文件，文件路径就是这个概念的身份标识：

1sales/
2├── index.md
3├── datasets/
4│   ├── index.md
5│   └── orders_db.md
6├── tables/
7│   ├── index.md
8│   ├── orders.md
9│   └── customers.md
10└── metrics/
11    ├── index.md
12    └── weekly_active_users.md
13

每个概念文档在顶部有一小块 YAML 头部，用来放结构化字段，后面是 Markdown 正文，承载其他内容：

1---
2type: BigQuery Table
3title: Orders
4description: One row per completed customer order.
5resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
6tags: [sales, revenue]
7timestamp: 2026-05-28T14:30:00Z
8---
9

10# Schema
11

12| Column        | Type     | Description                                  |
13|---------------|----------|----------------------------------------------|
14| `order_id`    | STRING   | Globally unique order identifier.            |
15| `customer_id` | STRING   | FK to [customers](/tables/customers.md).     |
16
17# Joins
18

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

概念之间通过普通的 Markdown 链接互相引用，把这个目录变成一张关系图，其丰富程度远超文件系统中由父子目录天然形成的层级关系。一个 bundle 可以（可选地）包含 index.md 文件（帮助智能体在浏览层级结构时逐步展开信息），以及 log.md 文件（按时间顺序记录变更历史）。

完整的 v0.1 规范（包括一致性判定标准、交叉链接规则和少量保留文件名）全部加起来也只需一页纸。

设计背后的三条原则 

1. 尽可能少的主观约束。

OKF 对每个概念唯一的硬性要求是：必须有一个 type 字段。其他一切（例如存在哪些 type、还要包含哪些字段、正文分为哪些章节），统统交由生产方自行决定。规范只定义「互操作的表面」，而不是内容模型本身。

2. 生产方 / 消费方解耦。

OKF 清晰地区分了知识的生产者和使用者。一个由人手工编写的 bundle，可以由 AI 智能体来消费；一个由元数据导出流水线生成的 bundle，可以在可视化工具中浏览；一个由某个 LLM 生成的 bundle，又可以被另一个 LLM 查询。格式本身就是契约，两端的工具都可以自由替换。

3. 格式，而不是平台。

OKF 不绑定任何特定云、数据库、模型提供方或智能体框架。读取、写入或服务 OKF 永远不会要求使用某个专有账号或 SDK。我们把它作为开放标准发布，是因为知识格式真正的价值来自「说这门语言的人越多越好」，而不是「被谁拥有」。

随规范一同发布的内容 

为了让这个格式更加具体，我们在生产端和消费端分别发布了参考实现：

  • 一个 丰富化（enrichment）智能体：它会遍历一个 BigQuery 数据集，为每张表和每个视图草拟一份 OKF 概念文档，然后再跑第二次 LLM，抓取权威文档，对每个概念进行补充（例如引用、schema、关联路径等）。
  • 一个 静态 HTML 可视化器：它可以把任意 OKF bundle 转成一个交互式图谱视图，放在单一的自包含 HTML 文件里；不需要后端，不需要在查看端安装任何东西，数据不离开页面。
  • 三份可直接浏览的示例 bundle：
    GA4 电商、Stack Overflow 和 比特币公共数据集，都由参考智能体生成，并作为活的示例提交到仓库中，展示符合 OKF 规范的实际样子。

这些都是有意而为的「概念验证」。智能体只是演示了一种生产 OKF 的方式；格式本身对使用什么智能体框架、什么 LLM 没有任何限制。可视化器只展示了一种消费方式；格式本身并不要求必须用 HTML 或图谱视图。我们预期（也欢迎）生产方和消费方的生态远远超出我们今天发布的这些工具。

下一步计划 

OKF v0.1 是一个起点，而不是终点。随着更多生产者和消费者的出现，以及我们在实践中不断学习智能体真正需要怎样的知识表示，这个格式也会持续演化。

我们从第一天起就选择在公开场合发布，因为只有这样，一个「知识格式」才能真正名副其实——无论你是在构建知识目录、丰富化流水线、面向 AI 智能体的 wiki，还是任何 AI 知识领域的产品。

从这里开始，我们鼓励你：

  • 阅读规范（它真的很短！）
  • 为你的源系统、数据库或文档站点编写一个「生产者」
  • 编写一个「消费者」：一个查看器、一个搜索索引，或者一个能对 bundle 进行推理的智能体
  • 在你自己的数据上尝试参考实现
  • 提交 issue、发 PR、提扩展建议：规范是有版本号的，并且从设计之初就考虑了向后兼容的演进方式

代码仓库、规范以及示例 bundle 都在 GitHub 上开放。我们也已经更新了 Google Cloud 的 Knowledge Catalog，使其可以摄取 Open Knowledge Format，并把它提供给我们的智能体使用。相关代码和示例可以在这里找到。

格式本身才是这次的核心贡献。我们发布的工具是为了让它变得具体可感，并降低入门成本。无论你今天的知识长什么样，OKF 都希望成为一种通用语，让它在明天得以自由交换与流通。


原文：Introducing the Open Knowledge Format


Google 推出开放知识格式（Open Knowledge Format） | 技能包 SkillPkg