同样问“六月销售额最高的三位客户”，AI 可以选择模型字段，也可以生成语义 SQL，随后再由执行引擎落实业务定义。代表性平台采用了不同入口，不能都画成“自然语言 → JSON DSL → SQL”。
本稿从原第七章移为选读资料，按 2026 年 10 月 15 日核对的官方公开文档保留，供后续备课参考；功能状态未在本轮重新核实。
| 平台 | 业务定义放在哪里 | 查询怎样进入执行层 |
|---|---|---|
| Looker | LookML 的维度、指标和关联 | AI 选择字段、过滤、排序与条数，由 Looker 组织查询 |
| Cube | 语义模型中的维度、指标和关联 | Semantic SQL 引用指标，引擎进行语义改写与方言转换 |
| Snowflake | Semantic View | Cortex Analyst Routing Mode 优先生成语义 SQL，必要时回退标准 SQL |
| Databricks | Unity Catalog Metric View | SQL、看板与 Genie Agents 等入口使用共同指标定义 |
Looker 把查询组合交给已有语义模型。 AI 根据 LookML 元数据匹配客户、销售额和日期，确定过滤与排序；Looker 根据模型构造并执行查询。Agent 还可以配置术语和已验证查询。共享 Agent 并不会自动授予底层模型数据权限。官方机制说明。
Cube 提供面向语义层的 SQL。 指标通过 MEASURE() 引用，改写引擎在相应聚合上下文展开定义，并转换为目标数据源方言。Semantic SQL 原理。SQL API 提供 Postgres 兼容协议；访问控制还需配置身份校验与安全上下文。SQL API、身份与权限。
Snowflake 将语义 SQL 与标准 SQL 放进路由策略。 模型覆盖的指标优先使用 Semantic View；无法满足时可能回到物理表查询。因此，模型覆盖率会影响实际走哪条路。Routing Mode 页面仍标为 Preview，并建议转向 Cortex Agents；这里的预览标记针对 Routing Mode。Routing Mode。
Databricks 将指标定义与分组字段分开。 同一个指标可以按客户或月份查询，在当前分组条件下计算。Metric View 的 SQL 使用 MEASURE() 引用指标；查询时若要关联其他表，官方示例先把指标查询放入 CTE，再关联结果。查询文档。访问由 Unity Catalog 权限管理。管理文档。
Cube 和 Databricks 都出现 MEASURE()，也不能据此认为它们的解析、函数和查询范围完全相同。
“查六月销售额”可能只需一次查询；“为什么下降”可能要比较月份、定位客户，再检查商品变化。多步 Agent 负责选择和衔接这些动作，语义模型负责每一步使用的指标与执行规则。
从这些方案可以看到，是否使用 Agent，与是否使用语义层，是两个不同的设计选择。多调用几次工具，不能代替金额、粒度和数据范围的定义。
先看已有环境，再用同一组业务问题验收：
| 方案 | 采用时的主要前提 |
|---|---|
| Looker | 已有或愿意维护 LookML、Explore 和相应数据访问配置 |
| Cube | 准备维护语义模型、服务部署及客户端身份接入 |
| Snowflake | 数据与权限处于 Snowflake 环境，并确认所用功能状态 |
| Databricks | 使用 Unity Catalog 及支持相应能力的计算资源 |
试用记录应包含实际模型、指标定义、查询或调用记录、返回结果和用户身份。再核对同额发票、月底边界、无权限字段和模型未覆盖问题，观察系统怎样回答或拒绝。
用实际题库中的结果、澄清和拒绝记录比较效果。
有的路线让 AI 选择语义字段，有的让 AI 编写语义 SQL，也有平台保留物理 SQL 回退。比较时要看业务定义由谁执行、权限在哪里落实、哪些请求真正经过模型。
Foggy 当前资料中的实践入口采用 TM/QM 配合 DSL；语义 SQL 作为架构专题讨论。实际接入时按所选版本重新核对能力。