AI 科技資訊人工智慧的新知入口
首頁 / Open Knowledge Format (OKF) 是什麼？讓 AI 代理人讀得懂、帶得走的知識格式
大型語言模型AI 代理人 (Agents)AI 標準與協作 (Standards)

Open Knowledge Format (OKF) 是什麼？讓 AI 代理人讀得懂、帶得走的知識格式

AI 模型越來越會寫程式、整理文件、分析資料，但它們仍然有一個很現實的限制：如果沒有正確的背景知識，就很容易回答得漂亮卻不準確。

在企業裡，真正重要的脈絡通常分散在很多地方。資料表的欄位意義在資料型錄裡，業務指標定義在簡報裡，事故處理流程在 Wiki 裡，資深工程師腦中還有一堆沒有寫下來的經驗。當 AI 代理人要完成任務時，光靠模型本身通常不夠，它需要能可靠讀取這些組織知識。

Open Knowledge Format (OKF)，可以翻成「開放知識格式」。這是 Google Cloud 在 2026 年 6 月 13 日介紹的開放規格，目標是用一種簡單、可攜、不綁定特定廠商的方式，整理 AI 代理人需要的知識脈絡。

如果把大型語言模型想成一位很聰明的新同事，OKF 就像是一套整理好的公司知識手冊：不綁特定系統，人能讀，AI 也能讀。

一句話重點

OKF 是一種用 Markdown 檔案 + YAML frontmatter 表示知識的開放格式，讓資料表、指標、API、作業手冊、文件脈絡等內容，可以在不同工具、團隊與 AI 代理人之間交換。

它解決什麼問題？

現在很多 AI 應用不是卡在模型能力，而是卡在「脈絡取得」。

例如你問公司內部 AI 代理人：「週活躍使用者要怎麼算？」它可能需要同時知道：

  • 哪一張事件資料表是正式來源。
  • 哪些事件要算，哪些測試事件要排除。
  • 使用者 ID 要怎麼合併。
  • 這個指標過去是否改過定義。
  • 相關 SQL 範例放在哪裡。

這些資訊常常不在同一個系統裡。有些在資料型錄，有些在 Google Docs，有些在 Notion，有些藏在程式碼註解，有些則只存在於團隊習慣中。

OKF 想解決的不是「再做一個知識服務」，而是先定義一個大家都看得懂的格式。只要不同系統能輸出或讀取 OKF，知識就比較不會被鎖在單一平台裡。

OKF 怎麼運作？

OKF v0.1 的核心設計很簡單：一個知識包就是一個資料夾，裡面放很多 Markdown 檔案。每一個 Markdown 檔案代表一個「概念」。

這個概念可以是：

  • 一張 BigQuery 資料表。
  • 一個資料集。
  • 一個商業指標。
  • 一支 API。
  • 一份事故處理手冊。
  • 一段產品或系統背景說明。

資料夾結構本身就是知識的組織方式。例如：

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

每個概念檔案上方會有一小段 YAML frontmatter，用來放機器比較容易查詢的欄位。下面則是一般 Markdown 內容，讓人類與 AI 都能閱讀。

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---
Schema






Column
Type
Description





order_id
STRING
訂單唯一識別碼




customer_id
STRING
對應 customers 表的使用者





Joins


可以用 customer_id 和 customers 連接。

這樣的設計刻意不複雜。它不是新的資料庫，也不是新的雲端服務，而是把已經很普遍的 Markdown、資料夾、YAML frontmatter 組合成一套約定。

核心特色

1. 人類與 AI 都能讀

OKF 使用 Markdown，所以工程師可以直接用編輯器打開，也可以放在 GitHub 上閱讀。AI 代理人也可以把檔案內容載入上下文，不需要先串接特定 SDK。

這一點很重要。企業知識如果只能透過某個封閉平台讀取，AI 代理人就必須為每個平台各寫一套整合。OKF 則把交換單位降到「檔案」。

2. 用 YAML frontmatter 保留可查詢欄位

完全自由的文章雖然好讀，但機器不一定好篩選。OKF 用 frontmatter 放少量結構化欄位，例如 type、title、description、resource、tags、timestamp。

這些欄位可以讓工具快速知道：這是一張資料表、一個指標，還是一份操作手冊。至於更細的內容，仍然放在 Markdown 本文中。

3. 可以用 Git 管理知識版本

因為 OKF 知識包本質上是一個資料夾，所以可以放進 Git。這代表知識可以被 pull request 審查，可以看修改歷史，也可以追蹤是哪一次改動讓指標定義變了。

