Open Knowledge Format（OKF）是什么：工作原理、适用场景与企业实施

Open Knowledge Format（开放知识格式，简称 OKF）是 Google Cloud 推出的开放、厂商中立的草案规范。它把企业知识打包成带 YAML 前置元数据、彼此链接的 Markdown 文件，让人类与 AI 智能体无需专有 SDK 即可读取同一套可移植上下文。截至 2026 年 7 月 12 日，当前版本为 OKF v0.1 Draft。

先明确两个边界：这里的 OKF 不是同样使用该缩写的 Open Knowledge Foundation。它也不是数据库、模型、检索引擎、智能体协议或经 Google 确认的排名信号。OKF 是一个刻意保持最小化的知识交换格式，负责包装这些系统使用的知识。

OKF 要解决什么问题？

多数企业缺的不是知识，而是可组装的上下文。“活跃客户”的定义在 BI 看板里，计算逻辑在 SQL 中，例外规则埋在 Slack，API 合约放在 OpenAPI，事故流程写在 Confluence，真正的设计原因还留在某位资深工程师脑中。

智能体可以搜索这些系统，但每个集成都返回不同结构。每做一个新助手，都要重新搭连接器、分块、元数据映射和权限逻辑；更换目录产品或模型供应商时，整理过的知识往往锁在旧平台。Google Cloud 于 2026 年 6 月 12 日发布 OKF，把反复出现的“LLM wiki”模式规范化：由人类和智能体共同维护的 Markdown 知识库。Google Cloud 官方公告指出，缺少的是格式，而不是又一个服务。

Open Knowledge Format 如何工作？

一个 OKF 知识包（Knowledge Bundle）是一棵目录树。每个稳定的知识单元叫作概念文档（Concept），存储为 UTF-8 Markdown 文件。文件在知识包中的路径去掉 .md 后就是概念 ID。普通 Markdown 链接把概念组成图，目录则提供可浏览的层级。

company-knowledge/
├── index.md
├── log.md
├── metrics/
│   ├── index.md
│   └── monthly-recurring-revenue.md
├── systems/
│   └── billing-api.md
└── playbooks/
    └── failed-payment.md

每个概念把可查询的少量元数据与人类可读内容放在一起：

---
type: Metric
title: Monthly Recurring Revenue
description: 按月标准化的合同经常性收入。
resource: https://analytics.example.com/mrr
tags: [finance, saas, board]
timestamp: 2026-07-12T09:00:00Z
---

# Definition

MRR 包含有效订阅，不包含一次性服务。
退款规则见 [billing playbook](/playbooks/refunds.md)。

# Citations

