过去几年自然语言查询数据库的技术路线看起来非常直接用户提出一个问题大模型读取数据库 Schema、生成 SQL数据库执行查询再把结果返回给用户。随着模型代码能力提高这条链路迅速成为 Data Agent 最常见的产品形态。但当 Data Agent 从演示环境进入企业生产系统后问题很快发生了变化。企业并不只需要一段“可以运行”的 SQL而是需要一段在业务含义、指标口径、表关系、访问权限和执行成本上都正确的 SQL。语法错误通常会被数据库直接拦截业务语义错误却可能返回一份看似合理、实际上无法用于决策的结果。大模型看到的是 customer_id、order_table、revenue_amount 和 risk_score业务人员看到的却是客户生命周期、合同状态、历史交易、流失风险和下一步经营动作。两者之间缺少的不是更长的提示词而是一套稳定、统一、可复用、可以被机器执行的业务语义。Semantic Layer 因此开始承担新的角色它不再只是 BI 系统中统一指标口径的一层模型而正在成为 Data Agent 理解企业数据、生成业务查询并调用底层执行引擎的中间语言。图 1传统 NL2SQL 与 Semantic Layer 中介架构的职责差异1. NL2SQL 的瓶颈不只是模型不会写 SQL在结构简单、表数量有限的测试环境中大模型可以直接读取 Schema根据用户问题生成 SQL。但真实企业数据仓库通常包含数百张表、上千个字段、多种 SQL 方言以及散落在文档、报表和分析师经验中的业务规则。Spider 2.0 就是为这种企业级 Text-to-SQL 工作流设计的评测框架其数据库经常包含超过 1000 个字段任务还可能要求理解元数据、方言文档和项目代码。基于 o1-preview 的代码 Agent 在 Spider 2.0 上只完成了 17.0% 的任务而在传统 Spider 1.0 上达到 91.2%。这组差异说明企业 NL2SQL 并不是学术基准的简单放大版。模型不仅要生成代码还要在庞大的物理结构中完成业务概念落地、数据关系发现和执行路径选择。业务词汇无法与物理字段直接对应用户询问“今年高价值客户的流失风险”数据库中通常没有一列直接叫作“高价值客户”。这一概念可能来自过去 12 个月消费金额、购买频率、利润贡献、客户等级和合同状态的组合。模型即使找到了客户表也未必知道企业内部对“高价值”使用的是哪一套正式定义。同一个指标可能存在多个合法口径“收入”可以表示下单金额、确认收入、回款金额、含税收入也可以表示扣除退款和折扣后的净收入。不同部门使用的时间字段、订单状态和汇率规则也可能不同。模型生成的 SQL 在语法上完全正确结果却可能与财务或经营口径不一致。JOIN 不是字段匹配而是业务关系客户、订单、合同、商品、库存和渠道之间并不总是通过清晰主外键连接。某些关系需要经过映射表某些连接键需要清洗某些事实表只能在特定时间范围内关联。直接让模型从字段名称猜测 JOIN 路径很容易生成能够执行但重复计数、漏数或扩大数据范围的查询。权限与治理无法只靠 Prompt企业查询还受到行级权限、列级权限、敏感数据分级、数据域边界和计算资源限制约束。随着 Schema 扩大把全部规则塞进上下文不仅成本高也很难保证每一次生成都严格遵守。权限必须成为查询规划与编译过程中的正式约束而不是模型“应该记得”的提示。图 2用户使用业务语言提问数据库却使用物理结构存储数据2. 为什么 Semantic Layer 正在成为“业务编译器”2026 年 6 月发布的一项研究提出了 Semantic Layer 中介的企业 NL2SQL Agent。系统没有让大模型直接读取原始 Schema 并生成最终 SQL而是先让模型基于经过整理的语义层生成一种中间表示——Semantic Model QuerySMQ再由确定性引擎将 SMQ 编译为 SQLite、BigQuery 或 Snowflake 方言的 SQL。这套架构最重要的地方不是多加了一个组件而是重新划分了大模型与确定性软件的职责。2.1 模型负责理解和表达意图识别用户要分析的业务对象、指标、维度、时间范围与筛选条件把自然语言转换为结构化的业务查询在复杂任务中规划子问题并组合编译器返回的可靠构件。2.2 Compiler 负责把意图落到物理数据把业务指标映射到正式计算表达式根据已声明的关系图选择物理表与 JOIN 路径注入过滤、时间、去重和权限规则生成目标数据库方言的 SQL并提供查询预览或验证结果。图 3SMQ 只表达“查什么”Compiler 决定“如何在物理数据库中执行”这种设计与程序编译器的逻辑相似。开发者使用高级语言表达程序意图再由编译器转换成机器可执行指令Data Agent 则使用业务中间表示描述查询意图再由 Semantic Layer 和编译器转换成数据库可执行 SQL。论文中的语义模型把物理表包装为带有业务名称的模型并暴露维度、度量和指标。每一个元素同时包含给模型阅读的人类可读描述以及用于编译的精确物理表达式。抽象名称与物理字段被分离之后模型可以围绕业务含义推理编译器则负责处理真实表名、列名和方言。论文还把跨模型 JOIN 维护为独立关系图。连接路径、连接键和必要的清洗表达式只声明一次编译器便可以在后续查询中重复使用避免模型每次重新发现 JOIN。2.3 为什么中间表示比直接 SQL 更容易治理自由 SQL 的搜索空间几乎不受约束。模型需要一次完成表选择、列选择、JOIN、聚合、过滤、排序、窗口函数和方言适配任何一个错误都可能使结果失效。SMQ 这类中间表示则把查询约束在指标、筛选条件和分组维度等有限结构内使系统能够在执行前完成结构校验、权限检查和规则展开。中间表示还提供了可观测性。系统可以记录模型选择了哪个指标、使用了哪些筛选条件、编译器展开了哪些表关系以及最终 SQL 如何形成。当结果异常时团队能够区分问题来自用户意图解析、语义定义、编译规则还是复杂 SQL 的组合过程。3. 94.15% 的结果说明了什么又不能说明什么上述研究使用 Gemini 3 Pro在 547 项 Spider2-snow 任务上完成 515 项报告 94.15% 的执行准确率在当时官方榜单中位列第三。这一结果明显高于直接围绕原始 Schema 工作的多种公开方案但不能简单写成“Gemini 3 Pro 的 NL2SQL 准确率达到 94.15%”。结果来自一个完整系统强推理模型、逐数据库整理的语义层、SMQ 中间表示、确定性编译器、受约束的 Agent 循环和多后端执行框架。论文也明确指出语义层包含零样本基线无法获得的领域知识因此对比反映的是整套系统的价值而不是模型的独立能力。图 4研究报告的分来源执行准确率原生 Snowflake 类样本仅 18 项结果背后的三点启示第一企业 NL2SQL 的性能杠杆可能不只在模型而在语义层质量。论文将语义层描述为主要维护面补充缺失字段、改进元素描述、声明 JOIN 关系能够直接改善对应数据库上的准确率。第二确定性编译并不意味着所有 SQL 都能被模板化。论文中的 SMQ 只覆盖选择、过滤、分组和已声明 JOIN 等常见分析核心窗口函数、递归 CTE 和复杂子查询仍可能由 Agent 基于编译器构件进一步组合。业务编译器的目标不是消灭模型推理而是把最容易出错、最应该稳定的部分从自由生成中剥离出来。第三语义层同样存在过拟合风险。如果团队为了提高某一评测集的准确率把问题特定线索不断写进字段描述语义层可能从通用业务知识退化为隐藏答案。论文因此提出应把语义层当作代码管理描述用于表达可复用知识结构信息进入类型化字段并接受评审和回归测试。4. 从 BI 语义层到 Agent 语义层Semantic Layer 并不是一个新概念。传统 BI 架构已经长期使用语义层统一指标、维度、数据关系和过滤规则使不同报表围绕同一份业务定义计算结果。但 BI 语义层主要回答的是“这个指标怎么算”。当使用者从 BI 工具变成能够规划、调用工具和执行任务的 Agent 后语义层需要回答的问题明显扩大这是什么业务对象、对象之间是什么关系、当前处于什么状态、哪些规则必须遵守、当前用户能访问什么以及分析完成后可以执行什么动作。图 5Agent 需要的语义资产从指标计算扩展到实体、规则、权限与行动Agent 语义层需要增加的五类能力Entity把分散在多张表中的数据抽象为客户、订单、合同、设备、供应商和库存等稳定业务对象。Relationship明确客户拥有哪些订单、订单对应哪些商品、商品由哪些供应商提供而不是让模型临时猜测字段连接。Rule把高价值客户、库存异常、合同逾期、有效订单等判断条件编码为可复用规则。Permission定义用户和 Agent 可以读取哪些实体、字段与记录以及可以执行哪些类型的操作。Action把创建工单、调整状态、触发审批、通知负责人等操作定义为受控接口并配套审计、审批与回滚机制。因此面向 Agent 的 Semantic Layer 正在与 Ontology 靠近。前者通常从指标、维度和查询逻辑出发后者从业务对象、关系、状态与动作出发。两者结合后企业才能形成一个既能回答问题又能够在治理边界内推动业务流程的 AI 基础层。5. Palantir、Databricks、Microsoft 与 Snowflake 正在走向哪里主流数据平台和企业 AI 厂商的产品起点不同但它们正在共同解决同一个问题如何在物理数据与 AI Agent 之间建立一个受治理的业务语义接口。图 6四条路线的起点不同但共同方向都是为 Agent 提供业务上下文与治理边界Palantir从业务对象与 Action 出发Palantir Ontology 将现有数据源映射为对象、属性和关系并通过 Object Type、Link Type 和 Action Type 描述企业业务世界。Palantir 文档把 Action Type 定义为一组对对象、属性和链接进行修改的事务性操作Action 还可以包含提交后触发的副作用。这使 Ontology 不只是查询语义层也成为业务应用和行动执行的基础。Databricks从湖仓治理与指标语义出发Databricks 的 Unity Catalog business semantics 用于集中定义和管理业务指标与 KPI并把 Metric View 作为核心实现。Metric View 将度量定义与用于分组、筛选和聚合的维度分离使指标能够定义一次、在运行时被统一查询。Databricks 还增加了显示名称、格式与同义词等 Agent 元数据帮助 Genie Agents 等自然语言工具更准确地解释数据。Microsoft从 Semantic Model 走向跨域 OntologyMicrosoft Fabric IQ 的 Ontology 被定义为供团队、Agent 和工作流共同使用的受治理业务模型包含实体类型、关系、属性、规则和约束并可绑定 OneLake 中的真实数据。Microsoft 还支持从现有 Semantic Model 生成 Ontology把已经沉淀在 BI 模型中的表、关系和业务定义进一步转化为 Agent 可使用的企业上下文。Snowflake把语义概念直接存入数据库Snowflake Semantic Views 是数据库 Schema 级对象可以定义逻辑表、业务实体关系、事实、维度和指标。Cortex Analyst 读取 Semantic View 中的业务定义并针对物理表生成 SQL。Snowflake 还通过 Verified Query Repository、评估和建议机制把经过人工验证的问题与 SQL 用于提高结果准确性和可信度。不是简单的“谁像谁”Palantir 更强调业务对象和行动系统Databricks 与 Snowflake 更靠近指标、查询和数据平台治理Microsoft 正在连接 Power BI Semantic Model、Ontology 与 Data Agent。它们并不完全等价但都在承认同一个事实Agent 不能只面对裸表。6. 下一代企业 Data Agent 的架构会发生什么变化传统 Data Agent 原型通常可以简化为“数据源—LLM Agent—SQL—查询结果”。这套架构开发快却把大量复杂性推给模型Schema 变化、指标定义、权限规则和方言差异都需要通过上下文临时注入。更稳定的企业架构会将职责拆成多个可治理层数据湖仓负责存储与计算Semantic Layer 负责指标、维度、逻辑关系和查询规则Compiler 将业务查询转换为可验证 SQLOntology 描述业务实体、状态、权限和 ActionAgent Runtime 负责理解意图、规划任务、调用工具和组合结果最终业务动作通过受控接口执行。图 7从数据源到业务行动的分层架构每一层都有明确责任与治理边界这套架构带来的四个变化第一Agent 与物理数据结构解耦。只要业务语义接口保持稳定底层表结构、字段名称和计算引擎发生变化时Agent 不需要重新读取全部 Schema。第二查询过程从黑盒生成变成可审查编译。团队可以在执行前检查指标、筛选条件、JOIN 路径、权限和资源预算并在问题出现后定位到具体层。第三业务知识从散落的 SQL 和文档变成可复用资产。指标、实体、关系和规则能够同时服务 BI、应用、Agent 和自动化流程。第四Data Agent 才可能安全地从问数走向行动。只有当实体、状态、权限和 Action 被正式定义之后Agent 才能在明确边界内创建工单、触发审批或修改业务状态。7. 企业应该如何建设这层“业务编译器”Semantic Layer 不是把现有数据目录换一个名字也不是一次性整理全部企业数据。更现实的路径是从业务价值高、数据边界清晰、评价标准明确的主题域开始建立可以被真实问题反复验证的语义闭环。图 8从一个主题域开始先建立可验证查询再逐步开放业务行动第一步选择有边界的业务域不要从“让 Agent 回答企业所有数据问题”开始。可以选择销售经营、供应链库存、客户流失或设备运维等主题域明确用户、数据源、核心问题和结果验收标准。第二步把语义资产当作正式产品为每一个指标、实体、关系和规则指定定义、负责人、版本和适用范围。语义层需要像代码一样经历评审、测试、发布和变更管理而不是由个人在 Prompt 中临时维护。第三步设计受约束的业务查询语言中间表示不一定必须采用论文中的 SMQ 格式但应具备相同原则模型表达业务目标不直接填写任意物理表名和字段名查询结构能够被静态检查指标、维度和实体引用来自受治理目录。第四步将确定性规则收回系统指标展开、JOIN 选择、时间口径、默认过滤、权限判断、SQL 方言和资源限制都应该尽量由确定性组件实现。模型适合处理模糊意图和长尾组合不应该重复猜测已经能够被规则化的知识。第五步建立真实问题验证集评估不能只看 SQL 是否执行成功。企业需要沉淀真实业务问题、标准结果、允许误差、权限角色、查询成本和失败类型并在语义定义或编译器升级后持续回归。第六步按照风险等级开放 Action先从只读查询开始再增加建议生成、人工确认、审批后执行和自动执行。每一种 Action 都需要明确前置条件、权限、审计日志、幂等性和回滚方案。Agent 能否行动不应由模型自我判断而应由业务规则和授权系统决定。8. Semantic Layer 也不是万能答案把语义层放到 Agent 与数据库之间并不会自动解决企业数据质量、组织协作和知识维护问题。相反它把原来隐藏在 SQL 和个人经验中的问题集中暴露出来首先错误的语义定义会被大规模复用。如果“净收入”本身定义错误确定性编译器只会更稳定地生成错误结果。因此业务负责人、数据团队与治理团队需要共同承担语义资产的准确性。其次语义覆盖度与维护成本存在张力。覆盖太少Agent 仍然频繁回到自由 SQL覆盖太多团队可能陷入庞大而难以持续更新的建模工程。语义层应优先覆盖高频、高价值和高风险问题。再次中间表示必须保留逃生通道。企业分析存在大量窗口函数、复杂时间逻辑和临时探索完全封闭的 DSL 可能限制能力。更合理的方式是让编译器提供经过验证的基础构件由 Agent 在严格规则下完成长尾组合。最后Semantic Layer 与 Ontology 的融合会带来新的治理问题。当系统从“定义指标”扩展到“定义可以执行的动作”错误的影响将从回答不准确升级为业务状态被修改。查询治理与行动治理必须分层设计。结语Data Agent 的竞争正在从模型能力转向语义系统能力SQL 不会消失它仍然是企业数据系统最重要的执行语言之一。变化在于SQL 不应该继续承担业务语义的全部表达责任大模型也不应该直接面对不断变化、缺少业务含义的物理 Schema。未来更合理的分工是用户使用自然语言表达业务问题模型把问题转换为结构化业务意图Semantic Layer 提供指标、维度、关系和规则确定性编译器生成并验证 SQLOntology 补充实体、状态、权限和 ActionAgent 在治理边界内完成分析与执行。因此Semantic Layer 正在从 BI 时代的指标层升级为 Agent 时代的中间语言。下一代 Data Agent 的核心竞争力也许不再是谁能生成最复杂的 SQL而是谁能够建立一套更准确、更完整、更可验证的企业语义系统。Data Agent 不该直接写 SQL它需要一层“业务编译器”