谷歌 OKF：开放知识格式

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

企业AI系统失败的最大原因之一不是模型——而是知识。

现代软件工程有Git来对源代码进行版本控制。每次更改都被跟踪、审查和可复现。然而，企业知识很少遵循同样的纪律。业务概念分散在维基、运维手册、API规范、架构文档和内部操作手册中，每个都在独立演进，几乎没有一致性或可追溯性。

随着AI代理成为企业工作流中的一等参与者，知识需要Git带给代码的同样工程严谨性。它必须是版本化的、连接的、可移植的，并且对人类和机器都可理解。

这正是谷歌云开放知识格式（OKF）旨在解决的问题。OKF于2026年6月12日发布，是一个开放规范，标准化了企业知识如何使用Git原生仓库进行表示、版本化和关联。

在许多方面，OKF代表了从对代码进行版本控制到对企业知识进行版本控制的转变——为AI代理、RAG系统和企业副驾驶提供可靠的基础，以消费可信的、演进中的组织上下文。

在本文中，我们将探讨OKF是什么、其设计原则、它在生产AI架构中的位置，以及为什么它可能成为企业AI工程的基础标准之一。

1、什么是谷歌开放知识格式（OKF）？

开放知识格式（OKF）是谷歌云推出的一个开放、厂商中立的规范，用于以人类和AI代理都能理解的方式表示组织知识。OKF没有定义新的平台、数据库或专有协议，而是定义了一个简单、可移植的格式，使用标准Markdown文件和YAML元数据来打包知识。

OKF仓库的核心只是一个Markdown文件目录。每个文件代表一个单一的概念——如数据表、API端点、指标、操作手册、运维手册、业务策略或架构决策——包含两个部分：机器可读的YAML前置元数据和人类可读的Markdown正文。这使得每个概念对开发者来说都易于理解，同时AI系统无需自定义SDK或专有工具即可轻松解析。

与传统文档（知识分散在维基、PDF和内部门户中）不同，OKF将知识组织成相互关联的概念集合。元数据描述概念是什么，而标准Markdown链接捕获它与其他概念的关系，允许AI代理导航知识，而不是将每个文档视为孤立的文本片段。

一个简化的OKF仓库可能如下所示：

knowledge/

├── apis/
│   └── payment-api.md
├── datasets/
│   └── transactions.md
├── runbooks/
│   └── payment-latency.md
├── metrics/
│   └── payment-success-rate.md
└── index.md

每个概念包含结构化元数据，然后是实际文档：

---
type: API Endpoint
title: Payment API
description: Processes customer payment requests
resource: https://internal.company.com/apis/payment
tags:
  - payments
  - api
---

# Payment API

The Payment API is responsible for...

YAML告诉AI什么是该概念，并提供路由、过滤和发现的元数据。Markdown以人类可读和可维护的格式解释概念。两者共同创建了一个可移植、版本控制且对人类和AI代理都可消费的知识工件。

最重要的是要理解，OKF是一个知识表示标准，而不是检索系统或AI框架。它不替代RAG、向量数据库或知识图谱。相反，它标准化了企业知识的创作、组织和交换方式，以便任何AI系统都能一致地消费它。从这个意义上说，你可以将OKF视为组织知识的OpenAPI——为不同工具和平台提供通用的、可互操作的格式。

2、为什么OKF不仅仅是文档

乍一看，OKF看起来像是一组Markdown文件。但其目的远不止于文档。

传统文档是为人类阅读而设计的。然而，AI系统需要的不仅仅是描述性文本——它们需要结构化上下文。它们需要知道资源代表什么、谁拥有它、它与其他资源的关系，以及它是否权威。

OKF通过将人类可读内容与机器可读元数据相结合来弥合这一差距。每个知识对象携带语义信息，使AI应用程序能够在不完全依赖自然语言解释的情况下识别、发现和推理企业资产。

这使得同一知识库可以跨多个系统使用。开发者可以将其作为文档浏览，搜索引擎可以索引它，AI代理可以检索相关概念，治理平台可以验证所有权和元数据——所有这些都来自同一个事实来源。

换句话说，OKF将知识视为可重用的工程资产，而不是静态文档。它不是为人类和机器维护单独的表示，而是建立了一个两者都能一致消费的单一标准化格式。

文档告诉你某物是什么。OKF提供了允许AI系统理解该知识如何融入更大企业上下文的结构。

这种从文档到结构化知识工件的转变，正是使OKF对生产级AI系统特别有意义的原因。

3、OKF背后的设计原则

OKF不是为了成为另一个文档框架而设计的。它围绕一组原则设计，这些原则使企业知识更容易在人类和AI驱动的工作流中创建、维护和消费。

• 开放和厂商中立。 OKF是一个开放规范，使组织能够在不绑定特定供应商或平台的情况下共享和交换知识。
• Git原生。 基于Markdown和纯文本构建，OKF与基于Git的工作流无缝集成，包括版本控制、拉取请求和代码审查。
• 人类可读和机器可读。 知识易于工程师用Markdown编写，而结构化元数据使其易于AI系统和自动化工具消费。
• 可组合和可互操作。 单个知识对象可以链接在一起，允许多个工具和AI应用程序一致地消费相同的知识。
• 设计上可扩展。 组织可以定义自定义概念类型和元数据，同时保持符合核心规范。

这些原则共同使OKF不仅仅是一个文档格式——它们为企业知识建立了一个可移植、标准化且AI就绪的基础。

4、OKF如何在生产AI系统中工作

想象你正在为一个大型企业构建一个AI运营助手。一位工程师问道：

"支付服务延迟已超过SLO。我应该首先检查什么？"

回答这个问题并不像检索运维手册那么简单。AI需要理解更广泛的运营上下文，包括：

