当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作为格式值得肯定，但不能将其视为完整的记忆系统。下一步需要运行时层来决定检索、排除、时效、范围和权限。格式不是瓶颈，状态管理才是。