當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作為格式值得肯定，但不能將其視為完整的記憶系統。下一步需要執行時層來決定檢索、排除、時效、範圍和許可權。格式不是瓶頸，狀態管理才是。