對資料團隊來說，這接近「metadata as code」的概念：把資料知識當成程式碼一樣管理，而不是放在看不到版本差異的文件平台裡。

4. 不綁特定雲端、模型或代理框架

OKF 的官方定位是格式，不是平台。它不要求一定要用 Google Cloud，也不要求特定模型、特定代理框架或特定資料庫。

這使它比較像一種交換語言。生產端可以是資料型錄匯出工具、文件爬取流程、工程師手寫文件，消費端可以是搜尋索引、圖形視覺化工具、AI 代理人或靜態文件網站。

5. 用連結把知識變成關係圖

OKF 不是只靠資料夾階層。概念檔案之間可以用一般 Markdown 連結互相指向，例如某個指標可以連到資料表、SQL 範例與業務定義。

這讓知識從「樹狀資料夾」變成更接近「關係網」。AI 代理人要追查某個答案時，也比較容易沿著連結找到相關脈絡。

它和一般 Wiki、Notion、資料型錄有什麼不同？

比較項目 OKF 一般 Wiki / Notion 傳統資料型錄
主要定位 知識交換格式 人類協作文件 資料資產管理
儲存方式 Markdown 檔案與資料夾 平台內頁面 平台資料庫或服務
AI 代理人讀取 可直接讀檔案 常需 API 或匯出 常需平台整合
可攜性 高，可放 Git 或打包 取決於平台匯出能力 取決於廠商支援
結構化程度 輕量 frontmatter 通常較自由 通常較強但較封閉

OKF 不是要取代所有 Wiki 或資料型錄。比較合理的看法是：它可以成為這些系統之間的中間格式。

例如資料型錄可以輸出 OKF，文件系統可以補上業務說明，AI 代理人再讀取整理後的 OKF 知識包。

非工程背景的人需要知道什麼？

對管理者、內容工作者或產品團隊來說，OKF 的重點不是 Markdown 或 YAML 本身，而是「AI 要有共同可讀的知識底座」。

很多企業導入 AI 時，會先問要選哪個模型、哪個聊天機器人、哪個代理框架。但真正影響品質的，常常是組織知識有沒有整理好。

如果公司內部對「客戶流失率」「活躍使用者」「正式資料來源」都沒有一致定義，AI 只會把混亂放大。OKF 值得注意的地方，是它把這些脈絡變成可以版本管理、可以搬移、可以給 AI 讀取的文件集合。

適合誰使用？

  • 資料團隊：想把資料表、欄位、指標、查詢範例與來源說明整理成可追蹤格式。
  • AI 代理人開發者：需要為代理人建立一套可讀、可更新、可攜的知識庫。
  • 平台與工具開發者：想讓自家資料型錄、文件系統或搜尋工具支援一種開放交換格式。
  • 重視知識治理的企業：希望把重要定義與操作流程放進版本控制，而不是散落在不同文件平台。

可能不適合誰？

  • 只需要個人筆記的人：如果只是私人備忘錄，Obsidian、Notion 或一般 Markdown 筆記已經足夠。
  • 期待完整知識管理平台的人：OKF 是格式，不是包含權限、搜尋、審核流程、視覺化介面的完整產品。
  • 沒有整理知識意願的團隊：格式只能降低交換成本，不能自動替組織決定哪些知識是正確版本。

目前可以怎麼開始？

Google Cloud 目前已公開 OKF v0.1 規格、GitHub 儲存庫、參考實作與範例知識包。想嘗試的人可以從三個方向開始：

  1. 先閱讀 OKF v0.1 規格，了解必要欄位與資料夾約定。
  2. 選一個小範圍試做，例如只整理一個資料集或一組常用指標。
  3. 把 OKF 知識包放進 Git，讓團隊用 pull request 維護內容。

如果是資料團隊，可以先從最常被 AI 或同事問到的問題開始，例如「這張表怎麼 join？」「這個指標怎麼算？」「哪個欄位是正式來源？」

我們的觀察

OKF 值得注意，是因為它碰到 AI 代理人接下來會遇到的真問題：模型本身越來越強，但企業脈絡仍然零散、封閉、難以移動。

它的設計也很務實。不是再創造一個大型平台，而是選擇 Markdown、YAML、資料夾、Git 這些已經被大量工具支援的基礎元素。這讓導入門檻相對低，也降低被單一服務綁住的風險。

不過，OKF v0.1 仍是早期規格。它能否成為廣泛採用的標準，取決於更多資料型錄、AI 代理框架、企業文件工具是否願意支援。短期來看，它最適合先被用在資料團隊與 AI 代理人專案中，作為一種輕量、可版本管理的知識交換層。

來源