知识管理

了解下 OKF — Open Knowledge Format（开放知识格式）

2026 年 7 月 27 日

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

往期回顾

2026 年 6 月，Google Cloud 正式发布了一项名为 Open Knowledge Format（开放知识格式，OKF）的开放规范。它的本质其实很简单——就是一套关于"怎么用 Markdown 文件组织知识"的约定。

这篇文章主要聊 3 件事

01｜OKF 要解决什么问题

02｜OKF 的核心设计

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

01OKF 要解决什么问题

Google Cloud 在一篇博客中指出一个现实：大多数组织中，AI 需要的信息主要是内部知识——数据库表的 schema、业务指标的含义、事故处理手册、系统之间的关联路径、旧 API 的弃用通知等等。但问题是，这些知识极度分散。

知识的碎片化现状

1. 元数据目录——各自有各自的 API

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

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

4. 工程师的大脑中，并未输出到文档

当一个智能体需要回答"如何从xxx中计算xxx"时，它得从这些互不兼容的系统里拼凑答案。结果是：每个用 AI 的人都在重复解决同样的"上下文组装"问题。

已有解法：知识即 Wiki

Andrej Karpathy 的 LLM Wiki 模式正在多个场景下被重新验证

Andrej Karpathy 在他的 LLM Wiki Gist 中说得很清楚：LLM 不会感到无聊、不会忘记更新交叉引用、可以一次处理 15 个文件。那些让人类放弃 Wiki 的维护工作，LLM 反而擅长。

这种模式以不同名称反复出现——接入编码智能体的 Obsidian Vault、AGENTS.md / CLAUDE.md 约定文件、装满 index.md 和 log.md 的仓库。但每一种都是量身定制的，互相之间不兼容。OKF 就是为了弥合这个差距而提出的。

02OKF 的核心设计

OKF 的定位很明确：解决这个问题需要的是一种格式，而不是另一项知识服务。这种格式应该满足：任何人都能生产（不需要 SDK）、任何人都能消费（不需要集成）、能在系统和组织之间迁移、和代码一起放在版本控制中、人和智能体都能直接读取。

它的具体形态很简单：一个包含带 YAML frontmatter 的 Markdown 文件的目录。

一个 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 格式。不过这些工具只是为了让格式落地，格式本身才是核心贡献。

立即咨询 JOTO

JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。联系 JOTO 获取 AI 落地咨询

留下你的场景和痛点,我们帮你判断从哪一步开始。