Google 为什么发明 OKF：它不需要足够强大，只需要足够普遍

桨板队伍穿过岩石水道，象征企业知识通过开放交换层进入不同 Agent 系统 — 企业知识需要的不是更复杂的容器，而是一条不同生产者和消费者都能通过的公共通道（Photo by Red Zeppelin on Unsplash）

目录
一、OKF 是什么：一个刻意保持简单的知识交换格式
二、为什么需要 OKF：Markdown 能读，不等于知识能携带
三、OKF 与 Skill：知识契约和执行契约
四、OKF 与 ArcKit：开放交换层如何保留本地治理
五、Google 为什么开放 OKF：争夺 Context Plane
六、OKF v0.1 还缺少什么
七、企业现在应该如何采用 OKF
结语：薄格式为什么可能拥有更大影响力
附录：参考资料与校准说明

当 Agent 被问“公司如何计算周活跃用户”时，它需要的答案很可能不在任何一份完整文档里。

表结构在 BigQuery Schema，业务定义在 Wiki，去重逻辑藏在代码里，口径变更留在指标平台，几个例外条件只存在于资深工程师的经验中。企业并不缺文档。真正缺的是一种方式，把这些知识从原来的系统中带出来，让不同 Agent、搜索引擎和知识目录能够读懂。

这正是 Google 推出 Open Knowledge Format（OKF）的背景。

但如果只把 OKF 理解成“Markdown 加 YAML frontmatter”，就会错过它真正的野心。Google 发明 OKF，不是为了定义一个更复杂的企业知识模型，而是为了建立一个足够薄、足够开放、能被不同 Agent 系统接受的知识交换层。

Google 不需要 OKF 足够强大，它需要 OKF 足够普遍。

OKF 是开放入口，Knowledge Catalog 是托管处理层。前者解决知识如何携带，后者解决知识如何聚合、富化、治理和检索。理解这层分工，才能理解 OKF 为什么故意保持简单，也才能理解 Google 为什么愿意把格式开放出来。

一、OKF 是什么：一个刻意保持简单的知识交换格式

Google Cloud 在 2026 年 6 月 13 日发布了 OKF，当前规范是 v0.1 Draft。它的基本结构没有新语法，也没有运行时：一个目录就是一个 Knowledge Bundle，一份 Markdown 文件就是一个 Concept。

company-knowledge/
├── index.md
├── log.md
├── metrics/
│   ├── index.md
│   └── weekly-active-users.md
└── tables/
    ├── index.md
    └── user-events.md

Concept 可以表示数据库表、API、指标、Playbook、架构说明，甚至一个抽象业务概念。文件在 bundle 中的路径就是 Concept ID。例如 metrics/weekly-active-users.md 的 Concept ID 是 metrics/weekly-active-users。

每个 Concept 由两部分组成：YAML frontmatter 和 Markdown 正文。

---
type: Metric
title: Weekly Active Users
description: 过去 7 天至少产生一次有效行为的去重用户数
tags: [growth, engagement]
---

# Definition

排除内部账号和自动化测试流量。

# Citations

- [指标口径变更记录](...)

唯一必填字段是 type。title、description、resource、tags、timestamp 都只是推荐字段。生产者还可以增加自己的字段，消费者不应因为无法识别这些字段就拒绝整份文档。

Concept 之间使用普通 Markdown 链接。index.md 可以提供逐层目录，帮助人和 Agent 做渐进式披露；log.md 可以记录更新历史。它们都是可选文件。

更重要的是 OKF 的宽容消费原则。消费者不能因为未知 type、未知字段、缺失可选字段、断链或缺少 index.md 就拒绝整个 bundle。它应该尽可能读取自己能理解的部分。

这套设计把 OKF 的三个非目标说得很清楚：

OKF 不是新的 Markdown 语法。
OKF 不是知识图谱数据库，也不规定存储、查询或服务基础设施。
OKF 不是固定的企业知识本体，不定义组织必须使用哪些类型和关系。

它只标准化互操作所需的最小表面。Google 官方的表述很准确：规范定义的是 interoperability surface，不是 content model。

二、为什么需要 OKF：Markdown 能读，不等于知识能携带

