--- title: "Open Knowledge Format（OKF）：企业实施指南（2026）| Wavect" canonical: https://wavect.io/zh/blog/open-knowledge-format-okf/ language: zh description: "了解 OKF 如何用 Markdown 和 YAML 组织 AI 智能体知识、它与 RAG 和 MCP 的区别，以及企业何时值得实施。" image: "https://wavect.io/img/blog/headers/header_open-knowledge-format-okf.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 17 分钟 阅读 · 2026年7月12日 最近审核 2026年8月12日 [**下一篇**](/zh/blog/software-maintenance-cost-benchmark-dach-saas/) # Open Knowledge Format（OKF）是什么：工作原理、适用场景与企业实施 要点速览 Open Knowledge Format（OKF）是 Google Cloud 推出的厂商中立 v0.2 规范，用带 YAML 前置元数据、相互链接的 Markdown 文件包装企业知识。v0.2 仍只把 type 设为始终必填的概念字段，同时加入可选的来源信息、从验证记录推导的信任等级、生命周期与新鲜度信号，以及可证明计算。它用 generated.at 取代 timestamp，并用前置元数据中的 sources 取代正文引用列表，同时允许消费方兼容读取 v0.1。OKF 不会取代 RAG、MCP、OpenAPI、向量库、权限、检索评估或治理，也不是经确认的 SEO、抓取或 LLM 引用信号。务实做法是在一个明确负责的领域开展 20 到 50 个概念的可逆试点，并加入 CI 验证、访问控制、具名审核者、stale_after 日期与可量化的检索质量。 **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 官方公告](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing) 指出，缺少的是格式，而不是又一个服务。 如果你评估的是具体实现而不是格式，可以阅读我们的 [OpenKB 评测与 RAG 对比](/zh/blog/openkb-review-vs-rag/) ，了解这款开源知识编译器、独立证据，以及企业部署仍需补齐的控制。 如果问题是跨资源、记忆和技能的运行时上下文，请阅读我们的 [OpenViking 生产就绪评测](/zh/blog/openviking-agent-memory-review/) ，其中分析文件系统检索、AGPL 风险、运营成本和有限试点。 如果你要解决的是员工和智能体如何共享受治理权威来源这一系统问题，我们的 [AI 就绪企业 Wiki 架构指南](/zh/blog/ai-ready-company-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 规范](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md) 的核心设计。 ## 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 是 | OKF 不是 | | --- | --- | | 交换经过整理和维护的知识的可移植格式 | 托管式知识管理平台 | | Markdown、YAML 前置元数据与链接 | 数据库、向量库或正式知识图谱 | | 生产方与消费方之间的契约 | 检索、排序或工具执行算法 | | 人类、Git、搜索工具和智能体都可读取 | 权限、数据防泄漏或审计系统 | | 可通过自定义元数据和正文扩展 | 固定的企业分类法或本体 | | 采用 Apache 2.0 的开放 v0.2 规范 | 已经成熟且广泛采用的标准 | ## OKF 与 RAG、MCP、OpenAPI、llms.txt 有什么区别？ 它们是可以组合的不同层，并不是互相替代的产品。 | 层 | 回答的问题 | 擅长 | 不负责 | | --- | --- | --- | --- | | **OKF** | 可移植知识应如何包装？ | 上下文、元数据、链接、版本和交换 | 检索、执行与授权 | | **RAG** | 这次请求应加载哪些片段？ | 搜索、排序、分块检索与 grounding | 定义可移植的创作格式 | | **MCP** | 智能体如何发现并调用工具或资源？ | 运行时能力、类型化操作、实时系统访问 | 标准化工具背后的知识 | | **OpenAPI** | HTTP API 如何工作？ | 端点、参数、模式与客户端生成 | 记录广泛的企业语境与决策 | | **llms.txt** | LLM 应从网站哪里开始？ | 公共网站发现与导航 | 定义完整的内部知识包 | | **知识图谱** | 有哪些实体与类型化关系？ | 正式语义、图查询与推理 | 像普通文字一样易于维护 | 一个实用架构是：领域负责人在 Git 中维护 OKF，CI 自动验证，RAG 索引知识包，MCP 服务器提供搜索和实时系统访问；智能体只加载少量相关概念，并在需要时沿链接深入。OKF 是持久知识源，RAG 是选择机制，MCP 是运行时入口。 ![Kevin Riedl](/img/team/kevin.webp) "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 吗？ | 适合立即试点 | 适合等待或保持简单 | | --- | --- | | 多个智能体需要同一套知识 | 文档规模小且稳定 | | 知识被困在多个目录和 wiki | 眼前问题是搜索质量而非可移植性 | | 重视 Git 审核、审计与厂商中立 | 非技术编辑者没有合适界面 | | 已有领域 Owner 与治理能力 | 无人负责新鲜度和权限 | | 能接受年轻的 v0.2 规范继续演进 | 必须使用最终版或认证标准 | 我们在 2026 年 8 月的建议是：做一个可逆的小型试点。选择 20–50 个概念、一个 Owner 团队、一个智能体用例和一条可衡量工作流。只在能回答真实运营问题时使用 v0.2 的来源与新鲜度字段，并保留原始材料。格式变化时，Markdown 和 YAML 迁移成本低；即使试点失败，整理后的文档仍然有价值。 ## 常见问题 ### Open Knowledge Format（OKF）是什么？ Open Knowledge Format（开放知识格式，简称 OKF）是 Google Cloud 发布的开放、厂商中立规范。它使用带 YAML 前置元数据的 Markdown 文件组织知识，使人类和 AI 智能体无需专有 SDK 即可读取和交换同一套内容。当前版本是 v0.2。 ### OKF 文档中哪个字段是必填项？ 每个概念文档中只有 `type` 始终必填。 `title` 、 `description` 、 `resource` 与 `tags` 是推荐字段；v0.2 的来源、信任、生命周期、新鲜度和计算字段均为可选，除非其自身合约另有要求。 ### OKF 会取代 RAG 或 MCP 吗？ 不会。OKF 规定知识如何打包和交换；RAG 负责检索相关内容；MCP 负责连接智能体与工具或数据源。三者可以组合使用。 ### OKF 能直接提升 SEO 或 AI 引用率吗？ 目前没有官方依据表明 OKF 是搜索排名、抓取或引用信号。它不能替代可索引网站、权威来源或网页结构化数据。 ### OKF 可以用于生产环境吗？ OKF v0.2 是一项年轻规范，已提供可用的结构、来源、信任、新鲜度和证明约定。企业生产部署仍需自行建立访问控制、CI 强制检查、检索评估、审核流程、运行时安全和治理。 ### OKF 与 Open Knowledge Foundation 有关吗？ 没有。两者使用相同缩写。本文讨论的是 Google Cloud 于 2026 年 6 月推出的 Open Knowledge Format，而非非营利组织 Open Knowledge Foundation。 ## 第一手资料 1. [Google Cloud：Introducing the Open Knowledge Format](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing) 2. [官方 OKF v0.2 规范](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md) 3. [官方仓库与参考工具](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf) 4. [官方示例知识包](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf/bundles) 5. [Andrej Karpathy 的 LLM wiki 模式](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) 6. [OKF 的 Apache 2.0 许可证](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/LICENSE.md) *状态核查日期：2026 年 8 月 12 日。建立长期企业规范前，请再次检查版本与未解决问题。* ## 最终思考 Open Knowledge Format 的吸引力来自它只标准化了极少内容。一个始终必填的字段、常见文件、普通链接和宽容的消费契约，让经过整理的知识能在人类、智能体、目录和模型栈之间自由移动。v0.2 加入来源、信任、新鲜度和可证明计算等实用信号，同时没有把格式变成平台。 这些字段提供证据，不负责强制执行。OKF 仍不会自动选出正确上下文、执行权限、保护执行器、保证审核发生，也不会自己获得 AI 引用。把它作为检索与工具之下的持久知识层，在可移植性已经造成成本的地方试点，并在知识包变成另一个被遗忘的 wiki 之前建立治理。 ## 你可能也喜欢.. [**MCP、RAG、Agent Skills 与 Custom GPTs 对比** 选择正确 AI 上下文和集成层的实用决策框架。](/zh/blog/mcp-vs-rag-vs-agent-skills-vs-custom-gpts/) [**AI Enablement 与普通 AI 咨询对比** 比较真正可运行、归团队所有的 AI 系统与只交付策略的咨询。](/zh/compare/ai-enablement-vs-generic-ai-consultancy/) 智能体工程 ## 继续浏览此集群 编程智能体、MCP、上下文系统、评估与可靠自动化控制。 [从核心文章开始**AI 智能体的图工程：知识图谱什么时候值得做？**](/zh/blog/graph-engineering-ai-agents/) - [OpenViking 2026 评测：文件系统式记忆适合生产吗？](/zh/blog/openviking-agent-memory-review/) - [TrueForge 评测：开源 Agent Harness 是否达到生产要求？](/zh/blog/trueforge-agent-harness-review/) - [智能体可读的网站：llms.txt、Markdown 镜像，以及会坏在哪里](/zh/blog/agent-readable-website-llms-txt-markdown-mirrors/) - [本地化 URL 会搞坏 hreflang：只保留一个英文 slug](/zh/blog/english-slugs-vs-localized-urls-hreflang/) - [AI 智能体能用你的产品，还是只能读到它？](/zh/blog/can-an-ai-agent-use-your-product/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 17 分钟 阅读 · 2026年7月12日 最近审核 2026年8月12日 [**下一篇**](/zh/blog/software-maintenance-cost-benchmark-dach-saas/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/open-knowledge-format-okf/#webpage", "@type": "WebPage", "dateModified": "2026-07-12", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-12", "url": "https://wavect.io/zh/blog/open-knowledge-format-okf/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Open Knowledge Format（OKF）是 Google Cloud 推出的厂商中立 v0.2 规范，用带 YAML 前置元数据、相互链接的 Markdown 文件包装企业知识。v0.2 仍只把 type 设为始终必填的概念字段，同时加入可选的来源信息、从验证记录推导的信任等级、生命周期与新鲜度信号，以及可证明计算。它用 generated.at 取代 timestamp，并用前置元数据中的 sources 取代正文引用列表，同时允许消费方兼容读取 v0.1。OKF 不会取代 RAG、MCP、OpenAPI、向量库、权限、检索评估或治理，也不是经确认的 SEO、抓取或 LLM 引用信号。务实做法是在一个明确负责的领域开展 20 到 50 个概念的可逆试点，并加入 CI 验证、访问控制、具名审核者、stale_after 日期与可量化的检索质量。", "articleBody": " 博客概览/AI 与智能体/智能体工程 Open Knowledge Format（OKF）是什么：工作原理、适用场景与企业实施 要点速览 Open Knowledge Format（OKF）是 Google Cloud 推出的厂商中立 v0.2 规范，用带 YAML 前置元数据、相互链接的 Markdown 文件包装企业知识。v0.2 仍只把 type 设为始终必填的概念字段，同时加入可选的来源信息、从验证记录推导的信任等级、生命周期与新鲜度信号，以及可证明计算。它用 generated.at 取代 timestamp，并用前置元数据中的 sources 取代正文引用列表，同时允许消费方兼容读取 v0.1。OKF 不会取代 RAG、MCP、OpenAPI、向量库、权限、检索评估或治理，也不是经确认的 SEO、抓取或 LLM 引用信号。务实做法是在一个明确负责的领域开展 20 到 50 个概念的可逆试点，并加入 CI 验证、访问控制、具名审核者、stale_after 日期与可量化的检索质量。 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 对比，了解这款开源知识编译器、独立证据，以及企业部署仍需补齐的控制。 如果问题是跨资源、记忆和技能的运行时上下文，请阅读我们的 OpenViking 生产就绪评测，其中分析文件系统检索、AGPL 风险、运营成本和有限试点。 如果你要解决的是员工和智能体如何共享受治理权威来源这一系统问题，我们的 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 的三条合规规则是什么？ 每个非保留 Markdown 文件都必须包含可解析的 YAML 前置元数据。 每个前置元数据块必须包含非空的 type。不存在中央类型注册表。 保留文件存在时必须符合指定结构。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 是OKF 不是 交换经过整理和维护的知识的可移植格式托管式知识管理平台 Markdown、YAML 前置元数据与链接数据库、向量库或正式知识图谱 生产方与消费方之间的契约检索、排序或工具执行算法 人类、Git、搜索工具和智能体都可读取权限、数据防泄漏或审计系统 可通过自定义元数据和正文扩展固定的企业分类法或本体 采用 Apache 2.0 的开放 v0.2 规范已经成熟且广泛采用的标准 OKF 与 RAG、MCP、OpenAPI、llms.txt 有什么区别？ 它们是可以组合的不同层，并不是互相替代的产品。 层回答的问题擅长不负责 OKF可移植知识应如何包装？上下文、元数据、链接、版本和交换检索、执行与授权 RAG这次请求应加载哪些片段？搜索、排序、分块检索与 grounding定义可移植的创作格式 MCP智能体如何发现并调用工具或资源？运行时能力、类型化操作、实时系统访问标准化工具背后的知识 OpenAPIHTTP API 如何工作？端点、参数、模式与客户端生成记录广泛的企业语境与决策 llms.txtLLM 应从网站哪里开始？公共网站发现与导航定义完整的内部知识包 知识图谱有哪些实体与类型化关系？正式语义、图查询与推理像普通文字一样易于维护 一个实用架构是：领域负责人在 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？ 选择一个边界清晰、需要真实决策的领域。例如收入指标、支持流程或生产服务，而不是“全部企业知识”。 盘点来源与负责人。为每个概念记录权威来源、Owner、敏感级别、更新触发条件和下游消费方。 定义小型本地规范。约定 5–10 个类型、本地必填字段、命名和正文模板，并明确这些不是基础规范的一部分。 先生成，再整理。导出工具和 LLM 擅长起草；领域专家必须解决冲突、删除敏感信息并批准事实。 在 CI 中验证。检查 YAML、type、保留文件、重复资源、内部链接、参与者与日期格式、来源 ID、过期概念、计算合约、敏感模式与 Owner。 接入一个消费方。为 RAG 建索引或作为智能体资源提供；衡量答案正确率、来源可追溯性、检索精度与更新时间。 建立运营机制。确定审核人、过期标准、访问边界，以及删除如何传播到索引与缓存。 OKF 没有解决什么？ 权限：规范没有定义文档级或字段级访问控制。 重命名与删除：路径就是概念 ID，因此移动需要外部迁移约定。v0.2 增加了 deprecated，但", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "Google Cloud：Introducing the Open Knowledge Format", "url": "https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing" }, { "@type": "WebPage", "name": "官方 OKF v0.2 规范", "url": "https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md" }, { "@type": "WebPage", "name": "官方仓库与参考工具", "url": "https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf" }, { "@type": "WebPage", "name": "官方示例知识包", "url": "https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf/bundles" }, { "@type": "WebPage", "name": "Andrej Karpathy 的 LLM wiki 模式", "url": "https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f" }, { "@type": "WebPage", "name": "OKF 的 Apache 2.0 许可证", "url": "https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/LICENSE.md" } ], "dateModified": "2026-08-12", "datePublished": "2026-07-12", "description": "Open Knowledge Format（OKF）是 Google Cloud 推出的厂商中立 v0.2 规范，用带 YAML 前置元数据、相互链接的 Markdown 文件包装企业知识。v0.2 仍只把 type 设为始终必填的概念字段，同时加入可选的来源信息、从验证记录推导的信任等级、生命周期与新鲜度信号，以及可证明计算。它用 generated.at 取代 timestamp，并用前置元数据中的 sources 取代正文引用列表，同时允许消费方兼容读取 v0.1。OKF 不会取代 RAG、MCP、OpenAPI、向量库、权限、检索评估或治理，也不是经确认的 SEO、抓取或 LLM 引用信号。务实做法是在一个明确负责的领域开展 20 到 50 个概念的可逆试点，并加入 CI 验证、访问控制、具名审核者、stale_after 日期与可量化的检索质量。", "headline": "Open Knowledge Format（OKF）：企业实施指南", "image": "https://wavect.io/img/blog/headers/header_open-knowledge-format-okf.svg", "inLanguage": "zh", "keywords": "Open Knowledge Format, OKF, AI 智能体, 知识管理", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/open-knowledge-format-okf/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/open-knowledge-format-okf/", "wordCount": 646 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/agent-engineering/", "name": "智能体工程", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/open-knowledge-format-okf/", "name": "Open Knowledge Format（OKF）：企业实施指南（2026）| ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Open Knowledge Format（开放知识格式，简称 OKF）是 Google Cloud 发布的开放、厂商中立规范。它使用带 YAML 前置元数据的 Markdown 文件组织知识，使人类和 AI 智能体无需专有 SDK 即可读取和交换同一套内容。当前版本是 v0.2。" }, "name": "Open Knowledge Format（OKF）是什么？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "每个概念文档中只有 type 始终必填。title、description、resource 与 tags 是推荐字段；v0.2 的来源、信任、生命周期、新鲜度和计算字段均为可选，除非其自身合约另有要求。" }, "name": "OKF 文档中哪个字段是必填项？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不会。OKF 规定知识如何打包和交换；RAG 负责检索相关内容；MCP 负责连接智能体与工具或数据源。三者可以组合使用。" }, "name": "OKF 会取代 RAG 或 MCP 吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "目前没有官方依据表明 OKF 是搜索排名、抓取或引用信号。它不能替代可索引网站、权威来源或网页结构化数据。" }, "name": "OKF 能直接提升 SEO 或 AI 引用率吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "OKF v0.2 是一项年轻规范，已提供可用的结构、来源、信任、新鲜度和证明约定。企业生产部署仍需自行建立访问控制、CI 强制检查、检索评估、审核流程、运行时安全和治理。" }, "name": "OKF 可以用于生产环境吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "没有。两者使用相同缩写。本文讨论的是 Google Cloud 于 2026 年 6 月推出的 Open Knowledge Format，而非非营利组织 Open Knowledge Foundation。" }, "name": "OKF 与 Open Knowledge Foundation 有关吗？" } ] } ```