Open Knowledge Format（OKF）：谷歌推出面向 AI 智能体的开放知识交换标准

2026/8/22·1 views

在RAG、AI Agent遍地开花的今天，大家都在关注大模型、检索框架、智能体编排，但很少有人思考：企业知识应该用什么格式存储、交换、迁移。各个知识库、RAG平台各搞一套私有格式，知识被锁死在厂商平台内，Agent之间无法互通知识。2026‑06 Google Cloud正式发布 Open Knowledge Format（OKF v0.1），把Andrej Karpathy提出的LLM‑wiki模式标准化，打造一套厂商中立、人和AI都能读写的知识开放规范。

一、背景：企业知识碎片化的现实困境

企业内部沉淀大量高价值知识：数据表Schema、业务指标定义、故障运维手册、API废弃说明、业务规则。但这些知识散落各处：元数据目录、内部Wiki、共享盘、代码注释、Notion、甚至只存在老员工的脑子里。

当下的痛点：

知识孤岛严重：每家RAG平台、元数据系统、Agent框架都定义自己私有数据模型，知识不能导出、跨工具无法复用。
重复造轮子：每开发一套AI智能体，都要重新做一遍知识解析、导入、适配。
迁移成本极高：换知识库产品，大量业务知识需要重新加工，无法直接迁移。
人与Agent两套体系：人工维护的文档和AI消费的知识两套格式，需要做繁琐转换。

很多团队想到用Wiki、Obsidian Vault来做AI知识库，也就是著名的LLM‑wiki思想：让大模型读写Markdown知识库，像人类查阅Wiki一样获取事实知识。但过去只是团队内部约定，没有统一规范，A团队的Wiki不能直接被B团队Agent读取。OKF就是把这套模式固化为公开标准。

OKF不是新数据库、不是新RAG服务，它仅仅是一套文件格式规范。

二、OKF到底是什么？

OKF全称 Open Knowledge Format，开放知识格式。
OKF Bundle 就是一个普通文件夹，里面是一批Markdown文件，头部附带YAML Frontmatter元数据，没有特殊二进制、不需要SDK、不需要专属运行时。

核心特征：

本质就是Markdown + YAML元数据
Markdown正文存放业务内容、表格、说明；YAML frontmatter存放结构化查询字段：type、title、description、resource、tags、timestamp。普通编辑器、GitHub都可以直接阅读编辑。
就是普通文件目录
可以打包tar压缩包，可以存入Git版本库，可以放到任意文件系统。路径本身代表知识实体的唯一身份。
markdown内部链接构建知识图谱
文件之间通过普通Markdown链接互相引用，目录不再只是层级文件夹，而是形成一张知识关系图。

示例单份OKF文档片段：

markdown 复制代码

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026‑05‑28T14:30:00Z
---
# Schema
| Column | Type | Description |
|---|---|---|
| `order_id` | STRING | 全局唯一订单ID |
| `customer_id` | STRING | 关联客户表外键 |

# Joins
与 [customers](/tables/customers.md) 通过 `customer_id` 做关联。

目录结构示例：

复制代码

sales/
├── index.md
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
└── metrics/
    ├── index.md
    └── weekly_active_users.md

index.md用于目录概览，log.md记录变更历史，全部是普通文本文件。

OKF三大设计原则

最小侵入原则：只强制要求type字段，其余字段、文档结构不做强制约束，给业务极大自由度，只定义互操作契约，不干涉业务内容。
生产者与消费者解耦：人写的OKF文档可以给Agent读；ETL流水线导出OKF可以给可视化工具浏览；A大模型生成OKF，B大模型可以直接消费，两端工具完全独立。
格式而非平台：不绑定云厂商、数据库、模型、Agent框架，无专有账号、无闭源SDK，任何人都可以读写该格式。

三、OKF能解决哪些业务问题

1. 知识可迁移，告别厂商锁定

你在RAG系统、元数据平台沉淀的业务知识，可以导出为OKF目录包，迁移到另一个RAG引擎、另一个Agent框架，不用重新解析、重写文档。

对比现状：很多RAG平台导出只能给自家系统导入，跨平台基本作废。

2. Git管理企业知识，实现知识即代码

整套OKF Bundle放进Git仓库，版本回溯、PR评审、变更记录，和管理源代码一样管理业务知识。人工编辑、AI Agent自动更新文档，全部留存版本历史。

3. 一套知识同时服务人与AI

同一份Markdown文件：

工程师、业务人员直接打开阅读编辑；
AI智能体直接解析YAML元数据、读取正文、解析内部链接，获取实体关系。
不需要维护两套不同格式的知识库。

4. 打通多Agent之间知识共享

多个业务智能体（投研Agent、运维Agent、数据分析Agent）可以读取同一套OKF知识库，知识只维护一份，多处复用。

四、谷歌配套参考实现

规范之外谷歌同时发布了参考工具，全部为概念验证Demo，不是闭源产品：

富集Agent：扫描BigQuery数据集，自动生成每张数据表的OKF文档，抓取官方文档补充字段说明、关联关系。
静态HTML可视化器：单个HTML文件，加载OKF Bundle渲染知识关系图谱，不需要后端服务，数据完全在浏览器本地。
示例数据集：GA4电商、StackOverflow、比特币公开数据集三套OKF样例，放在GitHub仓库。
Google Cloud Knowledge Catalog原生支持导入OKF，喂给云侧AI智能体使用。

重点：OKF是开放标准，不局限于Google生态，其他厂商、开源框架都可以实现读写OKF。

五、OKF与RAG、RAGFlow的关系

很多人会疑惑：OKF会替代RAG吗？不会，两者是互补关系。

RAG / RAGFlow	OKF
一套完整应用平台：文档解析、分块、向量库、检索、智能体编排	只是知识存储交换格式，不做检索、不做向量、不做Agent调度
负责把原始PDF/Word处理成可检索内容	定义处理完成之后，知识应该以什么形态保存、流转

工作流可以这样组合：

PDF/Word → RAGFlow做ETL解析、提炼业务实体 → 导出OKF Bundle → Git保存版本 → 多个Agent、不同RAG系统读取OKF知识库。

RAGFlow这类开源RAG引擎未来完全可以增加OKF导入导出能力，让企业知识库可以跨系统流转。

六、OKF的局限与现实挑战

尚处于v0.1早期版本，规范还在迭代，v0.2已经开始补充可信度、来源溯源相关字段，生产大规模落地还需要生态成熟。
OKF解决知识表示与交换，不解决向量索引、检索性能、大模型幻觉；仍然需要RAG系统做检索增强。
需要配套工具链：需要ETL工具把PDF、数据库元数据转成OKF；也需要工具把OKF批量灌入向量库。原生没有内置检索能力。
大规模海量知识，大量小Markdown文件会带来文件系统管理的工程问题。

七、写在最后

大模型时代，大家疯狂卷模型能力、Agent框架，但知识本身的标准化被忽略。OKF的定位，类似AI知识领域的HTML：HTML没有发明浏览器，只是定义网页长什么样，让不同浏览器都可以解析网页。OKF没有发明RAG或者Agent，而是定义知识实体长什么样，让不同RAG、不同Agent可以交换知识。

未来，企业知识库不应该绑定某一个RAG产品。知识本身应该可以导出、版本管理、跨平台流转。OKF给行业提供了一个极简、开放的备选项。

项目信息：

官方文档：https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/
GitHub仓库：存放规范、样例、参考实现

对这篇文章有意见或建议？提交反馈