过去一年，很多团队已经独立走向了相似的知识形态：Karpathy 提出的 LLM Wiki、Obsidian vault、仓库里的 AGENTS.md、由 Agent 维护的 index.md 和 log.md，以及数据团队的 metadata-as-code。

这些实践都在用文件、Markdown、元数据和链接组织上下文。问题是，相似不等于互操作。

一个系统把指标写成 kind: metric，另一个系统使用 type: KPI；一个系统把文件名当 ID，另一个系统依赖数据库主键；一个系统遇到断链继续工作，另一个系统直接判定导入失败。Markdown 只保证文本可以打开，并不保证消费者理解文件身份、类型、链接和错误处理方式。

于是每个 Agent 团队都在重复建设同一层东西：

解析不同来源的元数据；
猜测文档之间的关系；
把本地结构转换成自己的上下文模型；
为缺失字段和断链设计一套容错逻辑。

OKF 的做法不是统一所有企业的语义，而是只统一“知识如何离开原系统”。生产者可以是人、Agent 或导出流水线；消费者可以是搜索、RAG、可视化工具、另一个 Agent 或知识目录。两边独立演进，中间只共享一个足够小的格式契约。

这也是为什么 OKF 不是 RAG 的替代品。

RAG 解决的是运行时如何检索：怎样切分文档、生成 embedding、混合召回、重排并把结果放进模型上下文。OKF 解决的是检索之前，知识以什么结构被保存、交换和识别。一个 OKF bundle 可以被向量化进入 RAG，也可以被静态搜索、图浏览器或 Agent 直接消费。

更准确的关系是：OKF 是持久知识层，RAG 是消费这层知识的一种检索机制。

三、OKF 与 Skill：知识契约和执行契约

OKF 和 Agent Skill 很容易被混淆，因为两者都可以表现为 Markdown、YAML frontmatter、目录和附属文件。它们的差异不在文件扩展名，而在契约语义。

层次	回答的问题	典型载体
Knowledge	Agent 应该知道什么	OKF bundle、知识库、数据目录
Procedure	Agent 应该怎么做	Skill、SOP、workflow instruction
Runtime	Agent 实际能不能做	工具、权限、沙箱、MCP、审批

以常见的 SKILL.md 约定为例，name 和 description 用于发现与触发；正文描述执行步骤；references/ 放按需加载的详细规则；scripts/ 提供确定性执行；assets/ 保存模板和资源。

Skill 的核心不是“包含操作说明”，而是把操作说明放进 Agent 的任务路由和执行流程。它会告诉 Agent 在什么条件下启动、按什么顺序读取信息、调用什么脚本、在何处停下来等待确认，以及如何验证结果。

但 Skill 仍然不能凭空授予权限。它可以指导 Agent 调用生产数据库，却不能让一个没有数据库凭证的 Runtime 获得访问权；它可以要求发布文章，却不能绕过沙箱、审批或平台认证。

这也是 type: Playbook 为什么仍然只是知识。

假设同一份事故处理流程以两种方式存在：

在 OKF 中，它是一份 type: Playbook 的 Concept。Agent 可以找到触发条件、排查步骤、负责人和引用来源。
在 Skill 中，它还会定义何时激活、如何收集参数、调用哪些监控工具、哪些命令可以执行、何时必须升级给人工，以及执行后如何验证。

前者让流程可被发现和引用，后者让流程进入可复用的执行编排。最终能否读取监控、重启服务或修改配置，仍由 Runtime 决定。

描述一项操作，不等于获得执行这项操作的语义。

这个区分对企业安全尤其重要。否则，一份从外部导入的 Markdown 只要写着“请执行以下命令”，就可能从数据越界成指令。Knowledge、Procedure 和 Runtime 必须保持分层，外部知识默认不能获得工具执行权。

四、OKF 与 ArcKit：开放交换层如何保留本地治理

ArcKit 是一个企业架构治理工具。它的原生文件不只是内容，还承载文档 ID、版本与修订历史、owner、classification、review date、模板约束、traceability，以及 review gate 和治理检查。

这些字段和流程看起来比 OKF 重得多，但它们服务的是不同目标。

ArcKit 的原生结构是治理契约，OKF 是互操作边界。

