认识 OKF — Open Knowledge Format（开放知识格式）

2026-07-29 0

Google Cloud推出OKF规范，用Markdown统一知识组织，解决AI时代知识碎片化难题！
核心内容：
1. OKF解决的知识碎片化问题及背景
2. OKF的核心设计：带YAML frontmatter的Markdown文件目录
3. 三项设计原则与后续发展方向

往期回顾

两个 DeepSeek 账号被我用于对照测试 DeepSeek++的体验

开发本地项目时，我尝试采用了DeepSeek++

一项开放规范在2026 年 6 月由Google Cloud 正式推出，名称是Open Knowledge Format（开放知识格式，OKF）。说到底，它并不复杂：为“以 Markdown 文件怎样组织知识”制定一套约定。

本文主要讨论 3 件事

01｜OKF 试图解决的问题

02｜OKF 的核心设计

03｜三项设计原则及后续方向

01OKF 试图解决的问题

数据库表的 schema、业务指标含义、事故处理手册、系统关联路径和旧 API 弃用通知等内部知识，是多数组织中AI 所需信息的主要来源。Google Cloud 在一篇博客中指出，现实难点在于这些知识散落得极其严重。

知识碎片化的现状

1. 各有独立 API 的元数据目录

2. Wiki、共享云盘及第三方系统

3. Notebook 单元格与代码注释、文档字符串

4. 知识仍留在工程师脑中，并未整理为文档

面对“如何从xxx中计算xxx”这类问题，智能体只能跨越彼此不兼容的系统拼出答案。于是，“上下文组装”这个相同问题，被每个采用 AI 的人重复解决。

现有思路：把知识作为 Wiki

多个场景正在再次验证Andrej Karpathy 的 LLM Wiki 模式

LLM 不会厌倦，不会漏掉交叉引用更新，并能一次处理 15 个文件，这是Andrej Karpathy 在其 LLM Wiki Gist 中明确表达的观点。人类常常放弃的 Wiki 维护任务，恰好属于 LLM 的长项。

接入编码智能体的 Obsidian Vault、AGENTS.md / CLAUDE.md 约定文件，以及堆满 index.md 和 log.md 的仓库，都是这种模式以不同名称出现的形态。问题在于，各种方案均为量身定制，彼此并不兼容；OKF 的提出正是要填补这一差距。

02OKF 的核心设计

OKF 的定位十分清晰：解决该问题需要一种格式，而非新增一项知识服务。该格式应允许任何人生产而无须 SDK，允许任何人消费而无须集成，能够跨系统和组织迁移，可以和代码共同进入版本控制，并让人和智能体直接读取。

它采用的具体形态非常简单：目录之中存放 Markdown 文件，每个文件均带 YAML frontmatter。

一个 OKF 文档包采用如下目录结构：

YAML frontmatter 与 Markdown 正文共同组成每份概念文档，其中frontmatter 只有 type 字段属于必填项：

整个目录因概念间的普通 Markdown 链接而形成关系图。此外还能用 index.md 完成渐进式披露，log.md 变更历史也会得到记录。OKF v0.1 SPEC.md（GitHub）提供了完整规范。

我的理解

一种格式的价值并不由创造者决定，而取决于实际使用者的数量。Google 没有将其藏在自家产品里作为独家功能销售，而是选择以开放标准发布，这一做法本身更有利于生态发展。

03后续方向和三项设计原则设计所遵循的三项原则

1.尽量减少预设。仅强制要求 type 字段，其他内容由生产者自行决定。

2.消费者与生产者彼此独立。无论由人类手写、流水线生成还是LLM 合成，格式始终作为契约存在，两端都能独立替换。

3.它是一种格式，而不是平台。不与任何特定云、数据库或模型提供商绑定。

已经完成的标准并不是OKF v0.1，它只是起点。原文建议各方研读规范，开发生产器与消费者，试用参考实现并提交 Issue 和 PR。贡献的核心在格式本身，工具的作用则是推动落地。

参考实现也由Google 一并发布：智能体能够自动遍历数据集并生成 OKF 文档，可视化工具则可把 OKF 包呈现为交互式图形；Google Cloud 的 Knowledge Catalog 目前也支持导入 OKF 格式。工具承担的是格式落地工作，真正的核心贡献仍然是格式本身。