LLM Wiki知识库落地实践标准权威指南（2025版）

2026-06-22阅读 0热度 0

ai 人工智能

技术调研深入到一定程度，一个熟悉的困境便会浮现：资料收集齐全后，关键结论心里清楚，但想让 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 概念	PKM 对应	说明
`index.md`	MOC（Map of Content）	入口导航页，列出该领域的核心页面
目录分层结构	PARA / 主题文件夹	按领域组织，非扁平文件列表
frontmatter `type`	页面类型标签（Concept / Note / Reference）	定义这篇笔记的知识类型
references	双向链接 `[[wikilink]]`	概念之间的关联
`type: Reference`	Literature Note	引用来源

OKF 将这些分散的做法系统化、标准化了，并配备了工具链。但如果你已经在用 Obsidian 进行日常知识管理，完全可以理解为：你早已用自己的方式践行 OKF 思路，只是未曾意识到这和 Google 提出的正式规范是同一回事。

一个关键分类：Skill 和 OKF 各司其职

在 AI Agent 的语境中，Skill 和 OKF 经常被混为一谈，但它们解决的是完全不同的问题：

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

在典型的技术调研场景中：OKF 负责告诉 AI「方法 A 是什么、适用场景是什么、和方法 B 的核心差异是什么」；而 Skill 负责「用方法 A 写一段示例代码、用 pip 安装这个包」。两者缺一不可，且分工明确。

这与 CoALA 框架也一一对应：

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

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

	RAG	OKF
本质	检索技术	知识表示格式
知识组织	非结构化 Chunk，向量索引	结构化图谱，预先定义关联
查询方式	语义相似度搜索	精确路由（读索引 → 读概念 → 读详情）
维护成本	低，追加文档即可	高，需要同步更新
适用场景	变化频繁的非结构化知识	相对稳定、有明确 Schema 的领域

可以这样理解：RAG 是搜索引擎——你输入「Vue 响应式原理」，它返回一堆包含这些词的网页。OKF 则是翻目录——你翻开《Vue 权威指南》的目录，直接定位到「响应式原理」那一章。

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

enrichment_agent 工具链

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

Agent	能力
`build_bq_agent`	读取 BigQuery 表结构，自动生成 metrics + joins
`build_web_agent`	抓取官方文档，生成对应的 reference 文档

背后默认调用的是 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 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