使用 Google Open Knowledge Format 來讓你的 Agent 更懂你，完成更高品質的工作

你把方法寫成一套 SOP，交給 Agent 去執行、去回答學員問題。

一開始很順。

但半年後，Agent 累積出幾百份自己生成的補充教材、自己寫的常見問答，你已經記不清楚哪些是你確認過的，哪些是它自己延伸出來、你從沒看過的。

這不是系統化失敗了。是系統化到了一個新的階段——你交出去的不只是執行，是知識本身在被 Agent 持續改寫。而你原本沒有一套方法，去分辨哪些改寫可以信。

Google Cloud 剛好在處理同一個問題，只是場景換成企業的資料團隊。2026 年 6 月，他們發布 Open Knowledge Format（OKF）v0.1，把「用 markdown 建一個 Agent 讀得懂的知識庫」這件事定成一份公開規格。7 月，他們發布 v0.2，補上第一版沒解決的事：當知識是 Agent 自己在寫的時候，你怎麼知道能不能信。

知識散在各處，Agent 每次都得重新拼湊

Google Cloud 在 v0.1 的文章裡描述的處境，換到教學現場一樣成立：一個表格的欄位定義、一個指標的算法、一份事故排除手冊——放在企業裡是這些東西；放在你身上，就是你的教學框架、你判斷學員問題的標準、你上次為什麼決定改掉某個做法。這些東西通常分散在不同的筆記、不同的對話紀錄、你自己的腦子裡。

Agent 要回答一個學員的問題時，得從這些互不相通的地方自己拼湊答案。結果是——每個團隊都在重新解一次「怎麼把知識組裝給 Agent」這個問題，沒有一套共同的規則。

Google Cloud 判斷，這裡缺的不是又一個知識管理工具，是一個格式：任何人不用學新工具就能寫、任何 Agent 不用額外整合就能讀、能跟著你的方法一起被版本控管、人看得懂、Agent 也能直接解析。

OKF v0.1：把方法拆成一份份可被引用的文件

OKF 的做法很直接。一個知識庫就是一個 markdown 檔案的目錄，每個檔案代表一個概念——一個定義、一份流程、一個判斷標準，都可以獨立成一份檔案。

每份文件分兩塊：開頭一小段結構化欄位（只要求一個 type，其他像標題、說明、資源連結、標籤都是選填），下面是自由書寫的正文。文件之間用一般的連結互相引用，整個目錄因此變成一張你的知識彼此怎麼串接的關係圖。

背後有三個原則：格式盡量不做主張（只規定要有 type，其他交給你自己決定）；誰寫的跟誰用的互相獨立（你手寫的文件 Agent 能讀，Agent 生成的文件你能檢查）；是格式不是平台（不綁定任何特定工具，你今天用哪套系統都能套用）。

Google Cloud 同時放出參考實作：一個會自動幫資料表寫出這種文件、再補上引用來源的產生工具；一個把整個知識庫變成可互動關係圖的檢視器；還有幾個示範知識庫，讓人看得到規格套用出來的實際樣子。

六週後，開發者社群問了同一個問題：這些知識能信嗎

OKF v0.1 上線之後，開發者社群提出大量延伸提案，但很多回饋指向同一個更根本的擔憂：當 Agent 開始自己往知識庫裡寫東西，這個知識庫還能被信任嗎？

Google Cloud 講得很直接：一份人手寫的文件背後有一個隱含保證——有人寫了它，寫錯了可以找他負責。當 Agent 一夜之間生出大量文件，這個保證就不存在了。要交出這份責任，你（或下一個要用這份知識的 Agent）就得靠明確的訊號自己判斷，而不是靠「有人簽名」這件事。他們把這件事拆成五個問題：這份東西是從什麼生成的、我該多相信它、它現在還是對的嗎、這是不是最新版、這個結果真的是照規定的方式算出來的嗎。

7 月，OKF v0.2 上線，讓這五個問題全部可以直接從文件開頭讀出答案——而且沒有變得更複雜：原本沒用新欄位的舊文件，照樣完全有效，只是現在「沒被確認過」跟「確認過」可以被明確分開，而不是全部混在一起。

v0.2 補的四件事，正好對應你系統化教學方法時會遇到的四個關卡

