如果你聽到 OKF 的第一反應是「又一個工程規格」，可以先把它當成一套公司知識整理法。當 AI 代理要回答「退款規則怎麼判斷？」「這個數字怎麼算？」「這份 SOP 哪一版才是最新？」它需要一份可靠、可更新、能追到來源的知識。
OKF（Open Knowledge Format）的做法，是把一組相關知識整理成一個資料夾。資料夾裡每份知識都用 Markdown 寫成檔案，檔案開頭再放一小段 YAML 欄位，標明這份知識的類型、標題、來源、標籤與更新時間。人可以直接讀，AI 代理也能用這些欄位判斷該讀哪一份、能不能引用、是否已經過期。
這篇先給產品、內容、客服、營運、資料與工程主管看。你不需要先會寫程式；先判斷 OKF 跟你現在遇到的知識混亂有沒有關係，再決定要不要請工程或資料團隊評估實作。
本文依據 Google Cloud 官方公告、OKF 0.1 版規格、GitHub README 與 commit 紀錄整理。Google Cloud 的參考工具尚未在本站實測，因此本文把 OKF 當成新草案與導入方向來評估，不把它寫成已驗證的正式標準。
OKF 是什麼？用四個概念看懂
一句話：OKF 是「一個知識包＋多份知識檔＋檔頭欄位＋正文」。
| OKF 概念 | 用白話說 | 常見例子 |
|---|---|---|
| 知識包（knowledge bundle） | 一整包相關知識，通常是一個資料夾或 repo | 客服政策知識包、產品規則知識包、資料指標知識包 |
| 知識檔（concept document） | 描述一個主題的 Markdown 檔 | 退款規則、週活躍使用者定義、訂閱方案限制 |
| 檔頭欄位（YAML frontmatter） | 檔案最前面的小型資料卡 | 類型、標題、來源、標籤、最後更新時間 |
| 正文（Markdown body） | 人類直接閱讀的說明 | 定義、範例、限制、判斷步驟、引用來源 |
這裡的「知識」範圍比工程文件更廣。只要是代理需要穩定引用、不能亂猜的內容，都可以放進這種整理方式裡，例如：
- 客服退款與升級規則。
- 產品功能限制與適用對象。
- 行銷活動的品牌用語與禁用語。
- 內容審稿標準與更新週期。
- 公司內部 SOP。
- 營收、留存、活躍使用者等指標定義。
- 資料表、程式介面（API）與系統限制。
- 事故處理紀錄與應變流程。
代理讀到 OKF 知識檔時，除了段落文字，也會取得知識類型、來源、最後確認時間，以及可連結的相關知識。
OKF 想解決什麼問題？
很多公司的痛點在於：知識存在，但太分散。規則在雲端文件，最新說法在 Slack，表格定義在資料工具，例外狀況在客服主管腦中，真正的限制又寫在工程文件裡。
人類還可以靠經驗判斷哪份比較新。代理比較麻煩：它可能抓到舊文件、引用錯來源，或把兩套互相矛盾的規則混在一起。最後看起來像模型亂回答，其實問題常出在「公司沒有一份可被信任的知識來源」。
OKF 的思路是先把可分享的知識變成普通檔案。普通檔案有幾個好處：
| 團隊需要的能力 | OKF 的做法 | 實際價值 |
|---|---|---|
| 人能讀懂 | 用 Markdown 寫正文 | 產品、客服、營運與工程能共同維護 |
| 代理能篩選 | 用檔頭欄位標明類型與來源 | 先挑對知識，再讀細節 |
| 能追版本 | 放進 Git 或文件系統 | 更新可審查、可回溯、可找責任人 |
| 能搬移 | 不綁單一知識庫服務 | 換工具時知識比較不會被鎖死 |
| 能互相連結 | 用一般文件連結串概念 | 指標、規則、流程和來源可以形成知識網 |
換句話說，OKF 不等於新的聊天機器人。它比較像把「代理要讀的公司知識」整理成一套人類也能維護的格式。
跟 llms.txt、RAG、MCP 差在哪？
這幾個名詞常被放在一起講，但處理的層次不同。你可以先這樣分：
| 名稱 | 白話理解 | 跟 OKF 的關係 |
|---|---|---|
| OKF | 知識本身怎麼整理 | 把客服規則、產品限制、指標定義整理成知識包 |
| llms.txt | 告訴 AI 這個網站有哪些重要頁面 | 可以把 OKF 入口或文件站列進索引 |
| RAG | 從知識庫找片段，再交給模型回答 | OKF 可以成為比較乾淨、可維護的資料來源 |
| MCP | 讓代理連接工具與服務 | 工具可以讀 OKF，或把 OKF 裡的知識提供給代理查詢 |
| NLWeb / WebMCP | 讓網站或瀏覽器提供代理可調用的能力 | 更偏網站查詢與操作；OKF 偏知識內容整理 |
如果你是內容或營運負責人，先不用背這些英文縮寫。重點只有一句：OKF 管的是「知識本身要長什麼樣」，其他技術多半在處理「代理要怎麼找到知識、怎麼使用工具」。
如果你想把 OKF 放進更完整的代理網站脈絡，可以接著看本站的 MCP 開發指南；如果你的任務偏向文件站與 AI 可讀內容，則可搭配 GitBook AI 文件、llms.txt 與 MCP 指南 一起評估。
非工程團隊可以怎麼用 OKF？
OKF 最容易被誤會成資料工程規格，但它的價值也延伸到客服、內容、產品與營運知識。以下幾種情境更接近一般團隊會遇到的問題：
| 角色或團隊 | 可以先整理的知識 | 為什麼值得 |
|---|---|---|
| 客服主管 | 退款規則、升級流程、補償條件 | 客服機器人回答時比較不會引用舊政策 |
| 內容團隊 | 品牌語氣、禁用詞、審稿標準、更新週期 | 寫作或審稿工具可以依同一份規則判斷 |
| 產品團隊 | 功能限制、方案差異、適用/不適用客群 | 業務、客服與文件不會各說各話 |
| 營運團隊 | 活動規則、例外處理、跨部門責任 | 遇到客訴或異常時可追到最新版本 |
| 資料團隊 | 指標定義、資料來源、計算方式 | AI 產報表或 SQL 時比較能引用同一份定義 |
| 工程團隊 | 程式介面、服務責任、權限與風險 | 代理執行任務前能先讀限制 |
一個非工程試點可以從「退款政策」開始，不必一開始就整理全公司知識庫。你可以先建立三份知識檔：
客服知識包/
├── 退款規則.md
├── 補償條件.md
└── 升級人工處理.md每份檔案至少寫清楚：這份規則適用誰、權威來源在哪裡、最後誰確認、多久要重看一次、代理可以直接回答哪些情境、哪些情境必須轉人工。
這樣做完後，就算還沒有完整代理，也能先改善文件治理。等到要接客服機器人、內部搜尋或自動審稿工具時，代理讀到的是一包有來源、有責任人、有更新節奏的知識，而非散落在各處的舊文件。
如果你是資料團隊：再看指標知識包
資料團隊可以從「週活躍使用者」這種常被問、也常被算錯的指標開始。先建立一份指標知識檔，寫清楚權威資料表、計算公式、排除條件、資料負責人、最後確認日期與可引用來源；再補上資料延遲處理方式與常見例外。
這個試點的成功標準看三件事：新人能看懂指標變更，分析師能追到權威來源，代理在產生報告或查詢語句時會引用同一份定義。若連這個小知識包都維護不起來，就先不要擴到客服、合規或跨部門知識庫。
如果團隊已在 Google Cloud 上做代理，OKF 也可以和 Google ADK、Vertex AI Agent Engine 這類架構互補：代理平台負責執行任務，OKF 負責整理代理要讀的知識脈絡。
現在該不該導入 OKF？
建議用團隊狀態判斷：
| 團隊狀態 | 建議 |
|---|---|
| 只是一般內容網站或部落格 | 不必急著導入 OKF。先顧好內容品質、結構化資料、FAQ 與 llms.txt。 |
| 正在用生成式工具寫文件或做內部問答 | 可以先借用 OKF 的精神：重要知識用文件寫清楚，補上來源、責任人與更新日期。 |
| 已有客服機器人、內部搜尋或 RAG | 值得挑一個高價值知識區域試做，降低舊文件與 PDF 造成的混亂。 |
| 正在做代理或跨工具自動化 | 值得正式評估 OKF，並同步設計權限、審查與更新流程。 |
對 SEO 或內容網站來說，OKF 目前不屬於搜尋排名因素。它比較像 AI 時代的知識治理工具：你的內容能不能被人與代理正確理解、引用、更新，才是核心。
實作時要注意的限制
OKF 現階段仍是 0.1 版草案，距離成熟標準還有距離。導入前要先接受幾個限制。
１．格式不會自動救內容品質
文件格式再漂亮，如果內容過時、定義互相矛盾、沒有負責人，代理還是會讀到錯誤脈絡。OKF 最有價值的地方是讓知識可以審查、比對、引用與追蹤；它不能替你決定哪個說法才是公司真相。
２．欄位太自由會失控
官方規格刻意保持彈性，目前只強制每份知識檔要有 type。這讓格式容易採用，但企業內部最好仍訂一份自己的欄位慣例。
建議至少統一：
- 知識類型。
- 負責人。
- 權威來源。
- 檢查週期。
- 保密等級。
- 代理可使用範圍。
- 是否已停用。
３．權限需要另外設計
OKF 知識包可以很容易被複製、索引與交給代理讀。這是優點，也是風險。涉及個資、營業秘密、客戶資料、內部事故、合約條款時，要把 OKF 放進既有權限與審計流程，避免把整包敏感知識直接交給模型。
４．不要把 OKF 當成唯一資料層
OKF 適合描述脈絡與知識，不適合取代資料庫、功能規格、程式介面文件或正式資料目錄。比較健康的做法，是讓 OKF 引用這些權威系統，並把「人與代理真正需要理解的上下文」寫清楚。
最新時間線：官方 repo 已經有後續修正
時間軸要看官方公告，也要看 GitHub repo。
| 時間 | 事件 | 編輯判斷 |
|---|---|---|
| 2026-06-12 | GoogleCloudPlatform/knowledge-catalog repo 匯入 OKF 參考工具 | OKF 已有規格、README、範例知識包與參考工具，超過單篇 blog 概念介紹 |
| 2026-06-13 | Google Cloud Blog 顯示「Introducing the Open Knowledge Format」發布 | 一手公告，定位為可攜、人類與代理都能讀的知識格式 |
| 2026-06-13 | GitHub repo 修正 OKF 內部連結，改用相對路徑 | 實作細節仍在調整；寫工具時要看最新規格與 repo，單看新聞轉述不夠 |
這個後續修正很有意思：它把概念之間的連結改成一般 Markdown 在 GitHub 裡也能正常瀏覽的寫法。這代表 OKF 很重視「普通文件在普通工具裡也要可讀」，服務對象不侷限於某個特定平台。
給繁中團隊的採用建議
OKF 短期內不會變成每家公司必用的標準，也不保證會被所有雲端或 AI 平台採納。
但它抓到一個真正的問題：企業代理要可靠，不能只靠更大的模型或更長的上下文。代理需要的是可維護、可驗證、可追溯的知識供應鏈。
如果你的問題是「代理不知道公司規則」，OKF 可能比換模型更值得研究；如果你的問題是「使用者需求還沒驗證」，OKF 的優先級很低。
FAQ
OKF 是 Google Cloud 專用格式嗎？
Google Cloud 官方把 OKF 定位為可攜的開放知識格式；規格本身是 Markdown 檔案加 YAML 欄位，不需要 Google Cloud 帳號或特定 SDK 才能讀。不過 Google Cloud 同時提供 Knowledge Catalog 與 BigQuery 相關參考工具，Google 生態的整合會比較早出現。
非工程師需要懂 OKF 嗎？
需要懂概念，不一定要懂實作。產品、客服、營運、內容與資料主管真正要判斷的是：公司是否有一批常被 AI 引用、常被問、又容易過期或互相矛盾的知識。如果有，就值得請工程或資料團隊評估 OKF 類似的整理方式。
OKF 可以取代 RAG 嗎？
不建議這樣看。RAG 是「怎麼從知識庫找資料再回答」的做法，OKF 是「知識本身要怎麼整理」的格式。OKF 可以讓 RAG 的來源更乾淨、更可維護，但仍然需要檢索、權限控管、提示設計與評估。
小公司需要現在導入 OKF 嗎？
如果只是一般內部文件，不必為了追新規格而改造。更好的做法是先用 OKF 的精神：重要知識用 Markdown 或文件寫清楚，加上來源、負責人、更新日期與適用範圍。等 AI 工作流真的需要，再補更完整的知識包規範。
OKF 和 llms.txt 最大差別是什麼？
llms.txt 比較像網站給 AI 的索引入口，告訴 AI 哪些頁面重要；OKF 則是把一組知識整理成可攜、可維護的知識包。簡化說：llms.txt 告訴 AI 去哪裡看，OKF 定義 AI 看到的知識包長什麼樣。
OKF 對 SEO 或內容網站有用嗎？
短期 SEO 影響有限，因為 OKF 主要面向企業知識與代理脈絡，目前不屬於搜尋排名因素。但對文件站、教學站與產品知識庫來說，OKF 的思路可以幫助內容變得更容易被代理正確引用。這和 GitBook AI 文件、llms.txt 與 MCP 的方向一致：內容要讓人看得懂，也要讓 AI 能正確引用。
參考來源
- Google Cloud Blog：Introducing the Open Knowledge Format
- GoogleCloudPlatform/knowledge-catalog：OKF README
- GoogleCloudPlatform/knowledge-catalog：Open Knowledge Format v0.1 specification
- GitHub commit：Fix OKF cross-links to use file-relative paths
- Google Cloud Blog：Introducing the Google Cloud Knowledge Catalog