随着企业把 AI agent 从实验原型推向生产，数据团队发现一个根本问题：能访问数据，不等于理解数据。一个 agent 要准确回答复杂业务问题，需要多种上下文——表结构、数据血缘、治理策略、业务定义。但这些上下文不是同一类东西。知道数据在哪里，和知道如何用 SQL 计算指标，是两件不同的事。很多企业把组织层面的宽泛上下文（来自结构化或非结构化文档的元数据）与确定性的业务语义（定义净收入、流失率等指标的精确 SQL 公式、连接路径、过滤规则）混在一起，以为一个数据目录或 BI 工具就能同时搞定资产发现和精确计算。现实中，没有单一工具能承担 agentic AI 的全部负载。

Google Cloud 的方案是把这两层分开，再原生打通。Knowledge Catalog 负责宽泛的企业上下文：它聚合结构化表和非结构化文档的元数据，让 agent 发现资产、检查数据质量、追踪端到端血缘、尊重列级隐私标签、查看企业政策文档。LookML 负责确定性的数学语义：Looker 的建模语言编码了经过生产验证的语义逻辑——多粒度连接保护、条件过滤器、精确 KPI 公式，agent 不需要在运行时猜测 SQL 数学。今天宣布正式可用（GA）的，就是 LookML 语义语言索引进入 Knowledge Catalog。Looker 业务逻辑自动索引进去后，Gemini Enterprise 和自定义 agent 同时获得企业级发现能力和确定性 BI 语义。

为什么必须要有确定性语义？LLM agent 直接连原始数据库表时，即使有表描述和业务术语表，仍然要自己推断表之间的数学关系。没有显式规则，agent 容易掉进两个陷阱。一是指标定义漂移：不同 text-to-SQL agent 可能对净收入、获客成本这类基础 KPI 给出互相矛盾的公式，忽略领域特定的会计规则（比如只有 order_status = ‘Complete’ 才确认收入，或者按活跃服务天数分摊年合同）。二是朴素连接扇出：复杂 schema 里常有发票、行项目、退款之间的一对多、零对多关系。没有预先建模的连接关系和对称聚合规则，agent 生成的 SQL 会把行数放大，虚增财务数字。Knowledge Catalog 和 Looker 一起解决这个问题：在 LookML 里建模一次，语义就能在 Google Cloud 的 AI 生态里到处使用。

之前目录集成只能捕获浅层的文件级指针和基本仪表盘清单。这次发布后，LookML 的确定性语义成为 Knowledge Catalog 上下文图里的第一类图层。agent 在图中找到一个指标时，同时能看到它的精确定义、连接路径、以及回到源表的血缘。同步默认开启，生产 LookML 的更新会近实时反映到 Knowledge Catalog。元数据默认索引，Gemini Enterprise 无需自定义 agent 代码或单独的数据存储，直接用内置只读技能和混合搜索，在一个步骤里查询技术 schema、业务词汇表和索引的 LookML 逻辑，再传给联邦 BigQuery 连接器生成 SQL。自定义 agent 可以通过 LookupContext API 访问同样的上下文包。

索引覆盖多个实体层级。LookML models 层捕获描述元数据、数据库连接路由、include 层次、数据验证测试，以及模型到 Explore、View、Dashboard 的父子映射。LookML Explores 层索引完整连接逻辑——type、sql_on、基数（如多对一的扇出保护）、foreign_key、required_joins、sql_where，还捕获强制过滤护栏（always_filter、access_filter）、继承的维度和度量、预置 starter queries。LookML Views 和字段层提取列级编译后的 SQL 表达式、主键、维度组时间框架、字段同义词、派生表转换逻辑（包括 SQL 和原生派生表、分区键、聚簇键）。仪表盘、Looks 和磁贴层则记录 UI 创建和 LookML 定义的仪表盘、可视化磁贴，带过滤器、图表类型、所有权和使用统计。用户能从底层 BigQuery 表一路看到单个仪表盘磁贴的表级和列级血缘，数据工程师可以在 schema 变更引发问题前主动评估。

文章用三个架构模式对比了不同方案的效果，问题是一个跨域 prompt：“上财季按产品类别的总收入是多少，哪些区域促销政策限制适用？”模式一是基线数据库 agent，直连数仓，让 LLM 直接写 SQL，没有语义和目录上下文，看不到数据质量、PII 标签或政策文档，还容易 schema 幻觉，在多次调试中烧 token。模式二是上下文接地 agent，用 Knowledge Catalog 做发现和治理，能检索政策 PDF，但缺少语义 SQL 定义，可能漏掉条件会计规则或导致连接扇出。模式三是上下文加语义接地 agent，把 Knowledge Catalog 和带索引 LookML 的 Looker 结合，自动获取目录上下文和 LookML 连接路径、字段公式，应用状态过滤、财历、连接条件，输出准确且节省 token，还会附带一个“Open in Looker Explore”的交互式链接，用户一键就能下钻到行级明细。

对于 BI 场景，Looker Conversational Analytics 和 Knowledge Catalog + Looker 有明确分工。Conversational Analytics 是专门的 BI 助手，适合业务用户在 Looker 内针对一组精选 Explore 做自助探索和可视化。Knowledge Catalog + Looker 支持企业级 agent，在 Gemini Enterprise 里跨 BigQuery 等联邦数据源回答问题，这些问题通常同时涉及结构化表、BI 指标和非结构化文档。启用 Knowledge Catalog 后，助手能动态发现数百个 LookML 模型中的相关语义，把连接定义、指标 SQL 公式和 starter queries 传给 BigQuery 连接器，防止连接幻觉，并执行集中治理和 IAM 权限。

激活流程很直接：确认 Looker Core on Google Cloud 的第一方元数据索引已启用（新实例默认启用，存储技术元数据不额外收费）；启用 Cloud Dataplex API 和 Data Lineage API，授予 roles/dataplex.viewer、roles/looker.schemaViewer、roles/datalineage.viewer 等角色；在 Gemini Enterprise 里启用 Knowledge Catalog——以联邦查询模式附加 BigQuery（或 Spanner、Cloud SQL、AlloyDB）数据存储时会自动启用，也可以在控制台里随时开关。提问时，Gemini Enterprise 用端到端用户凭据连接 Knowledge Catalog，用户只能看到和查询自己有 IAM 权限的资产。更深入的使用方式见官方文档和 ADK agent codelab。