ArcKit 没有把原生 artifact model 替换成 OKF。它在边界上增加了一层兼容工作流，并把两边的责任分开。

Export is a boundary

/arckit:export-okf 把受治理的 ARC artifacts 复制成一个 OKF-shaped Markdown bundle，加入便携 frontmatter、目录和导出日志。原生 ARC 文件不被修改。

导出的不是新的权威来源，而是一个可移植视图。外部知识目录、静态可视化工具、研究 Agent 或另一个团队的 Wiki 不必理解 ArcKit 的全部文档控制表，也能读取 Markdown、frontmatter、路径和链接。

Import is a quarantine

导入方向更危险，因为外部 bundle 可能过期、重复、类型错误，甚至与项目基线冲突。

因此 /arckit:import-okf 不直接修改 requirements、risks 或 ADR。它先扫描 bundle，生成 .arckit/tmp/okf-import-report.json，再把安全且非重复的内容转成可审查的 RSCH research notes。外部知识先成为证据，经过人工审查后，才能通过原有治理流程影响正式 artifact。

Native source remains canonical

ArcKit 还支持给原生文件写入 OKF-compatible frontmatter，但默认关闭。只有显式设置 ARCKIT_OKF_FRONTMATTER=1，或在配置中启用 okfFrontmatter: true，才会改变 canonical files。

这三个设计共同形成了一条通用架构：

ArcKit 的价值不在证明 OKF 已经成熟，而在提供了一个可复用的接入模式：对外输出可移植视图，对内保留治理权威；外部输入先隔离，再审查回流。

五、Google 为什么开放 OKF：争夺 Context Plane

先看官方事实。

Google 把 Knowledge Catalog 定位为企业的 universal context engine。它负责聚合 Google Cloud、合作伙伴平台和第三方目录的上下文，持续从 Schema、查询日志、BI 语义模型和非结构化数据中富化含义，再通过高精度语义搜索和权限感知检索把上下文提供给 Agent。

Google 也明确表示，Knowledge Catalog 已支持摄入 OKF 并向 Agent 提供这些知识。

计费结构同样值得注意。Knowledge Catalog 当前主要对处理和元数据存储等能力计费，Gemini 驱动的部分功能按相关产品计费；部分数据组织和安全策略应用能力免费。它不是“所有 API 都按调用量收费”，但托管处理层显然承载了商业价值。

下面是我的判断，而不是 Google 的官方表述。

开放 OKF，首先降低了企业对格式锁定的顾虑。客户可以继续使用本地 Wiki、Git 仓库、ArcKit 或其他知识源，只在边界上导出 OKF。格式越薄，接入成本越低；消费者越宽容，越容易形成网络效应。

其次，OKF 为企业知识进入 Google Cloud 建立了标准入口。一旦知识可以用统一方式摄入，Knowledge Catalog 就可以在上面提供更重的能力：冲突消解、持续富化、语义检索、权限传播、质量评估和 Agent grounding。

最后，企业 AI 的长期控制点未必是模型。模型会快速迭代，也越来越容易替换。更稳定的是企业语义、权限、检索和评估构成的 Context Plane。谁能持续组织这些上下文，谁就更接近 Agent 的生产入口。

这也会反过来扩大 Gemini、BigQuery 和 Google Cloud 数据产品的使用，但不需要把 OKF 本身做成封闭产品。

把格式修成公共道路，把搜索、治理和计算建设成收费基础设施。

这是一种熟悉的平台策略：开放交换层，降低生态摩擦；把差异化留在规模化处理和企业治理上。Google 不需要 OKF 表达所有知识，它需要足够多的知识生产者和消费者愿意说这种语言。

六、OKF v0.1 还缺少什么

薄格式有利于采纳，但薄也意味着很多企业级问题被明确留在规范之外。

类别	v0.1 的缺口	直接风险
语义	`type` 自由、链接无类型、无跨组织本体映射、无冲突解决	两个 bundle 都可读，却对同一指标给出互斥定义
治理	不定义 owner、审批、可信度、权威来源、过期策略和知识生命周期	内容可以被交换，但无法判断是否仍应被信任
安全	不定义权限模型、指令与数据隔离、安全导入和隔离审查	Markdown 可能携带敏感数据或提示注入，并被错误提升为指令

