青蛙小白
博客 / 2026/06

Google 发布 OKF：把 LLM Wiki 变成开放标准

2026/06/15 · — 字 · 阅读约 — 分钟 ·
#AI Agent
目录

今天 Google Cloud 发布了 Open Knowledge Format（OKF），一个把 LLM Wiki 模式标准化的开放规范。读完之后感觉这件事比标题看起来重要得多——它触碰的是构建 AI Agent 时一个真正的基础性问题。

问题：上下文组装是一个重复造轮子的苦差事

基础模型越来越强，但限制它们能做什么的往往不是模型能力，而是相关上下文的缺失。当一个 Agent 需要回答"怎么从我们的事件流里算 weekly active users？“时，它得从以下地方拼凑答案：

  • 元数据目录（各有各的 API）
  • Wiki、第三方系统、共享网盘
  • 代码注释、docstring、notebook 单元格
  • 几个资深工程师的脑子

每个 Agent 构建者都在从头解决同一个上下文组装问题。每个目录厂商都在重新发明同样的数据模型。知识被锁在创建它的系统里，无法跨产品、跨组织流动。

模式已存在，缺的是格式

Karpathy 在他的 LLM Wiki gist 里把这个思路说得很清楚：与其让模型反复搜索同样的文档找同样的事实，不如给 Agent 一个共享的 markdown 库，让它随时间越来越有用。“LLM 不会无聊，不会忘记更新交叉引用，可以一次性改 15 个文件”——那些让人类放弃维护个人 wiki 的琐事，恰恰是 LLM 擅长的。

类似的模式已经在各处冒出来：Obsidian vault 接 coding agent、AGENTS.md / CLAUDE.md 约定文件、数据团队的"metadata as code"仓库。但每个实例都是独立的。Karpathy 的 wiki 和你团队的 wiki 和某个厂商的目录导出，可能长得一样（markdown、frontmatter、交叉链接），但它们从来没有设计成互相配合。缺乏统一约定，知识就一直被困在原来的团队里。

缺的不是另一个知识服务，而是一个格式。

OKF 是什么：一屏幕能讲完的设计

OKF bundle 就是一个 markdown 文件目录，每个概念一个文件，文件路径即概念的身份：

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

每个概念文档有一小块 YAML frontmatter 用于结构化字段，body 是普通 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 ID.  |
| customer_id | STRING | FK to [customers](/tables/customers.md). |

# Joins

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

概念之间用普通 markdown 链接互联，整个目录变成一张关系图。

就这些。没有复杂的压缩方案，没有新的运行时，没有必须用的 SDK。

  • Just markdown — 任何编辑器可读，GitHub 可渲染，任何搜索工具可索引
  • Just files — 可以打成 tarball、放进任何 git 仓库、挂载到任何文件系统
  • Just YAML frontmatter — 只有少数需要被查询的结构化字段：type、title、description、resource、tags、timestamp

三个设计原则

1. 最小主张（Minimally opinionated）：OKF 对每个概念只要求一件事——type 字段。其他一切（有哪些 type、body 有哪些章节）由生产者决定。规范定义互操作边界，不定义内容模型。

2. 生产者/消费者独立：人工手写的 bundle 可以被 AI Agent 消费；元数据导出管道生成的 bundle 可以在可视化工具里浏览；一个 LLM 合成的 bundle 可以被另一个 LLM 查询。格式是合约，两端的工具独立可替换。

3. 格式，不是平台：OKF 不绑定任何云、数据库、模型提供商或 Agent 框架。读写它永远不需要专有账号或 SDK。

随规范一起发布的东西

Google 同时发布了几个参考实现：

  • Enrichment Agent：遍历 BigQuery 数据集，为每张表/视图起草 OKF 文档，再跑一轮 LLM 爬权威文档做内容增强
  • 静态 HTML 可视化器：把任何 OKF bundle 渲染成交互式图视图，单个自包含 HTML 文件，无后端，无需安装，数据不离开页面
  • 三个示例 bundle：GA4 电商、Stack Overflow、Bitcoin 公开数据集，由参考 agent 生成，作为符合规范的活样本提交在仓库里

此外，Google Cloud 的 Knowledge Catalog 已更新，可以摄入 OKF 并向 Google 的 Agent 提供服务。

为什么这件事值得关注

OKF 解决的不是 Google 自己的问题，而是每个在构建 AI Agent 的团队都在重复解决的问题。它的价值主张很简单：一个知识格式的价值来自有多少方在使用它，而不是谁拥有它。

规范本身已开源，鼓励任何人写生产者（针对自己的数据库、文档站）、写消费者（查看器、搜索索引、推理 Agent）、提 issue 和 PR。

如果你的团队正在维护某种形式的"给 AI 用的内部知识库”——无论是 CLAUDE.md、Obsidian vault、还是 notion 导出——OKF 定义的那组极简约定值得认真看一看。不需要迁移，只需要对齐一套约定，知识就能开始跨工具流动。

参考

TAGS # AI Agent
评论