當OKF在AI工具中運行時會發生什麼

開放知識格式(OKF)是谷歌推出的一種基於Markdown的AI知識標準，旨在使知識可移植且易於維護。然而，一個關鍵問題在於：當OKF包被實際放入AI工具中，模型需要自行決定檢查哪些文件時，會發生什麼？本文通過實驗揭示了這一運行模式的真實表現。

實驗設置簡單直接：模型獲得標準的助手提示和兩個工具——列出可用OKF Markdown文件的工具和讀取特定文件的工具。沒有自定義檢索代理提示。當模型調用read_file時，解析文件的前置元數據，提取beliefId並報告給PrecisionMemBench評分系統。評分依據的是模型實際讀取的正確信念文件，而非最終答案的質量。

單次查詢結果尚可：平均精確度0.47，召回率0.91，77個案例中36個通過。但會話場景（更接近真實使用）表現不佳：12輪會話中僅2輪通過，平均召回率降至0.45，p95延遲達59.3秒。失敗案例集中在範圍消歧（12例僅4例通過）、超期排除（3例全部失敗）、類型路由（精確度0.20）以及預算淘汰（精確度0.13）等方面。

積極的一面是，OKF確實改善了檢索形態。模型可以利用文件名、標題、描述、標籤和文件正文，這比黑盒向量檢索提供了更多線索。別名解析尤為成功，23個別名案例中平均精確度0.72，召回率0.92。當查詢與文件表面匹配良好時，OKF表現穩健。

然而，文件訪問不等於記憶檢索。OKF描述知識，但無法決定多少知識應進入模型請求。會話中，話題切換、先前輪次噪聲、隱式引用等問題使檢索成本和不穩定性急劇增加。連續狀態管理缺失是核心短板。

結論明確：OKF解決了可移植性問題——團隊可以在工具間移動精心策劃的知識包，而不依賴供應商記憶數據庫。但它未解決選擇問題：哪些信念相關？哪些是最新的？哪些適用於當前用户、團隊或任務？這些運行時決策需要額外的治理層。

因此，OKF作為格式值得肯定，但不能將其視為完整的記憶系統。下一步需要運行時層來決定檢索、排除、時效、範圍和權限。格式不是瓶頸，狀態管理才是。