Google Cloud 推出开放知识格式（OKF），以 Markdown 文件将组织知识结构化，供 AI 智能体直接读取，解决知识碎片化与上下文缺失问题。
大语言模型（LLM）在每一次版本迭代中都在增强能力。然而，AI 智能体仍会给出错误答案，原因不在推理能力，而在上下文缺失。智能体会对上下文做大量假设：它不知道你的指标定义、数据库表之间的连接路径，也不知道文档中哪些内容已经弃用。当 AI 智能体作为智能应用的一部分处理信息时，这类上下文缺失造成的错误会不断累积，最终影响整个智能体的表现。
AI 智能体无法访问全部内部知识，而这些知识正是技术写作者产出的内容。智能体所需的上下文分散在知识库的多篇文章中。许多 AI 智能体各自独立地搭建自己的框架，以确保整套产品运转良好。Andrej Karpathy 提出的 LLM Wiki 与 Google 的开放知识格式（OKF）是两个独立的方向，却指向同一个目标：为 AI 智能体提供有效的内容供给。Google 的 OKF 是一种厂商中立、技术无关的方式，用于暴露完整的知识库，承载 AI 智能体所需的全部信息。
什么是开放知识格式（OKF）？
开放知识格式（OKF）是 Google Cloud 发布的一项开放规范，用于把组织知识存储为一个由 Markdown 文件构成的普通目录，任何 AI 智能体都能直接读取。Google 于 2026 年 6 月 12 日发布了 0.1 版本。
在 OKF 知识包中，每个文件代表一个概念，例如一项指标定义、一张数据库表或一份操作手册（runbook）。文件路径即概念标识，概念之间通过普通的 Markdown 链接相互连接，从而把整个目录变成一张相互关联的知识图谱。
每个文件都以一小段 YAML front matter 开头，在智能体读取正文之前先告知它这个文件是什么。该规范仅要求一个字段：
type。OKF 在设计上保持厂商中立，不依赖 SDK 或专有工具，并把 Andrej Karpathy 在 2026 年 4 月描述的“LLM Wiki”模式固化下来。分散的知识如何拖垮 AI 智能体
在许多组织中，模型所需的知识散落在四类互不兼容的位置：数据目录、Wiki、代码注释与隐性知识。AI 智能体需要从这些地方汇集信息。举例来说，假设智能体要根据事件流计算周活跃用户：
- 活跃用户的定义存在于指标文档中；
- 事件表的 schema 存在于数据目录中；
- 用户表的连接路径存在于代码库中；
- 用户表中的某些字段可能已弃用，而这一点只在 Slack 频道里被提及。
此时，AI 智能体必须找到以上全部信息，才能获得正确的上下文。每家厂商都提供各自的 SDK、API 与知识图谱 schema。关于数据模型的信息跨越多个平台，例如帮助中心文章、代码注释、Slack 讨论串，以及你个人头脑中的模型。同一份知识还会以不同形态出现，例如 YAML 文件、Markdown 文件与 Slack 消息。这是信息在结构上的碎片化。而同一事实若写法略有差异，AI 智能体就更难推断出这些信息指向的是同一件事，这是语义层面的问题。即便再搭建一层信息整合层，也无法根治该问题。一个共享格式则能帮助所有 AI 智能体无缝访问全部信息，而无需分别调用多个知识系统。
从 LLM Wiki 模式到开放知识格式
Andrej Karpathy 发布了 LLM Wiki：由知识库承载内容，并由 LLM 而非技术写作者或信息开发者来维护它。这与 RAG 是截然不同的思路。RAG 是上传内容、切分成块，再检索用于生成回答；LLM Wiki 则构建并维护一个持久化的 Wiki。LLM Wiki 是一组结构化、相互链接的 Markdown 文件；LLM 只读取新来源一次，抽取其中重要的内容，并把它并入已有页面。LLM 会自动完成维护工作，更新交叉引用、保持摘要最新，模糊之处也会被标记出来。由此，它消除了 Wiki 的维护成本。
LLM Wiki 同时也会制造知识孤岛：你的 Wiki、我的 Wiki，以及你厂商导出的 Wiki 看起来都很相似，却彼此无法读取。这正是开放知识格式要填补的缺口。OKF 把 LLM Wiki 固化为一种可移植、厂商中立的格式。OKF 0.1 把知识表示为一个由 Markdown 文件构成的目录，配以 YAML front matter 和一组约定。读取 OKF 不需要重型工具，它可以以 tarball、Git 仓库或挂载文件系统的形式托管。
OKF 的简洁体现在三个特性：
- 可移植性：所有文件都是 Markdown；
- 可发现性：可查询字段是一组简短而固定的类型，如
type、description、resource、tags、timestamp； - 信息标准化：通过概念文件实现。
index.md 会列出所在目录的内容，使 AI 智能体在读取单个页面之前，先对 OKF 知识包形成整体了解。log.md 则以带日期的条目记录变更，形似 changelog。由此，OKF 让知识既便于携带，也对 AI 智能体友好。OKF 知识包的结构
要理解 OKF 的构成，可以看一个销售领域的示例。它是一组按描述归类的 Markdown 文件。
图：销售域的OKF捆绑示例
一个示例订单（order）概念文件大致如下：
该文件展示了 orders 表如何与 customers 表链接，以及如何对二者进行连接。这是对 OKF 结构的高层概览。此后，写出描述、链接到正确的相邻概念等工作，就落到了技术写作者肩上。这有助于 AI 智能体理解一个知识包是如何组织、如何维护的。OKF 的这一原则，与
Claude.md、skills.md 文件遵循的是同一套思路。检验它的最佳方式，就是把 AI 智能体指向你的 OKF 知识包，然后开始提问。用 Baklib 搭建的知识库已经沿用类似的形态——Markdown 文章、分类与交叉链接——因此可以自然地映射为 OKF 概念文件。OKF 0.1：起点，而非终点
LLM Wiki 提供了一种让 LLM 维护 Wiki 的模式。如果这一模式广泛传播，可能会形成知识孤岛。Google 的 OKF 试图标准化 AI 智能体发现与使用知识库的方式，同时不丢失任何上下文。由于 Google 已将这一标准开源，你可以为自己的知识系统编写生产者（producer），并编写一个基于该知识包进行推理的消费者（consumer），而不必受制于专有工具。鉴于它只是 0.1 版本，后续版本仍有很大的改进空间。
用 Baklib 承接你的 OKF 知识
提交反馈
博客