• 服务定义和所有权
• 服务级别目标（SLO）
• 基础设施依赖
• 监控仪表板
• 最近的部署历史
• 事件响应手册
• 已知的运营问题

没有标准化的知识模型，AI必须跨架构文档、监控门户、Git仓库、事件管理系统和运营手册进行搜索——然后推断这些部分如何相互关联。

使用OKF，这些知识对象已经连接好了。

payment-service.md
        │
        ├── payment-api.md
        ├── payment-slo.md
        ├── payment-dashboard.md
        ├── deployment-pipeline.md
        ├── incident-runbook.md
        └── dependency-map.md

AI不是检索不相关的文档，而是从支付服务作为中心知识对象开始，沿着其关系导航到相关的API、仪表板、SLO、部署管道、依赖关系和运营程序。

5、从文档检索到知识导航

在传统的RAG管道中，AI代理搜索多个仓库——运维手册、仪表板、架构文档、API和运营指南——然后依靠LLM来推断这些部分如何组合在一起。关系是隐式的，迫使模型在每次交互中重建企业上下文。

OKF改变了这种范式。AI不是从不相关的文档开始，而是从一个知识对象（如服务、业务能力或应用程序）开始，然后沿着其预定义的关系发现API、依赖关系、监控仪表板、运营手册、部署管道和其他连接的资产。

这将检索转化为知识导航。AI不是拼凑孤立的信息，而是遍历企业知识的结构化网络，从而获得更丰富的上下文、更准确的推理和基于组织架构的响应。

6、OKF vs RAG vs 知识图谱

最大的误解之一是将OKF视为RAG或知识图谱的替代品。事实并非如此。

这些技术解决不同的问题，并且相互补充。

• RAG从大型知识仓库中检索相关的企业信息。
• 知识图谱建模实体及其关系，用于图遍历和推理。
• OKF标准化了企业知识在到达这些系统之前如何被表示、版本化和连接。

在实践中，OKF可以成为企业的规范知识层。AI代理通过RAG检索内容，使用知识图谱导航关系，而OKF提供标准化的事实来源，保持两者同步。

它们不是竞争技术，而是形成企业AI堆栈的不同层次。

7、为什么OKF对AI工程师很重要

大多数关于OKF的讨论都集中在文档上。真正的价值在于观察生产AI系统是如何构建的。

当今的企业AI应用程序很少孤立运行。单个用户请求可能需要检索架构知识、发现API、理解服务依赖关系、检查运营手册，并在代理产生答案或执行操作之前调用外部工具。挑战不在于推理模型——而在于碎片化的企业上下文。

OKF通过引入一个位于企业和AI应用程序之间的规范知识层来解决这个问题。每个代理不需要实现自己的检索逻辑和关系映射，知识被建模一次并在平台上一致地重用。

考虑几个生产场景：

代理AI。 多代理系统在规划或执行之前花费大量精力建立上下文。使用OKF，编排器可以从服务或业务能力作为知识对象开始，遍历其连接的API、依赖关系、所有权、SLO、运维手册和部署管道。规划阶段变得确定性，因为关系已经被建模，而不是由LLM推断。

模型上下文协议（MCP）。 MCP标准化了模型与工具交互的方式。OKF通过标准化这些工具暴露的知识来补充它。由OKF支持的MCP服务器可以提供结构化的、版本控制的企业上下文，而不是返回孤立的文档或临时元数据，使上下文可移植到任何MCP兼容的客户端。

企业副驾驶。 内部副驾驶通常为单个查询检索数十个文档，并依靠LLM组装连贯的响应。随着文档增长，检索质量越来越难以维护。使用OKF，副驾驶检索一个连接的知识对象并遵循其显式关系，减少不必要的检索并改进基础。

开发者助手。 现代开发者助手需要的不仅仅是源代码。它们需要架构决策、服务所有权、API契约、部署工作流、运营手册和依赖信息。OKF提供了这些工件的统一表示，使助手能够理解系统是如何工程化的，而不是简单地搜索仓库。

平台工程。 平台团队维护服务目录、黄金路径、基础设施标准、CI/CD管道、安全策略和运营指导。将这些发布为结构化知识对象，使组织中的每个AI应用程序都能消费相同的工程标准，而无需为每个平台构建自定义集成。

企业搜索。 传统企业搜索检索按相关性排序的文档。AI原生搜索越来越多地需要检索实体和关系。OKF将检索从以文档为中心的搜索转向以知识为中心的导航，其中结果不仅仅是一个文档，而是企业本身的连接表示。

随着组织从孤立的副驾驶转向生产AI代理舰队，知识层的质量变得与语言模型的质量同样重要。模型将继续改进，但没有结构化、连接和版本控制的企业知识，每个AI应用程序将花时间重建上下文而不是对其进行推理。

这就是OKF变得重要的地方——不是作为另一种文档格式，而是作为生产AI系统的基础设施。

8、结束语

随着AI系统变得更加自主，企业知识的质量将越来越多地决定AI结果的质量。仅靠更好的模型无法弥补碎片化、不一致或不连接的知识。

谷歌云的开放知识格式（OKF）是将企业知识视为工程资产的重要一步——一个结构化、版本控制、可移植且为人类和AI设计的资产。它是否成为行业标准还有待观察，但它反映了企业架构的更广泛转变：从以文档为中心的知识管理转向AI原生的知识工程。

对于构建生产系统的AI工程师、架构师和平台团队来说，这种转变值得关注。下一代代理应用程序不仅需要更好的模型——它们需要更好的知识基础。

原文链接: Google's Open Knowledge Format (OKF): A Better Way to Build Knowledge for AI Agents

汇智网翻译整理，转载请标明出处