Karpathy LLM Wiki 到 Google Open Knowledge Format

如果你已經在用 Claude Code 或 Codex 指揮 Agent 幫你做事，你的專案裡大概率已經有一個 CLAUDE.md，或是一整個 Obsidian vault、一堆 index.md、log.md——你在餵給 Agent「這個專案是什麼、規則是什麼、上次決定了什麼」的上下文。

Google Cloud 剛剛把這件事，變成一份任何人都能用的公開規格。

2026 年 6 月，Google Cloud 發布 Open Knowledge Format（OKF）v0.1：一個把「LLM Wiki」這個做法標準化的開放格式。7 月，他們發布 v0.2，補上第一版沒有解決的問題——當知識不再是人手寫的，是 Agent 自己在寫、自己在更新的時候，你要怎麼知道能不能信任它。

兩篇加起來，講的其實是同一件事：Agent 是員工，員工需要一本能一直更新、又不會走鐘的工作手冊。這篇把兩篇原文拆給你看。

問題不是模型不夠聰明，是知識散得到處都是

Google Cloud 在 OKF v0.1 的文章裡先講了一個大部分團隊都有的處境：一家公司裡，AI 真正需要用到的知識——一張表格的欄位定義、一個指標「公司內部到底怎麼算」、一次事故的排除手冊、兩個系統之間怎麼串接、一支舊 API 什麼時候會被棄用——這些東西散落在後設資料目錄、Wiki、共用雲端硬碟、程式碼裡的註解、還有幾個資深工程師的腦子裡。

當 Agent 被問「我們的週活躍用戶要怎麼從事件流算出來」，它得從這些互不相容的介面裡自己東拼西湊。結果是每個做 Agent 的團隊都在重新解一次「怎麼組裝上下文」這個問題，每家目錄廠商都在重造一次同樣的資料模型，知識本身則被鎖死在最先建立它的那個系統裡。

這個模式你可能已經在做——只是沒有共同的規格

開發者社群其實已經在自己拼湊解法。Google Cloud 引用 Andrej Karpathy 的話：「LLM 不會覺得無聊，不會忘記更新交叉引用，一次可以動 15 個檔案。」人類維護個人 Wiki 時最容易放棄的那種瑣碎登記工作，正好是 LLM 最擅長的事。

於是「知識即 Wiki」這個模式不斷用不同名字重複出現：接上 Coding Agent 的 Obsidian vault、AGENTS.md / CLAUDE.md 這一整個家族的慣例檔案、Agent 動手做事之前會先讀的一堆 index.md 和 log.md、資料團隊裡「把後設資料當程式碼管」的做法。

問題是這些做法彼此長得像（markdown、frontmatter、交叉連結），卻沒有一個是刻意設計成可以互通的。沒有人規定每份文件該有哪些欄位、檔名該代表什麼——所以每個團隊的知識庫，還是只能自己人用，換一個 Agent、換一個團隊就要重寫一遍。

Google Cloud 判斷，這裡缺的不是又一個知識服務，是一個格式：任何人不用 SDK 就能生產、不用整合就能消費、能在系統和組織之間搬家、能跟著程式碼一起放進版本控制、人看得懂、Agent 也能直接解析，不需要中間的翻譯層。

OKF v0.1：一個目錄，一堆 markdown，一小撮規則

OKF 的設計刻意簡單。一個 OKF bundle 就是一個 markdown 檔案的目錄，每個檔案代表一個概念（concept）——一張表、一個資料集、一個指標、一份手冊、一支 API，什麼都可以是概念，檔案路徑本身就是這個概念的身分。

每份概念文件分成兩塊：一小段 YAML frontmatter 放結構化欄位，其餘是自由書寫的 markdown 內文。v0.1 只要求一件事——每個概念都要有 type 欄位，其餘像 title、description、resource、tags、timestamp 都是選填但建議填的欄位。概念之間用一般的 markdown 連結互相參照，整個目錄因此變成一張比檔案系統的父子關係更豐富的關係圖。

規格背後有三個設計原則：

• 最小主張：OKF 只規定一件事——每個概念要有 type。其他所有東西（有哪些類型、要放哪些欄位、內文要分幾節）都交給生產者自己決定。
• 生產者與消費者互相獨立：人手寫的 bundle 可以被 Agent 讀；資料匯出管線產生的 bundle 可以被視覺化工具瀏覽；一個 LLM 生成的 bundle 可以被另一個 LLM 查詢。格式是契約，兩端的工具各自可以替換。
• 是格式，不是平台：不綁任何雲端、資料庫、模型供應商或 Agent 框架，永遠不需要專屬帳號或 SDK 才能讀寫。

