推出 Open Knowledge Format（开放知识格式）

JavaEdge在掘金
5 阅读1分钟

本文已收录在Github，关注我，紧跟本系列专栏文章，咱们下篇再续！

  • 🚀 魔都架构师 | 全网30W技术追随者
  • 🔧 大厂分布式系统/数据中台实战专家
  • 🏆 主导交易系统百万级流量调优 & 车联网平台架构
  • 🧠 AIGC应用开发先行者 | 区块链落地实践者
  • 🌍 以技术驱动创新，我们的征途是改变世界！
  • 👉 实战干货：编程严选网

随着基础模型能力不断提升，限制其发挥作用的瓶颈越来越多地来自缺乏相关上下文信息，尤其是在构建智能体（Agent）系统时更是如此。虽然这些模型已经能够帮助编写代码、总结文档或分析数据集，但要想输出准确且可执行的结果，它们仍然需要获得正确的信息。

因此，我们今天正式推出 Open Knowledge Format（OKF），一种开放规范，它将 LLM-wiki 模式标准化为可移植、可互操作的格式。这是一种与厂商无关、同时适合智能体和人类使用的标准，用于表示现代 AI 系统所需的元数据、上下文以及经过整理的知识。

当前发布的 OKF v0.1 将知识表示为由 Markdown 文件组成的目录结构，并使用 YAML Front Matter 存储元数据。同时，它定义了一组简单的约定，使得不同来源创建的知识库能够被不同智能体直接使用，而无需额外转换。

就是这么简单。不需要复杂的压缩方案，不需要新的运行时环境，也不需要专用 SDK。一个 OKF 文档集合具有以下特点：

  • 就是 Markdown —— 可以在任何编辑器中阅读，可直接在 GitHub 上渲染，也能被各种搜索工具索引
  • 就是文件 —— 可以打包传输、托管在任意 Git 仓库中，也能挂载到任何文件系统
  • 就是 YAML Front Matter —— 用于存储少量需要结构化查询的字段，例如类型（type）、标题（title）、描述（description）、资源链接（resource）、标签（tags）和时间戳（timestamp）

如果你使用过 Obsidian、Notion、Hugo，或者过去一年出现的各种 LLM Wiki 模式，那么这种结构会非常熟悉。OKF 的作用，就是把这些模式中实现互操作所需的关键约定正式规范化。

接下来，我们将介绍 OKF 试图解决的问题、它的工作原理、如何开始使用，以及未来的发展方向。

碎片化的上下文环境

在大多数组织中，基础模型所依赖的信息主要来自内部知识，例如：

  • 数据表的结构定义
  • 企业内部对某项指标的业务含义
  • 事故处理手册
  • 不同系统之间的数据关联路径
  • 旧 API 的弃用通知

如今，这些知识碎片分散在各种系统中：

  • 拥有各自 API 的元数据目录
  • Wiki、第三方系统或共享网盘
  • 代码注释、文档字符串（docstring）或 Notebook 单元格
  • 少数资深工程师的大脑里

当 AI 智能体需要回答“如何根据事件流计算周活跃用户（Weekly Active Users）？”时，它不得不从这些分散且彼此不兼容的信息源中拼凑答案。每个厂商都有自己的目录系统、SDK 和知识图谱模型，而这些知识几乎无法在不同产品或组织之间自由迁移。

结果就是：每个智能体开发者都在重复解决相同的上下文组装问题；每个目录产品厂商都在重复设计类似的数据模型；而知识本身则被锁定在最初创建它的平台中。

将知识视为持续演进的 Wiki

开发团队正在改变构建 AI 智能体的方式。

与其让模型一遍又一遍地搜索相同文档、查找相同事实，不如为智能体提供一个共享的 Markdown 知识库，并让它随着时间不断完善。这种方式下，智能体可以负责阅读和更新文件，而团队则负责维护内容，并像管理代码一样管理知识。

知名 AI 研究者和教育者 Andrej Karpathy 在他的 LLM Wiki 文章 中对此进行了精辟阐述：

“LLM 不会感到厌烦，不会忘记更新交叉引用，还能一次性修改 15 个文件。”

那些让人们最终放弃维护个人 Wiki 的繁琐工作，恰恰是 LLM 最擅长处理的事情。

类似的“知识即 Wiki（Knowledge-as-Wiki）”模式正在不断出现，只是名字不同而已。例如：

  • 与编程智能体结合的 Obsidian Vault
  • AGENTS.md、CLAUDE.md 等约定文件
  • 包含 index.md、log.md 等文件，并供智能体在执行任务前查阅的仓库
  • 数据团队内部的“元数据即代码（Metadata as Code）”仓库

这种模式既有吸引力又十分强大，但每个实现都各自为政。Karpathy 的 Wiki、你团队的 Wiki，以及某个厂商导出的知识目录，虽然看起来都很相似（Markdown、Front Matter、交叉链接），却并没有被设计成能够互相协作。

目前并没有统一标准来回答：

  • 每个文档应该包含哪些字段？
  • 不同文件名分别代表什么含义？

因此，这些 Wiki 中沉淀的知识依然被限制在原始团队内部。每当构建新的智能体时，人们都不得不重复投入大量工作。

