Google OKF 开放知识格式简介

基础模型能力再强，如果没有「业务上下文」，也发挥不出应有实力。在构建 AI Agent 系统时，模型能写代码、做总结、做分析，但前提是你喂给它的信息要足够准确。

Google 推出的「开放知识格式」（Open Knowledge Format，简称 OKF），是一套把 LLM-wiki 模式标准化的开放规范，主打便携和跨工具互通。它格式中立，人类和 AI Agent 都能直接读取，主要用来承载 AI 系统所需要的元数据、上下文和人工筛选过的知识。

在 OKF 规范里，知识就是一个包含 Markdown 文件和 YAML 前言（Frontmatter）的目录。通过少量约定，知识库就能直接被不同的 AI Agent 读懂，完全不需要中间翻译层。

OKF 没有复杂的压缩机制，不需要运行时，也不绑定特定 SDK。一份知识包里面就只有 3 样东西：

纯粹的 Markdown 文件：任何编辑器都能打开，GitHub 上可以直接渲染，搜索工具也能建立索引。
普通文件系统目录：可以打包成 tarball，托管在 Git 仓库，或者直接挂载到文件系统上。
极简的 YAML 前言：只包含需要被查询的结构化字段，比如 type、title、description、resource、tags和 imestamp。

如果你用过 Obsidian、Notion、Hugo 或 LLM-wiki，对这套结构应该不会陌生。OKF 就是把这些模式用少量约定固化下来，让工具之间能够互通。

破碎的上下文生态

基础模型需要的信息，大多是企业内部知识：比如某张数据表的 Schema、业务对某个指标的定义、某次故障处理的 Runbook、系统间的关联路径，或者某个废弃 API 的下线通知。

然而现状是，这些知识散落在相互不兼容的系统里面。它们可能在自带独立 API 的元数据目录里，在企业 Wiki 和云盘里，在代码注释和 Jupyter Notebook 里，甚至只存在于资深工程师的脑子里。

当 AI Agent 需要回答「如何从事件流里计算周活跃用户」时，它就得去这些零散的平台上东拼西凑。但每家供应商又都在推自己的数据目录、SDK 和图谱 Schema，造成了知识很难在不同产品和组织之间平滑迁移。

结果就是，开发者需要为每个 AI Agent 从头解决「组装上下文」的问题，供应商又在重复造轮子，而知识本身却被锁在了最初生成它的平台里。

知识即 Wiki，由大模型来维护

现在，构建 AI Agent 的方式已经在改变：很多开发者不再让模型一遍遍检索相同的文档，而是直接喂给 Agent 一个共享的 Markdown 知识库。阅读和更新文件的操作直接交给 AI Agent，团队像管理代码一样专注维护核心内容。

Andrej Karpathy 在讲 LLM-wiki 的 Gist 里提到一个逻辑：大语言模型不会觉得烦，不会忘记更新交叉引用，还能在一次运行中修改 15 个文件。但人类往往会嫌记录麻烦，懒得维护 Wiki，而大模型正好适合接手这种琐碎的工作。

类似的「知识即 Wiki」模式其实已经在各种名头下跑了很久，比如和编码 AI Agent 绑定的 Obsidian 笔记库，AGENTS.md或CLAUDE.md这种规范文件，提供 AI Agent 干活前查阅的知识仓库，以及数据圈的「元数据即代码」实践。

这种模式目前的实现都是各做各的。不管是谁搭建的 Wiki 或导出的目录，表面上都是 Markdown、带 YAML 前言、支持双向链接，但设计时并没有考虑互通。文档该有哪些字段、文件名代表什么，完全没有统一共识。换一个新的 AI Agent 来读取，往往又得重新做适配。

OKF 开放知识格式简介

要解决这个问题，其实并不需要新搭一个知识管理服务。你需要的是一种格式，一种满足下面几个条件的知识表示格式：

不用依赖 SDK，谁都能生成
不用额外集成，谁都能读取
跨系统、跨组织、跨工具迁移时结构不会损坏
能和代码一起放进版本控制系统
人类和 AI Agent 都能直接读取，不需要中间转换层

OKF 从一开始就是按这个目标来设计的。

OKF 的设计原理

OKF 知识包，本质上就是一个存放 Markdown 文件的目录。每个文件对应一个概念，比如数据表、指标、故障手册或 API。文件路径就是概念的唯一标识：

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

每个概念的文档顶部，都包含一小段 YAML 前言，用来存放结构化字段，往下则是 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    | Globally unique order identifier.        |
| `customer_id` | STRING    | FK to customers. |

# Joins

Joined with customers on `customer_id`.

概念之间用普通的 Markdown 链接跳转，把目录织成网状图谱。知识包还可以选择性加上两类文件：index.md方便 AI Agent 按层级导航和获取信息，log.md则用来按时间顺序记变更历史。

OKF 的三大设计原则

极简的约束：OKF 对概念文档的硬性要求只有一条：必须包含type字段。具体有哪些类型、加不加扩展字段、正文分几章，完全由内容生产者自己决定。规范只给互操作划好边界，不干涉内容。
生产和消费解耦：「谁写知识」和「谁用知识」完全分开。手写的知识包可以直接喂给 AI Agent，流水线导出的能在可视化工具里浏览，一个大模型合成的知识包也能直接给另一个模型调用。两端的工具随时也能独立替换。
只是格式，不是平台：OKF 不绑定云厂商、数据库或 AI Agent 框架，也不强制注册账号或使用专属 SDK。

随规范发布的配套工具

为了让这套格式能真正落地，Google 在生产端和消费端开源了几个参考实现：

信息富化 AI Agent：能遍历 BigQuery 数据集起草 OKF 文档，再用大模型爬取权威文档，补上引用来源、Schema 结构和表关联路径。
静态 HTML 可视化器：把 OKF 知识包转成图谱视图。完全独立免后端，数据不用离开浏览器。
三个示例知识包：覆盖 GA4 电子商务、Stack Overflow 和比特币公共数据集，由上面的参考 Agent 生成并提交到了代码仓库。

目前 Google Cloud 的知识目录已经支持 OKF 格式，可以直接提供给 AI Agent 使用。格式的规范文档、相关代码和示例知识包，也已经开源发布到了 GitHub 上。

Google OKF 开放知识格式简介

破碎的上下文生态

知识即 Wiki，由大模型来维护