Google Cloud 同時發布了參考實作：一個會走過 BigQuery 資料集、自動幫每張表寫出 OKF 概念文件、再用第二輪 LLM 去補上引用來源與欄位定義的「enrichment agent」；一個把任何 OKF bundle 變成互動關係圖、不需要後端、資料不離開畫面的靜態 HTML 視覺化工具；還有三個現成的示範 bundle（GA4 電商資料集、Stack Overflow、Bitcoin 公開資料集），示範一份符合規格的 bundle 長什麼樣。

六週後，社群問了同一個問題：這份知識我敢信嗎？

v0.1 上線之後，開發者社群提了大量延伸提案——型別化的關係邊、Agent 路由用的欄位、可選的清除規範、.okfignore 的慣例——也開始建自己的示範 bundle、整理 OKF 生態系工具。但很多回饋指向同一個更根本的擔憂：當 Agent 開始自己往這個知識庫裡寫東西，這個知識庫還能被信任嗎？

一個人手寫的 Wiki 頁面，背後有一個隱含的保證——有人寫了它，寫錯了可以找他負責。當一個 Agent 一夜之間生出一萬個概念文件，這個保證就不存在了。要交出這份責任，消費端（往往也是另一個 Agent）就得靠明確的訊號來自己判斷，而不是靠「有人簽名」這件事。Google Cloud 把這件事拆成五個問題：

1. 這份知識是從什麼東西生成的？（provenance 出處） 2. 我該多相信它？（trust 信任） 3. 它現在還是對的嗎？（freshness 新鮮度） 4. 這是不是目前的版本？（lifecycle 生命週期） 5. 這個數字真的是照我們規定的方式算出來的嗎？（attestation 驗證）

2026 年 7 月，OKF v0.2 上線，讓這五個問題全部可以直接從 frontmatter 讀出答案——而且格式本身沒有變得更霸道：type 仍是唯一必填欄位，所有新欄位都是選填的，一個完全不採用新欄位的 bundle 跟 v0.1 時代一樣有效。差別只是，一個沒被驗證過的概念，現在可以跟一個驗證過的概念被明確分開，而且不會因為沒被驗證就被拒絕。

v0.2 加的四組欄位，各自回答一個問題

出處：只記訊號，不打分數。 新的 sources 欄位記錄一個概念的材料來源——一份外部文件、bundle 內的相對路徑，或是一段像「X 專案裡所有的查詢」這樣的範圍描述，每筆來源可以附上作者、使用次數、最後修改時間這些客觀訊號。Google Cloud 特別強調他們刻意沒加的東西：一個信任分數。分數是主觀的、換一個消費者就不成立、寫下去的那一刻就開始過期。他們選擇只記訊號，讓消費端自己判斷——就像你自然會更信任一個被大量使用、最近才更新、作者身分清楚的來源，而不是一個匿名的。內文引用來源時用一般的 markdown 註腳對應到來源的 id，出處因此是逐句的，不是文末一串沒人分辨得出來的清單。

信任：`generated` 是誰寫的，`verified` 是誰確認過。 這兩個欄位刻意分開，因為「誰寫的」跟「誰確認過」是兩件事——generated: { by, at } 記錄內容怎麼被產生、最後一次實質改動是什麼時候；verified: [{ by, at }] 是一份獨立確認的清單，可能是人簽核，可能是每晚跑的財務流程，也可能兩者都有。消費端從 verified 推出一個信任層級：沒有 verified 就是未驗證；只有機器確認過是機器已確認；有 human:<id> 確認過就是人工已審核。這些層級是建議性的訊號，不是存取控制，但足以讓消費端說出「只讓人工審核過的指標進主管儀表板」這句話，變成一條 frontmatter 篩選條件。

新鮮度與生命週期：一個絕對日期，比一個相對倒數計時更可靠。 status 讓一個概念在 draft → stable → deprecated 之間移動（沒寫就當作 stable）；stale_after 是一個絕對日期，而不是「距離讀取多久算過期」的相對 TTL——這是刻意的選擇：過不過期變成一個單純的日期比對，不需要知道這份文件是什麼時候被讀的，這正是非 LLM 的消費端最需要的那種確定性。

