OKF：Google 的 Markdown 代理規格

2026 年 6 月 12 日，Google Cloud 發布了一份規格，定義 AI 代理該如何讀取與交換經過整理的知識。你可能以為背後會有圖形資料庫、schema 註冊表、SDK，還要一套服務來跑它。

不過，Open Knowledge Format 其實就只是這樣：一個裝滿 Markdown 檔案的資料夾，每份檔案帶著 YAML frontmatter。

整個格式就這樣。而有趣的地方，正是這份克制。

規格比你想的還要小

大多數寫 OKF 的文章，都只是在複述這則公告。值得直接讀規格原文，因為它的涵蓋範圍小得驚人。

OKF v0.1 對每份概念文件只要求剛好一個欄位：

---
type: BigQuery Table
---

就這樣。type 是一個簡短字串，用來標明這份文件描述的是哪一種概念，供路由與篩選使用。這些值並非集中登記——沒有委員會在審核合法 type 的清單。產出者自己挑一個一看就懂的描述詞，然後就繼續往下做。

還有五個欄位是建議填寫，但都不是必要的：

欄位	用途
title	顯示名稱。若缺少，消費端可以從檔名推導。
description	一句話摘要。
resource	唯一識別底層資產的 URI。
tags	一份 YAML 清單，用於跨領域分類。
timestamp	最後修改時間，ISO 8601 格式。

產出者可以自由加入任何自訂欄位。消費端必須保留未知欄位，而不是直接拒絕它們。

一份完整、符合規格的概念文件長這樣：

---
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, orders]
timestamp: 2026-05-28T00:00:00Z
---

# Schema

| Column | Type | Description |
|--------|------|-------------|
| order_id | STRING | Unique identifier |

如果你曾經在 Obsidian 裡寫過帶 frontmatter 的筆記，你寫的東西其實已經很接近一份合格的 OKF 概念文件了。

沒有圖形資料庫的知識圖譜

不管你會不會採用 OKF，這個設計決定都值得偷學。

概念之間的關係，用標準 Markdown 連結來表達。不是資料庫裡的邊，也不是 frontmatter 裡的 relationships: 區塊。就只是連結：

Each order references a [customer](/tables/customers.md).

建議使用相對於 bundle 的絕對路徑（以 / 開頭）以確保穩定性；一般的相對路徑，例如 ./other.md，也可以用。

而真正讓這套機制運作起來的關鍵在於：關係的種類，是由周圍的文字承載的，而不是連結本身。「每筆訂單都參照一位顧客」這句話就是邊的標籤。不需要維護本體論，也不需要為一套述詞詞彙達成共識，因為自然語言早就有一套了，而讀它的消費端剛好是一個語言模型。

過去十年，知識圖譜工具做了大量工作，就是為了把關係類型形式化，好讓機器能夠解讀。OKF 賭的是：這已經不再必要——因為現在機器直接看得懂文字了。

兩個保留檔名

在一個 bundle 裡，只有兩個檔名帶有特殊意義：

• index.md — 一份目錄清單，讓漸進式揭露成為可能。它不帶 frontmatter。代理會先讀這份索引，只跟隨自己需要的連結，而不是把每一份概念文件都塞進情境視窗。
• log.md — 按時間排序的更新紀錄，用 ISO 8601 日期作為標題，最新的排在最前面。

其他每一份 .md 檔案都是概念文件。最後，一個 bundle 看起來就像一個普通、可以直接瀏覽的資料夾：

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

index.md 才是那個低調卻重要的角色。這跟一份寫得好的 CLAUDE.md 背後的直覺一模一樣：不要把整個資料庫都丟進情境視窗，而是給代理一份目錄，讓它自己去抓需要的內容。

OKF 不是什麼

它不是 RAG。 RAG 是在查詢當下，靠檢索原始片段、寄望相關內容浮現出來，重新推導知識。而一個 OKF bundle 儲存的是經過整理、彼此互連的概念文件，代理可以直接讀取與更新。整理這件事只刻意做一次，而不是每次查詢都近似地重做一遍。