[1] [财务政策](https://docs.example.com/finance/mrr)

只有 type 是必填项；title、description、resource、tags 与 timestamp 都是推荐项。生产方可以添加自定义字段，消费方应保留无法识别的字段。这种宽松契约正是官方 OKF v0.1 规范的核心设计。

OKF v0.1 的三条合规规则是什么？

1. 每个非保留 Markdown 文件都必须包含可解析的 YAML 前置元数据。
2. 每个前置元数据块必须包含非空的 type。不存在中央类型注册表。
3. 保留文件存在时必须符合指定结构。index.md 用于按需逐层浏览目录，log.md 用于记录带日期的变更；两者均为可选。

其他大多只是软性建议。合规消费方不能仅因缺少可选字段、出现未知类型、自定义键、断开的交叉链接或缺失索引而拒绝知识包。目标是让一个正在变化、部分由智能体生成的知识库仍然可用。

OKF 是什么，又不是什么？

OKF 与 RAG、MCP、OpenAPI、llms.txt 有什么区别？

它们是可以组合的不同层，并不是互相替代的产品。

一个实用架构是：领域负责人在 Git 中维护 OKF，CI 自动验证，RAG 索引知识包，MCP 服务器提供搜索和实时系统访问；智能体只加载少量相关概念，并在需要时沿链接深入。OKF 是持久知识源，RAG 是选择机制，MCP 是运行时入口。

"OKF 不解决检索或治理。它先回答一个更安静的问题：知识能否脱离创建它的工具继续存在，并且仍能被下一个人或智能体读懂。"

OKF 在哪里产生真实商业价值？

• 上下文不随供应商更换而丢失。更换模型、向量库、目录或智能体框架，不必重写已整理的知识。
• 像审查代码一样审查知识。Pull Request、diff、CODEOWNERS、标签与回滚开箱即用。
• 加快入职与事故响应。同一概念既能给助手使用，也能渲染为文档，并在系统故障时直接阅读。
• 建立统一导出目标。目录、wiki 和仓库都可以生成 OKF，而不用逐个适配每个消费方。
• 按需加载上下文。智能体先读 index.md，只打开真正相关的概念。

当多个智能体需要同一套上下文、知识经常变化、厂商锁定或审计很重要时，商业价值最明显。如果只有一份稳定 FAQ 和一个聊天机器人，普通文档加可靠搜索可能已经足够。

OKF 知识包中应该放什么？

• 业务指标、定义、负责人、计算规则与例外；
• 系统、API、数据集、表、事件模式与依赖关系；
• 产品规则、架构决策、运行手册与升级路径；
• 合规控制、证据位置、政策与复核日期；
• 明确自动化边界的客户支持 playbook。

不要把密钥、个人数据、原始客服对话、合同或凭证直接复制到 Git 可读的知识包。“纯文件”既提高互操作性，也方便数据泄漏。分类、最小权限、保留期限和人工审核依然不可省略。

企业如何实施 OKF？

1. 选择一个边界清晰、需要真实决策的领域。例如收入指标、支持流程或生产服务，而不是“全部企业知识”。
2. 盘点来源与负责人。为每个概念记录权威来源、Owner、敏感级别、更新触发条件和下游消费方。
3. 定义小型本地规范。约定 5–10 个类型、本地必填字段、命名和正文模板，并明确这些不是基础规范的一部分。
4. 先生成，再整理。导出工具和 LLM 擅长起草；领域专家必须解决冲突、删除敏感信息并批准事实。
5. 在 CI 中验证。检查 YAML、type、保留文件、重复资源、内部链接、时间戳、敏感模式与 Owner。
6. 接入一个消费方。为 RAG 建索引或作为智能体资源提供；衡量答案正确率、来源可追溯性、检索精度与更新时间。
7. 建立运营机制。确定审核人、过期标准、访问边界，以及删除如何传播到索引与缓存。

OKF 没有解决什么？

• 权限：规范没有定义文档级或字段级访问控制。
• 身份与生命周期：路径就是概念 ID；重命名和移动需要外部迁移约定。
• 真实性与新鲜度：结构合规不代表内容正确、完整、最新或安全。
• 关系语义：链接有方向但没有类型；“依赖于”“替代”仍写在自然语言里。
• 高频状态：Git 适合审核，不适合作为多写入者的实时事务状态。
• 发现：消费方仍需知道知识包在哪里并有权访问；OKF 不会自动让公网智能体发现它。

因此，更稳妥的做法是把 OKF 试点为经过整理的知识层，而不是新的 System of Record。实时数据留在业务系统，OKF 解释它的含义、连接方式与正确用法。

OKF 会提升 SEO 或 LLM 引用率吗？

不会自动提升。Google Cloud 公告和 v0.1 规范都没有把 OKF 定义为网页抓取、搜索排名或引用信号。公开 /okf/ 目录可能方便已经知道该入口的消费方，但不能据此承诺 Google 排名、AI Overview 或 ChatGPT 引用。

公共可见性仍然依赖可索引 HTML、答案优先的结构、稳定 URL、实名作者、第一手来源、结构化数据、内部链接与有价值的原创分析。OKF 可以作为额外机器可读导出，但不应替代网站。

企业现在应该采用 OKF 吗？

我们在 2026 年 7 月的建议是：做一个可逆的小型试点。选择 20–50 个概念、一个 Owner 团队、一个智能体用例和一条可衡量工作流。格式变化时，Markdown 和 YAML 迁移成本低；即使试点失败，整理后的文档仍然有价值。

第一手资料

1. Google Cloud：Introducing the Open Knowledge Format
2. 官方 OKF v0.1 规范
3. 官方仓库与参考工具
4. 官方示例知识包
5. Andrej Karpathy 的 LLM wiki 模式
6. OKF 的 Apache 2.0 许可证

状态核查日期：2026 年 7 月 12 日。建立长期企业规范前，请再次检查版本与未解决问题。