Google 推出 OKF：AI 知识库终于开始有“通用格式”了

Google Cloud 六月中旬发了一篇文章，介绍 Open Knowledge Format，简称 OKF。

光看标题，很容易把它当成又一个企业数据目录标准。文章发在 Google Cloud Data Analytics 频道，例子也全是 BigQuery、数据表、指标、runbook、API 这些企业场景。但这件事得放到另一个脉络里看。

过去半年，越来越多人意识到一个问题：AI 知识库不能只停在”上传资料，然后问答”这个阶段。真正好用的系统，应该让 AI 持续读取、整理、更新一套长期存在的知识结构。Karpathy 管这个叫 LLM Wiki。

Google 干的事，是把这个模式往前推了一步。如果大家都开始用 LLM 维护 Wiki，那这些 Wiki 能不能有一个通用格式？不同工具、不同 Agent、不同团队之间，能不能互相读取和交换？

OKF 回答的正是这个。

OKF 全称 Open Knowledge Format。Google 对它的定位就一句话：一个开放规范，把 LLM Wiki 这种模式形式化成一套可移植、可互操作的知识格式。

两个关键词。

第一个：”格式”。

OKF 不是新产品，不是 RAG 平台，不绑定 Google Cloud。它是一套文件约定：知识怎么落盘、页面有哪些基本元数据、页面之间怎么链接、目录怎么同时被 Agent 和人理解。

第二个：”互操作”。

现在很多团队都在做类似的事——用 Markdown 写内部 Wiki，frontmatter 放元数据，AGENTS.md 或 CLAUDE.md 约束 Agent 行为，index.md 和 log.md 管理导航和演化记录。

问题在哪？每家都有自己的约定。

你家的 Wiki、Karpathy 的 Wiki、某个数据目录导出来的 Markdown，看起来都很像：文件夹、Markdown、元数据、链接。但它们没有共同协议。一个 Agent 读得懂自己的项目，换个团队的知识库就抓瞎。

OKF 想填的正是这层断裂。它要定义一层足够薄、足够通用的知识交换层。

OKF v0.1 没有搞复杂系统。基本形态就是一个文件夹，里面一堆 Markdown，每个文件顶上有一段 YAML frontmatter。

大概长这样：

knowledge-bundle/
├── index.md
├── log.md
├── datasets/
│   └── orders_db.md
├── tables/
│   ├── orders.md
│   └── customers.md
└── metrics/
    └── weekly_active_users.md

每个 Markdown 代表一个概念。可以是一张表、一个指标、一个 API、一个 runbook，也可以是业务流程、方法论、主题页。文件路径直接当概念 ID：

tables/orders.md → tables/orders

页面顶部的结构化字段：

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://example.com/orders
tags: [sales, revenue]
timestamp: 2026-06-12T10:00:00Z
---

OKF 强制要求的字段只有一个：type。

这个克制让我很认可。没有规定你必须用哪些类型，没有要求接入 schema registry，不强迫你用某套 SDK。title、description、resource、tags、timestamp 全是推荐字段，不是硬约束。

设计逻辑很清醒：知识格式要先活下来，就不能一上来太重。依赖专有平台、复杂服务、中心化注册表的格式，成不了 Agent 之间的通用语言。反过来，Markdown、YAML、Git、普通文件夹这些东西虽然朴素，优势却实实在在——人能读，机器也能读，能 diff，能版本管理，能被任何工具索引。

OKF 没发明新东西。它承认了一件已经发生的事：Agent 时代的知识中间层，大概率就是”Markdown + 元数据 + 链接 + 版本管理”。

Google 文章举的企业数据场景很说明问题。

在一个真实组织里，AI Agent 要回答一个看似简单的问题——比如”怎么从事件流里计算周活用户”——它可能需要同时理解：表结构、字段含义、指标定义、join 路径、历史变更、业务口径、数据质量问题、某个团队写过的 runbook。

这些信息散落在不同地方：数据仓库、BI 工具、文档系统、Slack、会议纪要、老员工脑子里。

传统做法是给 Agent 接各种工具，运行时临时拼上下文。能用，但每个系统都在重复解决同一个问题——上下文怎么组装？知识怎么表示？不同工具之间怎么迁移？

OKF 的思路不一样：先把这些”围绕数据和系统的知识”整理成一个开放的知识包。Agent 不用每次都从碎片系统里捞材料，直接读一套已经整理好、带元数据、带链接、可追踪版本的 Markdown 知识库就行。

人打开能读，Agent 打开能根据 type、路径、链接、index.md、log.md 去遍历、检索、更新、组合。

它跟传统知识管理规范的根本区别就在这里——不是给人类编辑部设计的，是给人和 Agent 共同维护知识准备的。

很多人会问：这不还是知识库吗？

