2026 年 6 月，Google Cloud 以 Apache 2.0 开源了开放知识格式（OKF），将 Karpathy 两个月前提出的 LLM-Wiki 模式正式化为厂商中立的开放规范。OKF 不要求推翻现有工具，不要求先部署向量数据库，而是从「把知识整理清楚」这个根本出发。本文从知识库困境、Karpathy 的摄入时编译洞察、OKF 的正式化与企业化设计、与 RAG 的分层关系、一周 MVP 落地路径五个维度展开分析。
2026 年 4 月，Andrej Karpathy 在 GitHub 发了一个 Gist，描述了一种个人知识库架构：原始资料放 raw/ 目录，LLM 编译生成的结构化文章放 wiki/ 目录，index.md 做导航入口。
按传统理解，这只是一个个人实验。
然而，两个月后，Google Cloud 把这个模式正式化为一个开放规范——Open Knowledge Format（OKF），2026 年 6 月 12 日以 Apache 2.0 许可证开源，版本号 v0.1。它不是一个产品，不是 SaaS 平台，而是一个格式规范：定义如何用一组 Markdown 文件表示「给 AI Agent 和人类都能读懂的知识」。
背后的逻辑值得深究。Karpathy 的个人实验为什么值得 Google 用两个月时间正式化？企业的知识库又为什么需要关注这件事？围绕上述问题，本文将从知识库现状、Karpathy 的核心洞察、OKF 的规范设计、与 RAG 的分层关系以及落地路径五个角度展开分析。
**01**
## 你的知识库，AI 用起来有多痛苦
企业知识的现状，可以用一个典型场景来说明。
你让 AI Agent 帮你查一个业务指标的定义，它编了一个计算口径给你。问它某个操作流程怎么走，它引用了三年前的旧版文档。
问题不在模型。模型已经足够强了。问题在于模型需要的上下文——数据表的含义、指标的计算口径、系统之间的关联、操作流程的步骤——分散在各种互不兼容的系统里。Google 在发布 OKF 时的表述很直接：这些知识原子分散在元数据目录的专有 API 里、各种 Wiki 系统或共享网盘里、代码注释里、几个资深工程师的脑子里。每一个 Agent 开发者都在从零解决同一个上下文组装问题。
我们可以把企业知识的存在形态从「最难处理」到「最结构化」排列一下：纸质文件和扫描件、图片化 PDF、Word/Excel 文件、Confluence/Notion/SharePoint 页面、Markdown+Git 仓库。
这些形态背后有三个系统性问题。
第一个是知识孤岛。同一个指标、同一个流程在不同系统里有不同版本，Agent 不知道哪个是权威的。第二个是格式不统一。OCR 出来的文本、Confluence 页面、代码注释，三者格式完全不同，每个 Agent 都需要定制解析器。第三个是元数据缺失。文档没有类型、来源、时间戳、标签，Agent 在检索时无法有效过滤。
RAG 是目前最主流的解决方案，但它有几个结构性缺陷。文档被切分为语义碎片，一个指标定义可能被拆到三个 chunk 里，Agent 需要自行拼合。不同来源的文档元数据字段各异，没有统一的 type、resource、tags，难以做精确过滤。同一知识在多个文档里重复出现，Agent 不知道哪个版本最新、哪个最权威。
换言之，RAG 解决了「怎么检索」，但没有解决「知识本身怎么存放和标注」。
**02**
## Karpathy 的洞察：摄入时编译，而非查询时检索
理解 OKF 之前，需要先理解 Karpathy 的 LLM-Wiki 模式。
2026 年 4 月，Karpathy 在 GitHub Gist 中描述了一种知识库架构，包含三个核心组件：raw/ 目录存放原始资料（PDF、笔记、文章），wiki/ 目录存放 LLM 编译生成的结构化 Markdown 文章，index.md 作为导航入口，大小控制在 LLM 上下文窗口内。
这个模式与 RAG 是两种思路。RAG 是查询时检索——每次提问都从原始文档中搜索相关片段，拼接入 prompt。LLM-Wiki 是摄入时编译——在知识进入系统时，让 LLM 一次性把原始内容理解、提取、组织成结构化文章，之后查询时直接读编译后的知识。
让我们来打个比方。RAG 像是每次做菜都从原材料开始切配，LLM-Wiki 则是提前把食材处理好、分装好，用的时候直接取用。
这个洞察的价值在于：它把知识从「检索系统的附属品」提升为「独立维护的资产」。知识不再散落在文档碎片里，而是被编译成完整、准确、可维护的结构化条目。
但是，LLM-Wiki 有一个关键缺陷：它是一个个人模式，没有规范。每个人的 raw/、wiki/、index.md 实现都不一样，没有统一的元数据字段，没有类型系统，没有跨团队互操作的约定。
**03**
## OKF：LLM-Wiki 的正式化与企业化
OKF 做的事情，就是把 LLM-Wiki 从个人模式升级为可共享的开放规范。在 LLM-Wiki 的基础上，OKF 增加了四个关键设计。
第一个是标准化的 YAML frontmatter。每个概念文件包含结构化元数据：type（概念类型）、title（标题）、description（摘要）、resource（指向实际资产的 URI）、tags（分类标签）、timestamp（最后修改时间）。其中只有 type 是必填字段。
第二个是 Bundle 结构。一个 OKF Bundle 是一个目录树，包含若干 Markdown 文件，推荐用 Git 仓库存储，自带历史记录、归因和 diff。两个保留文件名有特殊语义：index.md 是目录列表，支持 Agent 渐进式导航——先看 index 了解有哪些知识可用，再深入读特定概念；log.md 是变更历史，按日期倒序记录知识演进。
第三个是跨链接规范。概念之间通过 Markdown 链接互相引用，使整个目录变成关系图谱。OKF 推荐使用 bundle 根相对路径，链接的语义由周围文字表达，不要求特殊语法声明关系类型。
第四个是极低的合规门槛。一个 Bundle 符合 OKF v0.1 只需满足三个条件：每个非保留的 .md 文件包含可解析的 YAML frontmatter；每个 frontmatter 包含非空的 type 字段；保留文件名在存在时遵循定义的结构。
值得注意的是，OKF 的设计哲学是「Consumer 宽容，Producer 灵活」——Consumer 不得因缺少可选字段、未知 type 值、断开的链接而拒绝一个 Bundle。这使得 OKF 可以渐进式引入，不需要一步到位。
**04**
## 不是 RAG 的替代品，是缺失的那一层
这是理解 OKF 定位最关键的一点。
OKF 不是 RAG 的竞争者。两者在架构上处于不同层次：OKF 是知识表示层，解决「知识怎么存放和标注」；RAG 是检索机制，解决「知识怎么检索」。一个 OKF 概念文件天然就是一个完整的、带元数据的、语义完整的知识单元——不需要再做 chunking 就可以直接向量化。
我们可以这样区分三种方案的定位。
传统向量 RAG 适合知识体量超过百万 tokens、更新频率高、需要近实时检索的场景。其优势是规模无上限，但启动成本高——需要 embedding pipeline、向量数据库、chunking 策略设计。
LLM-Wiki 适合个人或极小团队，知识体量在 50-100 篇概念以内，追求零基础设施成本，快速验证。其局限是规模受限，超过 LLM 上下文窗口后 index 会溢出。
OKF 适合需要与多个 AI 工具共享知识、计划逐步迭代、团队规模中等、知识来源多样的场景。它不依赖任何专有平台，只需要文本编辑器和 Git。
最佳实践不是三选一，而是三者分层组合：OKF 作为精炼的结构化知识层，存放少量、高质量、权威定义的核心知识；RAG 作为广覆盖的文档检索层，处理海量原始文档的模糊检索；Agent 先查 OKF bundle 获取结构化上下文，再用 RAG 检索补充证据。
**05**
## 从纸堆到知识库：一周跑通 MVP
很多中小企业的知识还在纸质或图片化文件里。OKF 提供了一条清晰的数字化路径：纸质文档 → 扫描 → OCR 提取结构化文本 → LLM 清洗和分类 → 写入 OKF 概念文件 → 人工审核 → Git PR → Merge。
相比 OCR + 传统 RAG 的路径，OKF 的优势体现在三个方面。其一，每个概念文件是完整的语义单元，不存在 chunk 截断问题。其二，YAML 元数据天然成为 RAG 的过滤条件，检索精确度大幅提升。其三，版本管理通过 Git PR 实现，每次知识变更都有审计记录。
一周就能跑通 MVP。
第一天，选定一个业务域（如企业内部指标体系），手工编写 5-10 个核心概念文件，建立 index.md 和 log.md，提交到 Git 仓库。
第二天，实现 OKF Loader——一个 Python 脚本，扫描目录、解析 YAML frontmatter、构建内存对象，支持按 type 和 tags 过滤。
第三天，接入向量库，对概念文件的 body 做 embedding，将向量加 YAML 元数据存入 pgvector 或 Qdrant，实现混合检索：先按 type/tags 过滤，再按向量相似度排序。
第四到五天，接入 Agent。基于 LangChain 或 LangGraph，实现先查 OKF Loader 精确获取概念，再查 RAG 引擎补充证据，最后拼接为 context 输入 LLM 生成答案。
第六到七天，写 CI 校验脚本——GitHub Actions workflow，在 PR 时自动检查 YAML 解析和 type 字段存在性。
对于已有 Confluence、Notion 或纯 RAG 系统的团队，不需要推倒重来。渐进式引入即可：先选一个业务域建立 OKF Bundle，双轨并行；再优先迁移高价值知识——指标定义、核心数据表、关键 SOP；最后逐步扩展到更多业务域。
**06**
## 知识是一等公民
OKF 代表的理念，是把知识从检索系统的附属品提升为一等公民——独立设计、版本控制、审核和共享。
这个理念的关键不在于部署什么技术栈，而在于从「把知识整理清楚」这个根本出发。OKF 不要求推翻现有工具，不要求第一步就部署向量数据库，只需要文本编辑器、Git 和基本的 Python 技能。它与传统 RAG 不是竞争关系，而是互补——OKF 提高了 RAG 的知识源质量，同时也可以独立为小规模场景提供零基础设施的知识库。
当然，OKF v0.1 还是一个草案。规范本身可能在未来版本发生变化，生态工具仍在早期，企业生产级案例有限。但对于正在进行知识数字化的团队来说，现在正是关注和试水的窗口期。
当 Karpathy 的个人实验被 Google 用两个月时间正式化为开放标准，这个信号本身就值得认真对待。你的企业如果正在评估 AI 落地的知识基础设施，OKF 值得重点关注。
