谷歌雲推出開放知識格式（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儲存經過策劃、版本控制的概念，代理直接讀取和更新。

更多技術細節請檢視原文。