6月12日，Google Cloud发布了一份叫OKF的开放规范。

没有发布会，没有宣传视频，就是一篇博客文章加一个GitHub仓库。规范文件本身只有15KB，读完大概十分钟。但HN上讨论了76条，知乎和博客园上好几篇文章在解读，说明有人觉得这事值得关注。

我把规范文档和HN的讨论帖都过了一遍。说实话，第一感觉是：方向值得跟进，但文档本身确实还很粗糙。

OKF在做什么

先简单交代背景。OKF全称Open Knowledge Format，由Google Cloud Data Cloud团队的Sam McVeety和Amir Hormati主导开发。它本身是一份开放规范，不绑定任何具体产品——把知识表示成一组带YAML frontmatter的Markdown文件目录，人和AI Agent都能读写，不需要定制工具。

一个OKF知识包（Bundle）就是一个文件夹。每个Markdown文件描述一个概念（Concept），可以是一张数据表、一个API、一个业务指标、一份运维手册——什么都行。唯一必填的字段是type，其余的title、description、resource、tags、timestamp全部可选。

概念之间用标准Markdown链接互相引用，整个目录自动构成一张关系图。两个保留文件：index.md是整个Bundle的目录索引，Agent可以先读它了解全局结构；log.md记录变更历史。

规范还要求"容错消费"——消费者必须容忍未知的type值、缺失的可选字段和断裂的交叉链接，一个文件不合规不影响其他文件的可用性。这个设计有意做得很轻。

关于OKF"是什么"的部分，网上已经有很多文章讲过了，我不展开。

它解决了什么问题

Google在公告里说得很直接：随着模型能力持续提升，限制它们发挥的往往不是模型本身，而是缺乏相关上下文。模型能写代码、总结文档、分析数据，但它得先拿到正确的信息。

现实情况是，AI Agent需要的知识散落在各处——数据目录里的表结构、Wiki里的指标定义、GitHub里的API文档、共享盘里的运维手册。每次让Agent干一件事，它都得先拼凑这些上下文，每个Agent还要重复这个过程。

OKF的目标是把这些散落的碎片变成标准格式的知识包，任何生产者可以写，任何消费者可以读。一份知识写一次，不用为每个Agent重新组装。

这部分已经有文章讲得比较透了。我想聊的是另一件事：OKF对普通知识工作者意味着什么。

你的笔记工具跟得上吗

其实很多人忽略了一点：OKF虽然挂着Google Cloud的牌子，但它面向的受众比企业数据团队更广。如果你平时用Obsidian、Notion、Typora这类工具整理知识，OKF跟你有关系。

怎么理解？OKF知识包的结构——Markdown文件+YAML frontmatter+文件间链接——跟很多人的笔记组织方式已经很接近了。尤其是Obsidian用户，你的本地Markdown文件加双向链接，跟OKF的思路几乎一脉相承。

我做了个简单的对比：

维度	OKF规范要求	Obsidian	Notion	Typora/纯Markdown
文件格式	Markdown	本地.md文件	富文本+数据库，非纯Markdown	本地.md文件
元数据	YAML frontmatter	支持front matter	有属性但非YAML格式	支持
文件间链接	Markdown链接	双向链接，天然契合	页面引用，非标准Markdown链接	需手动维护
目录索引	index.md	有MOC实践但非标配	页面树自带索引	无内置索引
嵌套表格	不支持	原生不支持	核心功能，影响最大	原生不支持
版本管理	Git友好	纯文件，完美兼容	云端锁死，无法用Git	纯文件，完美兼容

从这个表能看出来，Obsidian用户离OKF最近，Notion用户离得最远。

换个角度看，这也意味着如果你正在选笔记工具，OKF兼容性可以作为一个参考维度。不是说现在就要按OKF规范来组织笔记——v0.1还早——但了解这个趋势，对未来的工具选型有帮助。

OKF v0.1有多粗糙

说完好的，说说现实。规范文档读下来，几个直观感受：

嵌套表格搞不定。 HN上有开发者指出，Markdown本身就不支持嵌套表格，OKF基于Markdown，自然继承了这个限制。如果你在Notion里用多层嵌套表格来表达结构，迁移到OKF格式会丢信息。这对Notion用户影响很大——Notion的数据库视图本身就是一种嵌套结构。

空间布局信息丢失。 HN用户sadschnitzel提到了一个很实际的问题：纯Markdown没法表达空间布局和颜色中隐含的语义，比如复杂电子表格或Miro白板里的信息。OKF选择了Markdown，也就选择了放弃这些维度。

