谷歌雲推出開放知識格式（OKF）：為AI代理提供精心策劃上下文的供應商中立Markdown規範

基礎模型越來越強大，但它們仍然在同一個問題上停滯不前：上下文。模型可以編寫代碼或分析數據集，但需要正確的內部知識。這些知識包括表模式、指標定義、運行手冊、連接路徑，它們分散在目錄、維基和一些高級工程師的頭腦中。

谷歌雲推出了開放知識格式（OKF），這是一個開放規範，將LLM-wiki模式形式化為可移植、可互操作的格式。它是一個供應商中立、代理和人類友好的標準，適用於現代AI系統所需的上下文。

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 vault、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旁邊，通過拉取請求審查更改。
• 事件運行手冊：將每個運行手冊存儲為一個概念。值班代理讀取index.md，跟隨交叉鏈接，解決它需要的連接路徑。
• 跨組織知識交換：供應商將目錄導出為OKF。你的代理直接消耗它，無需集成工作。
• 開發者團隊維基：用版本控制的Markdown替換陳舊的Notion或Obsidian空間，代理保持最新。

OKF與其他方法的比較

OKF v0.1：存儲Markdown + YAML文件，僅需type模式，可移植，無需SDK/註冊表，代理可讀無需翻譯。 Notion：專有數據庫，每個工作區模式，僅可導出，需要API，代理通過API可讀。 Obsidian vault：Markdown文件，無強制模式，可移植，但約定是定製的。 元數據目錄：供應商存儲，供應商模式，僅可導出，供應商SDK，供應商特定。 RAG索引：向量存儲，嵌入模型，可移植，但需要查詢時重新派生，塊而非概念。

與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
        for target in set(re.findall(r"\]\((/[^)]+\.md)\)", body)):
            links.append((str(path), target))
    return concepts, links

concepts, graph = load_bundle("sales/")

不需要後端或安裝即可讀取或服務一個包。這些文件與它們描述的代碼一起存在於版本控制中。

關鍵要點

• 谷歌的開放知識格式（OKF）v0.1將LLM-wiki模式形式化為可移植、供應商中立的規範。
• 一個包只是一個Markdown文件目錄，帶有YAML前置元數據——沒有SDK、運行時或註冊表。
• 每個概念只需要一個字段：type；文件之間的交叉鏈接形成知識圖譜。
• 谷歌發佈了參考工具：一個BigQuery豐富代理、一個靜態HTML可視化器和三個示例包。
• 與RAG不同，OKF存儲經過策劃、版本控制的概念，代理直接讀取和更新。

更多技術細節請查看原文。