它也不是 AGENTS.md 或 CLAUDE.md。 那些是指令檔案——告訴代理該怎麼在一個儲存庫裡行動。OKF 描述的是主題知識：這張表代表什麼、這個指標怎麼定義、為什麼這份資料集在三月有個缺口。工作性質不同，但彼此互補。

它也不是 MCP。 MCP 是一套執行期協定，用來把代理接到活的系統上。OKF 則是靜靜躺在硬碟上的檔案格式。這兩者很可能會一起用：MCP 負責連到資料倉儲，OKF 負責解釋裡面裝了什麼。

符合性規則，刻意寫得很寬容

只要每一份非保留的 .md 檔案都有可解析的 YAML frontmatter、每個 frontmatter 區塊都有非空的 type，而保留檔案（若存在）都遵守各自的結構，一個 bundle 就符合 OKF v0.1。

更能說明問題的，是規格禁止消費端做的事。消費端不得因為缺少選填欄位、type 值不在預期範圍內、出現未知的鍵、互連連結失效，或是沒有 index.md，就拒絕一個 bundle。

這是由一群早就料到 bundle 會是半成品、部分由機器產生、而且不斷在變動的人設計出來的格式——這也正是真實知識庫的樣子。嚴格的格式，往往死於自己的嚴格。而這一套，是為了在雜亂的資料夾裡活下來而設計的。

Google 同時發布了參考工具：一個 BigQuery 擴充代理、一個靜態 HTML 視覺化工具，還有三份範例 bundle。

有一點該講清楚： OKF 目前是 v0.1，而且明確標示為草案。這份規格有版本號，設計上也考慮了向後相容的成長空間，但欄位名稱與慣例仍然可能會變動。今天先別為了它去重建你的知識庫，但值得留意這個標準正朝哪個方向走。

為什麼這件事不只跟 Google Cloud 有關

把 BigQuery 的例子拿掉，OKF 其實是一個影響範圍大得多的賭注：機器可讀知識真正耐用的格式，就是你自己擁有的資料夾裡，一份份純 Markdown 檔案。

不是一個帶 API 的專有目錄，不是你讀不懂的向量資料庫裡的 embeddings，也不是一個匯出按鈕會把你的表格搞爛的 wiki。就是檔案。放在硬碟上。可以 diff，可以 grep，能在不同廠商之間搬來搬去，人類看得懂，市面上每一個模型也都看得懂。

這跟 Claude Code、Cursor、Copilot 和 Windsurf 各自獨立選擇 Markdown 作為指令格式時，得出的結論一模一樣。Google Cloud 把它寫成一份規格，只是確認了這件事，而不是發明了它。

Minibase 的定位

如果你有在維護一個 Minibase Vault，你手上其實已經有結構上很接近 OKF bundle 的東西了：一個裝著帶 frontmatter 的 Markdown 檔案的資料夾，放在你自己的硬碟上，由 Claude 和 ChatGPT 讀取。

要讓它正式符合規格，只需要一個小改動——在你的 frontmatter 裡加上 type，剩下的交給你原本就有的連結：

---
type: Article
title: How the Open Knowledge Format can improve data sharing
resource: https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/
tags: [okf, agents, markdown]
timestamp: 2026-07-19T00:00:00Z
---

這就是這則公告落到實務上的樣子。一個代理知識庫真正困難的部分，從來都不是檔案格式，而是把好的原始素材放進去。規格告訴你資料夾該長什麼樣子，但不會幫你把它填滿。

而填滿它，正是 Minibase 做的事：一鍵就能把任何網頁——文件、GitHub README、一份規格、一串討論串、一篇研究論文——轉成乾淨的 Markdown，放進你的資料夾裡，等著你下一次跑代理時派上用場。

格式現在已經標準化了。你放進去的東西，才是你的優勢所在。

---

Minibase 能把任何網頁轉成你的代理讀得懂的乾淨 Markdown——安裝擴充功能，開始建立能讓你的代理變得更聰明的 bundle。