把 Excel、BI 语义模型、指标层、Text-to-SQL、知识图谱和 Agent 放在一条时间线上，最容易得到一个过度简化的故事：工具越来越智能，用户离数据库越来越远，最后只要用自然语言提问就够了。真实的发展并不是一条不断替换旧技术的直线。Excel 没有消失，SQL 没有消失，数据仓库也没有因为大模型出现而失去价值。变化发生在另一处：每一代产品都在重新回答一个问题——业务人员脑中的概念，怎样稳定地落到机器可执行的数据结构上。
这个问题过去由报表作者临时解决。财务在工作簿里写公式，BI 团队在模型里定义度量，数据团队在 SQL 中维护宽表，业务人员靠口头约定补上剩余含义。大模型把自然语言变成了新的入口，却没有自动消除这些分歧。相反，当一个答案可能被 Agent 继续用于调价、分配预算或修改客户账户时，口径差异的代价从“看错一张报表”升级成了“执行一项错误动作”。
企业语义层的价值，不是把字段说明写得更像自然语言，而是把业务问题编译为一份可验证、可授权、可追溯的执行契约。 这份契约至少要回答：讨论的是哪个对象，采用哪个指标版本，在哪个时间与权限范围内成立，允许沿哪些关系取数，结果能支持什么判断，又明确不能触发什么动作。
本文是“业务与数据语义对齐”系列的第一篇，讨论语义资产怎样从个人工作簿一路演进到面向 Agent 的公共基础设施，并在 2026 年 9 月 1 日这个时间截面上梳理 IBM、Microsoft、Oracle、AWS、Google、Snowflake、Databricks、Salesforce/Tableau、SAP、ServiceNow、Palantir、ThoughtSpot、Denodo、Cube、dbt 与 Wren AI 等产品分别在解决什么问题。第二篇再把这些概念带进运行时，回答企业语义怎样约束 Agent 的推理、权限与行动。
先把“语义”拆开，否则所有产品都会显得相似
行业里至少有五种不同东西被叫作语义。第一种是展示语义，即把 ad_spend_amt 改名为“广告花费”，把技术字段组织成业务人员能找到的目录。第二种是分析语义，即定义维度、度量、层级、聚合和合法关系，让不同报表对同一个问题给出一致答案。第三种是实体语义，即确认 Campaign、Target、Search Term、ASIN、库存快照和订单各自是谁，以及它们之间怎样关联。
图 1：展示、分析、实体、知识与运行语义围绕业务问题分工（概念示意）
第四种是知识语义，用分类、词表、公理、约束和来源表达概念为什么成立，以及还能推出什么。RDF、RDFS、OWL、SHACL、SPARQL 和知识图谱主要落在这里。第五种是运行语义，描述某个动作在什么前提下可以执行、由谁批准、修改哪个对象、失败后怎样恢复。Palantir 把对象之外的 Functions、Actions 与 Security 纳入 Ontology，Microsoft Fabric IQ 把语义模型、Ontology、Graph、数据 Agent 和运营 Agent放在一个体系中，原因都在于第五种语义不能再留给应用层临时补齐。
这五种语义不是成熟度排行榜。一个只做标准财务分析的团队，可能把分析语义做好就已经解决主要问题；一个负责亚马逊广告自动调价的团队，即便模型很小，也必须认真处理实体、时间、权限和动作语义。把“是否用了本体”当作先进程度，把“是否有自然语言问数”当作智能程度，都会掩盖真正的责任边界。
还要把语义与知识区分开。大模型知道 ACOS 通常表示广告投入产出比的倒数，也知道 campaign、keyword 和 ROAS 的通用含义，这属于通用或行业知识。它不知道某家公司把品牌词防守活动的目标 ACOS 设为多少，不知道日本站销售额是否含消费税，不知道新品观察期是否排除最近七天，也不知道某个 Seller Profile 当前授权给哪一家服务商。这些是企业事实、合同、状态和权限，不能靠参数中的“行业常识”猜出来。
因此，本文使用“业务语义”指组织对对象、指标、关系、时间、策略和动作边界的明确约定；使用“数据语义”指这些约定如何绑定到数据源、字段、查询与计算；使用“语义层”指承担翻译、约束和执行计划职责的系统能力。它可以由一个产品提供，也可以分布在仓库模型、指标注册表、目录、本体、策略引擎和 Agent Harness 中。
第一阶段：Excel 解决的不是“小数据”，而是业务人员拥有计算权
电子表格之所以成为长期存在的业务工具，不只是因为它容易输入数据。更关键的是，它把数据、公式、布局和解释放在同一个可直接修改的表面上。业务人员可以在一列写销量，在另一列写广告花费，再用一个公式算 ACOS；单元格引用同时承担数据血缘、计算逻辑和展示关系。语义没有独立出来，但它离业务判断很近。
这种模式的优点是反馈快。一个投手发现退货需要从销售额中扣除，可以立刻增加一列；财务决定汇率改用月末价，也可以直接替换公式。问题同样明显：工作簿中的“销售额”没有稳定身份，公式可以被复制后悄悄偏移，筛选与隐藏行会改变结果，文件名和邮件时间代替了正式版本。两个人各自拥有一份正确的表，合并后仍可能产生第三种口径。
图 2：数据、公式、说明和版本从同一个单元格展开（概念示意）
Excel 阶段留下了一个直到 Agent 时代仍然重要的教训：语义必须服务于实际决策，而不是成为脱离使用者的建模工程。后来很多语义平台拥有更强的形式和治理能力，却要求业务人员先学一套新的对象、文件和发布流程。如果修改一次广告归因口径需要跨越数周审批，团队最终仍会回到工作簿中完成真正的判断。
但另一个教训同样重要：个人可修改不等于组织可复用。电子表格适合探索和协商，不适合充当跨报表、跨应用和跨 Agent 的唯一语义真相。正确的演进不是禁用 Excel，而是让工作簿中的成熟定义可以被提升为版本化的公共契约，同时保留业务人员试验新口径的空间。
对 Amazon Ads 团队而言，Excel 最适合承载的是候选策略、临时分析和人工复核，不应独占 profile、marketplace、currency、attribution window、target identity 这些基础定义。只要某个公式会影响多个客户、多个广告账户或自动动作，它就已经越过个人工作簿的边界，需要进入可审计的模型。
第二阶段：数据仓库和 BI 把“业务视图”从报表里抽出来
数据仓库解决了数据分散和历史留存，BI 语义模型进一步解决“用户不应该每次从物理表开始理解业务”的问题。维度建模把订单、商品、客户、日期等稳定分析对象组织起来，OLAP 与 BI 模型把层级、度量、聚合和导航路径封装在报表之前。语义第一次成为可被多份报表复用的中间层。
IBM Cognos 是理解这段历史的重要样本，不能在今天的语义产品盘点中略过。Cognos Framework Manager 的模型组织文档明确区分 import view、用于处理查询复杂性的中间层，以及面向用户的 business view；一个模型还可以针对不同用户组发布多个业务视图。这个设计已经包含现代语义层的三个核心思想：物理来源不等于业务表面，复杂关系需要在中间层治理，同一事实可以按使用者语境投射为不同视图。
图 3：物理来源、查询处理与业务视图逐层分离（概念示意）
Oracle Analytics 的语义模型架构延续了类似分层：物理层描述来源，逻辑业务模型表达可分析对象和计算，展示层面向用户组织主题区。Microsoft Analysis Services 与后来的 Power BI semantic model 则让 measures、relationships、hierarchies 和 row-level security 成为广泛使用的分析合同。这些系统并不“旧”；今天 Agent 仍然需要它们解决聚合、关系和权限，只是消费端从仪表盘扩展到了自然语言与工具调用。
这个阶段也产生了长期技术债。第一，语义模型往往绑定某个 BI 工具，模型之外的 notebook、应用和 API 又重复实现指标。第二，模型擅长可聚合分析，不擅长表达业务对象的完整生命周期。第三，发布后的语义通常由中心团队维护，业务变化速度与模型交付速度产生张力。第四，很多模型只记录当前定义，不记录定义为什么改变、哪些决策受影响。
BI 语义层解决了“怎样一致地看数据”，却没有完整解决“怎样让语义跨工具流动”以及“怎样把分析结论变成受控行动”。 后来的 headless semantic layer、开放交换规范和运营本体，分别从这两个缺口继续向前发展。
第三阶段：自助分析扩大消费面，也放大了指标分叉
自助 BI 把建图表和组合字段的能力交给更多分析人员。它降低了出报表的门槛，却没有自动降低定义指标的门槛。业务人员可以快速复制一个数据源、创建计算字段和发布仪表盘，结果是同一个“活跃客户”“净销售额”或“广告转化率”在不同工作簿中产生多个合理版本。
图 4：同一净销售额在税、退款、币种和窗口上流向不同结果（概念示意）
这不是简单的治理不严，而是消费模式发生了变化。中心模型要求先确定公共定义，自助分析允许先解决局部问题。二者都合理，冲突来自没有明确区分探索语义与生产语义。探索语义可以临时、局部、可修改；生产语义必须有 owner、版本、测试、适用范围和退役策略。若所有定义都强制中心化，业务会绕开平台；若所有定义都允许自由发布，平台只会成为重复指标的目录。
现代产品开始把这一矛盾显式化。Tableau Semantics 将 semantic model、可复用 semantic definitions、metrics、访问控制和验证放进 Data 360，并把模型作为一等元数据提供给 Tableau Next 和 AI。Salesforce 的Semantic Query API要求调用方提交结构化语义查询，由模型解析字段、关系、过滤、聚合，以及 timezone、locale、currency 等每次查询的语境。这说明自然语言只是入口，真正可执行的是结构化语义请求。
ThoughtSpot 在 2026 年发布 Spotter Semantics，把 search token、聚合感知和面向 Agent 的上下文作为产品重点。Strategy One 延续 MicroStrategy 长期维护的企业语义图思路，把统一语义、分析与 AI 放在同一平台。Qlik Answers、Looker、Quick BI 智能小Q、DataArts Insight 等产品也都以不同方式把业务字段、关系、指标和自然语言体验连接起来。它们的共同变化不是“聊天框更好看”，而是承认 AI 消费者需要一份比表结构更稳定的业务模型。
第四阶段：指标层从 BI 内部走向 headless 和 code-first
当指标需要同时服务仪表盘、嵌入式分析、实验平台、API 和机器学习时，把定义锁在某个 BI 工作簿里就不够了。headless semantic layer 试图把模型与展示解耦：上层通过统一 API 或查询语言请求指标，下层由语义引擎选择关系、生成 SQL、处理聚合并应用访问策略。
dbt Semantic Layer 与 MetricFlow代表 code-first 路线。实体、度量、维度与时间粒度进入版本控制，查询计划在模型图上解析。Cube 把数据模型、访问策略、预聚合与多种 API 放在独立运行时，并在 Agent 场景中强调语义层与 context layer 的关系。Wren AI 的 MDL把 model、column、relationship、view、cube 等业务结构编译为可规划 SQL；其架构说明把项目上下文、计划引擎、连接器、记忆与 Agent 工作流分开，便于检查“模型写了什么”和“数据库实际执行了什么”。
图 5：同一语义运行时服务 BI、Notebook、API、实验平台与 Agent（概念示意）
Snowflake Semantic Views、Databricks metric views、LookML、AtScale、GoodData、Denodo 等产品的实现不同，但都在回答三个相似问题：指标能否脱离某个可视化工具复用；查询能否先经过业务模型再落到物理 SQL；访问控制和性能优化能否保持语义等价。
开放性不能只看模型文件是否能导出，还要看定义能否被多个消费端复用、运行时是否必须依赖单一商业服务，以及退出后能否继续解释旧结果。2025 年一场关于“真正开放的语义层”的社区讨论把这些实际约束说得很具体：代码化定义、跨工具消费、部署选择和迁移成本必须一起评估。它不是产品能力的权威证据，却能提醒采购方把“开放”拆成可验证条件。
这里需要警惕一个常见说法：指标层不是“把 SQL 做成 YAML”。如果模型只把已有 SQL 包一层名称，却不声明实体主键、关系基数、时间角色、聚合方式和适用范围，那么它仍然无法阻止 fanout、比率平均和快照求和。真正的语义引擎必须能够拒绝无合法路径的请求，而不是总能拼出一条 SQL。
以 ACOS 为例，行级表达式可以写作 spend / attributed_sales，跨 campaign 汇总时却必须重新计算 SUM(spend) / NULLIF(SUM(attributed_sales), 0)。库存是某一时点的状态，不能按日期直接求和；placement 报告与 search term 报告如果不存在联合粒度，也不能因为共享 campaign 和 date 就任意连接。语义层的价值恰好体现在这些“不允许”中。
第五阶段：NL2SQL 让入口自然化，中间表示开始变得重要
自然语言查询数据库不是大模型出现以后才有。早期系统依靠规则、语法和领域词典，后来的神经模型把问题直接映射为 SQL。Spider 等基准推动了跨数据库 Text-to-SQL 研究，但企业环境很快暴露出基准之外的问题：相同词汇指向多个字段，用户省略时间和组织范围，数据库模式远大于模型上下文，正确 SQL 也可能违反业务口径。
研究路线并没有只追求更强的端到端生成。IRNet设计 SemQL 作为自然语言与 SQL 之间的中间表示，以降低具体 SQL 细节对语义解析的干扰；NatSQL继续简化中间表达；PICARD在解码过程中用增量解析约束生成，使无效 SQL 更难出现。这些工作共同提供了一个重要方向：让模型先进入受约束的表示空间，再生成最终查询，比完全自由地输出字符串更容易验证。
到了企业产品中，中间表示不再只是学术语法。Salesforce 接收 structuredSemanticQuery，Cube 接收结构化查询，dbt MetricFlow 解析指标请求，Wren 可以在 MDL 对象上计划 SQL，Microsoft Fabric IQ 在预览能力中使用 NL2Ontology 把自然语言问题转为对本体的结构化查询。Snowflake Cortex Analyst 与 Cortex Agents 依赖 semantic views 和 verified queries，而不是每次只把 DDL 扔给模型。
图 6：IR、Metric Query、Semantic Query 与 Ontology Query 构成可检查道岔（概念示意）
因此可以把市场上的实现概括为几类转换，但必须说明：除了 NL2SQL 和 Microsoft 明确使用的 NL2Ontology，NL2DSL2SQL、NL2Metric2SQL 等名称更多是架构描述，并非统一标准。它们的区别不在营销名称，而在中间表示能承载什么约束。
| 转换路径 | 中间表示主要承载什么 | 能提前发现什么 | 典型实现或研究 |
|---|---|---|---|
| NL → SQL | 几乎没有显式中间层 | 主要依赖生成后校验 | 通用 Text-to-SQL |
| NL → IR → SQL | 查询结构、操作符、schema linking | 语法与部分结构错误 | SemQL、NatSQL、PICARD |
| NL → Metric Query → SQL | 指标、维度、时间粒度、过滤 | 指标不存在、维度不兼容、聚合错误 | MetricFlow、Cube、Tableau Semantics |
| NL → Semantic Model Query → SQL | 对象、关系、计算、语境 | 非法关系、字段越界、时间/币种冲突 | Salesforce Semantic Query API、Snowflake Semantic Views、Wren MDL |
| NL → Ontology Query → 多后端 | 实体类型、关系遍历、规则、有效期 | 实体歧义、路径和规则冲突 | Fabric IQ NL2Ontology、RDF/SPARQL 体系 |
中间表示的工程价值有三点。第一，它让系统知道自己理解了什么。用户说“增长最快的商品”，系统可以显示绑定的是 advertised ASIN 还是 purchased ASIN、采用广告销售还是总销售、比较环比还是趋势斜率。第二，它让权限作用在业务对象而不是最后一条 SQL 上。第三，它让评测从“最终数字碰巧相同”升级为逐层检查意图、指标、路径、计划和执行。
NL2SQL 的长期方向不是消灭 SQL，而是让 SQL 退到编译目标的位置；用户面对业务语言，系统内部保留可检查的语义计划，数据库继续执行它擅长的物理查询。
第六阶段：大模型内化通用知识，企业语义反而变得更窄、更硬
大模型使一个旧前提失效了：企业不再需要把所有通用知识都重新解释一遍。模型通常已经理解“订单”“库存周转”“广告点击”“campaign”“ROAS”等常见概念，也能阅读 SQL、API 文档和数据字典。把百科式定义全部复制进知识库，既占用上下文，也容易造成版本混乱。
但由此推导“企业不再需要语义层”同样错误。模型内化的是来自训练材料的统计知识，不是某个组织在当前时点承诺采用的业务合同。它可能知道 ROAS 的通常公式，却不知道销售额采用七天还是十四天归因；可能知道 Amazon Ads 有自动和手动投放，却不知道一个成熟搜索词迁移后，原自动 target 是否必须降价、否定还是保留用于探索；可能知道库存不足应减少投放，却不知道该品牌把二十一天可售天数视为红线。
今天企业语义的边界可以压缩为六类难以由通用模型可靠内化的内容：
图 7：模型知识扩张，组织承诺、动态状态和权限仍留在企业一侧（概念示意）
- 组织专属定义：指标公式、适用对象、币种、税务、归因与比较基线。
- 动态事实：当前库存、价格、预算、授权、对象状态与数据成熟度。
- 身份与关系：内部 SKU 与各站点 ASIN、账户与代理商、target 与 search term 的稳定对应。
- 决策政策：什么条件下扩量、暂停、迁移、否定或升级人工处理。
- 权利和责任：谁能看利润、谁能改预算、谁为定义和动作负责。
- 历史承诺：为何采用当前版本，哪些例外被批准，失败后如何回滚。
这些内容有共同特征：它们会变化，错误成本高，必须明确归属，而且需要在多个系统之间保持一致。模型可以帮助抽取、映射和提出候选，不能成为唯一事实来源。一个定义若没有 owner、版本、有效期和证据，放进向量库也不会自动变成可信语义。
未来的边界还会继续移动。行业公开知识会更多地被模型吸收，厂商产品元数据会通过开放接口被实时获取，企业真正需要长期维护的将集中到差异化经营逻辑、动态运营状态、监管边界和可执行承诺。语义资产会从“解释世界是什么”收缩为“声明本组织在当前上下文中认为什么有效，并愿意据此承担什么行动后果”。
2026 年的智能语义产品，并不是同一种产品
把所有带 semantic、knowledge、ontology、copilot 或 agent 标签的产品放进一张功能表，结论通常失真。更可靠的办法是用两个坐标定位：横轴表示语义显式程度，从相似度和检索，到受治理指标，再到形式本体和规则；纵轴表示执行深度，从发现资料、回答问题、生成查询，到推理决策和修改业务系统。
图 8：语义显式程度与执行深度共同定位不同产品路线（概念示意）
第一类：分析与指标语义
IBM Cognos、Microsoft Power BI semantic models、Oracle Analytics semantic model、Looker/LookML、Tableau Semantics、Snowflake Semantic Views、Databricks metric views、ThoughtSpot Spotter Semantics、Strategy One、Quick BI 和 DataArts Insight 主要从分析问题出发。它们擅长把物理表转换为可复用的维度、度量、关系与权限，并向仪表盘或自然语言分析提供统一口径。
这类产品需要继续细分。Cognos 与 Oracle 的成熟业务模型积累了复杂企业报表经验；Power BI、Looker 和 Tableau 拥有强消费生态；Snowflake 与 Databricks 更靠近数据平台和 Agent；ThoughtSpot 从搜索与自然语言分析进入；阿里云 Quick BI 的 SmartQ、华为云 DataArts Insight 则面向中文企业分析入口。不能只看是否支持聊天，要检查模型能否独立版本化、查询是否经过显式语义对象、访问策略在哪一层生效，以及结果是否返回可审计计划。
IBM 在这条路上尤其值得单独观察。Framework Manager 早已把 import view、query complexity 与 business view 分层；watsonx.data 的 Semantic Automation Layer将业务术语和描述用于元数据增强；watsonx BI 的业务语言配置又把元数据增强、实体关系和真实业务逻辑用于自动生成语义数据模型。它不是从“没有语义”突然跳到 AI，而是在把传统业务元数据、治理目录和自然语言问数重新组合。
第二类：headless 或开放语义层
dbt Semantic Layer/MetricFlow、Cube、Wren AI、AtScale、GoodData 与 Denodo 更强调跨消费端复用。它们可能以代码、API、虚拟化或独立引擎存在，不要求用户先进入某个固定 BI 界面。对多 Agent 系统而言，这类产品的优势是语义可以成为公共服务，而不是每个 Agent 各自复制一份 prompt。
开放程度仍要分层判断。代码可见不等于模型可移植，API 可调用不等于定义可交换。需要检查语义文件是否能完整导出，关系与指标是否有稳定标识，执行语义能否在另一个引擎重现，权限和缓存是否属于专有扩展。2026 年推进的 Open Semantic Interchange（OSI）试图建立厂商中立的语义模型交换规范，但规范发布并不等于所有复杂模型已经无损互操作；真正可移植性仍需用实际往返测试证明。
Google Cloud 在 2026 年提出 Open Knowledge Format（OKF），用 Markdown、YAML frontmatter 和约定打包 schema、metric、runbook 等 Agent 上下文。v0.2 增加来源、信任、新鲜度、生命周期和计算证明等信号。OKF 更接近可携带的知识与上下文包，OSI 更接近分析语义模型交换；二者解决的边界不同，不能互相替代。
第三类：目录、治理与上下文系统
IBM watsonx.data intelligence、Informatica CLAIRE、Collibra、Alation、Atlan、Google Knowledge Catalog 等产品从目录、血缘、质量、业务术语和数据产品进入。它们的强项是回答“有哪些资产、谁负责、来自哪里、是否可信、怎样申请访问”，并把这些信息提供给人和 Agent。
目录中的 business glossary 并不自动成为查询语义层。一个术语页面可以说明 TACOS 的含义，却未必能生成正确 SQL；一条 lineage 可以说明字段来自哪张表，却未必知道 ratio 应在聚合后重算。反过来，查询语义层也可能缺少审批、责任人、质量事件和政策证据。因此，成熟架构通常需要目录与执行语义双向同步，而不是选一个产品取代另一个。
Collibra 的 semantic layer 能力把业务资产、指标和治理上下文组织起来；Alation 在 2026 年提出 AIOS、Agent SDK 与 agentic data management，强调将上下文提供给不同 Agent；Informatica CLAIRE 将元数据、质量、治理和 AI 助手结合。对于采购评估，必须把厂商公开主张与实际可调用接口、权限继承和版本行为分开验证。
第四类：实体、本体与运营语义
Palantir Ontology、Microsoft Fabric IQ Ontology、SAP Knowledge Graph、ServiceNow Knowledge Graph/Workflow Data Fabric、Stardog、Ontotext GraphDB、TopQuadrant EDG、PoolParty、Neo4j 与 RelationalAI 主要处理实体、关系、规则、推理或运营对象。它们之间的差异更大：有的是形式本体与图数据库，有的是企业知识图谱平台，有的是把对象、动作和工作流整合起来的运营系统。
Palantir Ontology system明确把 data、logic、action、security 结合起来，并用 Language、Engine、Toolchain 描述平台；Microsoft Fabric IQ把 semantic model、ontology、graph、data agent 和 operations agent 连接到 OneLake；ServiceNow Workflow Data Fabric把数据产品、稳定合同、知识图谱、工作流和 Agent 放在已有业务平台中；SAP Knowledge Graph依赖 SAP 业务语境为 Joule 与 Agent 提供上下文。
这些产品都在谈“业务上下文”，但购买理由完全不同。需要跨系统表达开放公理和进行描述逻辑推理，应该看 OWL、GraphDB、Stardog、TopBraid 等能力；需要在人和 Agent 之间交付对象化运营应用，Palantir、ServiceNow、SAP 或 Fabric IQ 更接近问题；需要在 Snowflake 内以声明式逻辑处理复杂关系和决策计算，RelationalAI 的路线又不同。不能用一张“知识图谱功能勾选表”完成选型。
第五类：语义搜索与企业知识入口
Glean、Coveo 、Elastic 等产品从文档、人员、权限与检索进入。它们用连接器、索引、知识图谱或上下文排序帮助用户找到企业信息，也可为 Agent 提供相关材料。这里的“语义”主要指理解查询意图、实体和内容相关性，不等同于指标聚合或形式本体。
一个企业搜索产品可以准确找到“Amazon Ads 日本站归因口径说明”，却不能据此保证查询中使用了正确 sales 字段；一个指标层可以准确计算 ACOS，却不知道某次策略例外记录在哪份会议纪要。智能产品经常需要两者协作：检索系统找到政策证据，语义查询系统执行口径，运行时再检查当前权限和状态。
IBM 这条线为什么重要：语义不是 2026 年才被 AI 发明
如果只看最近两年的产品公告，很容易把语义层理解为大模型准确率不足后的临时补丁。IBM Cognos 的演进说明事情正好相反：企业长期需要一个独立于物理数据和报表布局的业务模型，AI 只是让这个模型多了新的消费者。
Framework Manager 的 import view 保留数据源结构，查询处理层解决关系和复杂计算，business view 再按业务使用者组织可见对象。这种分层不是界面习惯，而是一种责任隔离。源系统可以因迁移而改变，业务视图不必随之重写；不同用户组可以看到不同主题，底层关系仍由同一模型治理；复杂 Join 不必交给每位报表作者理解。
图 9：业务视图、自助建模、治理上下文与自然语言消费保持谱系（概念示意）
到了 data modules，建模对象更靠近自助分析，用户可以组合来源、关系、计算和导航路径。到了 watsonx.data intelligence 与 Semantic Automation Layer，业务术语、描述和治理资产参与数据发现与丰富。watsonx BI 再把这些业务语言用于理解问题和构建 semantic data model。把这几段放在一起，能看到一条连续路线：
- 先把物理元数据投射为业务视图；
- 再让更多分析者组合和维护业务模型；
- 把术语、目录、血缘和治理上下文接入模型；
- 最后让自然语言系统在这份语境上生成查询。
这条路线的优势是重视企业既有资产。许多大型组织并不是从零开始，它们已经有 Cognos package、报表、术语表和权限。新的 Agent 架构若要求全部推倒重建，会同时丢失多年沉淀的计算和例外。更合理的迁移是盘点哪些业务视图仍在使用，抽取稳定指标与实体，补充版本、来源和测试，再通过结构化接口提供给新消费者。
局限也必须正视。传统 BI 模型通常围绕查询和报表优化，不天然包含 Agent 动作、长时程任务和外部 API 的事务语义。模型里能正确计算广告花费，不代表它能安全修改 Amazon campaign budget；business view 中的权限也不一定覆盖 Agent 调用链中的缓存、记忆和工具。IBM 的历史证明分析语义是地基，不证明地基本身就是完整 Agent 运行时。
这个判断同样适用于 Oracle、Microsoft、SAP 和其他长期企业软件厂商。成熟产品往往拥有被新术语遮住的语义资产：Oracle 的逻辑业务层、SAP 的业务对象与预定义内容、Microsoft 的 tabular model、ServiceNow 的统一记录和工作流。评估“Agent readiness”时，应先检查这些资产能否被新接口消费、版本化和测试，而不是只比较新发布的聊天入口。
同一句自然语言，在不同产品里实际走的是不同路径
用户都可以输入“按地区查看本季度净销售额”，界面看起来相似，后台可能是完全不同的系统。
在传统 BI 语义模型中，问题被绑定到已发布主题、维度和 measure，再由查询引擎生成 SQL 或多维查询。主要保证来自模型作者预先定义的关系与计算。在 AWS QuickSight Topics 中，作者配置领域字段、同义词、聚合和自然语言相关信息，Q 依据 topic 解释问题。Oracle 和 Cognos 也主要依靠业务模型限制查询空间。
在 Salesforce Semantic Query API 中，最终执行入口是 structured semantic query，字段、关系、filter、grouping、aggregation 和 semantic context 都有结构。自然语言功能的关键价值是生成这份结构，而不是绕过它。Snowflake Cortex Analyst/Agents 则使用 semantic view 描述逻辑表、facts、dimensions、metrics、relationships 和 verified queries，并把生成 SQL 留在 Snowflake 内执行。
图 10：不同产品生成不同中间产物并承担不同风险（概念示意）
在 dbt MetricFlow 中，调用方请求 metric、dimensions、time granularity 和 filters，规划器依据 semantic graph 解析实体关系和 SQL。Cube 使用自己的查询格式和数据模型解析措施、维度、访问策略与预聚合。Wren 允许 Agent 或开发者针对 MDL 中的模型和计算字段编写 modeled SQL，再通过 planner 展开到物理来源。
在 Microsoft Fabric IQ Ontology 的预览路线中，自然语言可以进入 NL2Ontology，查询以 entity type、properties、relationships、filter、aggregation 和 validity 等本体语义工作，并可能路由到底层 Graph 或 Eventhouse 等系统。Palantir 更进一步：用户和 Agent 不仅查询对象与链接，还可能调用 Functions 和 Actions 操作对象或外部系统。
这些路径无法用一个“NL2SQL 准确率”比较。前四类主要产生分析结果，Ontology 路线还可能跨关系域，运营路线则引入动作。相同问句的评测目标因此不同：
| 产品路径 | 最关键的可检查产物 | 主要风险 |
|---|---|---|
| BI semantic model | 已解析 measure、dimension、filter 与 query | 模型外定义被偷偷补入报表 |
| Topic / conversational BI | topic 选择、词项绑定、聚合与澄清 | 同义词匹配正确但业务口径错误 |
| Metric API | metric request 与 semantic graph path | 指标存在但维度路径造成 fanout |
| Semantic query | 结构化逻辑请求与生成计划 | 字段范围、时间/币种语境或权限错误 |
| Ontology query | entity、relationship、rule 与 backend plan | 实体同名、关系有效期或规则类型混淆 |
| Operational ontology | Proposal、Action、permission 与 receipt | 分析正确但动作越权、重复或无法补偿 |
因此，采购演示必须要求厂商展示中间产物。若只能看到用户问题和最终图表，团队无法判断准确性来自受治理模型、检索示例还是一次模型猜测。演示还应故意提出不可回答的问题，观察系统会追问、拒绝、降级，还是仍给出一个漂亮答案。
从词汇表到可执行模型，中间有四次“硬化”
许多语义项目停在 glossary：业务和数据团队统一了名词，却发现报表仍不一致。原因是名词共识必须经过四次硬化才能进入运行系统。
第一次是标识硬化。术语“广告销售额”要获得稳定 ID，并区分 Sponsored Products、Sponsored Brands、DSP、AMC 等适用域。中文名、英文名、缩写和历史别名都指向 ID，不能靠字符串相等决定含义。
图 11：候选术语依次经过标识、计算、关系与治理工位（概念示意）
第二次是计算硬化。定义绑定到分子、分母、grain、time role、currency、attribution window 与空值规则。计算实现可以因仓库变化而替换，逻辑合同保持可比较。若一个指标无法生成至少一组输入输出样例，它还不是可执行定义。
第三次是关系硬化。指标可在哪些实体和维度上切分，沿什么路径连接，基数和有效期是什么。一个 measure 有正确公式但允许任意 Join，仍会产生错误答案。关系硬化尤其要记录禁止路径。
第四次是治理硬化。定义获得 owner、reviewer、生效日期、权限和发布状态；变更触发依赖测试；旧版本停止新引用但保留历史复盘。只有经过这一步，Agent 才能把它当作组织承诺，而不是一段相关文本。
四次硬化不必一次完成。探索阶段可以只有术语和候选公式；进入团队共享时补充 ID 与计算；跨系统复用时补充关系；进入自动动作前必须完成治理和验证。把所有候选都要求达到最高等级会拖慢业务，把未经硬化的候选直接提供给 Agent 又会制造风险。资产需要明确状态，例如 draft、reviewed、certified_for_analysis、approved_for_action、deprecated。
语义层与数据产品：接口稳定不等于意义稳定
数据产品强调清晰 owner、可发现接口、质量与服务水平，它与语义层高度相关，但二者不能互换。一个 campaign performance 数据产品可以稳定提供 campaign_id、date、spend 和 attributed_sales，却仍允许不同消费者用不同窗口和聚合计算 ACOS；一个语义指标可以有稳定定义，却依赖质量很差、经常迟到的数据产品。
ServiceNow Workflow Data Fabric 把 Data Product 描述为由一个或多个 Data Interface 组成、代表业务概念的受治理可复用包，并通过 mapping 将来源对齐接口；trust score、catalog、knowledge graph 和 zero-copy connector 又补充可信度与连接。Google OKF 用可携带文件描述 schema、metric、runbook 和来源。这些路线都说明数据接口与上下文正在靠近。
真正落地时应把数据产品合同与语义合同分开引用。数据产品承诺可用性、schema、刷新、质量和访问；语义合同承诺对象、指标、关系与用途。来源 schema 改变，数据产品 owner 负责兼容或通知；指标公式改变，语义 owner 负责版本和影响分析。两种变更可能互相触发，却不能由同一个版本号含混表示。
Amazon Ads 场景中，Reporting API 数据产品可以按 report type 和 grain 提供标准化事实，Marketing Stream 数据产品提供小时级流与 campaign 变更，库存数据产品提供 ASIN/SKU snapshot，订单产品提供销售与退款。语义层在它们上面声明哪些来源可组合、何时成熟以及什么结果能进入策略。先把所有来源 Join 成一张“ads_360”表，会同时失去产品合同和语义边界。
语义债务怎样计量，而不是等事故发生
技术债常用代码复杂度和故障衡量，语义债务更隐蔽。它表现为同一问题需要人工解释、不同报表结果无法对账、查询高度依赖少数专家、定义变更无法找到影响，以及 Agent 经常以“补充 prompt”修复错误。
可以建立五类量化指标。第一是定义分叉率：同名或同义指标存在多少活跃实现，它们的分子、窗口和适用域差异多大。第二是未绑定查询率：生产 SQL 或仪表盘中有多少计算绕过已发布语义对象。第三是人工澄清成本：一个业务问题平均需要多少轮确认，哪些歧义重复出现。
第四是变更影响盲区：指标、关系或来源变更后，有多少下游资产无法自动定位。第五是错误归因时间：从发现数字异常到确定是数据、语义、权限还是策略问题需要多久。Agent 上线后还可以增加安全拒答率和越界回答率，前者不是越低越好，后者必须趋近于零。
语义平台的投资回报也应从这些指标衡量，而不是统计创建了多少术语。若半年后 glossary 从五百条增长到五千条，报表分叉率和问题定位时间没有下降，项目只是增加了元数据。相反，一个只覆盖三十个关键指标和十条决策路径的模型，如果显著降低对账与事故成本，已经产生真实价值。
不要按厂商品牌选型，要按“语义到哪里停止”选型
产品选型的第一问不应是“支持不支持 AI”，而应是语义责任在哪一层停止。下面七个问题比功能列表更能暴露差异：
- 意义从哪里来：人工建模、历史查询归纳、自动推断，还是三者混合？推断结果是否需要审批？
- 中间表示是什么：自由文本、指标请求、结构化 semantic query、图查询还是对象动作？能否导出和测试？
- 系统能做什么：只检索定义，还是能够查询、预测、推理、优化和执行？
- 动作怎样建模：产品是否只给建议，还是存在带前置条件、权限、幂等和回执的 Action？
- 治理在哪里生效：权限是在检索前、计划前、SQL 执行时，还是结果返回后？
- 反馈怎样沉淀：用户修正会进入例子、模型、策略版本还是不可追溯的聊天历史？
- 能否退出：定义、关系、规则、测试和决策记录能否迁出，并在另一运行时重现？
这套问题会得到一个比“语义成熟度分数”更真实的结果。某产品可能在 BI 查询上非常成熟，在跨系统动作上完全不负责；某运营平台能安全执行动作，却不提供开放形式语义；某知识图谱能完成逻辑推理，但需要团队自行建设应用和事务外壳。产品不是越全越好，关键是空白责任是否由现有系统明确承担。
用一个现代 Amazon Ads 问题检验整条语义链
历史技术不必逐代套进 Amazon Ads。真正有价值的是直接拿一个今天的决策问题，检验最新架构是否补齐过去的缺口。假设投放负责人提出：
找出美国站最近十四天值得增加预算的 Sponsored Products campaign，排除库存不足和利润风险，并说明依据。
如果只有自然语言和数据库 schema，系统很容易把问题翻译为“按 campaign 汇总 spend 和 sales，筛选 ACOS 较低且预算花完的记录”。这条 SQL 可能运行成功，却至少遗漏十个语义决定。
图 12：账户、市场、时间、指标、库存、利润与权限装成一份请求（概念示意）
第一，“美国站”应绑定哪个 profile 与 marketplace，账户时区和币种是什么。第二，“最近十四天”是否包含归因尚未成熟的日期。第三，“值得”对应收入、广告 ROAS、贡献利润、增长目标还是新品曝光。第四，“增加预算”只针对预算受限 campaign，还是也包括因竞价不足而未消耗的 campaign。第五，campaign 下有哪些 advertised ASIN，它们的库存覆盖天数和 Featured Offer 状态是否一致。
第六，广告归因销售与店铺总销售来自不同事实，TACOS 的分母怎样对齐。第七，订单退款和 COGS 在哪个有效期版本进入利润。第八，一个 campaign 是否与其他 campaign 争夺相同搜索词和同一 ASIN。第九，portfolio 或客户合同是否存在预算上限。第十，结果只是分析建议，还是允许继续调用 Amazon Ads API。
一个合格的语义请求不会直接保存用户原句，而会形成类似下面的逻辑对象：
intent: scale_budget_candidates
scope:
marketplace: US
profiles: authorized_profiles(current_user)
entity: sponsored_products_campaign
observation:
window: last_14_complete_local_days
attribution_maturity: stable_only
metrics:
- contribution_after_ads_v3
- budget_lost_opportunity_v2
constraints:
inventory_cover_days: ">= 21"
featured_offer_rate: ">= 0.95"
semantic_coverage: ">= 0.98"
output: ranked_proposals_with_evidence
action_permission: none这不是某个行业标准语法，而是本文用于说明中间表示的示例。关键不在 YAML，而在每一个值都必须引用已发布的注册项。contribution_after_ads_v3 有公式、owner、有效期和测试；last_14_complete_local_days 明确 profile 时区和归因成熟规则；authorized_profiles 由身份系统求值；action_permission: none 明确当前请求只能生成候选，不能改预算。
接下来，计划器从语义图中选择合法路径。Campaign performance 按 campaign × date 聚合，advertised product 报告提供 campaign 与 ASIN 的观察，库存按 ASIN × marketplace × snapshot_time 获取最后有效状态，利润按 SKU/ASIN 映射与有效期绑定。任何多对多路径都必须先确定汇总粒度，不能把四张事实表直接连接成一张宽表。
最后，结果应携带证据而不是只返回排名：使用的数据快照、指标版本、稳定日期范围、覆盖率、被排除 campaign 的原因、缺失字段和不确定性。即使问答界面只显示一句中文，后端也要保存完整语义计划。否则用户无法分辨系统是真的理解了业务，还是恰好生成了一个看起来合理的数字。
Amazon 官方资料进一步说明为什么这些边界不能省略。Sponsored Products targeting 指南区分 automatic、manual 与 negative targeting，并明确 customer shopping query 与 keyword 不是同一个对象；Sponsored Products best practices分别描述 search term、targeting、advertised product、placement 等报告；Amazon Marketing Stream提供小时级指标和 campaign 变更消息。不同来源回答不同问题，语义层必须保留这种差异，而不是提前压成“广告明细”。
语义标准、交换协议和连接协议分别负责什么
语义产品快速增加后，行业容易把“开放”理解为“支持 MCP”。MCP 的核心作用是让客户端发现并调用 server 暴露的 resources、prompts 和 tools，并在 HTTP 场景下提供授权框架。它解决连接与调用方式，不定义“净销售额”怎样聚合，也不规定 Campaign 与 Target 的业务关系。MCP tools 规范甚至明确提醒工具元数据需要被客户端谨慎对待；能被发现的工具，不等于语义正确或动作安全。
分析语义的交换更接近 OSI。知识与上下文的便携更接近 OKF。图与本体的开放语义由 RDF、RDFS、OWL、SHACL、SPARQL 等 W3C 标准承担。OWL 2 Overview定义类、属性、个体和公理的知识表示，SHACL用于验证 RDF 图是否符合 shapes，SPARQL 1.1提供图查询和属性路径。这些标准也不会替代指标引擎、身份系统或动作编排。
可以把它们理解为不同层次的契约：
图 13：连接、分析、知识包、形式知识与运行契约彼此互锁（概念示意）
| 层次 | 主要问题 | 可选规范或产品能力 | 明确不负责什么 |
|---|---|---|---|
| 连接契约 | Agent 怎样发现和调用能力 | MCP、REST、SDK | 业务指标与对象定义 |
| 分析语义契约 | 指标、维度、关系怎样交换与查询 | OSI、各类 semantic query API | 外部动作事务 |
| 知识包契约 | 上下文、来源、版本怎样携带 | OKF、目录导出 | 查询执行正确性 |
| 形式知识契约 | 概念、关系、公理、约束怎样表达 | RDF、OWL、SHACL、SPARQL | 业务工作流和写回 |
| 运行契约 | 谁在何种状态下执行什么动作 | Action model、策略引擎、Harness | 不能由通用连接协议自动推导 |
MCP 可以把语义能力送到 Agent 面前，却不能替企业生产语义；OSI、OKF 与 W3C 标准可以提高可移植性，也不能替组织决定哪一版定义具有执行权。
业务语义不应再只是一份知识库
过去常见做法是把字段说明、会议纪要和指标文档放进向量库，让 LLM 在回答前检索。它比完全没有上下文好，但有三个根本限制。
第一，文档通常描述原则，不保证能生成唯一计算。两份文档分别说“ACOS 等于花费除以销售额”和“销售采用十四天归因”，系统仍要知道具体字段、时间角色、空值处理与聚合顺序。第二，向量检索以相关性为主，不保证返回当前生效版本。旧政策可能比新版本更符合用户措辞。第三，文本没有天然的引用完整性，一个动作需要的六个前置条件可能散落在不同段落，漏掉任何一个都不会触发结构校验。
所以企业知识库应从“答案材料仓”转为语义工程的一种输入。LLM 可以从文档中提出术语、同义词、规则和例子，领域 owner 负责确认，编译流程把确认内容写入不同资产：术语进入 glossary，公式进入 metric registry，关系进入 semantic model 或 ontology，约束进入 policy/shapes，成功查询进入 golden examples，例外与理由进入 decision log。
自动抽取不应直接覆盖生产定义。Google OKF v0.2 增加 generated、verified、status、stale_after、sources 等信号，正是因为 Agent 会大量生成上下文；IBM 的 Semantic Automation Layer 和 watsonx BI 也强调通过元数据增强生成业务语境。自动化可以降低发现和维护成本，发布权仍需与责任绑定。
一个真正的语义编译器，内部至少经历八次判断
“先经过语义层再生成 SQL”仍然太笼统。若这层只是把几段字段描述拼进 prompt，它无法成为治理边界。可以借用编译器思路，把一次自然语言问数拆成八个具有明确输入输出的 pass。
第一遍是语境绑定。 解析当前用户、租户、角色、profile、marketplace、locale、timezone 和默认 currency。用户询问“美国站”时，系统先从授权范围得到候选，不让模型遍历全部账户。若候选超过一个，返回澄清问题。
第二遍是意图归一。 把“值得加预算”“还能放量”“预算不够”等表述映射到经过批准的 intent catalog。每个 intent 声明需要哪些指标、对象和约束。无法映射时可以进入探索问答，但不能进入动作候选。
图 14：从语境绑定到执行后证明逐门拒绝歧义与越界（概念示意）
第三遍是词项与实体解析。 区分业务术语、实体实例和值。用户输入的“品牌词”可能是受治理类别，“blue water bottle”可能是具体 search term，“Campaign A”是实例。实体解析需要 exact ID、别名、作用域与置信度，不能把向量相似直接当作身份相等。
第四遍是指标和时间求解。 根据 intent 选择 metric IDs、time roles、maturity policy、comparison baseline 和 currency。若用户明确要求广告 ROAS，就不能被“利润更合理”的系统偏好替换；系统可以提示局限，但应忠实执行合法意图。
第五遍是关系路径规划。 从对象图中寻找连接来源，检查 cardinality、grain、effective interval 和 access policy。可能存在多条合法路径时，规划器按语义优先级、数据新鲜度和成本选择，并把选择写入计划。不存在路径时明确拒答，不能让 LLM 发明 Join。
第六遍是逻辑优化。 决定聚合顺序、filter pushdown、currency conversion、snapshot selection、ratio recomputation 与预聚合复用。它类似数据库优化，却受业务等价约束。一个更快但改变 ACOS 或库存含义的计划不是优化。
第七遍是物理编译与静态验证。 把逻辑计划生成具体 SQL、SPARQL、KQL 或 API read request，限制数据源、语句类型、扫描、超时和返回量。生成器不能增加逻辑计划之外的字段和关系。
第八遍是执行后证明。 对账分子分母、检查维度汇总守恒、核对数据水位、覆盖率、权限和结果形状。最终响应引用 semantic request、logical plan、physical execution 和 reconciliation IDs。验证失败时返回结构化原因，不把异常结果交给模型润色成结论。
八遍不要求八个微服务。小团队可以在一个进程中实现，但产物和错误类型应分开。例如 AMBIGUOUS_PROFILE 属于语境绑定，NO_VALID_METRIC 属于指标求解，ILLEGAL_JOIN_PATH 属于路径规划，RECONCILIATION_FAILED 属于执行后证明。明确错误层次以后，团队才知道应修 glossary、model、planner、source 还是 policy。
这套设计也解释为什么自然语言不是唯一入口。BI 界面、API、定时任务和另一个 Agent 都可以直接提交 Semantic Request，复用后续七遍；自然语言解析只是其中一个前端。反过来，一个聊天产品如果没有稳定中间表示，就无法与其他消费端共享同一语义。
“智能”应当放在哪一遍，取决于错误可验证性
LLM 很适合第一到第三遍的候选生成：理解省略、同义词、业务表达和非结构化上下文。它也适合在执行后解释差异。关系与指标选择可以让模型排序候选，但最终绑定必须由 registry 与 constraint solver 验证。物理查询生成可以使用模型，但 AST、白名单和计划一致性应由确定性程序检查。
这种分工不是保守地限制模型，而是把智能放在错误容易被发现的位置。模型把“上个月”误解为自然月，可以在 Semantic Request 展示时修正；模型在 SQL 中悄悄加入一个 Join，若没有逻辑计划就很难发现。越接近真实数据和动作，越需要类型、状态和验证器接管。
自动语义建模同样遵循此原则。系统可以扫描数仓、BI 查询、代码和文档，提出关系、指标、同义词与 owner 候选；cardinality 可以用 profiling 验证，指标可以用历史报表对账，术语可以由领域 owner 审批。直接让模型“生成企业本体”然后发布，得到的是流畅定义，不是受约束资产。
长期看，语义产品的竞争力很可能不在聊天生成本身，而在这些 pass 是否开放、可观测、可插入治理。企业需要知道模型参与了哪里、确定性规则检查了什么、哪一步可以替换、失败是否有稳定错误码。黑盒系统即便平均准确率较高，也难以承担高风险决策。
一份能进入生产的语义资产，需要七类元数据
不少团队已经有指标字典，却仍无法支撑 Agent，原因是字典只记录名称和说明。对一个可能进入自动决策的语义对象，至少需要以下七类元数据。
第一类是身份。 每个实体、指标、策略和动作都有稳定 ID，显示名称可以变化。同名指标必须通过命名空间或适用域区分。Amazon Ads 的 sales 不能只靠中文别名，应区分广告产品、归因窗口和数据来源。
第二类是定义与计算。 保存业务定义、公式、分子分母、空值与零值规则、时间角色、币种和聚合行为。ratio、snapshot、semi-additive measure 必须显式标注，不能只存一段 SQL。
第三类是关系与粒度。 指明主键、外键、基数、有效期、允许方向和 fanout 风险。每个事实声明自己的 grain；没有联合 grain 的问题必须拒答或降级。
第四类是来源与证据。 记录源系统、表和字段映射、血缘、质量检查、更新时间、覆盖率和已知缺口。用户看到的不只是“可信”徽章，而是为何可信。
第五类是治理。 owner、reviewer、访问范围、敏感等级、批准记录、生效和退役日期。定义版本与数据版本分开管理，因为公式不变时数据仍会更新，数据快照不变时政策也可能变化。
第六类是使用合同。 哪些问题可以使用该资产，允许哪些维度和过滤，性能与成本边界，结果能否用于建议或动作。这个部分把分析语义连接到产品能力。
第七类是验证。 单元样例、守恒检查、黄金问题、反例、迁移测试和生产观测。没有反例的语义通常只证明“能算”，没有证明“不会在错误上下文里被使用”。
这些元数据不必放在一个数据库中，但必须能够在一次请求中组合。若目录持有 owner，指标层持有公式，本体持有关系，身份平台持有权限，Harness 持有动作策略，就需要稳定引用和版本快照把它们连接起来。
语义工程的组织问题，比建模语言更难
语义对齐经常被当作数据团队项目，结果模型完成后业务仍在表外维护规则。真正的责任分配至少涉及领域 owner、数据 modeler、平台工程师、业务运营、风险或财务、应用与 Agent 团队。每一方控制的内容不同，不能由一个“语义管理员”代替所有判断。
领域 owner 决定术语与策略何时成立；数据团队证明定义能在来源上重现；平台团队保证编译、权限和版本机制；运营团队提供真实问题、例外和失败样本；风险或财务确认损失边界；Agent 团队负责解析和工具调用，但无权私自修改指标合同。
发布流程可以借鉴代码，而不能机械复制代码评审。改动一个字段描述与改变利润公式的风险不同。低风险同义词可以快速发布，关系基数变化需要回归所有依赖查询，动作前置条件变化需要重新审批并检查未完成任务。语义变更单应自动生成影响清单：哪些报表、Agent、策略、缓存、实验和运行中任务引用了旧版本。
另外，语义平台不能只奖励“新增”。没有退役机制，术语和指标会持续膨胀。每个资产应有使用频率、最后验证时间和替代关系；长期无人使用但仍被 Agent 检索的定义尤其危险。删除也不能直接抹掉历史，因为旧决策需要按当时版本复盘。正确做法是停止新引用，保留只读历史，并让运行中任务继续绑定原版本或显式迁移。
如何判断语义产品真的改善了智能，而不是多了一层元数据
评测不能只看自然语言回答“像不像”。应建立从业务问题到最终结果的分层指标。
第一层评估术语和实体绑定：用户的“广告组”“搜索词”“商品”是否映射到正确对象，歧义时能否追问。第二层评估指标和时间合同：是否选择正确版本、窗口、币种和聚合。第三层评估路径和计划：Join 是否合法，是否发生 fanout，权限是否在计划前生效。第四层评估执行和对账：SQL 能否运行，汇总是否守恒，结果是否与权威报表在容差内一致。
第五层评估产品行为：系统是否在证据不足时拒答，能否解释排除原因，用户修正后是否进入可审查资产。第六层才评估业务结果：分析时间是否缩短，重复指标是否减少，错误决策率是否下降，自动建议是否提高净利润或降低浪费。
基准问题需要同时包含可回答、需澄清和不可回答三类。只收集能成功生成 SQL 的问题，会促使系统用猜测提高覆盖率。Amazon Ads 评测集中应专门放入“search term × placement 联合表现”这类来源不具备联合粒度的问题，以及跨币种、未成熟归因、缺失 COGS、ASIN 映射冲突和无权限 profile。正确拒答是能力，不是失败。
还要测语义变更。把 contribution_after_ads_v3 升级为 v4 后，旧黄金问题是否显式选择版本；正在运行的分析是否保持快照；缓存是否失效；Agent 是否能说明答案变化来自定义而非数据。只在静态数据上测准确率，无法证明系统能承受真实组织中的变化。
一条现实的建设路线：从三个决策问题开始
企业不需要先建设“全域语义大脑”。更稳妥的起点是选三个高频、可验证、错误成本明确的决策问题。例如 Amazon Ads 团队可以选择：哪些成熟 campaign 值得增加预算，哪些 search term 可以迁移为 exact target，哪些 ASIN 因库存或利润风险应限制投放。
第一步，业务、财务和数据共同写出问题的金标准，不只是一条 SQL，而是对象、指标、时间、约束、允许路径、拒答条件和结果样例。第二步，盘点现有报表、工作簿、模型和文档，识别冲突版本。第三步，只为三个问题建立最小语义图和指标合同，避免先覆盖所有表。
第四步，选择能满足现有栈的运行形式。已经使用 Power BI、Cognos、Looker 或 Tableau 的团队，可以从现有语义模型向外暴露受控查询；需要跨多个前端时评估 Cube、dbt、Wren、AtScale 或 Denodo；关系推理明显时再引入本体或知识图谱；复杂运营闭环则在第二篇讨论的运行时中增加 Action 与 Harness。
图 15：预算扩量、搜索词迁移和库存限投向外扩展复用资产（概念示意）
第五步，建立编译和拒答。自然语言先转为结构化语义请求，验证通过后再生成 SQL。第六步，保存证据和用户修正，但不让一次对话直接改变生产定义。第七步，以新增相邻问题的方式扩展，而不是一次开放任意问数。
这条路线看起来不宏大，却能很快检验语义层是否真实存在：同一个问题从 BI、API 和 Agent 进入时，能否获得相同的逻辑计划；来源缺失或权限变化时，能否一致拒绝；定义升级时，能否解释差异。若做不到，继续增加术语和图谱节点只会扩大不确定性。
未来探索：语义层会成为企业智能的编译器，而不是另一座数据仓库
未来三年最值得观察的不是哪家把“semantic”写进产品名，而是三种边界是否逐渐稳定。
第一，分析语义与知识上下文会靠近。指标层会吸收来源、新鲜度、证据和使用说明，目录也会增加可执行查询与验证。OSI、OKF、厂商 API 和代码化模型可能形成互补，但短期不会出现一个规范覆盖所有语义。
第二，语义模型与 Agent 运行时会靠近。Snowflake 在 2026 年 8 月建议从 Cortex Analyst 转向 Cortex Agents，并说明现有 semantic views 与 verified queries 可以继续使用；Microsoft Fabric IQ 把 ontology 作为数据 Agent、运营 Agent 和自定义 MCP Agent 的上下文来源；Tableau Next 也把 semantic layer 暴露给 Agent。市场已经从“AI 能否读数据”走向“Agent 是否沿受治理模型读数据”。
第三，语义生产会部分自动化。系统可以从 schema、SQL 历史、仪表盘和文档提出模型、关系与同义词，也能从失败查询发现缺口。2026 年的若干研究，如 Bootstrapping Semantic Layer from Execution for Text-to-SQL 和 AgentSM，都在探索从执行或可解释记忆中积累语义。它们仍是研究或预印本，不能直接当作生产保证，却说明语义维护正从纯手工建模走向“机器提出、人类负责、测试发布”。
未来企业语义的核心资产不会是一个无限扩张的知识库，而是一组可组合的契约：指标合同、实体关系、政策、工具能力、动作前置条件和决策证据。模型参数负责通用语言与世界知识，检索系统负责找到相关材料，语义编译器负责把问题落入已批准空间，运行时负责在当前状态和权限下执行。
总结：从同一个词，到同一个可执行答案
从 Excel 到 Agent，业务与数据语义对齐经历了六次重心迁移：个人公式让业务掌握计算，BI 模型把业务视图抽离报表，自助分析扩大消费也制造指标分叉，headless semantic layer 让指标跨工具复用，中间表示让自然语言查询可以被验证，大模型则把企业语义压缩到更动态、更专属、更需要承担责任的边界。
这条历史没有导向“最终产品”。Cognos、Power BI、Oracle、Tableau、Snowflake、Databricks、Cube、dbt、Wren、Fabric IQ、Palantir、SAP、ServiceNow、IBM watsonx.data intelligence 和企业搜索产品，分别覆盖不同语义层次。选型的关键不是谁宣称拥有完整上下文，而是明确每个系统从哪里接管语义、到哪里停止，以及剩余责任由谁承担。
语义对齐的终点不是所有人使用同一个词，而是同一个业务问题在给定对象、时间、权限和版本下，能够生成同一份可验证的逻辑计划；当条件不足时，也能以同样明确的方式拒绝。
第一篇停在“答案”这一层。真正困难的下一步是：当这个答案会推动预算、出价、否定关键词和库存联动时，语义怎样进入 Agent 的状态机、权限、长期任务与回滚机制。那是第二篇要解决的问题。