语义层成 Agent 新底座：从 Oracle、Google 和学术界这一周的共识，看 OntiCards 的卡位
Oracle 让 Agent 选 fixed trusted reports 而不是写 SQL，Google 把 Measures + Graph 并入 BigQuery，SIGMOD 2026 Semantic-Layer-mediated NL2SQL 把 Spider 2.0 准确率从 17% 推到 94.15%——三家在同一周押注同一件事，语义层正式成了 Data Agent 的新底座。
三家在同一周做了同一件事
过去一周，语义层（Semantic Layer）突然成为数据圈最热的关键词。
Oracle 在官方博客发文呼吁：让 Agent 选 fixed trusted reports，不要让它直写 SQL。具体做法是把分析师已经审过的查询封装成"报表工具"，Agent 只需要从这些工具里挑一个并填入参数。即便有人绕过 prompt 注入获得了 40+ 个 MCP 漏洞，Agent 能访问到的数据范围仍然是固定的。
Google Cloud 在 8 月 13 日发布《Using BigQuery Graphs with measures for trusted agentic workloads》，把 Graph 和 Measures 同时放进同一套受治理的数据模型里。在西雅图冬季夹克销量下降 12% 的零售案例中，SQL/Mesure 只能告诉你"降了多少"；而 Graph 能告诉你"为什么降"——是哪个配送中心、哪条供应商链、哪场风暴拖累了交付。Agent 必须同时拥有"calculator"和"map"才能负责地给出建议。
学界也没闲着。SIGMOD 2026 收录的 A Semantic‑Layer‑Mediated Agent for Natural Language to SQL 论文，把 Gemini 3 Pro 接到一个 curated semantic layer 上、用 Semantic Model Query（SMQ）做中间表示，在 Spider 2.0‑snow 547 题上达到 94.15% 执行准确率，位列官方榜第三。同期一篇分析指出，o1‑preview 在同一基准上只有 17.0%。17.0% 对 94.15%，几乎是一倍和五倍的差距。
Oracle、Google、学界——三路玩家在同一周押注同一件事。这不是巧合，而是工程共识正在形成："原始 Schema → 大模型直出 SQL" 这条路线，在企业里已经走不通。
为什么"模型直出 SQL"路线突然不香了？
把过去三年的工程经验拼起来看，模型直出路线有三层天花板，而每一层都恰好是语义层解决的问题。
第一层业务词汇不映射字段。用户问"高价值客户的流失风险"，数据库里没有一列叫这个名字。要把它算出来，需要业务侧提供"高价值"的定义（最近 12 个月消费金额 + 利润贡献 + 合同状态），模型并不知道你公司用的是哪个版本。
第二层指标口径冲突。Revenue 在财务是含税应收，在销售部门是订单金额，在客服中心是 GMV 减去退款。让模型在 prompt 里提示"请使用财务口径"治标不治本——切换业务时模型会忘记。
第三层JOIN 路径靠猜。客户表、订单表、合同表之间的关联往往是隐式的，需要业务侧提供关系地图。让模型自己猜 join，最常见的产物是重复计数或漏掉关键记录。
Spider 2.0 把这三点全部推到了极端：1000+ 字段、跨方言、跨 5+ 张表的真实企业 schema。o1‑preview 在这个基准上只完成 17.0% 的任务，恰好说明"模型聪明"和"模型能干活"是两件事。
把语义层加进架构之后，模型的角色从"独立写完 SQL"切换成"表达意图"——模型只需要回答"用户在问什么业务对象、用哪个指标、在什么时间窗口和筛选条件下"，剩下的编译（指标展开、表选择、JOIN 路径、权限注入）由语义层和下游编译引擎负责。Spider 2.0 从 17% 跳到 94.15%，原因不是 Gemini 比 o1 强 5 倍，而是把模型不该干的事从模型手上拿走了。
三层语义层 + 业务编译器的实践路线
为了让 Agent 真正变得可信，主流玩家开始把语义层扩展到三层：指标层（Measures）+ 实体层（Entities）+ 关系层（Relationships）。每一层独立维护、独立治理，下游的 Agent 编译引擎把它们编到可执行 SQL。
- Google BigQuery Graph with Measures（Preview）：在 Property Graph DDL 上直接定义 MEASURE（SUM/AVG/COUNT DISTINCT 等），与节点 KEY 绑定，避免 Graph 展开后重复计数。强调 zero ETL——企业不必先建独立图数据库。
- Oracle Trusted Reports：把查询模板固化为"报表工具"，Agent 在工具池里挑一个并填参数；查询逻辑不可以再被模型自由修改，从源头杜绝凭空构造 SQL。
- 蚂蚁 Agentar-SQL：用 Agentar-Scale-SQL 框架在 BIRD-SQL 上霸榜；某头部城商行试运营查询准确率 > 92%，较传统方案提升 3 倍以上。
- 阿里瓴羊"超级数据分析师"：把"问数 / 解读 / 报告"三个 Agent 编排起来，电商业务人员取数从 2 小时缩短到 10 秒——背后是统一的指标语义层。
- Snowflake Cortex Analyst + Semantic Views：把 dbt Semantic Layer / MetricFlow 的指标定义直接编译进 BI Agent 的 prompt。
| 路线 | 语义层形态 | 模型角色 | 重点解决 |
|---|---|---|---|
| 传统 NL2SQL | 无 | 直接生成 SQL | 模型能力 |
| Oracle Trusted Reports | 固化报表工具 | 选择工具 + 填参 | 可重复性 / 安全 |
| BigQuery Graph + Measures | 节点 + 边 + Measure 三层 | 表达业务问题 | 可治理性 |
| Semantic‑Layer‑mediated NL2SQL | 业务对象 + 指标 + 关系 | 翻译为 SMQ | 准确率 + 可审计 |
| OntiCards 数据卡片 | 实体 + 字段语义 + 关系 + 术语 | 由问数 Agent 调度 | 落地 + 闭环 |
可以看到，所有路线都在把"模型不该干的事"从模型手上移出去。区别只在于把这件事做成 BI 报表、做成 Graph、做成 dbt 指标还是做成业务对象——但骨架都是：模型表达意图，语义层负责编译与治理。
OntiCards 的语义层怎么"两手抓"
回到 OntiCards 自家：四层架构 中第二层「数据卡片层」，本质上就是一套面向 Agent 的语义层工程实现。我们没有把它做成 Graph、也没有做成 dbt，而是做成业务侧能直接理解、能直接治理的"数据卡片"。
一张数据卡片长这样：
- 实体（业务对象）：订单 / 商品 / 客户 / 配送中心（与你在意的事一一对应）
- 字段（业务字段而非物理字段）："高价值客户"、"本月新客"、"已签未发货"这种业务概念
- 关系：实体之间的业务关联（谁为谁下单、谁给谁供货）
- 质量门禁：哪些字段必须非空、哪些值必须在指定范围、哪些关联必须成立
相比 BigQuery 的 Graph 模型，OntiCards 的卡片更靠近业务：业务人员可以直接定义"高价值客户"，不需要写 Property Graph DDL。相比 dbt 的指标层，我们多了一层术语库——同一件事可能被叫做"销售额"、"营收"、"GMV"，术语库负责把多个口语化的叫法统一指向同一个业务对象。
相比 Oracle 的 Trusted Reports，我们更轻：Agent 不需要每次都从固化报表池里挑选——它可以临时查询新指标，前提是这些指标已经在卡片里被治理过。当新指标进入卡片时，质量门禁会自动跑一遍；不合格，Agent 永远看不到它。
这就是为什么说 OntiCards "正中靶心"——这一波语义层趋势不是某一家厂商的发明，而是整个行业向同一个方向收敛；OntiCards 一开始就把数据和 Agent 解耦成四层（接入 / 卡片 / 问数 / 消费），只是行业现在才意识到这条路是必要的。
怎么评估一个语义层是否合格？
如果你打算给自家 Agent 接入语义层（无论是采购还是自建），可以用以下四步快速体检：
- 业务可读：业务人员能直接参与定义。一个不能让业务理解和编辑的语义层，最终会退化成"数据团队二次维护的 Schema"。
- 指标有口径：每个业务指标必须能解释"在哪个时间窗口、按哪个状态、扣掉哪些项"才算定义过。
- 关系可表达：跨表 JOIN 不能靠工程师用 prompt 提示 Agent 临时拼凑；必须由语义层提供显式关系图。
- 治理可闭环：指标错误、口径漂移、字段缺失应当能在语义层就被拦截，而不是在数据分析师复核时才被发现。
如果你的语义层在四步上都过关，但 Agent 准确率仍然上不去——那大概率问题在数据接入层（数据质检与对账），不在语义层。换句话说，语义层不是万能解药，但它解决了 Agent 规模化最难的一半问题。
参考来源
有关语义层与本体（Ontology）的区别，可以参考 OntiCards 路线图；想直接体验"卡片驱动取数"，欢迎联系我们（hello@onticards.com）申请开通测试账号。定价 与金融行业方案 也已就绪。
