开放知识格式（OKF）全面分析：AI智能体时代的组织知识标准化

一、引言：OKF是什么？

2026年6月12日，Google Cloud正式发布了开放知识格式（Open Knowledge Format，简称OKF）0.1版。这是一套开放的、厂商中立的规范，用于表示组织内部的元数据、上下文和经过整理的知识，让人类和AI智能体都能直接读取。

OKF的核心主张极为简洁： 用普通的Markdown文件加YAML元数据头来表示知识。Google明确将其定位为“格式”而非“平台”——没有账号、没有SDK、没有厂商锁定，任何人用文本编辑器就能读写。

二、要解决什么问题？

2.1 上下文组装问题

在大多数组织中，AI模型需要的知识散落在互不兼容的系统中：

• 元数据目录（各有各的专有API）
• 内部Wiki、Notion、Confluence
• 代码注释和文档字符串
• 共享网盘中的PDF和Office文档
• 资深员工脑子里的“部落知识”

当一个AI智能体需要回答“如何计算周活跃用户数”时，它必须从这些互不兼容的来源中拼凑答案。每个团队都在从头解决同一个问题，知识被锁死在创建它的那个界面里。

2.2 现有方案的碎片化

过去一年里，开发者社区涌现出各种“LLM Wiki”模式——AGENTS.md、CLAUDE.md、Obsidian知识库——但每种都是定制化的，格式互不兼容，无法跨系统复用。OKF正是要填补这个空白：建立一套共同的约定，让不同生产者写的知识能被不同智能体消费，无需翻译层。

三、OKF核心规范解析

3.1 知识包（Knowledge Bundle）

一个OKF知识包就是一个目录树：

my_bundle/
├── index.md                  # 目录索引（可选）
├── log.md                    # 变更日志（可选）
├── datasets/
│   ├── index.md
│   └── sales.md
└── tables/
    ├── index.md
    ├── orders.md
    └── customers.md

每个非保留文件名的.md文件就是一个概念文档。index.md用于渐进式展示，让智能体先看目录再按需深入；log.md记录变更历史。

3.2 概念文档结构

每个概念（一张表、一个指标、一个API、一本运维手册）就是一个Markdown文件，包含两部分：

YAML元数据头（Frontmatter）：

---
type: BigQuery Table          # 必填
title: Orders                 # 推荐
description: 每行一个已完成客户订单  # 推荐
resource: https://...          # 推荐（底层资产URI）
tags: [sales, revenue]         # 推荐
timestamp: 2026-05-28T14:30:00Z # 推荐
---

唯一必填字段是type，用于标识概念类别（如Metric、Table、API、Runbook）。其余字段均为推荐项，消费者必须容忍缺失。

Markdown正文：

正文是标准Markdown，用于详细描述概念。可以用标题组织结构、表格描述Schema、代码块展示SQL示例。概念之间用普通Markdown链接相互关联，从目录中自然浮现出知识图谱。

3.3 设计原则

Google明确阐述了OKF的三个设计原则：

1. 极简主义：
    只强制type一个字段，其余全部由生产者自行决定。规范定义的是互操作界面，而非内容模型。
2. 生产者/消费者独立：
    生产者不需要知道消费者是谁，消费者不需要知道生产者是谁。格式是契约，两端的工具可独立替换。
3. 格式而非平台：
    不绑定任何云、数据库、模型或智能体框架。不需要专有账号，不需要SDK。

四、与LLM-Wiki模式的渊源

OKF并非凭空发明。它明确继承了Andrej Karpathy（OpenAI联合创始人）提出的“LLM-Wiki”模式。

2026年初，Karpathy在GitHub上分享了一个思路：与其让智能体反复查询相同文档，不如给它们一个共享的Markdown知识库，让智能体自己维护和更新。他观察到： 大语言模型不会厌烦，不会忘记更新交叉引用，一次处理就能覆盖15个文件——那些让人类放弃个人Wiki的维护性工作，恰恰是LLM擅长的。

这个思路在开发者社区迅速传播，但每个人都在自己的角落里重新发明轮子。OKF的价值就在于： 给这个模式加了一层标准化约定，让不同的“LLM Wiki”能够互操作。

五、OKF vs 其他标准

OKF与几个容易混淆的标准是互补而非竞争关系：

特别澄清：OKF ≠ SEO排名信号

OKF不会提升Google搜索排名。它不是公开网页格式，不是被全网爬取的发现标准，也不替代schema.org结构化数据。它是面向组织内部的：让你的智能体基于共享的权威知识运作，而不是每次都从零推导事实。

六、Google提供什么配套工具？

Google不止发布了规范，还提供了实际可用的参考实现：

1. 知识增强智能体（Enrichment Agent）：
    遍历BigQuery数据集，为每张表自动生成OKF文档草稿，再通过LLM补充Schema、关联路径和引用来源。
2. 静态HTML可视化工具：
    把任何OKF知识包转成交互式知识图谱，一个独立HTML文件，无需后端。
3. 三个示例知识包：
    GA4电商数据、Stack Overflow、Bitcoin公开数据集。

Google Cloud的Knowledge Catalog（原Dataplex）也已更新，支持直接接入OKF并服务于智能体。

七、谁应该采用OKF？

适用场景

• 团队正在运行内部Copilot或RAG系统，智能体频繁搞错指标定义或数据来源
• 数据和分析团队希望为每个指标建立唯一权威定义
• 平台和API团队希望智能体直接发现和使用他们的服务

怎么开始？

1. 从小处着手：
    选5-10个智能体最容易弄错的概念（核心指标、主要数据集、关键API）
2. 每个概念写一个文件：
    填上type、title、description，用Markdown写出精确定义
3. 放进Git做版本管理：
    让知识的每一次变更都可追溯、可审核
4. 让智能体指向它：
    把知识包加载到检索层或作为文件上下文提供给智能体
5. 持续迭代：
    每次智能体弄错一个事实，就新增或修正对应的概念文件

当前阶段的建议

如果你还没开始构建基于自有数据的智能体，OKF的优先级可以放低。当前让内容被AI发现和使用的更高杠杆动作是：做好schema.org标记、写好llms.txt、提供真正的API或MCP端点。

但如果你正在运行AI智能体处理自有知识，OKF是值得认真对待的。投入很小（一份规范、一个免费工具、一次Git提交），但解决了每个智能体项目都会遇到的核心问题。

八、总结

OKF的价值不在于发明了新技术——Markdown、YAML、目录树都是存在了几十年的原语。它的贡献在于： 在AI智能体时代，为知识表示找到了一个务实的平衡点——足够结构化以支持自动化处理，足够自由以容纳丰富的自然语言描述，足够简单以实现零门槛的生产与消费。

Google将它定位为“起点而非最终标准”。随着更多生产者和消费者加入生态，格式会继续演进。但对于已经在构建AI智能体的团队来说，今天就可以从中获益——用一个下午的时间，把那些让智能体最头疼的知识整理成一份Markdown知识包，然后看着它一步步变得更可靠、更准确。