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

在技术调研达到一定深度时，常常会感到一种似曾相识的困惑：资料搜集了一大堆，关键结论心中也有数，但真正让 AI 帮忙整合成一个清晰的知识结构时，对方却总是表现出“信息太多，抓不住重点”的状态。

这种情况，本质上并非笔记没写好，而是笔记之间缺少了一张“知识地图”。AI 无法判断哪一篇是在深入分析方案 A 的缺点、哪一篇是在对比方案 B 的适用场景。它面对的只是一锅无序混搭的文本，而非一个有序的知识库。

Karpathy 提出的 LLM Wiki 概念——采集、整理、生成可查询的 wiki——指明了方向。但一旦进入实操阶段，许多实际问题便浮现出来：frontmatter 中究竟应该放哪些字段才合适？目录应该如何组织才能最高效？AI 应该按照什么路径来检索知识？这些关键环节长期缺乏公认的标准，大家只能自行摸索前进。

OKF 正是在这样的背景下，补上了最为关键的一环。

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 经常被混为一谈，但它们解决的是完全不同的问题：

• Skill = 程序性知识，回答“怎么做”
• OKF = 声明性知识，回答“是什么”以及“知识在哪里”

一个典型的技术调研场景中：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 正文：

它还支持按节点类型过滤、快速搜索、以及查看每个节点的“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 正文：

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

正文则分层写入：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

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：OKF LLM Wiki知识库落地实践标准要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题