当企业开始大规模部署 AI Agent，一个尴尬的现实浮出水面：模型越来越聪明，但它们需要的"知识"——指标口径、表结构、API 契约、运维手册——依旧散落在 Confluence、数据目录、Slack 讨论串和某个工程师的脑子里。每接入一个新工具、换一个新厂商，知识就得重新搬运、重新适配。2026 年 6 月 12 日，Google Cloud 发布的 Open Knowledge Format（OKF）v0.1 试图终结这种重复劳动：它把过去一年社区里自发流行的"LLM wiki"模式，正式提炼成一份厂商中立的开放规范。本文带你看清 OKF 到底是什么、长什么样，以及它在已经相当拥挤的 Agent 协议版图中处于什么位置。
OKF 想解决的核心问题：知识的"格式战争"
OKF 由 Google Cloud 数据分析技术负责人 Sam McVeety 和 BigQuery 技术负责人 Amir Hormati 在 Google Cloud Blog 上联合宣布。他们给出的判断很直接：当下构建 Agent 系统最持久的失败点，不是模型能力，而是这些 Agent 赖以工作的知识缺乏任何公认格式。
现实中，同一份"什么是月活用户"的定义，可能在 BI 工具里是一段 SQL 注释，在数据目录里是一个字段描述，在 Wiki 里是一篇文档，在 Agent 的 system prompt 里又是一段被硬编码的文字。它们彼此不互通，更无法在人、Agent、工具、组织之间自由流转。OKF 的主张是：把这些散落的知识源收敛到一种既能被人读写、又能被机器消费的共同格式里，让知识可以像数据一样被打包、被传递。
Google 特别强调，OKF v0.1 是"起点而非已完成的标准"，采用开放开发模式，期待生态里的生产者和消费者持续扩展它。这种"先发布、再共建"的姿态，本身也是为了降低其他厂商参与的心理门槛。
OKF 长什么样：Markdown + YAML 的朴素组合
OKF 没有发明新的复杂语法，而是刻意选择了最普及的载体——Markdown 文件配 YAML frontmatter。这意味着任何人用文本编辑器就能打开、阅读和修改，任何 LLM 也能毫无障碍地解析。
在数据建模上，OKF 把组织知识抽象成若干"概念"（concept）文档，常见类型包括：
- 数据集（dataset）：一张表或一个数据源是什么、从哪来、归谁管
- 指标（metric）：业务指标的精确定义与计算口径
- API：接口契约与调用方式
- 表（table）/ 字段：结构与语义说明
- 操作手册（runbook）：处理某类任务的标准流程
这些概念文档被组织成 bundle（知识包），可以整体打包、版本化、跨系统搬运。一个 bundle 既是给人看的文档集，也是给 Agent 喂的知识库——同一份内容，两种受众，零转换成本。这正是 OKF "可移植"承诺的关键：知识从此不再绑死在某个平台的私有 schema 上。
三个示例与两个参考实现：不只是规范文档
为了让 OKF 不停留在纸面，Google 同时在 GitHub 上放出了配套资产：
三个示例 bundle，覆盖了真实世界里常见的数据形态：
- GA4 电商数据集
- Stack Overflow 数据集
- Bitcoin 数据集
两个参考实现，演示 OKF 在生产与消费两端如何落地：
- Enrichment Agent（富集 Agent）：自动为 BigQuery 数据集中的每张表生成对应的 OKF 概念文档。这解决了"存量知识冷启动"的痛点——你不必手写成百上千份文档，让 Agent 替你生成初稿。
- HTML 可视化工具：把 OKF bundle 渲染成交互式的图表视图，让人能直观浏览知识之间的关系，而不是面对一堆裸 Markdown 文件。
一端自动生产知识、一端友好消费知识，Google 用这两个实现勾勒出了 OKF 的完整生命周期，也给其他想接入的团队提供了可抄的样板。
OKF 与 MCP、A2A 是什么关系？
熟悉 Agent 生态的读者会立刻发问：已经有了 Model Context Protocol（MCP）和 Agent2Agent（A2A），OKF 是不是又一个重复造的轮子？
理解这一点的关键是分清**"管道"与"内容"**：
- MCP 解决的是 Agent 如何连接到工具和数据源——它是传输层、是接口协议，关注"怎么把东西接进来"。
- A2A 解决的是 Agent 之间如何协作通信——关注"Agent 怎么互相说话"。
- OKF 解决的是流经这些管道的知识本身长什么样——它不关心传输，只关心"知识被表达成什么格式才能被普遍消费"。
换句话说，MCP 可以是搬运 OKF bundle 的通道，而 OKF 定义了被搬运之物的标准形态。三者更像互补关系而非竞争：协议负责连接，OKF 负责内容。当然，标准能否真正立起来，从来不取决于设计是否优雅，而取决于有多少厂商和工具愿意采纳——这也是 OKF 当下最大的悬念。
给开发者的现实建议
对正在搭建 Agent 或内部知识库的团队，OKF 至少提供了几个可立即借鉴的点：
- 即便不立刻采用 OKF，"Markdown + frontmatter 描述知识"这套模式也值得效仿——它天然对人和 LLM 都友好，迁移成本极低。
- 存量知识可半自动迁移：参考 enrichment agent 的思路，用 Agent 批量生成知识文档初稿，再由人审校，远比纯手写高效。
- 保持观望但不盲从：v0.1 还很早期，生态采纳度未知。可以先在小范围试点，把知识沉淀成可移植格式，避免被单一厂商的私有结构锁死。
总结
OKF 的野心不在于再造一个协议，而在于给 AI Agent 时代的"知识"确立一种通用语言。它用最朴素的 Markdown + YAML 降低门槛，用示例 bundle 和参考实现降低落地成本，并清晰地把自己定位在 MCP/A2A 之上的"内容层"。能否成为真正的事实标准，仍要看生态共建的进展。但它点中的痛点是真实的：在 Agent 越来越多的世界里，让知识摆脱信息孤岛、自由流转，已经从"锦上添花"变成了"刚需"。
评论