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

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

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

OKF 要解决什么问题？

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

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

如果你评估的是具体实现而不是格式，可以阅读我们的 OpenKB 评测与 RAG 对比，了解这款开源知识编译器、独立证据，以及企业部署仍需补齐的控制。

如果你要解决的是员工和智能体如何共享受治理权威来源这一系统问题，我们的 AI 就绪企业 Wiki 架构指南覆盖权威知识、权限、检索、受控写入与 30 天试点。

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]
status: stable
generated: { by: human:finance-owner, at: 2026-08-12T09:00:00Z }
verified: { by: human:controller, at: 2026-08-12T10:00:00Z }
stale_after: 2026-11-12
sources:
  - id: finance-policy
    resource: https://docs.example.com/finance/mrr
    title: 财务政策
---

# Definition

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

[^finance-policy]: 财务政策

只有 type 始终必填；title、description、resource 与 tags 仍是推荐项。v0.2 新增可选的来源、信任、生命周期、新鲜度与计算字段。生产方仍可添加自定义字段，消费方应保留无法识别的字段。这种宽松契约仍是官方 OKF v0.2 规范的核心设计。

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

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

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

OKF 从 v0.1 到 v0.2 有哪些变化？

v0.2 保留三条合规规则，同时让智能体维护的知识更易检查。它没有引入中央模式，而是新增几组可选字段：

• 来源：sources 记录概念依据的材料。每个来源可以包含稳定的 id、标题、作者、使用次数与最后修改日期。Markdown 脚注可以引用来源 ID，为具体陈述建立归因。
• 信任：generated 记录谁或什么生成了当前内容，verified 记录后续核验。消费方据核验者推导出未验证、机器确认或人工审核等级。这些是提示信号，不是访问控制。
• 生命周期与新鲜度：status 可以是 draft、stable 或 deprecated。stale_after 给出一个绝对日期，超过后消费方应警告或拒绝使用。
• 可证明计算：新的 Attested Computation 概念类型把获准计算与运行时、类型化参数、执行器、回执字段和确定性证明器绑定。OKF 存储合约和检查方式，但不自行执行计算。

有两项字段变化需要迁移。generated.at 取代 v0.1 的 timestamp，前置元数据中的 sources 取代正文 # Citations 列表。v0.2 消费方可以回退读取两种旧格式，因此团队可以逐步迁移。根目录 index.md 现在也可声明 okf_version: "0.2"。

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，只打开真正相关的概念。
• 可查询的信任与新鲜度。消费方可以区分未验证内容和人工审核内容，并在超过 stale_after 日期后发出警告。

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

OKF 知识包中应该放什么？

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

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

企业如何实施 OKF？

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

OKF 没有解决什么？

• 权限：规范没有定义文档级或字段级访问控制。
• 重命名与删除：路径就是概念 ID，因此移动需要外部迁移约定。v0.2 增加了 deprecated，但仍未定义删除传播或 tombstone。
• 真实性与执行：结构合规与信任字段都不能证明内容正确，也不能证明审核确实执行。
• 关系语义：链接有方向但没有类型；“依赖于”“替代”仍写在自然语言里。
• 高频状态：Git 适合审核，不适合作为多写入者的实时事务状态。
• 发现：消费方仍需知道知识包在哪里并有权访问；OKF 不会自动让公网智能体发现它。

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

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

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

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

企业现在应该采用 OKF 吗？

我们在 2026 年 8 月的建议是：做一个可逆的小型试点。选择 20–50 个概念、一个 Owner 团队、一个智能体用例和一条可衡量工作流。只在能回答真实运营问题时使用 v0.2 的来源与新鲜度字段，并保留原始材料。格式变化时，Markdown 和 YAML 迁移成本低；即使试点失败，整理后的文档仍然有价值。

第一手资料

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

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