Google OKF v0.2 加入來源追蹤同 SQL 核驗，企業仍要自行設定把關流程

AI agent 識搵文件，唔代表搵啱文件

Google 喺 6 月公開 Open Knowledge Format，約一個半月後已經推到 v0.2。iThome 報道，新版集中補返企業知識庫最棘手嗰截：當文件由 AI agent 大量產生，再交畀另一批 agent 使用，系統點分得出內容源頭、邊個確認過、仲有冇效，同埋個數究竟點計出嚟。OKF 用 Markdown 加 YAML frontmatter 保存呢啲資料，可以跟程式碼一樣放入 Git 管理，唔使綁死某個模型、資料庫或者雲端平台。

圖片：Google Cloud

四組欄位，處理四種唔同風險

講個實例：公司知識庫同時放住兩份「年度營收」定義，一份跟舊會計政策，另一份先係而家採用嗰套。sources 記低內容參考過邊份政策、由邊個部門提供同幾時更新，交代 provenance（來源脈絡）；generated 留低作者或者產生內容嘅 agent，verified 就另行記錄人工或自動程序幾時核對過。使用端可以只畀人手確認過嘅指標入管理層報表，測試環境就接受機器核對版本。

status 可以將舊定義標成 deprecated，保留畀歷史查詢重現結果，同時唔再派畀新任務。stale_after 則係一個實際日期，到期後由使用端警告或者拒絕採用。呢個設計幾貼地，因為文件冇改過，都可能因為政策、資料表結構或者業務口徑轉咗而過期。不過有個位好易睇漏：呢啲欄位全部係選用，連 status 冇寫時都會當成 stable，半桶水採用反而可能令舊文件繼續扮正常。

鎖住核准計法，agent 只可以填參數

v0.2 最有意思嘅新增功能係 Attested Computation。團隊可以保存一段核准 SQL，列明 agent 只准填年份、地區呢類有型別嘅參數。執行器跑完查詢後，要交回 job_id、實際執行過嘅 SQL 同結果等 receipt，再由冇用 LLM 嘅 attester 做機械式核對。agent 如果自行轉表、刪走 JOIN、加條件，或者展示嘅數字同查詢結果唔一致，核驗就應該失敗。

呢度要分清兩層：verified 確認文件入面嗰套定義仲符合公司政策，屬於文件層級記錄；attestation 就逐次檢查今次計算有冇照核准方法跑，結果唔會寫返入知識庫。一份過期定義仍然可以順利通過執行核驗，因為程式確實照住舊 SQL 跑；一份啱啱由財務確認過嘅定義，每次執行亦照樣要核驗。兩邊缺一，個數都未夠穩陣。

OKF 可以同 RAG、MCP 一齊用

OKF 處理知識點樣包裝同標示，RAG 負責由知識庫搵出相關內容，MCP 就幫 agent 接駁資源同工具。三者可以疊埋：先用 OKF 保存資料表、指標同來源資料，再由搜尋層揀文件，最後經 MCP 工具執行核准查詢。OKF 規格本身冇提供向量索引、權限管理、執行環境或者中央可信分數，亦冇保證模型引用內容後一定唔會講錯；佢提供嘅係一套可以畀程式過濾同把關嘅共同欄位。

值得試，但先揀高風險指標做

用緊 BigQuery、內部數據目錄，或者已經畀 agent 回答營收、毛利、活躍用戶等指標嘅團隊，可以先揀幾個有明確擁有人同審批周期嘅計算做試點。實際成本會落喺整理來源、指定驗證人、設定更新日期、寫 attester，同埋令 consumer 真係拒絕過期或核驗失敗內容。官方參考實作仍屬 proof of concept，示例亦明顯偏向 Google Cloud；規格連 receipt 協議、attester 接口同 sandbox 都留待之後處理。而家其他資料平台同 agent 框架仲未廣泛支援，OKF 最後會唔會多人採用，仍要再觀察。

參考來源

• iThome — Google更新OKF開放知識格式，加入AI代理知識來源追溯與查詢結果驗證 — original report
• Google Cloud：OKF v0.2 加入信任訊號 — 官方發布文章，核對設計目的、BigQuery 示例、兼容性同參考實作定位。
• OKF v0.2 官方規格 — 核對必填與選用欄位、verification 同 attestation 分工，以及尚未定義嘅執行細節。
• OKF 官方程式庫 — 查看參考 agent、視覺化工具同示例 bundle；官方將實作定位為概念驗證。
• MCP 官方簡介 — 用嚟區分 MCP 接駁外部系統嘅角色同 OKF 知識格式嘅範圍。
• Google Cloud RAG 架構說明 — 核對 RAG 由擷取、索引到服務層嘅工作，說明佢同 OKF 可以點樣配合。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。