Open Knowledge Format（以下簡稱 OKF）是 Google 在 2026 年 6 月提出的開放規格，把「給 AI 代理讀的知識」標準化成一包可攜式的 markdown 檔案。它不是 SEO 排名因素，而是要解決一個越來越普遍的問題：當你用 AI 代理做事時，模型需要大量的內部知識（表格結構、指標定義、操作手冊），但這些知識散落在各種互相不相容的系統裡。OKF 把這些知識統一成一種任何代理、任何工具都能讀的格式。如果你已經研究過 llms.txt，可以把 OKF 想成是它的下一層：llms.txt 是一張給 AI 看的網站索引，OKF 則是一整包可以被代理反覆讀寫的結構化知識。
TL;DR: OKF 是 Google 開源的 v0.1 草案規格，用「markdown 檔 + YAML frontmatter」組成知識 bundle，核心規則只有三條（每個概念檔要有 frontmatter、要有 type、保留檔結構正確）。目前幾乎沒人部署，但正因為新，現在寫繁中第一份完整指南就是卡位。
文章目錄
OKF 是什麼？一包給 AI 代理讀的 markdown 知識
用白話說，OKF 就是「規定你怎麼把知識寫成 markdown 檔案，讓任何 AI 代理都能讀懂」的規格。一個 OKF 單位叫做 bundle（知識包），它就是一個資料夾，裡面放著許多 .md 檔案。每個 .md 檔案描述一個概念（concept），例如一張資料表、一個商業指標、一份事故處理手冊、或一個 API 端點。這些檔案靠著標準的 markdown 連結串起來，形成一張知識圖，而不是各自孤立的文件。
重點是：它就是檔案，可以 commit 進 git、可以壓成 zip、可以放任何伺服器，不需要任何專屬 SDK 或帳號。這點很重要，因為它意味著知識可以像程式碼一樣被審查、被版本控管、被 review，而不會被鎖死在某個後設資料目錄或知識庫服務裡。這種「把給機器讀的知識變成可版本控制的檔案」的概念，和 AI SEO 與 GEO 想解決的問題方向一致：都是要讓內容更容易被 AI 理解與引用，只是 OKF 聚焦在「組織內部知識」這一塊，而前者聚焦在「對外的搜尋與答案能見度」。
為什麼需要 OKF：解開 AI 代理的 context 瓶頸
基礎模型再強，也受限於它能讀到的內容。當你讓 AI 代理回答「我們的事件串裡，每週活躍使用者要怎麼算？」這種問題時，它得從表格 schema、指標定義、join 路徑、欄位單位、資料新鮮度這些散落各處的知識拼出答案。問題是這些知識今天分散在四個地方：各家廠商自己的後設資料目錄與 API、團隊的 wiki 與共用硬碟、程式碼裡的註解與 docstring、以及幾位資深工程師的腦袋。每個代理開發者都得從零解決同一個「組裝 context」的問題，每個目錄廠商都在重造同一套資料模型，而知識本身被鎖死在「創造它的那個系統」裡，搬不出來。
OKF 借鏡了 AI 研究者 Andrej Karpathy 提出的「LLM wiki」想法：與其每次讓模型重新搜尋文件，不如維護一個會隨時間越來越有價值的共享 markdown 知識庫，讓代理自己讀、自己更新。Karpathy 的觀點很直接，他認為 LLM 不會無聊、不會忘記更新交叉引用、可以一次處理十幾個檔案，這些人類會放棄維護的繁瑣工作，正是 LLM 擅長的事。類似的「知識即 wiki」模式，其實已經以不同名字出現過：Obsidian 保險庫、AGENTS.md 與 CLAUDE.md 這類慣例檔、以及資料團隊裡的「後設資料即程式碼」儲存庫。OKF 做的，是把這些各自為政的做法，收斂成一套可以互通的格式。
這裡要小心一個常見誤解。OKF 解決的是「讓代理讀到正確的內部知識」，不是「讓你的網站在 Google AI 搜尋 排前面」。根據 Ahrefs 對 AI 引用行為的研究，約有 28% 被 AI 引用的頁面在傳統 Google 搜尋裡幾乎沒有流量，代表 AI 有一套獨立的發現機制；但這不代表部署某個格式就會被引用。格式只是基礎建設，真正決定能否被引用的還是內容本身的價值與可信度，這部分可以參考我們對 E-E-A-T 三個要點 的整理。
OKF 怎麼運作：bundle、concept、frontmatter 三件事
實務上，你只需要懂三件事。第一，bundle（知識包）就是一個資料夾，裡面是 markdown 檔案的樹狀結構，你想怎麼分類都行，可以按資料集、按業務領域、按團隊來分。第二，每個 .md 檔案就是一個 concept（概念），檔案路徑就是它的身分（例如 tables/orders.md 這個檔，概念 ID 就是 tables/orders）；搬動檔案要小心，因為其他概念可能用路徑連到它。第三，每個 concept 檔頂端有一段 YAML frontmatter，放需要被查詢的結構欄位，正文則是自由發揮的 markdown。
frontmatter 只有 type 是必填，用來標示這是什麼類型的概念，例如「Table」「Metric」「Playbook」「API Endpoint」，消費端會用 type 做路由、過濾與呈現。其餘 title（顯示名稱）、description（一句話摘要）、resource（底層資產的正規 URI）、tags（標籤清單）、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 order identifier. | | customer_id | STRING | FK to customers. | | total_usd | NUMERIC | Order total in USD. |
concept 之間用一般的 markdown 連結互相參照，例如 [customers](/tables/customers.md)，整個資料夾就變成一張比父子關係更豐富的關係圖。資料夾裡還可以有兩種保留檔：index.md 是目錄索引（讓人或代理先看到這層有什麼，支援「漸進式揭露」），log.md 是更新歷史（用日期分組、最新在最上面）。值得一提的是，規格明文規定消費端「必須容忍斷鏈」，一個指向還沒寫的知識的連結不算錯誤，只是代表尚未補完的內容，這設計讓 bundle 可以邊長大邊重構。這種「結構可以漸進、不必一次到位」的特性，跟我們在 內容叢集 裡提倡的主題逐步擴張是同一個邏輯。
消費端拿到一個 bundle 後，典型的讀法是：先看根目錄的 index.md 知道這包知識涵蓋什麼，再用 frontmatter 的 type 把概念分類（例如只挑出所有 Table、或只看 Metric），真正需要細節時才深入讀單一概念的正文。正因為消費只靠檔案與 markdown，同一個 bundle 可以同時被靜態檔案伺服器、知識管理介面、把內容載入 context 的 LLM、或圖譜視覺化工具讀取，不必為每個消費端客製介面。這也是官方強調「生產者與消費者分離」的實際意義：你怎麼產出這包知識、和別人怎麼讀它，是兩件可以各自獨立演進的事。
OKF 的三個設計原則
Google 在發布 OKF 時講了三個設計原則，這三點也決定了它適合誰、不適合誰。第一是「最小意見」：整個規格只強制一個欄位（type），其餘全部留給生產者自己決定，要有哪些 type、要加什麼欄位、正文怎麼組織，規格一概不管。標準只定「互通介面」，不定「內容模型」。第二是「生產者與消費者分離」：人手寫的 bundle 給代理讀、後設資料匯出管線產生的 bundle 給視覺化工具看、一個 LLM 合成的 bundle 給另一個 LLM 查，兩端工具可以獨立替換，格式就是它們之間的合約。第三是「是格式、不是平台」：OKF 不綁定任何雲端、資料庫、模型供應商或代理框架，永遠不需要專屬帳號或 SDK 才能讀寫，Google 把它當開放標準發布，因為知識格式的價值來自「有多少人說這個語言」，而不是「誰擁有它」。
把這三點合在一起看，你會發現 OKF 的企圖不是再蓋一個知識服務，而是讓「知識」這件事可以像程式碼一樣被交換、被版本控管。這和 技術 SEO 把後設資料「當程式碼管理」、以及 主題叢集內容 把內容結構化的思路是相通的：把混亂的東西用清楚的結構與慣例固定下來，機器和人才能一起協作。
OKF vs llms.txt vs AGENTS.md vs RAG（比較）
很多人會把 OKF 跟 llms.txt、AGENTS.md、甚至 RAG 搞混，但它們其實解的是不同層的問題。用一個比喻：llms.txt 像門口的告示牌（告訴訪客這棟樓有什麼），AGENTS.md 像每層樓的指引（告訴代理在這個專案怎麼做事），OKF 像整棟樓的內部資料庫（一包可以反覆查詢的結構化知識），RAG 則是搜尋引擎（用向量索引把片段撈出來）。它們可以並存，不是互斥，很多團隊會同時用 llms.txt 對外、OKF 對內。
| 項目 | 本質 | 放哪 | 解決的問題 |
|---|---|---|---|
| OKF | 多檔 markdown 知識包 | git repo / 檔案系統 | 給代理一包可反覆讀寫的內部知識 |
| llms.txt | 單一 markdown 索引檔 | 網站根目錄 /llms.txt | 給外部 AI 看的網站導覽 |
| AGENTS.md | 慣例設定檔 | 專案根目錄 | 告訴代理這個專案的規則與偏好 |
| RAG | 向量索引檢索 | 後端服務 | 依語意把相關片段撈進 context |
關鍵差異在於「知識要不要被你控制、可不可以被版本控管」。RAG 把知識藏在一個你看不見的索引裡，難以審查、難以跟著 repo 一起部署；OKF 把知識留在透明的 markdown 檔裡，人可以讀、git 可以 diff、代理可以查，這和 重視內容可審查性 的方向一致。如果你想做 llms.txt，可以搭配 llms.txt 產生器；想做 OKF，則用下方介紹的 OKF 產生器；想檢查自家頁面的 AI 可讀訊號，可用 AI 能見度檢查。
跟台灣網站的 SEO 與 GEO 有什麼關係
我會建議把期待放對地方。OKF 不是排名因素，Google 也從沒說部署它會影響 SEO 排名，這點跟 llms.txt 一樣，它們都是 AI 代理的導覽與知識輔助，不是搜尋引擎的排名要求。那它到底跟台灣網站有什麼關係？關係在「AI 搜尋與代理時代，你的內容能不能被機器正確理解」這個更大的脈絡。OKF 屬於這個脈絡裡「組織內部知識標準化」的一塊，跟 AISO（AI 搜尋優化）、Google AI Mode 背後的趨勢是同一條線。對大多數行銷導向的內容網站來說，優先順序應該是：先把基礎的 meta description、結構化資料、FAQ 結構化 顧好，再談 OKF 這類進階格式。但如果你是數據團隊、SaaS 產品團隊，或正在打造內部 AI 代理，OKF 就值得認真看，因為它直接影響你的代理能不能拿到正確知識。
舉個具體場景：一個電商團隊的數據分析師，想讓內部 AI 助理回答「上週哪個品類的退貨率異常」。助理得知道退貨率怎麼算、訂單表與退貨表怎麼 join、品類欄位的定義、以及資料通常延遲多久。這些知識今天散落在報表工具、團隊共筆、模型註解、和某位資深同事的腦袋裡，沒有單一可信來源。若把這些寫成一個 OKF bundle，助理就能穩定讀到正確定義，而不是每次靠人類臨時補充、或靠模型猜測而出錯。這就是 OKF 對「有資料資產的團隊」最實際的價值。
誠實說，目前台灣幾乎沒有關於 OKF 的討論，英文圈的部署案例也還非常少。這代表兩件事：一是現在投入沒有立即的流量紅利，二是誰先把這個主題在繁中市場講清楚，誰就拿到這個詞的話語權。這也是我們把 OKF 產生器做成免費工具、並寫這篇指南的原因：卡位的不只是工具，是「繁中第一手 OKF 解釋者」這個位置。對內容經營有興趣的讀者，可以延伸看我們對 內容擴充優先順序 的看法。
怎麼開始：用 OKF 產生器或手寫一個 bundle
最快的入門方式，是用我們做的 OKF 產生器：表單填一填概念的路徑、類型、描述、正文，工具會即時檢查是否符合官方 OKF v0.1 規格，然後把整包 bundle 打包成 .zip 讓你下載，放進 git repo 或任何檔案系統就能用。它內建官方的 Appendix A 範例，點一下就能載入一個示範 bundle，看看完整的知識包長怎樣。如果你想自己手寫，記得三條一致性規則就好：每個概念檔都要有可解析的 YAML frontmatter、frontmatter 裡一定要有非空的 type、保留檔 index.md 與 log.md 要照規格的結構寫。這三條是官方 SPEC 第 9 節明定的「符合 v0.1」條件，其餘都只是軟性建議，這跟我們在 策略三步審查 裡把關鍵檢查自動化的想法一致。
部署後，請把它當程式碼管理：進 git、走 pull request、定期更新 timestamp 與 log.md。知識會過期，不維護的 bundle 比沒有更糟，因為它會讓代理讀到錯誤資訊。這跟 內容品質需要持續維護 是同一個道理，也跟 搜尋演算法越來越看重語意理解 的方向相符：當機器越能理解你的內容，「知識正不正確、新不新鮮」就越重要。
OKF 現在值不值得投入（誠實評估）
回到搜尋意圖，直接給結論，分三種人看。對「行銷與內容網站」：現在還不值得投入，先把 SEO 基礎策略 與 精選摘要 顧好，投資報酬率高得多，也可以參考我們整理的 免費 Google SEO 工具。對「有內部數據資產、正在做 AI 代理」的團隊：值得跟進，因為 OKF 直接解決你代理讀不到正確知識的痛點，而且規格簡單、無供應商綁定，試錯成本很低。對「想做繁中權威卡位」的內容經營者：現在是甜蜜點，因為這個詞幾乎沒人寫，你寫了就是第一。
風險也要講清楚：OKF 還是 v0.1 草案，未來可能改動；它也還沒有任何搜尋引擎或 AI 平台公開宣告「會優先引用 OKF」，所以別把它當短期流量工具。但如果你觀察 Google 搜尋代理、ChatGPT、Claude 這些趨勢，會發現「代理直接消費結構化知識」的方向已經很明確。把它當「長期卡位加內部知識基礎建設」，會是比較務實的定位。想看更大局的人，也能回頭讀我們對 SEO 專家怎麼解釋 SEO 的整理。
說到底，OKF 反映的是一個更根本的轉變：知識正在從「被搜尋引擎索引的網頁」走向「被代理直接消費的結構化檔案」。先別管它會不會變主流，理解這個方向本身就值得，因為它決定了你未來要怎麼組織自己的內容與資料。要實際動手，就從 OKF 產生器載入範例開始，五分鐘就能產出第一個符合規格的 bundle。
常見問題
OKF 會影響 SEO 排名嗎？
不會。OKF 與 llms.txt 一樣，是 AI 代理的知識導覽格式，不是 Google 搜尋的排名因素。它影響的是「代理能否讀到正確知識」，不是「網頁是否排前面」。排名還是要回歸內容品質與 權威性 等基本面。
OKF 要放在哪裡？
一個 bundle 就是一個資料夾，可以放進 git repo（官方推薦，因為有版本歷史）、壓成 zip、或放在任何檔案系統。它不像 llms.txt 需要放在網站根目錄，因為它主要是給你自己的代理或工具消費的內部知識，不一定要對外公開。
OKF 跟 llms.txt 差在哪？
llms.txt 是單一檔案、放在網站根目錄、給「外部 AI」看的導覽索引；OKF 是一整包多檔 markdown 知識、給「內部代理」反覆讀寫的結構化資料。一個是入口告示牌，一個是內部資料庫，兩者可並存，很多團隊會同時部署。
我的網站需要 OKF 嗎？
多數行銷內容網站目前不需要，先把結構化資料與基礎 SEO 顧好，沒做過的話可以從 你真的需要 SEO 嗎 這篇開始評估。但若你是數據團隊、SaaS、或正在做內部 AI 代理，OKF 值得評估，因為它直接讓你的代理拿到正確的內部知識。
OKF 是 Google 官方標準嗎？
它是 Google 以開源方式在 GitHub（GoogleCloudPlatform/knowledge-catalog）發布的開放規格，目前版本是 v0.1 草案，明確歡迎社群貢獻與其他實作。它是「規格」而不是「產品」，任何人都可實作。但要注意它還在早期，未來可能演進，別把它當穩定不變的標準。
怎麼驗證我的 OKF bundle 是否符合規格？
照官方 SPEC 第 9 節的三條規則自我檢查：每個概念檔都要有可解析的 frontmatter、要有非空的 type、保留檔要照結構寫。我們的 OKF 產生器內建這套檢查，產出時就會標出不符合的地方，這跟 面對演算法更新 時先把可機械檢查的項目顧好是同一個道理。
想更了解 AI 搜尋時代的整體佈局，可以延伸閱讀 Google AI 搜尋、頁面體驗、能否預測 Google 更新，以及 Google 數位課程學 SEO。如果需要協助把網站的 AI 可讀性做起來，歡迎參考 Whoops SEO 服務。