缺少的不是新服务，而是统一格式

解决这个问题并不需要再创造一个新的知识服务平台。

真正需要的是一种格式（Format），一种能够：

  • 让任何人无需 SDK 就能生成
  • 让任何人无需额外集成就能使用
  • 能够在不同系统、组织和工具之间自由迁移
  • 与代码一起存放在版本控制系统中
  • 同时适合人类阅读和智能体解析，而且无需额外转换层

OKF 正是为此而设计的。

OKF 如何工作：一屏看懂设计

一个 OKF Bundle（知识包） 本质上是一个由 Markdown 文件组成的目录，每个文件表示一个概念（Concept）。

概念可以是任何需要记录的对象，例如：

  • 数据表
  • 数据集
  • 指标
  • 操作手册（Playbook）
  • 运维手册（Runbook）
  • API

每个概念对应一个文件，而文件路径就是该概念的唯一标识：

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

每个概念文档包含两部分：

  • YAML Front Matter：存储结构化字段
  • Markdown 正文：存储其他所有内容
---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
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`.

不同概念之间通过标准 Markdown 链接互相关联，从而将整个目录组织成一个知识图谱（Graph）。这种关系网络比文件系统天然提供的父子层级关系更加丰富。

此外，知识包还可以选择包含：

  • index.md：帮助智能体逐层浏览目录结构
  • log.md：记录知识变更历史

完整的 OKF v0.1 规范（包括兼容性要求、交叉链接规则以及少量保留文件名）仅需一页纸即可说明。

设计背后的三项原则

1. 尽可能少做限制

OKF 对每个概念只强制要求一个字段：type（类型）。

除此之外：

  • 类型如何定义
  • 是否增加其他字段
  • 正文应包含哪些章节

都由知识生产者自行决定。

规范只定义互操作的基础接口，而不限制具体内容模型。

2. 生产者与消费者解耦

OKF 明确区分：

  • 谁负责编写知识
  • 谁负责消费知识

例如：

  • 人工编写的知识包可以被 AI 智能体使用
  • 元数据导出工具生成的知识包可以被可视化工具浏览
  • 一个 LLM 生成的知识包可以被另一个 LLM 查询

格式本身就是双方的契约，而两端工具可以独立演进和替换。

3. 格式，而非平台

OKF 不依赖任何：

  • 云平台
  • 数据库
  • 模型提供商
  • 智能体框架

未来也不会要求使用专有账号或 SDK 来读取、写入或提供服务。

我们将其作为开放标准发布，因为知识格式的价值来自于有多少参与者共同使用它，而不是由谁拥有它。

随规范一起发布的内容

为了让 OKF 更具体、更容易上手，我们同时发布了生产端和消费端的参考实现：

  • 一个知识增强智能体（Enrichment Agent）：遍历 BigQuery 数据集，为每张表和视图生成 OKF 概念文档，然后通过第二轮 LLM 分析权威文档，为文档补充引用来源、Schema 信息和关联路径。
  • 一个静态 HTML 可视化工具：将任何 OKF 知识包转换为交互式知识图谱，并生成单个独立 HTML 文件。无需后端、无需安装，数据也不会离开当前页面。
  • 三个可直接浏览的示例知识包：

这些示例均由参考智能体生成，并作为符合 OKF 规范的真实案例提交到代码仓库中。

需要强调的是，这些只是概念验证（Proof of Concept）。

参考智能体展示的是一种生成 OKF 的方式，而不是唯一方式；参考可视化工具展示的是一种消费 OKF 的方式，而不是唯一方式。

我们期待未来出现更多样化的生产工具和消费工具，共同扩展整个生态。

下一步计划

OKF v0.1 是一个起点，而不是最终版本。

随着更多知识生产者和消费者加入，以及我们逐步理解智能体在实际应用中真正需要怎样的知识表示方式，这一格式还会持续演进。

我们从第一天起就选择开放发布，因为只有这样，知识格式才能真正成为行业标准。

无论你是在构建：

  • 知识目录系统
  • 知识增强流水线
  • 面向 AI 智能体的 Wiki
  • 或任何与 AI 知识管理相关的产品

都欢迎参与进来。

接下来，你可以：

  • 阅读规范文档（非常简短）
  • 为你的数据源编写生产器（Producer），例如数据库、文档站点或其他系统
  • 开发消费者（Consumer），例如可视化工具、搜索索引或知识推理智能体
  • 使用参考实现处理自己的数据
  • 提交 Issue、PR 或扩展提案，规范采用版本管理，并专门设计为支持向后兼容的扩展

代码仓库、规范文档和示例知识包均已发布在 GitHub。

同时，我们也已更新 Google Cloud 的 Knowledge Catalog，使其能够导入 Open Knowledge Format，并将其提供给我们的智能体使用。相关代码和示例可在这里查看。

OKF 本身才是最重要的成果。

我们发布的工具只是为了让这一格式真正落地，并降低尝试成本。无论你的知识目前以何种形式存在，OKF 的目标都是成为未来不同系统之间交换知识的通用语言（lingua franca）。

avatar
文章
阅读
粉丝