Open Knowledge Format 深度笔记

一、核心结论：OKF 不是新平台，而是“上下文的 USB-C”

这篇文章的主张很克制，也很重要：Agent 的能力瓶颈往往不是模型本身，而是缺少正确、可携带、可复用的上下文。OKF 想解决的就是“知识怎么从一个系统流到另一个系统，并被不同 Agent 直接消费”。

一句话：OKF 把企业知识表示成“一个目录里的 Markdown 文件 + YAML frontmatter + 少量约定”，让不同生产者写出的知识包可以被不同消费者和 Agent 读取，而不必为每个工具单独做集成。

它解决什么

企业知识碎片化：表 schema、指标定义、join path、runbook、API 变更都散在不同系统里，Agent 每次都要重新拼上下文。

它不是什么

不是数据库、不是知识图谱服务、不是新运行时、不是必须绑定 Google Cloud 的 SDK。

它像什么

像 Agent 时代的“metadata as code”：用文件、Markdown、frontmatter 和链接，把知识变成可版本化资产。

二、为什么需要 OKF：Agent 的上下文拼装太碎了

文章指出，Foundation Model 能写代码、总结文档、分析数据，但要产出准确行动，必须拿到组织内部的语义上下文：表的 schema、业务指标的含义、系统之间如何 join、事故 runbook、旧 API 的废弃说明等。

问题是这些知识通常分散在四类地方：元数据目录、Wiki/共享盘/第三方系统、代码注释或 Notebook、少数资深工程师脑子里。Agent 想回答“如何从事件流计算 weekly active users？”时，需要跨这些表面拼答案，而每个 vendor 又有自己的 catalog、SDK、schema。

所以 OKF 关注的不是“再建一个知识服务”，而是“把知识交换格式先统一”。只要格式足够简单、开放、可读，生产者和消费者就可以独立演化。

三、OKF 到底长什么样

OKF v0.1 的基本形态非常朴素：一个 bundle 是目录；每个 concept 是一个 Markdown 文件；文件路径就是 concept 的身份；YAML frontmatter 保存少量可查询字段；正文保存人类可读、Agent 可读的知识。

目录示例

sales/
├── index.md
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
└── metrics/
    ├── index.md
    └── weekly_active_users.md

Concept 文件示例

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme...
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

# Schema
| Column | Type | Description |
| order_id | STRING | Globally unique order identifier. |
| customer_id | STRING | FK to [customers](/tables/customers.md). |

# Joins
Joined with [customers](/tables/customers.md) on `customer_id`.

文章特别强调：OKF 只要求每个 concept 有一个 type 字段。其他字段、类型体系、正文结构都留给 producer 决定。这个选择很关键：它定义的是互操作表面，而不是强迫所有组织采用同一套内容模型。

组成	作用	为什么适合 Agent
Markdown body	承载 schema、解释、runbook、指标定义、join 说明	人能读，模型也容易解析和引用。
YAML frontmatter	保存 type、title、description、resource、tags、timestamp 等结构化字段	方便检索、过滤、索引和权限策略。
普通文件目录	承载 bundle，路径作为概念身份	能放 Git、tarball、对象存储、文件系统，不依赖运行时。
Markdown links	连接 tables、datasets、metrics、APIs、runbooks	把目录变成轻量知识图，Agent 可沿链接逐步探索。
index.md / log.md	可选的层级入口和历史记录	方便 progressive disclosure 和时间线推理。

四、三条设计原则：少管内容，多管互操作

1. Minimally opinionated

OKF 只强制 type，不规定你必须有哪些类型、字段或正文 section。这样不同组织可以保留自己的语义模型。

2. Producer / consumer independence

人手写的 bundle、metadata pipeline 生成的 bundle、LLM 合成的 bundle，都可以被 agent、viewer、search index 消费。

3. Format, not platform

OKF 不绑定云、数据库、模型厂商或 Agent 框架；价值来自有多少生产者和消费者愿意说同一种格式。

我的理解：OKF 把“知识目录”从产品功能降维成文件协议。只要能读写 Markdown，就能参与生态；这降低了企业知识进入 Agent 工作流的门槛。

五、Google 同时放出了什么

文章说 OKF v0.1 是起点，不是定稿标准。为了让格式变得可试用，Google 发布了 producer 和 consumer 两端的参考实现。

组件	文章中的说明	价值
Enrichment agent	遍历 BigQuery dataset，为每个 table/view 起草 OKF concept，再用第二个 LLM pass 搜索权威文档，补 citations、schemas、join paths。	展示如何把现有数据资产自动变成 Agent 可用知识。
Static HTML visualizer	把任意 OKF bundle 转成交互图视图，单文件、无后端、无需安装，数据不离开页面。	让人类也能浏览和审查 OKF bundle。
Sample bundles	GA4 e-commerce、Stack Overflow、Bitcoin public datasets。	作为符合 OKF 的活样例，降低学习成本。
Knowledge Catalog integration	Google Cloud Knowledge Catalog 已能 ingest OKF 并服务给 agents。	说明 OKF 不只是文档概念，已经进入 Google 数据云产品路径。

六、工程落地：怎么在团队里试 OKF

如果你在做企业 RAG、数据 Agent、指标问答、BI Agent 或内部知识库，OKF 可以先作为一个轻量规范试起来，不必等完整平台。

最小试点路线

选一个小领域：例如销售数据集、核心指标库、一个服务的 runbook。
为每张表、每个指标、每个 runbook 写一个 Markdown concept。
加上 type/title/description/resource/tags/timestamp。
用普通 Markdown link 表达 join、依赖、上游/下游关系。
放进 Git，走 PR review，把知识更新当代码管理。

Agent 使用方式

索引 OKF bundle，做全文检索和 metadata 过滤。
回答前先检索相关 concept，沿链接展开上下文。
对回答附来源文件和字段，避免凭空编业务定义。
允许 Agent 生成草稿更新，但必须人审后合并。
把 log.md 用作知识演化记录。

和现有体系的关系

已有东西	OKF 不是替代	OKF 可以补的层
数据目录 / Catalog	仍负责权限、资产注册、血缘、治理。	导出成可携带、Agent 可直接读的知识包。
RAG / 向量库	仍负责检索和召回。	提供结构更清晰、链接更明确、可版本管理的语料源。
语义层 / 指标层	仍负责指标计算逻辑和统一口径。	把业务解释、使用边界、示例查询、历史变更写成可读上下文。
Wiki / Notion / Obsidian	仍是人类编辑知识的入口。	用统一 frontmatter 和文件约定，让知识可被多种 Agent 消费。
MCP / Agent 工具协议	仍负责工具调用和上下文传递接口。	OKF 可以作为 MCP 工具或资源背后的标准知识内容格式。

我的判断：OKF 最可能先在“数据团队 + Agent/RAG 团队”的交界处落地。因为这里的上下文最碎、业务定义最重要、错误成本最高，也最需要一个能被 Git、搜索、Agent、可视化工具共同理解的中间格式。

资料来源

本文基于 Google Cloud Blog 原文反复阅读后整理，内容以解释、重组和工程化解读为主，没有复刻原文长段落。