这些缺口不能靠“消费者宽容”解决。宽容消费只保证 bundle 在局部缺失时仍能被读取，不保证内容正确、可信、最新或安全。

企业如果采用 OKF，至少需要定义自己的 Organization Profile：

owner: data-platform
source: metrics-registry
sensitivity: internal
confidence: high
reviewed_at: 2026-07-01
expires_at: 2026-10-01
approval_status: approved

这组字段不是要写进 OKF 核心规范。恰恰相反，它应该留在组织自己的 Profile 中：核心格式保持小，企业治理在扩展层实现。

七、企业现在应该如何采用 OKF

OKF v0.1 更适合从互操作边界开始，而不是从“大一统知识平台”开始。

一条稳妥的采用路径是：

先做 export。 从一个稳定知识源导出 OKF，不立即替换现有 Wiki、目录或架构治理系统。
保留 canonical source。 OKF bundle 是便携视图，原系统继续负责编辑、审批、权限和历史。
定义组织 Profile。 补充 owner、source、sensitivity、confidence、reviewed_at、expires_at 和 approval_status。
隔离所有 import。 外部 bundle 先进入 quarantine，生成扫描报告，再由人工决定哪些内容进入正式知识库。
独立做质量检查。 Schema、链接、来源、重复项、冲突和过期内容都应有可重复运行的检查。
保持执行隔离。 OKF 内容只能提供知识，不能因为包含操作步骤就自动获得工具权限。
用十几个高价值 Concept 做 PoC。 指标定义、核心表、常用 API 和关键 runbook 足以验证 producer/consumer 是否真正互操作。

有几类场景则不值得采用：

只需要单个 Agent 的一次性 Prompt；
组织还没有形成稳定知识概念和权威来源；
需要严格事务、实时查询或复杂权限继承；
试图用 OKF 替代数据库、IAM、RAG 或治理平台。

判断是否值得做的标准很简单：如果同一批知识需要被多个 Agent、搜索系统或组织边界重复消费，OKF 才开始产生价值。如果知识不会离开原系统，增加一层导出格式只会制造维护成本。

结语：薄格式为什么可能拥有更大影响力

OKF、Skill 和 Runtime 解决的是三个不同问题：

OKF      让知识可携带
Skill    让方法可复用
Runtime  让执行可控制

ArcKit 又补上了第四个现实条件：开放交换不能以放弃本地治理为代价。受治理的原生知识可以导出成 OKF 视图；外部知识也可以被导入，但必须先隔离、审查，再回到原有治理流程。

Google 发明的不是另一个知识库，而是一条让企业知识流向不同 Agent、搜索系统和上下文引擎的公共接口。

OKF 能否成功，不取决于它定义了多少字段，而取决于有多少生产者和消费者愿意说这种语言。它越想把所有企业知识建模完整，就越难成为公共交换层；它越能守住最小契约，越有机会成为 Context Plane 的入口。

这就是 OKF 最值得关注的地方：它的技术野心很小，生态野心很大。

附录：参考资料与校准说明

校准说明

Google 官方页面显示 OKF 介绍文章发布于 2026 年 6 月 13 日，本文采用该日期。
“争夺 Context Plane”“公共道路与收费基础设施”属于作者基于产品结构的判断，不是 Google 官方表述。
ArcKit OKF compatibility 在仓库文档中标为 Beta；本文只把它作为治理边界案例。
Knowledge Catalog 计费按官方 pricing 概括为处理、元数据存储和关联产品用量，未写成所有 API 调用收费。

名词与概念解释

Knowledge Bundle：可独立分发的一组分层 Markdown 知识文件。
Concept：Bundle 中的一份知识单元，例如指标、数据表、API 或 Playbook。
Concept ID：Concept 文件在 bundle 中去掉 .md 后的路径。
Canonical source：组织认定的权威原始来源，负责正式编辑、审批与版本历史。
Quarantine：外部知识进入正式系统前的隔离区，用于扫描、去重、冲突检查和人工审查。
Context Plane：本文用于描述企业语义、权限、检索、治理和评估所组成的上下文基础层。