发生了什么
Google Cloud 在博客中介绍了 OKF 规范的最新进展：v0.1 定义了由 Markdown 文件与 YAML frontmatter 组成的可移植格式，包含一个必填字段和五项约定；v0.2 则加入 provenance、verification、freshness、attestation 等信任信号，使团队能发布可信的上下文包供自家智能体使用。
文章指出，OKF 尚未解决跨团队共享问题：每个 bundle 使用一个 git repo 虽然可移植，但无法与所描述的数据一起被搜索，无法用组织统一的身份与合规策略治理，也无法和数据团队已有的 schema、lineage、ownership 等元数据并列。
解决方案是将 OKF bundle 映射到 Knowledge Catalog 的现有类型。该平台是 Google Cloud 的智能体上下文引擎，统一索引 BigQuery、Cloud Storage、运营数据库和应用中的资产；发布只需一次性设置和一次推送，设置会注册 EntryGroup、okf-bundle 的 EntryType 以及 okf 的 AspectType。
为什么重要
这一整合把 OKF 从单团队格式提升为组织级上下文层。没有目录时，每个下游智能体都必须知道每个 bundle 的位置，难以规模化；借助 Knowledge Catalog 的统一索引，bundle 能与数据资产并列出现，并复用搜索、IAM、lineage 与跨项目发现能力。
对治理而言，这意味着智能体上下文不再游离于现有安全体系之外，而是受基于 IAM 身份的统一访问控制约束。由于每个概念都带有技术元数据和 OKF 信任信号，AI 应用可以在与数据团队相同的治理框架下消费上下文。
关键事实
OKF v0.1 定义可移植格式：Markdown 文件加 YAML frontmatter，含一个必填字段和五项约定。
OKF v0.2 加入 provenance、verification、freshness、attestation 信任信号，用于机器生成的上下文包。
Knowledge Catalog 是 Google Cloud 的智能体上下文引擎，统一索引 BigQuery、Cloud Storage、运营数据库和应用中的资产。
发布 OKF bundle 到 Knowledge Catalog：一次性设置调用 gcloud dataplex，推送交给同仓库中的 kcmd CLI。
okf AspectType 由 okf-aspect.json 定义，包含 13 个字段，覆盖完整 OKF v0.2 规范。
接下来看什么
值得关注 OKF 是否会围绕组织内共享进一步增加约定，例如 bundle 的命名、版本化或授权模型。
同时观察 Knowledge Catalog 是否会继续强化对 OKF 信任信号的利用，使 provenance、verification 等信息在检索排序和审计中发挥更大作用。