OKF：LLM Wiki 知识库的落地实践标准

你花三个月做了技术调研，读了二十篇论文、整理了十几份文档、记了一百多条笔记。结论有了，关键词也有。但当你问 AI：「这个技术领域的核心概念是什么？不同方案的权衡是什么？」

它答不上来。

不是因为你笔记写得不好，而是因为这些笔记缺乏结构——AI 不知道「这篇是方法 A 的缺陷分析，那篇是方法 B 的适用场景，另外几篇是竞品对比」，它只能看到一堆文本，不知道它们之间的关系。

Karpathy 的 LLM Wiki 思路给了一个方向：采集 → 整理 → 生成可查询的 wiki。但真正落地时你会发现一堆问题没有答案：frontmatter 应该有哪些字段？目录怎么组织？AI 按什么路径找知识？这些没有标准答案，大家都在模糊地试。

OKF（Open Knowledge Format） 补上了这一环。

OKF 是什么

OKF 是 Google Cloud 在 2026 年初发布的知识表示格式规范。本质上，它是一组约定：如何用 Markdown 文件组织知识，使得知识结构——有哪些概念、各概念之间什么关系、AI 怎么找到它们——变得机器可读。

规范极度轻量，只有三条原则：

最小化偏见 — 只强制要求一个字段：type。其他字段全部由你自己定义。

生产者 / 消费者独立 — Google 给了一套从 BigQuery 自动生成 Bundle 的工具，但你可以手写、用任意工具生成。规范只是约定，不是绑定。

格式不绑定平台 — OKF Bundle 就是一个文件夹，里面是一堆 .md 文件。Git 管理、打包成 tarball、直接拷贝——没有任何专有依赖。

OKF 回答了落地问题：header 写什么（type 必填，其他自定义）、数据怎么组织（index.md + 分类目录 + references）、AI 怎么找（从 index.md 开始，按链接逐层读取）。

OKF 和 PKM 已有实践的对应关系

如果你已经在用 Obsidian，看到 OKF 的结构会觉得眼熟——它们的思路高度重合，只是表述不同：

OKF 把这些做法标准化了，并且配套了工具链。但如果你已经在用 Obsidian，你其实已经在实践 OKF 的思路了——只是没有意识到这和 Google 提出的规范是同一件事。

一个关键分类：Skill 和 OKF 解决不同问题

在 AI Agent 的语境里，这两个概念经常被混在一起，但解决的是完全不同的问题：

• • Skill = 程序性知识，回答「怎么做」
• • OKF = Declarative 知识，回答「是什么」以及「知识在哪里」

技术调研场景下：OKF 负责告诉 AI「方法 A 是什么、适用场景是什么、和方法 B 的核心差异是什么」；Skill 负责「用方法 A 写一段示例代码、用 pip 安装这个包」。两者各司其职。

这和 CoALA 框架也是一致的：

• • 程序性记忆：怎么做（Skill）
• • 语义记忆：是什么、在哪里（OKF）
• • 情景记忆：发生了什么（Chat History / Daily Notes）

OKF vs RAG：不是替代，是分工

• • RAG = 搜索引擎。输入「Vue 响应式原理」，返回一堆包含这些词的网页。
• • OKF = 翻目录。你翻开《Vue 权威指南》的目录，直接翻到「响应式原理」那一章。

更合理的组合是：用 OKF 定义知识边界和关联，让 AI 先确定查哪个库；再用 RAG 在具体库内做语义搜索。

enrichment_agent 工具链

OKF 官方提供了一套参考实现工具 enrichment_agent，基于 Google ADK（Agent Development Kit）构建，包含两个 AI Agent：

背后默认用 gemini-flash-latest——整个生成过程是 AI 密集型的，不是硬编码规则。

生成完 Markdown 文件后，writer.py 把所有内容打包进 viz.html——一个自包含的交互图谱，用 Cytoscape.js 渲染节点关系，点击节点可以看到完整文档。

最终交付两个产物：人类可读的 Markdown 文件（可版本控制）+ AI 可消费的 BUNDLE 对象（JSON 结构，大模型直接读取做推理）。

viz.html 图谱：实际效果

OKF 官方提供的 viz.html 用 Cytoscape.js 渲染成交互式图谱。以下是 GA4 Bundle 的实际运行效果：

点击任意节点，右侧面板会显示该概念的完整文档内容，包括 frontmatter 元数据和 Markdown body：

支持按类型过滤节点、快速搜索、以及查看每个节点的「Cited by」反向引用：

有意思的是细节：OKF 用标准 Markdown 链接[text](path.md)，Obsidian 用双向链接[[wikilink]]。如果你把 OKF Bundle 直接丢进 Obsidian，graph 视图是空的——Obsidian 只识别[[]]语法。目前两者没有很好的兼容方案。

Bundle 结构：知识如何分层组织

一个 OKF Bundle 本质上是一个目录，包含某个知识领域的完整文档：

ga4/
├── index.md                 # 入口（MOC 导航页）
├── datasets/
│   └── ga4_obfuscated_sample_ecommerce.md
├── tables/
│   └── events_.md
└── references/
    ├── metrics/
    │   ├── event_count.md
    │   └── user_count.md
    └── joins/
        └── events___ads_clickstats.md

每个 .md 文件的结构：YAML frontmatter + Markdown body。

---
type: BigQuery Table
title: Events table
description: 包含 Google Analytics 事件导出数据
resource: https://bigquery.googleapis.com/...
tags: [events, Google Analytics, BigQuery]
---

body 分层写入：Overview → Schema → Metrics → Joins → Citations。

对个人知识库的启发

OKF 的价值不是让你迁移到一套新系统，而是让你重新审视几个已经存在的实践：

MOC 是入口，不是装饰 — MOC 的本质是路由——告诉 AI 或其他人「这个领域的知识从哪里开始、核心是哪几篇」。写得好的 MOC 应该能让人在三分钟内搞清楚这个领域的结构。

frontmatter 的 type 字段值得认真填 — OKF 只强制要求 type，这是有道理的。类型标签是机器理解一篇笔记「是什么」的最直接路径。

References 是双向的 — A 引用了 B，B 应该能列出「被谁引用」。OKF 的 viz.html 在每个节点详情里显示了「Cited by」。Obsidian 的反向链接面板本质上做了同一件事——但很多人没有认真用过它。

知识库也需要「新陈代谢」 — OKF Bundle 的结构适合稳定领域，但现实中的知识库是不断生长的。定期 review、淘汰过时内容、合并重复概念——比一味新增更重要。

OKF 规范地址：https://github.com/GoogleCloudPlatform/knowledge-catalog