這份東西是從哪來的。 新增的欄位記錄一份知識的材料來源——是哪次諮詢整理出來的、參考了哪份原始文件、作者是誰、最近一次更新是什麼時候。Google Cloud 刻意不加的是一個「信任分數」——分數是主觀的，換一個人看標準就不一樣，寫下去馬上就過期。他們選擇只記錄客觀訊號，讓看的人自己判斷，就像你自然會更信任一份最近更新過、來源清楚的資料，勝過一份不知道誰寫的。

誰生成的，跟誰確認過，是兩件不同的事。 一個欄位記錄這份內容是怎麼被產生的、什麼時候改的；另一個欄位記錄有沒有人確認過它——可能是你本人簽核過，也可能只有系統自己跑過一輪，還沒有人看過。從這裡可以分出等級：完全沒人確認過的，是未驗證；只有機器確認過的，是機器已確認；你本人確認過的，才是人工已審核。這讓你可以直接規定——「只有我親自確認過的內容，才能拿去回答學員的重要問題。」

新鮮度用絕對日期，不是「讀取後幾天內有效」。 每份文件可以標一個過期日，過了這天就代表需要重新確認，而不是含糊的「這份內容還新嗎」。這讓判斷變成一件簡單的日期比對，不用去猜這份東西是什麼時候被讀的。

驗證回答一個更難的問題：這個結果，真的是照你教的方法算出來的嗎？ 出處回答資料從哪來，驗證回答的是——Agent 給學員的這個建議、這個結論，是不是真的照你設定的判斷標準跑出來的，還是它自己臨場改了做法。v0.2 為此定義一種新的文件類型：記錄一套核准過的計算方式，加上一個機制去檢查這套方式有沒有真的被照著執行。Agent 只能在你允許的範圍內填入參數，不能自己改動這套方法本身。任何一次偷改，都會在檢查時被抓出來。

v0.2 是向下相容的加法升級，只有兩個欄位改名（都有自動退回機制），舊文件原封不動放進來就有效。

你的方法，是 Agent 給不了你的那一半

Agent 可以幫你執行大量重複工作，但你的方法、你的框架、你的判斷標準，是 AI 給不了你的部分——這句話你可能已經聽過。OKF 補的正是「怎麼讓 Agent 忠實執行你的判斷標準，而不是自己延伸出一套」這個問題最基礎的答案。

真正的規模化，來自改變結構，不是提高個人產出。系統沒有體力限制，系統在你休息的時候繼續跑——但系統跑出來的東西，你要怎麼知道還是你教的那一套，不是它自己延伸出來的版本？這正是 OKF v0.2 在補的那個洞：不是不讓系統跑，是讓系統跑出來的每一份東西，都留下「這是誰寫的、誰確認過、還新不新」的紀錄，讓你或學員能一眼分辨。

你今天可以抄走的一件事

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

是打開你現在用來教 Agent 回答學員問題的那份文件，在最上面加三行：這是你什麼時候寫的、有沒有被你確認過、還是不是最新版本。

下次 Agent 要用這份資料回答學員之前，先讓它讀這三行。你會發現，光是這三行，就能讓你更快分辨出哪些答案可以直接放行，哪些還需要你親自看一眼。

想看完整規格與範例，原始碼全部公開在 GitHub。

如果你想把「把方法系統化、交給 Agent 規模化執行」這條路完整走一遍——看 aicoach.tw 的課程。

常見問題

這跟我現在用的筆記軟體或 Prompt 檔案有什麼不一樣？

沒有本質上的不一樣。OKF 形式化的正是這個做法本身——結構化的文件加上 Agent 讀得懂的格式。如果你已經在用類似的方式管理教材，你已經在做 OKF 想標準化的事，差別只在有沒有共同的欄位慣例，方便之後串接更多工具。

沒有技術背景，看得懂這份規格嗎？

看得懂。整份規格就是一般的文字檔案加一小段結構化欄位，不需要新的軟體、不需要學程式。真正需要技術背景的，是進階的自動驗證機制，一般的教材文件不需要用到那一層。

Agent 自己生成的教材，為什麼不能直接信？

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

確認過一次，是不是就一勞永逸？

不是。確認的是「這份定義本身還符合你的標準」，是慢的、文件層級的動作；每一次 Agent 實際拿去用，仍然需要重新檢查這次執行有沒有照著跑。一份你確認過的方法，還是需要每次執行都通過檢查，兩者缺一不可。

已經在用的教材系統，需要整套重寫嗎？

不需要。這是向下相容的做法，你可以先從最常被 Agent 引用的那幾份文件開始，補上「誰寫的、誰確認過」這三行，其他維持原樣，之後再照自己的節奏慢慢補齊。