开放格式留给生产者的那部分
2026-06-12,Google Cloud 发布了 Open Knowledge Format:一个由带 YAML frontmatter 的 markdown 文件构成的目录,彼此交叉链接成一张图,由 AI 智能体撰写和维护,配有一个静态可视化器和一页纸的规范。如果读这个博客时这段描述让你有种 déjà vu,那是应该的 —— 这正是 StrayMark 已经交付了好几个月的形态。我们是从自己的想法走到那里的;OKF 抵达时,则把整个"LLM-wiki 模式"所追溯到的那则 Karpathy gist 列为出处。两条路,同样的基本构件。诚实的反应不是摆出防御姿态 —— 一个有着 Google 那种影响力的存在,刚刚验证了这个赌注。但验证了形态,并不等于认同它的目的,而这恰恰是唯一有意思的问题所在 —— 一个他们的规范用一句话就回答了的问题。
"OKF 对每个概念只要求一件事:一个 type 字段。其余一切都留给生产者。" —— OKF v0.1 规范
这一句话就是整篇文章。因为其余一切 —— 规范交回到你手里的那部分 —— 正是这两个项目不再是同一样东西的地方。
趋同
把 OKF 和 StrayMark 剥到只剩机制,零件清单是一模一样的。一个知识单元是一个带 YAML frontmatter 块的 markdown 文件。frontmatter 携带一个必填字段 —— OKF 把它叫 type,我们把它叫文档类型。文档彼此链接,这些链接构成一张由工具渲染的图。语料由 AI 智能体撰写并保持更新。bundle 只是文件:可 diff、可托管在 git、不靠工具就能阅读。有一个生成器,通过遍历既有系统来播种语料。有一个图可视化器。
我们没有抄 OKF,OKF 也没有抄我们 —— 而且确切地说,我们也不是从 Karpathy 那里走到这里的。OKF 把他的 gist(其本身又是对 Vannevar Bush 1945 年 Memex 的一次回望)列为自己的源头;StrayMark 则是从自己的想法抵达同样的基本构件,没有那条血脉。而这恰恰是这种重叠值得一提的原因:当两个出发点不同的项目都落到 markdown + frontmatter + 图 + 智能体上时,这些基本构件就不是一阵风潮。它们是对的底层基质。
所以我们不打算跟 OKF 的机制争论。那些机制也是我们的。我们要指出的是:同样的零件,被组装成两台做着相反工作的机器 —— 那个地方在哪里。
两种读者,两种范式
这才是核心,而且它不是一个功能上的缺口。
对任何知识语料问一个最简单的问题:它是给谁的? OKF 干脆利落地回答:给 AI。 它的工作是让一个组织的数据对智能体可读 —— 把"了解这个系统"这份认知负担从人身上卸下,编码进一张模型可以为自己所用的图里。这就是为什么发布公告要搬出 BigQuery 来让这张图可被查询:那个隐含的、真正在做查询的消费者,是智能体。而且它契合当下业界的主流潮流 —— 长时运行的自主智能体,那些不睡觉的、接过一段话的 prompt 就去干上好几天的智能体。在那个世界里,人需要待在回路里的程度越低,系统就被认为表现得越好。OKF 是那个世界的好基础设施。
StrayMark 建立在一个不同的赌注之上 —— 关于这一切将走向何方。不是把人移出回路 —— 而是给人一个在回路之内、站得住脚的位置。语料之所以存在,是为了让一名工程师能够知道:做了什么决定、为什么,什么正在进行,什么仍然欠着,以及整件事正朝哪里走 —— 不必每一步都把整个代码库装进脑子,也不必沦为给一份自己其实无力评估的产出盖橡皮图章。这正是 Scott Hanselman 等人以AI 增强工程(AI-augmented engineering)之名一直在主张的立场:人没有被取代,而是被重新安置到真正属于工程的那部分 —— 判断、方向、问责 —— 并在那里被 AI 放大。这是 vibe coding 的对立极,也是那种全自主、自己决定做什么、去哪里、何时停下的"司机型"智能体的对立极。
所以这两个项目是在为不同的读者构建认知。OKF 为智能体构建认知。StrayMark 为这一对搭档构建认知 —— 智能体和人类工程师一同 —— 并努力让两者朝向同一张地图。Loom,我们那个(实验性的)图与架构可视化器,是最清楚的标志:它的状态 overlay 和 3D 架构视图,是为一个人在项目中的时空定位服务的教学式辅助 —— 你在这里,这个是活跃的,这个背着债务,工作正朝这边走。这种东西你不会为一个智能体去造。你是为搭档里的那个人去造的。
请仔细读这一点:这一切都不是为了拖慢 AI。地图不会拖慢你 —— 它正是你在不迷路的前提下跑得快的方式。重点是让 AI 在这样一种情境里有用:人保留控制,并持续地知道 —— 是什么、为什么、下一步是什么、还有什么悬而未决。
留给生产者的那部分
现在,规范里的那句话读起来就不一样了。OKF 按其本意是极简主张的。它标准化的是信封 —— 一个概念如何成形、链接如何运作、一个 bundle 如何打包 —— 然后就停下。其余一切都留给生产者。 对 OKF 的工作 —— 让数据对智能体可读 —— 来说,这恰恰是对的决定;信封就是它的贡献。
但"其余一切"并不是一袋可有可无的附加项。它是整个面向人的那一层:哪些文档类型值得保留(一个 ADR —— 一个决定及其缘由;一个 AILOG —— 智能体实际做了什么;一个 Charter —— 计划了什么;一个 TDE —— 明知故犯地背上的债务),在什么样的生命周期之下(charter 会相对代码发生漂移,后续事项会被捕获并提升,审计会跨多个独立模型运行,合规会映射到 EU AI Act 和 ISO 42001),带着什么样的保证。那一层不是供智能体消费的数据。它是知识 —— 不只是信息 —— 摆在一个人面前,好让其做出决定。 StrayMark 恰恰就对这件事抱持最大程度的主张。它就是那个"其余一切",刻意如此。
把这两者放进脑子里最清爽的方式是:
OKF 描述系统,好让 AI 能理解它。StrayMark 描述系统是如何被建起来的,好让人能信任它 —— 并持续对它握有指挥权。
你能不能把 OKF 一路向外扩展,直到它做了 StrayMark 的工作 —— 加上类型、一套生命周期、一个面向人的可视化器?能。但你那是在外部重建一件已经存在、而且已经做得很好的东西。诚实的关系不是竞争,也不是替代。而是两者面朝相反的方向:一个朝向数据以及读它的智能体,另一个朝向过程以及为它负责的人。一个团队可以两个都用。它们并不重叠 —— 而在它们看上去重叠的地方,StrayMark 已经覆盖了那块地。
规范没有标准化、而我们标准化了的那部分
同一个分歧,有一个更锋利、更具体的版本,藏在 OKF 的链接模型里。
在 OKF 里,链接是无类型的。规范说得很明确:"那种具体的关系类型……是由周围的散文来传达的,而不是由链接本身。" 一条从 A 到 B 的链接意味着以某种方式相关 —— 去读那一段。对一个其读者是"能读那一段的模型"的极简格式来说,这是合理的。
但去读 Karpathy 最初那则 gist 底下的评论串 —— OKF 所承袭的那条血脉 —— 你会发现这个模式自己的批评者们,正在点名它的失败模式。一条回复(pursultani 的)指出:LLM-wiki 模式默认会去调和矛盾,悄悄地把张力消解成一个收敛的单一故事 —— 而在许多领域里,一个矛盾承载着信息,应当被保留,而不是被抹平。所提的修法:在 frontmatter 里用有类型的边,好让一种关系可以说矛盾于、取代、是……的一个替代 —— 而不只是相关于。
保留一个矛盾而不是把它抹平,这恰恰是一个"人在回路"的动作:一个保持可见的张力,就是一个可以被拿去请一个人来裁断的张力。StrayMark 早就这么运作了。supersedes 是一条有类型的边:这个 ADR 取代那个,而旧的那个留在磁盘上,不可变,作为被保留下来的历史。alternatives_documented 记录下那些没有走的路。整个Transversal Debt Entry(横贯式债务条目)的概念之所以存在,就是为了把一个尚未解决的张力写下来,并把它摆在某个人面前,而不是把它糊弄过去。那则 gist 底下的另一条回复 —— 一个叫 memwiki 的实现 —— 正是专门为对抗*"智能体失忆"*(Agent Amnesia,即智能体忘掉架构决定)而造的。那一字不差,正是 StrayMark 立项要解决的问题 —— 我们是自己走到这里的,而那个评论串恰好佐证了它。那个评论串不是某个竞争对手的路线图。它是这个模式各种失败模式的一份清单,其中有好几项是我们从第一天起就当作需求来对待的 —— 因为我们是在为一个必须承受后果的读者而构建:一个人。
我们打算就此做点什么
两件事,都不带防御姿态。
第一,互操作。 因为基本构件是共享的,从一个 StrayMark 语料到一个合规的 OKF bundle,距离很小,而且大体上是机械性的 —— 一张类型名映射,再把我们那些有类型的 frontmatter 引用重写成相对 bundle 的 markdown 链接,而这正是 Loom 背后那套引用解析工作已经在做的事。一个 StrayMark 项目应当能够发出一个装着它治理记录的 OKF bundle,好让任何会说 OKF 的东西 —— 包括 Google 自家的 Knowledge Catalog —— 都能读它。而且它应当能无损往返:OKF 承诺保留它不认识的 frontmatter 键,而我们的治理元数据恰恰就是那些键。我们在 OKF 自己的信封上与它相会,且不丢失我们这边的任何东西。
第二,Loom 已经能渲染这个。 Loom 摄入带 frontmatter 的 markdown 并构建一张图;一个 OKF bundle 就是同样的输入。区别在于 Loom 拿它做什么 —— 状态 overlay、图分析、一个 3D 架构视图,全都指向为一个人提供定位。把 Loom 指向任何一个 OKF bundle,是一个小适配器,而不是一次重写。这也是对那个论点最直接的演示:拿一个被设计成供智能体阅读的语料,把它渲染成一个人能站进去的样子。
如果你读到了这里
这一次的可迁移练习与文件格式无关。它是一个问题,值得拿去问你的团队为它的 AI 保存的任何"知识":它是给谁的? 如果答案是智能体自己 —— 好让它能不带你、工作得更久 —— 那么一个像 OKF 那样极简、标准的信封,就是你所需要的大部分,而那个信封正要变成一种通用品,这对所有人都是好事。如果答案是你和智能体一起 —— 好让一个人持续保持定位、握有指挥权、并能做出那些本就属于他的判断 —— 那么信封从来都不是难的那部分。难的那部分,是去决定:你的项目应当记住什么、用哪些类型、在什么样的生命周期之下,以及这一切是要把谁留在回路里。一个标准化机构可以递给你那个信封。它刻意地无法递给你一个关于"人在这项工作中的位置"的立场。那个,从一开始就注定是要留给生产者的。
Open Knowledge Format v0.1:规范 · Google Cloud 公告 · OKF 所承袭的那则 Karpathy gist。StrayMark 的分析存放在仓库的 experiment-okf/ 里。
本文档在生成式 AI 工具(Claude Opus 4.8)的协助下完成;全部内容责任由人类作者承担。