我的理解是，RAG 主要解决”问的时候怎么找到相关片段”。OKF 更关心”知识在被问之前，应该以什么形态存在”。

普通 RAG 的链路：

原始资料 → 切块 → 向量化 → 查询时检索 → 拼上下文 → 生成回答

问题不是不能回答，是每次都太临时。今天问一个复杂问题，系统从几份资料里找到片段，综合出一个不错的答案。答案没有被写回，明天再问相似问题，它重新来一遍。

OKF 背后更接近：

原始资料 → Agent 整理 → OKF 知识包 → Agent / 人 / 工具共同消费

知识不再是运行时临时检索的材料，而是提前整理成一个稳定的中间层。

我之前讲 LLM Wiki 时，常用”编译”这个词打比方：RAG 像解释执行，LLM Wiki 像提前编译，OKF 则像给这个编译结果规定一种可交换格式。不严谨，但能帮你抓住它到底在解决什么。

这是最容易搞混的地方。

Karpathy 的 LLM Wiki 是一种工作流。它关心的是：怎么让 LLM 不只是回答问题，而是持续维护一个长期 Wiki。资料进来，LLM 读取原文，更新概念页、实体页、主题页、索引、日志，发现矛盾，补双链，把高质量问答写回知识库。解决的是知识复利。

OKF 是一种格式。它关心的是：如果每个人、每个团队、每个工具都开始生成这种 Wiki，那这些 Wiki 怎么被交换？哪些字段至少要约定下来？文件路径、frontmatter、链接、index.md、log.md 应该怎么理解？解决的是知识流通。

一张表拆开：

两者不是竞争关系。更准确地说，OKF 是 LLM Wiki 走向工具生态之后自然需要的一层协议。

你可以有一个不遵守 OKF 的 LLM Wiki，照样能解决个人知识复利。只是当你想把它交给另一个工具、另一个 Agent、另一个团队时，迁移成本会高一些。反过来，你也可以生成一个 OKF 知识包但不采用完整的 LLM Wiki 工作流，它依然是一套标准化文档，只是缺了持续维护、查询写回、定期体检这些复利机制。

最理想的状态：用 LLM Wiki 的工作流维护知识，用 OKF 的格式沉淀知识。

表面看，OKF 是给企业数据团队准备的。但我反而觉得，个人知识库玩家、自媒体作者、研究者也该早点关注。

理由不复杂：个人知识库正在从”给自己看的笔记”变成”给 AI 也能稳定使用的知识资产”。

过去写笔记，主要考虑自己能不能看懂。标题清楚、标签合理、双链不乱，就够了。但如果你希望 AI Agent 长期维护你的知识库，局面就变了。它需要知道：

这些问题靠”随便写 Markdown”搞不定，得有一套规则。Karpathy 把这套规则叫 Schema，Google OKF 则提供了一套更通用的落盘格式。一个偏操作，一个偏交换。

我的判断是：以前的知识库是人给自己建的，接下来是人和 AI 共同维护的，再往后还会变成能被不同 Agent 和工具交换的知识资产。方向已经很清楚了。

话虽这么说，有一句提醒：如果你连最小 LLM Wiki 都没跑通，先别追 OKF。

做知识库最容易犯的错就是先迷恋结构——目录分几层、字段统不统一、标签要不要做成 taxonomy、上不上知识图谱、做不做可视化。这些问题都可以聊，不是第一步。

第一步是跑通一个最小循环：

资料进入 raw
→ Agent 编译进 wiki
→ 基于 wiki 提问
→ 高价值回答写回
→ 定期 lint 维护
→ 支撑一次真实输出

这条流程跑通了，格式标准才有意义。不然你只是拥有一个更规范的空架子。

OKF 的价值不是让文件头写得更漂亮。它提醒我们：知识库会越来越像代码库——需要结构、版本、约定、可读性、可迁移性，也需要持续维护。

Google 推 OKF，让我更确信一件事：LLM Wiki 不是小众笔记玩法，它正在变成 Agent 时代的基础工作流。

Karpathy 先把”AI 维护 Wiki”这个模式讲清楚了。Google 现在进一步说明，这种 Wiki 需要开放格式、需要跨工具流通、需要成为 Agent 能直接消费的知识层。

对企业，这可能变成数据目录和知识目录的新接口。对个人，它提醒我们早点把资料从”存起来”升级到”编译成系统”。

如果你也碰到过这些情况——资料越存越多，真正写东西时还是从零开始；AI 回答过很多好内容，全散在聊天记录里；Obsidian、Notion、网盘越来越复杂，却没有变成稳定输出力——那这件事值得你认真看看。

OKF 本身只是个规范，不用焦虑要不要马上跟。但 LLM Wiki 这套方法，值得每个人早点开始。