--- title: '给LLM Wiki定的开放标准OKF来了' video_id: T33iI6izAKw url: https://youtu.be/T33iI6izAKw title_en: "Finally, an Open Standard for the Karpathy LLM Wiki is HERE" channel: Cole Medin published: 2026-07-02 duration: "19:37" topics: [RAG 与知识系统] noted: 2026-07-05 value: A views: '4.5万' --- [![封面](https://i.ytimg.com/vi/T33iI6izAKw/maxresdefault.jpg)](https://youtu.be/T33iI6izAKw) > Cole Medin · 19:37 · 发布 2026-07-02 · 4.5万次观看(截至抓取) · [观看原视频](https://youtu.be/T33iI6izAKw) · 全文中译 ## 主旨 Google 发布的 OKF(Open Knowledge Format)在 Karpathy 的 LLM wiki 模式上加了一层轻量标准——只统一文件组织方式和 metadata 字段——让不同人搭的第二大脑能被彼此的 agent 读懂、共享。 ## 核心论点 1. **Karpathy 的 LLM wiki 模式本身没问题,缺的是标准**——每个人接入后目录结构和字段命名都不一样,agent 换一个知识库就看不懂,团队/社群共享基本无解。 2. **OKF 只标准化两件事:文件怎么组织 + metadata 有哪些字段**,而且只有 `type` 一个必填项,刻意做成"最小公约数"。 3. **"内容不多"的批评是对的,但这正是设计目标**——标准要成为公约数,就必须克制到只留必要的部分,不然又会变成新的碎片化。 4. **迁移成本几乎为零**:把 spec.md 丢给 coding agent 就能一键新建或重构 wiki,规模大时可以让 agent 用 sub agent 分治不同目录。 ## 知识点详解 ### Karpathy LLM wiki 的老问题:没有标准就没法共享 [01:32](https://youtu.be/T33iI6izAKw?t=92) 译 Karpathy 那份 40k star 的 gist 火起来是因为思路简单:让 LLM 增量维护一份带交叉链接的 LLM wiki,而不是把文档一股脑扔进 RAG 索引,每次加新资料时 LLM 会读全文、抽取关键信息、更新已有的 entity 页面。 问题是每个人照着这个思路自己搭一套,目录结构、字段命名各不相同,agent 拿到别人的知识库就读不懂,想共享给团队或粉丝基本无解。 ### OKF 只标准化两件事:组织结构 + metadata 字段 [03:35](https://youtu.be/T33iI6izAKw?t=215) 译 OKF 的 spec.md 就干两件事:规定文档怎么分层组织(每层目录配一个 index 文件),规定 Front matter 里有哪些字段——只有 `type` 必填,`title`/`tags`/`related` 等都可选。 整份 spec 就是这份契约,喂给 coding agent 当 skill 用,读一遍就能照着建或重构。 ### index 文件 + [[渐进式披露]]:agent 怎么少花 token 找到答案 [04:25](https://youtu.be/T33iI6izAKw?t=265) 译 每层目录的 index 文件像一份说明书,先给 agent 一个高层概览——有哪些文档、每篇讲什么——agent 据此判断该往哪个方向深挖,再决定要不要打开某篇具体的 Entity document。 这跟 skill.md 的渐进式披露是同一个机制:先读摘要,按需再读全文,而不是一次性把所有内容塞进上下文。 ### Bundle:把知识库打包成可分享的产品形态 [11:17](https://youtu.be/T33iI6izAKw?t=677) 译 Cole 把自己频道最好的 4 个 AI coding 视频打包成一个 Bundle:顶层 index 分videos 和 concepts 两个分区,再配一个简单 CLI 按 bundle/concept ID 查询。 别人只要先把 spec 喂给自己的 coding agent学会 OKF,再把这个 repo 的 README 丢给它,就能直接把整个知识库接进本地的 Obsidian 或 Notion 提问,不用自己重新导入 transcript。 ### 实测:agent 靠分层结构逐层收窄找到答案 [16:50](https://youtu.be/T33iI6izAKw?t=1010) 译 Cole 在终端里只问"Cole 关于稳定拿到可靠代码输出的最大观点是什么",没指定看哪个 bundle。 Agent 跑了四条命令:先列出所有 bundle,读索引挑出相关的一个,再进 concepts 层,最后定位到"context engineering"这篇 Entity document 拿到答案——全程靠 index 结构一路收窄范围,没有一次性读完整个知识库。 ## 可执行步骤 - [ ] 把 OKF 的 spec.md 丢给你的 coding agent,先让它"学会"这套标准 - [ ] 新建知识库时按 OKF 结构走:顶层 index + 各分区(如 concepts/、videos/)各自的 index - [ ] 给每篇文档的 Front matter 至少加上 `type` 字段,作为分类检索的基础 - [ ] 已有的 LLM wiki 想统一格式,直接让 agent 按 spec 重构,量大就明确要求用 sub agent 分治不同目录 - [ ] 想把自己积累的知识打包分享给别人,参考 Bundle 思路做一层 index + CLI/README,让对方 agent 一次接入 ## 关联 - 印证:[[2026-06-17-Claude第二大脑的五个层级详解|Claude第二大脑的五个层级详解]] 对 Level 2 wiki 的描述与 OKF 默认形态一致,印证 wiki 的可读性与互操作性不依赖特定 agent。 - 印证:Greg·Skill 工作原理 把 [[渐进式披露]] 落到 skill 加载机制(名称+描述先进上下文、正文按需展开),与本片的 wiki 检索场景是同一原理的两个独立实例。 ## 术语 - OKF (Open Knowledge Format) - Google 发布的个人知识库开放标准,统一文件组织与 metadata 字段 - LLM wiki - Karpathy 提出的、用 LLM 增量维护并带交叉链接的个人知识库范式 - Bundle - OKF 下打包好的一份可分享知识库 - 渐进式披露(progressive disclosure) - 先读索引摘要判断方向,再决定是否打开全文的检索策略 - Entity document - 针对单个概念/实体的独立文档,是知识图谱的节点 - Front matter - Markdown 文档头部的 YAML 元数据块,OKF 中仅 `type` 必填 ## 金句 > "It's the bare minimum layer that we need on top so that we can produce and consume these wikis in exactly the same way across everyone's agents." [18:44](https://youtu.be/T33iI6izAKw?t=1124) 译 → 面对"OKF 太简单、没实质内容"的批评,Cole 的回应是:标准要成为公约数,就必须克制到只留必要的部分——少即是对。 ## 立场与利益 - PostHog 是本期视频的付费赞助植入,那段推广跟 OKF 内容本身无关,可整体忽略。 - Cole 反复提到自己的 bundle、Archon 项目,存在自我引流成分;但 OKF 标准是 Google 开源发布的,不是 Cole 自家产品,不构成直接利益绑定。 - Cole 自己也承认"我不认为 OKF 最后会成为标准,但类似的东西会出现"——这是对一个尚处早期、未经验证的标准的推广,不是既成事实,采用前可以先观望。 ## 价值定位 适合已经在搭 LLM wiki / 第二大脑、并且开始关心"这套知识库能不能被别人(或别的 agent)读懂、能不能打包分享"的用户;还没建知识库的人听 OKF 会觉得空。解决的是 Karpathy LLM wiki 火了之后的碎片化问题——各人目录字段不一,agent 换个库就读不懂。 以认知价值为主,即用价值要打个折:Cole 自己都说"不认为 OKF 最终会成为标准,但类似的东西会出现",标准本身尚早、可观望。真正能马上借鉴的不是 OKF 这个具体 spec,而是两个更通用的做法——**每层目录配 index 文件 + [[渐进式披露]]**让 agent 少花 token 逐层收窄(与本 vault 已有的同名概念印证),以及**把知识库打包成带 index+CLI 的可分享产品形态**(Bundle)。 本片独有的是 OKF 的最小契约设计(只 `type` 必填)和 Bundle 分享范式;"渐进式披露""index 组织"这些机制在 [[2026-06-25-Harness为王的能动工程大师课|大师课]] 的 skills 讨论里也出现过,不是本片首创。 ## 自检问题 1. Karpathy 的 LLM wiki 模式本身缺的是什么,导致个人知识库没法在人之间共享? **答案**:不是能力问题,而是缺一个统一标准——每个人接入后目录结构和 metadata 字段命名都不一样,agent 换个知识库就理解不了,见"Karpathy LLM wiki 的老问题"一节。 2. OKF 标准化的到底是"内容"还是"格式"?为什么"太简单"这个批评反而说明它设计对了? **答案**:OKF 只标准化组织结构(索引分层)和 metadata 字段(仅 `type` 必填),不规定知识内容本身。"没什么实质内容"的批评是对的,但这正是设计目标——最小公约数才能保证所有 agent 用同一种方式生产和消费知识库,见"OKF 只标准化两件事"一节和"金句"一节。 3. agent 回答问题时为什么不需要一次性读完整个知识库?靠的是什么机制? **答案**:靠分层 index + 渐进式披露——agent 先读顶层 index 判断方向,再逐层深入到具体 entity 文档,像 Cole 演示的那样跑四条命令层层收窄范围,见"index 文件 + 渐进式披露"和"实测"两节。 4. Bundle 这种形态解决的是创作者的什么痛点? **答案**:让创作者能把自己积累的知识(比如频道视频)打包成带 index + CLI 的可分享知识库,别人不用自己重新导入 transcript,直接把 repo 接进自己的 agent 就能提问,见"Bundle"一节。 5. 如果 OKF 最终没有成为行业标准,现在跟进这套东西还有没有意义? **答案**:有——Cole 自己也认为 OKF 不一定是最终标准,但"类似的东西会出现",现在理解和实践这套组织思路(index+分层+统一 metadata)是对个人知识库管理能力的提升,不依赖某个具体标准能否存活下去,见"立场与利益"一节。 > [!quote] 💬 热门评论 top-11 主 + 9 回(抓取 2026-07-07) > > [6] **@TomHimanen**:你还可以定义 OKF，并在文件级 harness（benquemax/henxels）中强制执行。它通过算法指导 agent，确保指令在 agent 提交前生效。这样也能让本地模型遵守 OKF 标准要求的规则（henxels）。 👍 15 >   ↪ **@eannane8712**:我讨厌自己每天努力学，还是听不懂这里一半的人在说什么。 👍 3 >   ↪ **@ColeMedin(UP)**:喜欢！ >   ↪ **@IoT_**:能详细讲讲这些 benquemax 的东西吗？ 👍 2 > [9] **@Mr_Big_Head**:只要设置一个 cron 任务，定期对你的 vault 做 RAG 摄取，添加元数据，方便你的 LLM 搜索和链接 vault。 👍 1 > ——其他 8 条:感谢/夸赞([2]@dj1480、[3]@Ic37r011、[4]@mish551x、[5]@bankableAI、[7]@nostrafanumproductions、[8]@DavidElfalan、[10]@lopa-wt7eg、[11]@pvwetten);1 条 spam 已略 >
英文原文[1] @ColeMedin(UP):The Dynamous Agentic Coding Course is now FULLY released - learn how to build reliable and repeatable systems for AI coding: https://dynamous.ai/agentic-coding-course 👍 4
  ↪ @Roberto-x4s1f:Click "more" at thd top abd then "show transcriot"....thats exactky how your agent does it.
  ↪ @mrsrhardy:you need a hybrid, LLM markup for short term and ddb obsidian for longer term data organization, one-shot a real solution
