技术资讯

Google Cloud 发布开放知识格式 OKF，用 Markdown + YAML 终结 AI 智能体的知识孤岛

hanghai tian

• 阅读时间 5 分钟
分享

Google Cloud 开放知识格式 OKF — 用 Markdown + YAML 终结 AI 智能体的知识孤岛

发布时间： 2026年6月16日
来源： OSCHINA / Google Cloud Blog
仓库： GoogleCloudPlatform/knowledge-catalog

OKF 知识格式结构

概述

Google Cloud 宣布推出开放知识格式（Open Knowledge Format，简称 OKF）v0.1 版本，同步在 GitHub 上以 Apache 2.0 许可证开源了规范全文、参考实现和示例数据集。

这个公告没有引发像新模型发布那样的轰动——不涉及 GPU、推理优化或模型架构突破——但它可能比大多数模型更新更值得被关注。因为 OKF 试图解决的，是当前 AI 智能体（Agent）生态中一个被长期忽视却又最为昂贵的问题：每一支团队都在重复解决"如何让 AI 获得正确的上下文"这个工程难题，而每一次解决方式都是定制的、不可复用的，最终成为一套套彼此隔离的知识孤岛。

一、OKF 核心设计思想

OKF 的定义简单到几乎令人失望。它就是一个由 Markdown 文件组成的目录结构，每个文件代表一个"概念"（concept）——可以是一张 BigQuery 表、一个业务指标、一条 API 端点、一份事故 Runbook。

每个 Markdown 文件顶部包含一小块 YAML 前置元数据（frontmatter），整个规范对字段的要求只有一个：type（类型）。其他字段——title、description、resource、tags、timestamp——全是推荐项而非强制项。

核心三句话

Google Cloud Data Cloud 团队的技术负责人 Sam McVeety 和 BigQuery 技术负责人 Amir Hormati 在联名博文中用三句话概括了 OKF 的本质：

  • 就是 Markdown —— 可以在任何编辑器中阅读，可以在 GitHub 上渲染，可以被任何搜索工具索引。
  • 就是文件 —— 可以打成 tarball，托管在任何 git 仓库，挂载到任何文件系统。
  • 就是 YAML frontmatter —— 只为少数需要可查询的结构化字段。

二、技术规范

2.1 目录结构

knowledge-bundle/
├── index.md              # 可选的索引页
├── concepts/
│   ├── customer_table.md
│   ├── order_api.md
│   ├── refund_runbook.md
│   ├── sla_metric.md
│   └── ...
└── okf.yaml              # 可选的包级元数据

2.2 Frontmatter 字段

字段 必填 说明
type ✅ 概念类型（如 table、api、runbook、metric）
title ❌ 概念标题
description ❌ 详细描述
resource ❌ 外部资源链接
tags ❌ 标签列表
timestamp ❌ 最后更新时间

2.3 概念文件示例

---
type: table
title: 客户订单表
description: 存储所有客户订单的核心交易表
resource: bigquery://project:dataset.orders
tags: [core, transactional, customer]
timestamp: 2026-06-16
---

# 客户订单表

## 架构

| 字段 | 类型 | 说明 |
|------|------|------|
| order_id | STRING | 订单唯一标识 |
| customer_id | STRING | 客户 ID |
| amount | FLOAT | 订单金额 |
| status | STRING | 订单状态（pending/confirmed/shipped/completed） |

## 使用说明

- 每日分区表，按 order_date 分区
- 保留周期为 7 年
- 查询时务必按分区键过滤以避免全表扫描

## 关联概念

- [客户表](customer_table.md)
- [订单退款 Runbook](refund_runbook.md)

三、与现有实践的关联

如果你用过 Obsidian、Notion、Hugo，或者过去一年里各种以 AGENTS.md 或 CLAUDE.md 命名的仓库约定文件，OKF 的形态会立刻让你觉得熟悉。

这正是 OKF 设计的出发点——它不是在发明一种新的知识组织方式，而是将一个已经由开发者社区在实践中反复验证过的模式，规范化为一个互操作标准。

Karpathy 的 LLM Wiki

这个模式的核心思想，最简洁的表达来自著名 AI 研究者 Andrej Karpathy。他提出的 LLM Wiki 概念中写道：

"LLM 不会感到无聊，不会忘记更新交叉引用，一次可以触碰 15 个文件。"

那些让人类放弃维护个人维基的"簿记工作"——更新索引、维护一致性、补充交叉链接——恰恰是 LLM 最擅长的机械劳动。

过去一年里，这种"将知识写成 Markdown 维基，让 AI 智能体自动维护和查询"的模式以不同名字反复出现：
- Obsidian 仓库连接编码智能体
- AGENTS.md 和 CLAUDE.md 系列约定文件
- 数据团队内部盛行的 "metadata as code" 仓库

四、相关项目生态（GitHub）

OKF 发布后，社区迅速涌现了一批周边工具：

项目 说明 Stars
okf-tools CLI 和 Python 库，用于查询、导航和编写 OKF 包 ⭐
okf-conformance OKF 合规性检查工具 ⭐
OKF-Claude-Code Claude Code 的 OKF 插件实现 ⭐

五、影响与展望

对 AI Agent 生态的影响

OKF 的定位非常精准——它不是给人类看的，而是给 AI 智能体看的"知识格式"。它解决的问题是：

  1. 上下文标准化：不同智能体之间共享知识的格式统一
  2. 知识可移植性：知识包可以跨系统、跨工具传递
  3. 低门槛：Markdown + YAML，开发者零学习成本
  4. 可演进：灵活的 frontmatter 体系，按需扩展

潜在局限

  • v0.1 版本过于简约，缺少版本管理、权限控制等企业级功能
  • 与已有 CMDB、数据目录工具的集成方案尚未明确
  • 生态尚处在萌芽阶段，只有 Google Cloud 一家主导

六、总结

OKF 的定位非常精准——它不是给人类看的，而是给 AI 智能体看的"知识格式"。它解决的问题是：

  1. 上下文标准化：不同智能体之间共享知识的格式统一
  2. 知识可移植性：知识包可以跨系统、跨工具传递
  3. 低门槛：Markdown + YAML，开发者零学习成本
  4. 可演进：灵活的 frontmatter 体系，按需扩展

潜在局限

  • v0.1 版本过于简约，缺少版本管理、权限控制等企业级功能
  • 与已有 CMDB、数据目录工具的集成方案尚未明确
  • 生态尚处在萌芽阶段，只有 Google Cloud 一家主导
苏ICP备19018690号-1