基础模型越来越强，却仍然在同一个问题上停滞不前：上下文。模型可以编写代码或分析数据集，但前提是拥有正确的内部知识。这些知识包括表结构、指标定义、操作手册、连接路径——它们零散地分布在数据目录、维基百科和少数资深工程师的头脑中。

Google Cloud 推出了开放知识格式（Open Knowledge Format，OKF），这是一项开放规范，将「LLM 维基」模式形式化为一种可移植、可互操作的格式。它是一个供应商中立、既适合智能体又适合人类的标准，用于承载现代 AI 系统所需的上下文。

开放知识格式（OKF）

OKF 是一种格式，而非服务或平台。OKF v0.1 将知识表示为包含 YAML 前置元数据的 Markdown 文件目录。一套约定的小规则使得由一家生产者编写的维基文件可以被不同的智能体直接读取，无需翻译。

这就是全部理念。没有压缩方案，没有新的运行时，也不需要专用的 SDK。一组 OKF 文档包只是 Markdown、只是文件、只是 YAML 前置元数据。它可以在 GitHub 上渲染，以 tarball 形式分发，并能挂载到任意文件系统。

如果你使用过 Obsidian、Notion 或 Hugo，你会觉得它很眼熟。OKF 只是将那些模式实现互操作所需的约定正式化了。

零散上下文的问题

在大多数组织中，模型上下文绝大部分是内部知识。如今，这些知识存在于互不兼容的孤岛中：拥有各自 API 的元数据目录、维基、共享驱动器、代码注释和文档字符串。

让一个智能体去计算「如何从事件流中获取周活跃用户数」。它必须从零散、互不兼容的多个数据源中拼凑答案。每家供应商都提供自己的目录、SDK 和知识图谱模式。没有哪份知识能在产品或组织之间移植。

结果是重复劳动。每个智能体构建者都要从头解决同样的上下文组装问题。每个目录供应商都在重新发明同样的数据模型。

Andrej Karpathy 在他 2026 年 4 月的 LLM Wiki 要点中阐述了这一核心理念。他的观点：LLM 不会感到厌倦，不会忘记更新交叉引用，并且可以一次性编辑多个文件。那些让人类放弃个人维基的管理工作，恰恰是 LLM 所擅长的。

同样的模式不断以不同名称重新出现。例子包括连接到编码智能体的 Obsidian 库、AGENTS.md 和 CLAUDE.md 约定文件，以及"元数据即代码"仓库。每个实例都是定制的，因此彼此之间无法互操作。OKF 将这一互操作层标准化，以便智能体可以承担繁重的工作。

OKF 的工作原理：一屏设计

一个 OKF 包是一个 markdown 文件的目录，表示概念——表格、数据集、指标、操作手册、运行手册或 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 前置元数据块，然后是包含其他所有内容的 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). |

保留的结构化字段包括 type、title、description、resource、tags 和 timestamp。概念之间通过普通的 markdown 链接相互关联。这些链接将目录转化为一个比文件系统父子关系更丰富的图。包可以选择性地包含 index.md 文件用于渐进式披露，以及 log.md 文件用于变更历史。

设计背后的三个原则

• 最小意见化：OKF 要求每个概念只有一个必填字段：type。其余所有内容留给生产者决定。规范定义了互操作表面，而不是内容模型。
• 生产者/消费者独立性：人类编写的包可以被智能体读取。流水线生成的包可以在可视化工具中浏览。格式就是契约；两端的工具是可互换的。
• 格式而非平台：OKF 不绑定任何云、数据库、模型提供商或智能体框架。它永远不会要求使用专有账户来读取、写入或提供服务。

用例及示例

• 数据团队的元数据即代码：将 BigQuery 表和指标定义导出为一个包。将其提交到所描述的 SQL 旁边，并通过 pull request 审查变更。
• 事件响应手册（runbooks）用于智能体：将每本手册存储为一个概念。值班智能体读取 index.md，跟随交叉链接，并解析它需要遵循的路径。
• 跨组织知识交换：供应商以 OKF 格式导出目录。你的智能体可以直接消费它，无需任何集成工作。
• 开发者团队维基：用一个保持版本化、由智能体保持最新的 Markdown 文件替代过时的 Notion 或 Obsidian 空间。

OKF 对比

与 RAG 的区别对开发者很有用。RAG 在查询时从原始块中重新推导知识。而 OKF 捆绑包存储经过整理、相互链接的概念，智能体可以直接读取和更新。

一个极简的 OKF 消费者

OKF 可以用标准工具解析。以下代码读取一个捆绑包并构建其链接图。

import pathlib, re, yaml

def load_bundle(root):
    concepts, links = {}, []
    for path in pathlib.Path(root).rglob("*.md"):
        text = path.read_text()
        meta = {}
        if text.startswith("---"):
            _, fm, body = text.split("---", 2)
            meta = yaml.safe_load(fm) or {}
        else:
            body = text
        concepts[str(path)] = meta            # type, title, tags, etc.
        for target in set(re.findall(r"\]\((/[^)]+\.md)\)", body)):
            links.append((str(path), target))  # markdown cross-links
    return concepts, links

concepts, graph = load_bundle("sales/")

读取或提供捆绑包无需后端或安装。相同的文件与它们所描述的代码一起存在于版本控制中。

关键要点

• Google 的开放知识格式（OKF）v0.1 将 LLM 维基模式形式化为一个可移植、供应商中立的规范。
• 一个捆绑包只是一个包含 YAML 前置元数据的 Markdown 文件目录——不需要 SDK、运行时或注册表。
• 每个概念只需要一个字段（类型）；文件之间的交叉链接构成知识图谱。
• Google 发布了参考工具：一个 BigQuery 增强智能体、一个静态 HTML 可视化工具以及三个示例捆绑包。
• 与 RAG 不同，OKF 存储经过整理、版本控制的概念，智能体可以直接读取和更新。