[2] @dj1480:Can't wait to try this! I'm so glad my agents will know everything in your videos :D 👍 2
[3] @Ic37r011:This was phenomenal. I have been using one I made that is super close to the standard. Now that you shared this I have a standard from the industry to adopt. Thank You! 👍 8
  ↪ @ColeMedin(UP):Very cool, you are welcome!
[4] @mish551x:So cool, Cole. HQ videos so far, plus great communication and expertise. 👍 3
  ↪ @ColeMedin(UP):I appreciate it!
[5] @bankableAI:I hadn't even thought about this! But I have a few use cases that need it so ty. 👍 1
[6] @TomHimanen:You can also define OKF and enforce it at file-level harness (benquemax/henxels). It instructs the agent algorithmically and makes sure instructions take effect before the agent can commit. This makes also local models obey the rules (henxels) that are required by OKF standard. 👍 15
  ↪ @eannane8712:I hate how I try to study this every day and still can't understand half the shit people say on here 👍 3
  ↪ @ColeMedin(UP):Love it!
  ↪ @IoT_:Can you please elaborate on these benquemax stuff? 👍 2
[7] @nostrafanumproductions:Great Video Cole! I am excited to try out your Knowledge Bundle. Thanks Bro! 👍 1
  ↪ @ColeMedin(UP):Thank you! Glad to hear you're going to give my bundle a spin :)
[8] @DavidElfalan:Thank you 👍 1
[9] @Mr_Big_Head:Just have a cron that runs a periodical rag ingest on your vault to add meta data for your llm to easily search and link your vault. 👍 1
[10] @lopa-wt7eg:Thanks G💪🐐 👍 1
  ↪ @ColeMedin(UP):You bet!
[11] @pvwetten:Excellent video, Tnx 👍 1