尽管基础模型的能力正在快速提升，但其发挥作用的瓶颈却日益集中于上下文信息的匮乏——尤其在构建智能体（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文章里把这个观点阐述得非常透彻：
那些让人们最终放弃维护个人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://...
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。OKF本身才是最重要的成果。我们发布的工具只是为了让这一格式真正落地，并降低尝试成本。无论你的知识目前以何种形式存在，OKF的目标都是成为未来不同系统之间交换知识的通用语言（lingua franca）。
