Google Cloud推出Open Knowledge Format (OKF) 为AI代理提供供应商中立的上下文规范
•0 阅读•5分钟•开源
GoogleLLMOKFMarkdown
•0 阅读•5分钟•开源
背景
随着基础模型能力的提升,企业在实际部署时遇到的最大瓶颈仍是 上下文获取。表结构、指标定义、运行手册等散落在数据目录、内部 Wiki、代码注释等孤岛,导致每个 AI 代理都需要自行实现一套爬取‑解析‑对齐的流程。Google Cloud 将这一痛点抽象为“碎片化上下文问题”,并提出以 Open Knowledge Format (OKF) 为统一的解决方案。
OKF 规格概述
OKF 并非服务或平台,而是一套 文件层面的约定:
- 每个概念(表、数据集、指标、运行手册、API 等)对应一个 Markdown 文件;
- 文件顶部使用 YAML front‑matter,仅强制包含
type字段,其余信息由生产者自行决定; - 文件路径即概念标识,跨文件的普通 Markdown 链接形成概念图谱。
示例结构:
sales/
├── index.md
├── datasets/
│ └── orders_db.md
├── tables/
│ ├── orders.md
│ └── customers.md
└── metrics/
└── weekly_active_users.md
对应的 orders.md 可能包含如下 front‑matter:
---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---
设计原则
- 最小化主观约束:只要求
type,其余字段完全由生产者决定,保持灵活性。 - 生产者‑消费者解耦:人编写的 bundle 与自动生成的 bundle 互相可读,工具链可自由替换。
- 格式‑而非平台:OKF 与云服务、数据库或特定模型无绑定,任何文件系统、Git 仓库均可直接托管。
典型使用场景
- 元数据即代码:数据团队将 BigQuery 表和指标导出为 OKF bundle,随 SQL 代码一起提交、审查,确保文档与实现保持同步。
- 运行手册供代理调用:运维机器人读取
runbook系列 Markdown,依据跨链接快速定位所需步骤并执行。 - 跨组织知识共享:供应商可将自有目录导出为 OKF,客户方的 AI 代理无需额外集成即可直接使用。
- 开发者 Wiki 替代:将陈旧的 Notion 或 Obsidian 知识库迁移至版本化的 OKF,AI 辅助编辑保持内容最新。
与传统 RAG 的区别
| 维度 | RAG | OKF |
|---|---|---|
| 知识形态 | 原始文本块(Chunk) | 结构化概念(Markdown + YAML) |
| 更新方式 | 重新索引或增量嵌入 | 直接编辑 Markdown,立即生效 |
| 可追溯性 | 难以定位单块来源 | 文件路径 + 链接形成明确图谱 |
| 依赖组件 | 向量数据库、检索服务 | 无需专有后端,只需文件系统 |
Google 提供的参考工具
- BigQuery Enrichment Agent:演示如何将 BigQuery 元数据自动转化为 OKF bundle。
- 静态 HTML 可视化器:将 bundle 渲染为交互式文档,支持在浏览器中浏览概念图。
- 示例 bundle:包括销售数据、监控指标以及常见运行手册,帮助开发者快速上手。
关键要点
- OKF v0.1 完全基于开源的 Markdown 与 YAML,不需要额外 SDK。
- 通过统一的
type字段实现跨组织、跨平台的概念互操作。 - 与 RAG 并非竞争关系,而是提供 可编辑、版本化、可审计 的知识层,适配需要精准上下文的 AI 代理。
- Google 已将规范、工具及示例代码开源,社区可自行扩展实现。
“OKF 的价值在于把‘知识即代码’落地为文件层面的标准,让 AI 代理不再受限于各家供应商的专有目录。”——Google Cloud AI 团队
通过 OKF,企业可以把散落在内部系统的碎片化信息转化为机器可直接消费的结构化资源,为大模型在实际业务中的落地提供了可靠的上下文支撑。
本文是对第三方新闻源的主观解读。消息可能出现过时、不准确、歧义或错误的地方,仅供参考使用。点击此处查看消息源。