Google把「让LLM维护知识库」写成了规范：我照这个思路跑了半年

几乎所有尝试过个人知识管理工具的人都面临同一个困境：无论是Obsidian、Notion还是Markdown文件夹，热情往往在几个月后消退，最终沦为被遗忘的数字坟场。这并非因为知识库没有价值，而是维护成本过高——每记录一条信息，都需要思考分类归属、更新交叉引用、修正索引。这种繁琐的「记账」工作，才是让人放弃的真正原因。

OKF规范的诞生与核心理念

LLM的出现为这一痛点提供了全新的解决思路。那些让人类放弃个人Wiki的琐碎工作，恰恰是LLM最擅长的领域：它不会厌倦重复性劳动，不会忘记更新交叉引用，能够同时修改多个文件中的相关内容。换言之，知识库荒废这个老问题，可能不需要更自律的人，而需要一个不嫌烦的维护者。

三大设计原则：克制与开放

2026年6月，Google Cloud将这一观察形式化为一份开放规范——OKF（Open Knowledge Format）v0.1。这不是一款产品或平台，而是一份关于「知识该如何存储，才能让人和AI agent都能直接读取」的开放约定。OKF的核心设计极为朴素：将知识表示为一个目录下的Markdown文件，每个文件代表一个概念（concept），文件之间通过标准Markdown链接互联成图，再辅以YAML frontmatter存储必要的结构化字段。

OKF的设计体现了惊人的克制。首先是「最少意见」原则——规范只强制要求一个字段（type），其余全部由使用者自行定义。其次是生产者与消费者解耦——一个人手写的bundle可以被agent消费，一个由LLM合成的bundle可以被另一个LLM查询，写与读不必是同一方、同一时刻、同一工具。第三是「格式而非平台」——OKF不绑定任何云、数据库或AI框架，永远不需要专有账号或SDK才能读写。这种开放性是OKF与市面上其他知识管理SaaS的本质区别。

基于同样的理念，笔者在过去半年构建了一套LLM-as-wiki-agent系统。该系统以Obsidian vault为载体，通过根目录的CLAUDE.md定义全部规则，wiki/目录由LLM全权维护。系统经历了四个版本的迭代：从v0.1确立schema规范，到v0.2固化摄入流程，再到v0.3引入双料流与自动升格机制，最终在v0.4实现了双向链接与自动化lint检查。关键突破在于v0.3引入的自动升格机制——通过launchd定时任务，使用更经济的模型自动将日常对话和信息流中的洞见升格为结构化知识页面，，实现了无人值守的持续知识积累。

实践者的六百天迭代

用OKF这把「官方尺子」来审视自身实现，可以发现几个有趣的发现。在存储形式上，笔者的方案与OKF高度契合——Markdown目录加frontmatter的形态完全一致。然而也存在两处差距：其一，生产者与消费者尚未解耦，系统运行在同一个LLM既写又读的闭环中；其二，整套方案绑死在Obsidian加自定义规则上，可移植性受限。这些差距恰恰指向了未来改进的方向——将私有约定逐步对齐到开放标准。

如有侵权，请联系删除。