15KB的规范，有人觉得太简陋。 HN用户port11的评论挺直白："Google发布了……带YAML frontmatter的Markdown，各位请鼓掌。15KB的规范就为了这个！"话是刻薄了点，但反映了部分开发者的疑虑——这规范是不是过于简单了？

也有人为此辩护。有人说简陋是好事，先跑起来再说，别一上来就搞个大而全的规范，最后谁也用不起来。两种意见都有道理。但v0.1就是v0.1，离"能直接用"有距离。

一个绕不开的老问题

读到OKF的时候，我脑子里冒出来的第一个问题是：这跟RDF和OWL有什么区别？

RDF（Resource Description Framework）和OWL（Web Ontology Language）是语义网时代的知识格式标准，W3C推的。理念很先进——用三元组描述知识关系，用本体定义知识结构。

结果呢？HN用户mrkiouak的评论一针见血：“RDF/OWL语义网格式每十年我就会重新看一次。总有一年会成功的！（暗示不会）”

知识格式标准化这件事，喊了二十多年，每隔几年就有人拿出来重新推一遍。OKF会不会走同样的路？

有一个差异可能重要：RDF/OWL是给机器看的，人基本没法直接读写，学习门槛很高；OKF基于Markdown+YAML，人能直接编辑，机器也能解析。一个格式如果人用不了，它永远只是论文里的概念。

但仅凭这一点就判断OKF能成，也过于乐观了。

Karpathy先跑了一年

还有一个背景值得说。OKF的直接灵感来自Andrej Karpathy提出的"LLM Wiki"模式——用Markdown维护一个Agent可读、可更新、可自维护的知识库。

过去一年，这个模式已经在社区里被无数团队各自实现了一遍。你可能在项目里见过AGENTS.md、CLAUDE.md，或者在Obsidian里见过index.md加log.md的文件夹结构。但每种实现都不兼容，各写各的。

OKF就是Google把这件事标准化了。

标准化有好处也有坏处。好处是有Google背书，可能吸引更多工具适配。Google同时给了三个参考实现：Enrichment Agent（自动为BigQuery数据集生成概念文档）、静态HTML可视化器（把Bundle变成交互图谱）、三个示例Bundle（GA4电商数据、Stack Overflow数据、Bitcoin数据集）。

坏处是一旦大公司主导标准，社区的声音可能被稀释。Karpathy的LLM Wiki是社区驱动的，迭代快但松散。OKF是公司主导的，规范但可能慢。而且Google有"砍产品"的历史——Reader、Plus、Wave，哪个不是轰轰烈烈开始，悄无声息结束？

OKF能不能成，标准本身只决定了一半，另一半看Google愿意投入多久。

现在该不该动

我的判断：方向值得跟进，但现在不急着迁移自己的笔记库。

如果你正好在选笔记工具，可以把OKF兼容性作为一个参考维度。如果你已经是Obsidian用户，你的笔记结构跟OKF最接近，未来如果要适配，成本最低。如果你是Notion重度用户，短期内不用担心，但可以开始关注——Notion的富文本和数据库结构跟纯Markdown之间有鸿沟，如果OKF真的推进下去，Notion要么自己适配，要么用户得考虑迁移。

对于已经在做AI Agent开发的团队，OKF的试用成本很低。一个Bundle就是一堆Markdown文件，不需要装任何东西，不需要注册任何服务。最坏的情况是你有了一份结构化的内容审计。

写在最后

OKF v0.1发布两周了。讨论热度不算高，但也没冷下来。

知识格式标准化这件事，喊了二十多年。这次Google来了，跟RDF时代不同的是，OKF选择了Markdown——一个普通人每天在用的格式。这个选择让OKF离知识工作者近了一步。

至于它能不能落地，现在谁也说不准。规范文档在GitHub上（仓库地址：GoogleCloudPlatform/knowledge-catalog），15KB，十分钟就能读完。建议你自己看一下，形成自己的判断。
🔑

数据来源：OKF规范文档（GitHub公开）、HN讨论帖（76条评论）、博客园/StartupHub解读文章，截至2026年6月25日。

OKF规范文档在GitHub上（仓库地址：GoogleCloudPlatform/knowledge-catalog），15KB，十分钟读完。我建议自己过一遍原文，比看任何二手解读都来得直接——v0.1够不够用，只有读了才知道。