驗證：這個數字真的是照規定的方式算出來的嗎？ 出處回答數字從哪來，驗證（attestation）回答一個更難的問題——這個 Agent 報出來的金額，是照規定的方式算的，還是它自己臨場改了一段 SQL？v0.2 為此定義了一個新的概念類型，Attested Computation：它記錄的不只是一個值代表什麼，還有一個經過核准的計算方式，以及檢查這個計算方式真的有被執行的機制。Agent 只能填入宣告好的參數，不能自己去改動或重寫這段計算邏輯。消費端透過 executor 執行這段計算，拿回一張「收據」（包含實際跑的查詢、任務 ID、結果），再由一個確定性的、不涉及 LLM 的 attester 檢查這張收據——比對實際執行的東西是不是等於核准過的計算邏輯、顯示的值是不是真的對得上收據裡的權威來源。因為這個比對是機械式的，換掉一個表名、加一個過濾條件、刪掉一個 JOIN，都會讓驗證失敗。驗證跟簽核不是同一件事：verified 確認的是這個定義本身還符合政策（慢、屬於文件層級、存在 bundle 裡）；attestation 確認的是這一次執行有沒有正確產出值（快、屬於每次執行的層級，從不存進 bundle 裡）。一份剛簽核過的定義，還是需要每一次執行都通過驗證；一份已經過期的定義，單次執行仍然可能驗證通過——兩者各自回答不同的問題，缺一不可。

v0.2 是一次相容性升級，只有兩個欄位改名（timestamp 由 generated.at 取代，內文的 # Citations 清單由 sources 取代），舊版 bundle 消費端都能自動退回讀取舊格式，一份 v0.1 的 bundle 原封不動放進 v0.2 的世界裡照樣有效。

這件事，跟你正在做的事是同一條線

Agent 不是工具，是員工——這句話你可能聽過。OKF 補的正是「員工需要什麼」這個問題最基礎的答案：一本會一直更新、寫得清楚、還能被驗證的工作手冊，而不是一個更聰明的大腦。

你出 10%（判斷、規則、驗收標準），AI 出 90%（執行、產出、更新這本手冊），產出是 100——這是 IDAW 的核心公式。但 v0.2 提醒了一件事：當 90% 的產出全部交給 Agent 之後，你要驗收的不再是「這件事有沒有做完」，是「這份 Agent 自己寫出來的知識，我敢不敢直接拿去用」。OKF 沒有幫你做這個判斷，它只是把判斷需要的訊號——誰寫的、誰確認過、還新不新、是不是照規矩算的——攤開放在你眼前，讓判斷本身變得可能。

你今天可以抄走的一件事

不是照著 OKF 的完整規格重蓋一套知識系統。

是打開你正在用 Agent 跑的專案，找一份 Agent 常常要讀、也常常在更新的檔案（可能就是你的 CLAUDE.md，或某個 index.md），在它的開頭加三行：這份東西是誰寫的、什麼時候寫的、有沒有人確認過。

下次 Agent 要用這份資料做判斷之前，先讓它讀這三行——你會發現，光是這三行，就能讓你更快分辨出哪些內容可以直接信，哪些還需要你自己再看一眼。

想看完整規格、範例 bundle 和參考實作，原始碼與規格全部公開在 GitHub。

如果你想把「用 AI 打造一人公司」需要的完整地圖走一遍，包括怎麼組建你自己的 Agent 團隊、怎麼替它們寫出一套可信的工作系統——看 12AI學院的創業旅程。

常見問題

OKF 是要取代我現在用的 Obsidian vault 或 CLAUDE.md 嗎？

不是。OKF 形式化的正是這個模式本身——markdown、frontmatter、交叉連結。如果你已經在用類似的做法，你已經在做 OKF 想標準化的事，差別只在有沒有共同的欄位慣例。

沒有工程背景，看得懂這份規格嗎？

看得懂。整份規格就是 markdown 檔案加一小段 YAML，沒有新的執行環境、沒有必要的 SDK，任何編輯器都能開、GitHub 上就能直接讀。真正需要工程背景的，是 Attested Computation 那種要接 BigQuery、跑 SQL 驗證的進階用法，一般知識文件不需要用到。

`verified` 跟 attestation 有什麼不一樣？

verified 確認的是「這份定義本身還符合規則」，慢、是文件層級的簽核；attestation 確認的是「這一次執行真的照規則跑出這個結果」，快、是每次執行都要重新檢查的層級。一份簽核過的定義還是需要每次都通過驗證，兩者缺一不可。

Agent 自己寫的知識庫，為什麼不能直接信？

因為人手寫的 Wiki 背後有一個隱含保證——寫錯了，你知道該找誰負責。Agent 一夜生出一萬個文件時，這個保證消失了。OKF v0.2 的做法不是禁止 Agent 寫，是把「誰寫的、誰確認過、還新不新」變成可以直接讀出來的訊號，讓你或下一個 Agent 決定要不要信。

v0.1 已經用起來的 bundle，換 v0.2 需要重寫嗎？

不需要。v0.2 是向下相容的加法升級，只有兩個欄位改名（都有自動退回機制），一份 v0.1 的 bundle 原封不動放進來就有效，你可以照自己的節奏決定要不要開始加新欄位。