OKF（Open Knowledge Format）是 Google Cloud 於 2026 年 6 月推出的開放規格，用 Markdown 檔案把企業內部知識整理成 AI Agent 能直接讀取的通用結構。它常被誤當成網站 SEO 標準，實則是在解 AI Agent 落地最關鍵的「知識供給」問題。
OKF（Open Knowledge Format）是 Google Cloud 於 2026 年 6 月 12 日發布的開放規格，核心很單純：用 Markdown 檔案搭配 YAML frontmatter，把企業內部知識整理成 AI Agent 能直接讀取、又能在不同工具之間通用的結構 [1]。
它要解的痛，很多企業並不陌生：花三個月導入 AI Agent，demo 當下對答如流，一上線面對真實業務卻開始答非所問、引用早就過期的資料，甚至把兩個部門對同一個指標的定義搞混。問題通常不在模型不夠聰明，而在它根本讀不到、或讀錯了你公司的知識。
如果你最近在追 llms.txt、AEO 或 GEO，可能看過有人把 OKF 說成「AI Agent 時代的網站新標準」——這其實是個誤會。發布它的是 Google Cloud 的資料分析團隊，不是 Google 搜尋；它要處理的是公司內部散落各處的知識，而不是你對外的行銷網頁。而它瞄準的這個痛點，正是多數 AI Agent 專案真正卡關的地方。
![一個 OKF bundle 就是一個資料夾，裡面每個「概念」——一張資料表、一個指標、一份 runbook、一支 API——各對應一個 Markdown 檔，檔案路徑就是它的身分 [1]。每個檔案最上面一小段 YAML 放結構化欄位（type、title、description、timestamp 等），下面用一般 Markdown 寫內容；概念之間再用普通的 Markdown 連結互指，整個資料夾就變成一張 AI 可以沿著走的知識圖譜 [1]。重點是它刻意做得很輕：不需要 SDK、不需要新的執行環境，就是純檔案——GitHub 打得開、可打包成 tarball、掛在任何檔案系統上 [1]。](https://cdn.prod.website-files.com/680c85b827b16308a50aedc1/6a3a06cb010fbda311202317_3.png)
一個 OKF bundle 就是一個資料夾，裡面每個「概念」——一張資料表、一個指標、一份 runbook、一支 API——各對應一個 Markdown 檔，檔案路徑就是它的身分 [1]。每個檔案最上面一小段 YAML 放結構化欄位（type、title、description、timestamp 等），下面用一般 Markdown 寫內容；概念之間再用普通的 Markdown 連結互指，整個資料夾就變成一張 AI 可以沿著走的知識圖譜 [1]。重點是它刻意做得很輕：不需要 SDK、不需要新的執行環境，就是純檔案——GitHub 打得開、可打包成 tarball、掛在任何檔案系統上 [1]。
這是最容易被搞混的地方。llms.txt 處理的是「對外的網站內容怎麼讓 AI 看懂」，OKF 處理的是「對內的企業知識怎麼餵給 AI Agent」——一個朝外、一個朝內，目標讀者和使用場景完全不同。發布 OKF 的是 Google Cloud 的資料分析團隊，與 Google 搜尋的排名機制無關，也不會改變 Googlebot 怎麼爬你的官網 [1]。所以你在做的 AEO／GEO，OKF 不是要追的那條線；但它點出的那個瓶頸，跟你想用 AI 處理客戶與內部知識的目標，其實高度相關。
OKF 也常被拿來和 MCP 混淆，但兩者是互補而非取代：MCP 管的是 Agent 怎麼存取工具與資料，OKF 管的是那份知識本身長什麼樣子——一個是插座，一個是流過插座的內容；MCP server 甚至能直接把 OKF bundle 當成知識來源對外提供 [5]。
AI Agent 落地真正卡關的，多半不是模型不夠強，而是企業沒把內部知識整理成 AI 讀得懂、又能持續更新的狀態——知識供給沒到位，Agent 一上線就會答錯、引用過期資料。
先看規模。Gartner 預測，超過 40% 的代理型 AI 專案會在 2027 年底前被取消，官方歸因是成本攀升、商業價值不明確、風險控管不足 [2]。但把鏡頭拉近到「為什麼一上線就垮」，會發現一個反覆出現的劇本：demo 當下餵的是一份乾淨的小樣本，真實企業的資料卻是散落、彼此矛盾、而且早就過期的。
台灣的數據也指向同一件事。根據台灣人工智慧產業基金會《2025 產業 AI 化大調查》，真正具備可用資料的企業僅約 5% 到 10%，多數仍卡在資料整備與邏輯釐清的早期階段 [3]。這道 demo 與 production 之間的鴻溝，技術上常被歸到 上下文工程 的範疇——而 OKF 想處理的，正是這條鴻溝最上游的那一段：知識本身有沒有被整理好。
企業真正要餵給 Agent 的知識，絕大多數是內部的：一張資料表的 schema、一個指標在你公司裡的精確定義、一份事故的 runbook、兩個系統之間怎麼 join、某支舊 API 為什麼不能再用 [1]。這些知識的麻煩之處在於——它們散落在各自獨立的 metadata catalog、wiki、程式碼註解裡，甚至只存在幾個資深工程師的腦袋裡 [1]。
台灣現場的痛點也是這個。資策會 MIC 調查指出，已導入 AI 的製造業者高達 8 成面臨數據挑戰，最棘手的正是「缺乏數據」與「難以理解數據之間的關聯」[4]。後面那一句特別關鍵：它要的往往不是更多資料，而是「資料與資料之間的關係」沒有被描述出來——而這正是 OKF 補的那一塊。
就算有了 OKF 這種格式，企業自己整理知識時仍會卡在三關：盤點不出「正確版本」、把隱性知識翻成結構、以及讓知識持續更新不過期——而這三關，工具其實都只解了一半。
多數人以為盤點就是把散落的文件集合起來，真正的第一關往往是「同一件事有好幾個版本」。光是「活躍用戶」這個指標，業務、數據、財務三個部門可能各有一套算法；你問五個人，會得到五個答案。再加上知識常藏在離職員工的 Excel、三年前的會議記錄、某個只有一個人看得懂的討論串裡——盤點真正花時間的，是先讓大家對「哪個定義才是對的」達成共識。OKF 給得了檔案結構，給不了這個共識。
第二關是翻譯。工程師腦中那套 join 邏輯、踩過的坑、為什麼某個欄位不能直接拿來用——這些隱性知識，要被重新寫成 AI 讀得懂的明確結構（類型、描述、彼此的關聯），而不是把舊文件複製貼上。OKF 規定了「格式長怎樣」，但「裡面填什麼、關係怎麼連」仍然是人的判斷。這一關最容易被低估工作量，也是 導入 AI Agent 前常被忽略的風險 之一。
第三關最常被忽略：知識會過期。schema 改了、指標定義變了、某個流程下線了——只要沒有人負責更新，知識庫三個月後就會開始說謊，而 Agent 會跟著一起說謊。Google 自己也把 OKF 定位成「像管理程式碼一樣維護」的活 wiki [1]。值得一提的是，OKF 其實是把 Andrej Karpathy 在 2026 年 4 月提出的「LLM Wiki」概念正式格式化 [6]，Karpathy 認為更新交叉引用、一次改十幾個檔案這類維護瑣事，正好是 LLM 不會累、不會漏的強項 [1]。但這只解決了維護的「手腳」——哪一份才算對的、多久更新一次、誰負責拍板，仍然是人與流程的判斷，不是換個格式、或把活丟給 LLM，就會自己消失。
重點先講：OKF 給得了「知識長怎樣」，給不了共識、翻譯與維護——這三關需要人。
前面三個現實困難其實有明確先後：先盤點、再翻譯、最後建維護機制。這正是顧問陪跑在 AI Agent 導入裡的位置——AltaBots.ai 的做法，是從這三關切進去陪企業逐關解決，而不是丟一套工具讓你自己摸索：在盤點關，陪你把跨部門打架的定義收斂成一個大家認帳的版本；在翻譯關，把資深員工腦中的邏輯整理成 Agent 讀得懂的結構；在維護關，建立更新的權責與節奏，不讓知識悄悄過期。
所以 AI Agent 導入的成敗，常常不在你選了哪套平台，而在有沒有人陪你把知識這關走完——這也是 挑選 AI Agent 顧問時該檢核的交付實務 的核心。OKF 這類格式會讓知識交付更標準化，對 AltaBots.ai 這種從決策端就陪企業整理知識的做法是順風；但真正讓 Agent 在你公司答得準的，始終是把知識吵清楚、翻好、養住的那段功夫。
OKF 還只是 v0.1 草案，但你不必等它定案。早一步反而有個好處，邏輯跟十年前上 schema 標記一樣：成本低、能讓你的知識被開始回答問題的 AI 讀懂，而早做的人會在它變重要之前先學會這套格式 [7]。下面三個低成本動作，能把 AI Agent 落地最關鍵的「知識這關」先補起來，而且不論未來要不要轉成 OKF 格式都用得上。
第一，選一個場景，不要一次盤全公司。 挑一個高頻、又最讓人頭痛的任務（例如某類客戶問題的回覆、某份每週都要產的報告），只盤這個場景需要的知識。範圍小，才吵得完、也才看得到成效。可以直接用 30 天概念驗證的節奏 來框這一輪，先證明一個場景，再擴散。
第二，把「資料之間的關係」寫下來，而不只是收集文件。 哪怕還沒用 OKF，先用 Markdown 或一份共用文件，把關鍵指標的定義、資料來源、彼此怎麼關聯描述清楚。這一步等於提前做好 OKF 要的內容，未來要轉格式幾乎是免費的。
第三，先定維護權責，再談工具。 指定誰負責更新這份知識、多久更新一次、怎麼確認沒漏掉。沒有這層，再漂亮的知識庫，沒人維護很快就會給出過期答案。
先動起來，比先求完整更重要；範圍可以小，但這三關的順序不要跳。
OKF 的出現，與其說是多了一個要追的新標準，不如說它幫所有想用 AI Agent 的企業，把焦點從「選哪套工具」拉回到「知識到底整理好了沒」這個真正的瓶頸上。
Google 推不推得動 OKF 變成業界共識，還要看接下來幾季有沒有其他廠商跟進。但無論標準最後長什麼樣子，把跨部門打架的指標定義吵出共識、把資深員工的隱性知識寫成結構、把更新權責建立起來——這三件事都不會白做，它們本來就是讓 AI Agent 在你公司真的答得準的前提。
如果你正在評估 AI Agent，卻不確定自己卡在盤點、翻譯，還是維護哪一關，AltaBots.ai 提供免費的 AI 落地診斷：先幫你定位現況、找出第一步該做什麼，再決定要不要往下走。難的從來不是工具，是有沒有人陪你把知識這關走完。
[1] Google Cloud.（2026）。How the Open Knowledge Format can improve data sharing. Google Cloud Blog.
https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/
[2] Gartner.（2025）。Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027. Gartner Newsroom.
https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
[3] 台灣人工智慧產業基金會（AIF）.（2025）。2025 台灣產業 AI 化大調查暨 AI 落地指引. AIF.
https://aif.tw/event/ai-research/
[4] 經理人（引述資策會 MIC 調查）.（2025）。導入 AI，8 成電子製造業這一點最痛. 經理人月刊.
https://www.managertoday.com.tw/articles/view/70116
[5] innFactory.（2026）。Open Knowledge Format (OKF): The Open Standard That Frees Your AI Knowledge From Silos. innFactory AI Consulting.
https://innfactory.ai/en/blog/open-knowledge-format-okf-standard-for-ai-knowledge/
[6] MarkTechPost.（2026）。Google Cloud Introduces Open Knowledge Format (OKF): A Vendor-Neutral Markdown Spec for Giving AI Agents Curated Context. MarkTechPost.
https://www.marktechpost.com/2026/06/16/google-cloud-introduces-open-knowledge-format-okf-a-vendor-neutral-markdown-spec-for-giving-ai-agents-curated-context/
[7] WitsCode.（2026）。The Open Knowledge Format (OKF), explained. WitsCode.
https://witscode.com/open-knowledge-format
