企业 Agent 为什么答得很顺，却不一定可靠
图：Agent 知识治理示意，知识从碎片进入可追溯案卷。
一个 Agent 最危险的时刻，不是它回答不上来。
是它回答得太顺了。
它能把语气调得很稳，把逻辑排得很像样，甚至给你一个看起来完全合理的结论。可你只要追问几句，麻烦就来了：这条规则来自哪份文档？这个指标到底按哪个口径算？它引用的来源还有效吗？谁允许它看到这段内容？
很多企业 AI 的幻觉，不是从模型开始的，而是从知识没有身份开始的。没有 resource，它不知道这条知识对应哪个真实资产；没有 owner，它不知道出了问题该找谁；没有 timestamp，它分不清新旧口径；没有 citation，它无法追溯判断来源；没有 permission，它甚至可能把不该看的上下文拿来推理。
一个老员工说“活跃用户”，脑子里会自动带上表、字段、口径和历史坑。Agent 没有这种组织记忆，它看到的是散在 Wiki、SQL 注释、数据目录、工单和群聊里的碎片。
Google Cloud 这次推 Knowledge Catalog 和 Open Knowledge Format，简称 OKF，要解决的就是这件事：让企业知识有身份、有来源、可引用、可治理。
当 MCP、function calling、workflow 这些能力逐渐普及，Agent 的主要失败点会从“不会调用工具”，转向“调用工具前拿错上下文”。它能查表，问题是查哪张表；它能写 SQL，问题是按哪个指标口径写；它能检索文档，问题是这份文档是否过期、当前用户是否有权使用。
这次发布的重点不是新目录，而是把来源、口径、权限和时效放进 Agent 的上下文层。
Agent 缺的不是工具，是可信案卷
过去两年，AI 圈给 Agent 装了很多“手”：MCP 让它接工具，function calling 让它调 API，workflow 让它跑流程，browser use 和 code interpreter 让它能查网页、处理文件、写代码。
可真到企业里，决定 Agent 能不能干活的，不只是它会不会调用工具，而是它有没有一套可信案卷：指标怎么算，哪张表能用，字段是不是废弃，权限边界在哪里。
没有这层知识，Agent 不会沉默。
它会把猜测包装成结论。
所以“知识决定 Agent 的能力下限”不是一句漂亮话。模型会写 SQL 只是上限；DAU 到底按设备、账号还是事件去重，events_20260101 这种表能不能合并，某个字段是不是三个月前已经废弃，当前用户有没有权限看这段数据，才决定它会不会稳定做对。
Knowledge Catalog 和 OKF 被低估，也是在这里。它们看起来像“知识管理”，实际做的是一组更具体的动作：给资产标身份，给判断挂来源，给字段接业务口径，给用户套权限边界，给变更留下审阅痕迹。
Knowledge Catalog 不是文档库
Google Cloud 的 Knowledge Catalog，可以先理解为面向企业 Agent 的上下文与治理产品。产品页给它的定位是“Always-on context and governance for your agents”。它卖的不是一个目录页，而是 Agent 调用知识时的上下文和权限约束。
传统数据目录主要服务人：我去哪儿找表，字段什么意思，负责人是谁，数据什么时候更新。Knowledge Catalog 面向的是另一种工作方式：Agent 在回答、检索、分析、执行任务时，能不能持续拿到可信上下文，并且被权限和治理规则约束住。
这也解释了它和 RAG 的差别。RAG 是检索模式，企业 RAG 当然也可以做治理；Knowledge Catalog 更像上下文控制面，负责资产身份、权限、业务语义、verified queries、metadata harvesting，再把这些上下文喂给检索和 Agent。
OKF 和 Knowledge Catalog 的关系，要放在这条线上看。Knowledge Catalog 是产品层，试图把企业级上下文和治理做成服务；OKF 是格式层，试图给知识一个开放、可读、可迁移的包装方式。一个做云服务，一个做文件格式，目标都是让知识能被 Agent 读取和审计。
开源 repo 里到底有什么
这里有个很容易误读的边界：Google 没有把 Knowledge Catalog 云服务本体开源。GoogleCloudPlatform/knowledge-catalog 这个 repo，README 里明确写着：This repository and its contents are not an official Google product.
它更像一套围绕 Knowledge Catalog 做上下文工程的开源工具箱。顶层主要有四块：
agents/ 是更完整的新主线，里面有 agents/mdcode 和 agents/enrichment。前者提供 kcmd，也就是 Metadata as Code 工具，把 Knowledge Catalog / Dataplex metadata 拉成本地 YAML 和 Markdown，再同步回 Catalog；后者是 Python enrichment agent，有 table、doc、context_overlay 三种模式，可以把 BigQuery、Drive 文档、GitHub repo、用户反馈、查询历史这些上下文揉进 catalog metadata。
okf/ 是 Open Knowledge Format 这条线。里面不只有 spec，还有 Python 参考 enrichment agent、viewer、测试、样例 bundle。okf/bundles/ 里已经签入 GA4、Stack Overflow、Bitcoin 三套样例，每套都有可以直接打开的 viz.html。
samples/ 是面向云服务 API 的样例，包括 discovery agent 和 enrichment sample。前者演示怎么基于 Catalog Search API 做发现，后者演示怎么生成、审阅、发布 metadata enrichment。
toolbox/ 也放了 mdcode 和 enrichment，更像早期或并行的 TypeScript 工具包线。这里容易混淆：toolbox/ 和 agents/ 不是同一条线，repo 也不是一个被开源的完整云服务。
三条线合在一起，可以看出 Google 在做什么：mdcode 负责和官方 Knowledge Catalog 双向同步，okf 负责 vendor-neutral 的 Markdown bundle，agents/enrichment 负责让 Agent 帮你生产和维护上下文。企业数据上下文正在变成可版本化、可 diff、可审查、可由 Agent 生产和消费的文件工件。
它让 metadata 可以被拉到本地、diff、审阅，再同步回 Catalog。知识不只是被“存起来”，而是变成 Agent 工作流里的工程对象。
OKF 像工程交接卷宗
图：OKF bundle 如何把散落知识变成可追溯知识包。
OKF 最好别理解成“又一种文档格式”。它想装进去的 knowledge，不是原始数据本身，而是围绕数据和系统的 metadata、context，以及经过整理的判断和说明。比如一张表到底代表什么，一个指标怎么算，一个 API 为什么废弃，一个 runbook 什么时候用，哪些说法有来源。
一个 OKF bundle 就是一棵 Markdown 目录。除 index.md、log.md 这类 reserved filenames 外，目录里的每个非保留 .md 文件都是一个 Concept。文件路径去掉 .md，就是 Concept ID；文件顶部的 YAML frontmatter 放机器要读的字段，最少必须有非空 type；正文 Body 放人和模型要读的解释、schema、例子和判断。
一个极短的 OKF concept 可以长这样：
---
type: Metric
title: Active Users
description: 活跃用户指标口径
tags: [metrics, ga4]
---
口径：去重统计 [events](../tables/events.md) 里的 `user_pseudo_id`。
# Citations
[1] [GA4 BigQuery Export docs](https://support.google.com/analytics/answer/7029846)这几行里已经能看到 OKF 的关键选择。type 给知识一个粗粒度身份，title 给人一个显示名，正文说清口径，Markdown link 把 metric 连到 table，Citation 交代来源。它没有试图替代底层数据 schema，也没有把关系语义写死成复杂本体；它只是让一块知识可以被识别、被引用、被检查。
它刻意没做三件事：没有 schema registry，没有 central authority，也不要求指定工具。消费者要足够宽容：未知 type、未知字段、断掉的 cross-link、缺 index.md，都不应该直接拒绝整个 bundle。
这是一把双刃剑。宽容消费降低了采用成本，适合跨团队、跨工具流转；但没有强 schema 和 typed edges，也意味着语义约束、审核流程、权限映射要靠外部系统补上。
这就是它像“工程交接卷宗”的地方。它不是上来要求全公司统一知识本体，而是先把关键资产、使用口径、历史判断、引用证据和相互关系装订在一起，让下一个工程师，或者下一个 Agent，不必从散落的群聊、Wiki 和 SQL 注释里重新考古。
两个实现细节：分片折叠和写入保护
只看 OKF spec，很容易觉得它太轻。reference implementation 里有两处工程判断，说明它不是纯格式设计。
第一个细节在 BigQuerySource。很多数据仓库都会有 events_20210101、events_20210102、events_20210103 这种日分片表。参考实现没有把这些物理表机械展开成一堆孤立概念，而是识别类似 events_YYYYMMDD 的数字后缀模式，把它们折叠成稳定的 tables/events_，同时记录 wildcard、shard_count、first_shard、last_shard。
这不是小优化。人类说“GA4 事件表”，通常指一个逻辑表族；Agent 如果看到几百张日分片表，很容易把物理存储结构误当成业务结构。OKF 在这里做的是概念归一化：让知识包更接近业务理解，同时保留分片范围和证据。
第二个细节在 write_concept_doc()。EnrichmentRunner 分成 BQ pass 和 web pass：前者从 BigQuery 抽 schema、分区、行数、字段信息这些硬事实，后者再用配置允许范围内的文档页面补语义、引用和关联路径。
但 web pass 不能随便覆盖 BigQuery 抽出来的事实。如果一份已有 BigQuery Table 文档被改写后，原来的 # Schema 字段集合变少，或者 # Citations 条目数变少，工具会拒绝写入。这个刹车，比“LLM 会写 Markdown”重要得多。再用 viewer 生成一个 self-contained viz.html，OKF bundle 不依赖后端也能被打开、浏览和审阅。
图：repo 中 GA4 sample bundle 的 viz.html，左侧是 concept graph，右侧是选中 concept 的 frontmatter 和正文。
别急着神化 OKF
现在把 OKF 说成行业标准还太早。它仍然是 v0.1 Draft，type 没有中心注册表，迟早会遇到命名混乱；Markdown link 是一条有向、无类型的边，可以表达“有关系”，但不能天然说明这是 join、depends-on、owner 还是 deprecated by；路径即 ID 很直观，也会带来迁移成本。
更麻烦的问题不在格式里。谁能改知识？谁来审核？敏感字段如何脱敏？指标废弃后怎么通知 Agent？不同团队、不同权限、不同环境之间的知识边界如何映射？这些不是 OKF 一个文件格式能包办的。
所以我不想把 OKF 神化成“AI 知识库终于统一了”。它还不是标准，只是把企业知识交给 Agent 的一次早期尝试。
过去我们问模型会不会推理，Agent 会不会调用工具。进企业后，问题会变成：组织知识能不能被识别、交接、审查、更新，并稳定地交给 Agent 使用。
没有可审计的知识目录，Agent 很难稳定处理指标、权限和来源问题。
如果把这篇文章也按 OKF 拆成 concept，它不应该只是一篇推文，而应该是一份能被 Agent 继续引用的知识包。文件路径可以是 analysis/google-knowledge-catalog-okf.md，这个路径就是 Concept ID；frontmatter 给机器读，正文给人和 Agent 读，Citations 把判断拴回来源。
最小版本大概会长这样：
---
type: Analysis
title: 谷歌发布 Knowledge Catalog 云服务和 OKF 协议，发力 Agent 知识治理
description: 分析 Google Cloud Knowledge Catalog 与 OKF 如何把企业知识转成 Agent 可读取、可审计、可迁移的上下文。
tags: [ai-agent, knowledge-catalog, okf, knowledge-governance]
---
这篇文章解释 [Knowledge Catalog](../products/knowledge-catalog.md) 与 [OKF](../specs/okf.md) 的关系：
Knowledge Catalog 处理企业 Agent 的上下文治理，
OKF 处理知识的开放包装和跨工具交换。
# Citations
[1] [Google Cloud: Knowledge Catalog](https://cloud.google.com/products/knowledge-catalog)
[2] [Google Cloud Blog: How the Open Knowledge Format can improve data sharing](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/)
[3] [OKF v0.1 Spec](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md)
[4] [GoogleCloudPlatform/knowledge-catalog](https://github.com/GoogleCloudPlatform/knowledge-catalog)这不是排版彩蛋，而是这篇文章主张的自我约束：一段判断如果想交给 Agent 复用，就要说清楚它是什么、连到哪里、依据来自哪里。
也想请懂数据目录、知识图谱、RAG、Agent 工程的读者帮忙校准：按 OKF 的尺度看，这个 type 是否合适，哪些判断还缺 citation，哪些概念应该拆出去，哪些 link 只是口头关系？
