架构师之道
● AI · LLM · Agents | Enterprise Architecture | Digital Transformation
一、引言：OKF是什么？
2026年6月12日，Google Cloud正式发布了开放知识格式（Open Knowledge Format，简称OKF）0.1版。这是一套开放的、厂商中立的规范，用于表示组织内部的元数据、上下文和经过整理的知识，让人类和AI智能体都能直接读取。
OKF的核心主张极为简洁： 用普通的Markdown文件加YAML元数据头来表示知识。Google明确将其定位为“格式”而非“平台”——没有账号、没有SDK、没有厂商锁定，任何人用文本编辑器就能读写。
二、要解决什么问题？
2.1 上下文组装问题
在大多数组织中，AI模型需要的知识散落在互不兼容的系统中：
元数据目录（各有各的专有API） 内部Wiki、Notion、Confluence 代码注释和文档字符串 共享网盘中的PDF和Office文档 资深员工脑子里的“部落知识”
当一个AI智能体需要回答“如何计算周活跃用户数”时，它必须从这些互不兼容的来源中拼凑答案。每个团队都在从头解决同一个问题，知识被锁死在创建它的那个界面里。
2.2 现有方案的碎片化
过去一年里，开发者社区涌现出各种“LLM Wiki”模式——AGENTS.md、CLAUDE.md、Obsidian知识库——但每种都是定制化的，格式互不兼容，无法跨系统复用。OKF正是要填补这个空白：建立一套共同的约定，让不同生产者写的知识能被不同智能体消费，无需翻译层。
三、OKF核心规范解析
3.1 知识包（Knowledge Bundle）
一个OKF知识包就是一个目录树：
my_bundle/
├── index.md # 目录索引（可选）
├── log.md # 变更日志（可选）
├── datasets/
│ ├── index.md
│ └── sales.md
└── tables/
├── index.md
├── orders.md
└── customers.md
每个非保留文件名的.md文件就是一个概念文档。index.md用于渐进式展示，让智能体先看目录再按需深入；log.md记录变更历史。
3.2 概念文档结构
每个概念（一张表、一个指标、一个API、一本运维手册）就是一个Markdown文件，包含两部分：
YAML元数据头（Frontmatter）：
---
type: BigQuery Table # 必填
title: Orders # 推荐
description: 每行一个已完成客户订单 # 推荐
resource: https://... # 推荐（底层资产URI）
tags: [sales, revenue] # 推荐
timestamp: 2026-05-28T14:30:00Z # 推荐
---
唯一必填字段是type，用于标识概念类别（如Metric、Table、API、Runbook）。其余字段均为推荐项，消费者必须容忍缺失。
Markdown正文：
正文是标准Markdown，用于详细描述概念。可以用标题组织结构、表格描述Schema、代码块展示SQL示例。概念之间用普通Markdown链接相互关联，从目录中自然浮现出知识图谱。
3.3 设计原则
Google明确阐述了OKF的三个设计原则：
- 极简主义：
只强制 type一个字段，其余全部由生产者自行决定。规范定义的是互操作界面，而非内容模型。 - 生产者/消费者独立：
生产者不需要知道消费者是谁，消费者不需要知道生产者是谁。格式是契约，两端的工具可独立替换。 - 格式而非平台：
不绑定任何云、数据库、模型或智能体框架。不需要专有账号，不需要SDK。
四、与LLM-Wiki模式的渊源
OKF并非凭空发明。它明确继承了Andrej Karpathy（OpenAI联合创始人）提出的“LLM-Wiki”模式。
2026年初，Karpathy在GitHub上分享了一个思路：与其让智能体反复查询相同文档，不如给它们一个共享的Markdown知识库，让智能体自己维护和更新。他观察到： 大语言模型不会厌烦，不会忘记更新交叉引用，一次处理就能覆盖15个文件——那些让人类放弃个人Wiki的维护性工作，恰恰是LLM擅长的。
这个思路在开发者社区迅速传播，但每个人都在自己的角落里重新发明轮子。OKF的价值就在于： 给这个模式加了一层标准化约定，让不同的“LLM Wiki”能够互操作。
五、OKF vs 其他标准
OKF与几个容易混淆的标准是互补而非竞争关系：
特别澄清：OKF ≠ SEO排名信号
OKF不会提升Google搜索排名。它不是公开网页格式，不是被全网爬取的发现标准，也不替代schema.org结构化数据。它是面向组织内部的：让你的智能体基于共享的权威知识运作，而不是每次都从零推导事实。
六、Google提供什么配套工具？
Google不止发布了规范，还提供了实际可用的参考实现：
- 知识增强智能体（Enrichment Agent）：
遍历BigQuery数据集，为每张表自动生成OKF文档草稿，再通过LLM补充Schema、关联路径和引用来源。 - 静态HTML可视化工具：
把任何OKF知识包转成交互式知识图谱，一个独立HTML文件，无需后端。 - 三个示例知识包：
GA4电商数据、Stack Overflow、Bitcoin公开数据集。
Google Cloud的Knowledge Catalog（原Dataplex）也已更新，支持直接接入OKF并服务于智能体。
七、谁应该采用OKF？
适用场景
团队正在运行内部Copilot或RAG系统，智能体频繁搞错指标定义或数据来源 数据和分析团队希望为每个指标建立唯一权威定义 平台和API团队希望智能体直接发现和使用他们的服务
怎么开始？
- 从小处着手：
选5-10个智能体最容易弄错的概念（核心指标、主要数据集、关键API） - 每个概念写一个文件：
填上 type、title、description，用Markdown写出精确定义 - 放进Git做版本管理：
让知识的每一次变更都可追溯、可审核 - 让智能体指向它：
把知识包加载到检索层或作为文件上下文提供给智能体 - 持续迭代：
每次智能体弄错一个事实，就新增或修正对应的概念文件
当前阶段的建议
如果你还没开始构建基于自有数据的智能体，OKF的优先级可以放低。当前让内容被AI发现和使用的更高杠杆动作是：做好schema.org标记、写好llms.txt、提供真正的API或MCP端点。
但如果你正在运行AI智能体处理自有知识，OKF是值得认真对待的。投入很小（一份规范、一个免费工具、一次Git提交），但解决了每个智能体项目都会遇到的核心问题。
八、总结
OKF的价值不在于发明了新技术——Markdown、YAML、目录树都是存在了几十年的原语。它的贡献在于： 在AI智能体时代，为知识表示找到了一个务实的平衡点——足够结构化以支持自动化处理，足够自由以容纳丰富的自然语言描述，足够简单以实现零门槛的生产与消费。
Google将它定位为“起点而非最终标准”。随着更多生产者和消费者加入生态，格式会继续演进。但对于已经在构建AI智能体的团队来说，今天就可以从中获益——用一个下午的时间，把那些让智能体最头疼的知识整理成一份Markdown知识包，然后看着它一步步变得更可靠、更准确。
