为 Agent 建立企业语义层，正确的方向在哪里中讨论了企业的语义层建设最终需要留下什么：指标口径、业务对象和关系，以及 Agent 执行业务时所需的状态、规则、权限和动作。
再往前一步，AI时代下的语义层建设方式又该如何？
过去的数据模型或业务模型，会先进行一轮正式建模。所有内容都需逐项梳理。大模型时代下，我们多了一种新的可能。企业多年数字化已经留下大量 Schema、SQL、报表、主数据和系统配置，AI 可以先从这些资产里识别候选语义。
企业语义层的建设，大致分成两个阶段。第一次从0到1的建设，主要整理企业过去已经形成的业务知识；进入稳定使用以后，工作重点转向语义的持续维护。
成熟企业的业务定义必然分散在不同地方。过去谁也不能也不需要把这些内容整理成统一模型。但Agent需要一个统一的语义模型让其理解企业的运作方式，并从中跑起来。
一个采购指标藏在几十张报表和 SQL 里，一张采购订单在 ERP、采购平台和合同系统中分别使用不同编号，审批规则同时存在于制度文件和流程配置中。
如果 PurchaseOrder 长期与 Supplier表、Contract表 一起查询，某个交付日期又反复出现在延期计算中，结合 Schema、数据血缘、历史 SQL 和报表，就有条件识别一批候选业务对象、关系和指标。
企业的数据基础越成熟，可利用的材料越多。已有的数据中台、指标平台、BI平台、知识平台、历史查询等等，都是语义初始化的来源。这类自动识别能够明显降低首次建设的工作量，同时也有清楚的边界。历史资产中既有业务知识，也有过去系统设计和工作习惯留下的问题。
自动发现解决的是前期大规模梳理费时费力的痛点。然而企业仍然需要确认哪些指标口径可以正式采用，哪个系统是对象的权威来源，哪些历史做法属于正式规则。
所以第一次建设更接近一次企业级语义的初始化。AI从企业已有资产中找出大量候选内容，由员工把需要长期使用的定义人工确认，形成第一版可用的企业语义。
第一版语义层建立以后，面对的问题会发生变化。
企业的语义层会持续变化，其中大部分新变化没有数据可以挖掘和推断。
企业决定下个财年采用新的指标口径时新的定义来自财务政策。采购把审批线从 10 万调整到 20 万，也需要先修改制度文件和规则，再由系统落实和 Agent 执行。
由AI自主挖掘和员工直接定义，在这个阶段同时存在。新的系统、查询和业务行为会持续产生候选语义，业务部门也会不断提出新的业务对象和规则。区别在于，工作重点已经从整理历史，逐渐转向管理变化。
| 语义初始化 | 持续运营 |
|---|
| 主要任务 | | |
| 主要来源 | | |
| 机器的作用 | | |
| 人的作用 | | |
| 主要风险 | | |
到了持续运营阶段，语义层中的Owner、版本、生效时间和适用范围就会变得重要。
如果采购审批规则已经调整，而三个 Agent 仍然分别引用三个旧 Prompt，语义层即使第一版建得很完整，实际运行一段时间以后也会逐渐失真。正式规则需要在统一位置完成变更，经过确认后生效，并让引用它的应用使用一致的版本。
第一次建设决定企业能否较快形成一套可用语义。持续运营决定在长久的未来，这套语义是否仍然代表企业当前的业务。
不同厂商，也在从各自的产品基础向企业语义靠近
从这个视角再看市场上的语义层产品，各家的路线基于它们原本掌握的企业资产不同而各不相同。
| 产品出发点 | 代表厂商 | 原有优势资产 | 向企业语义扩展的方向 |
|---|
| 数据与分析平台 | Databricks、Snowflake | | |
| 企业业务应用 | SAP | | |
| Knowledge Graph / Ontology | Neo4j 等 | | |
| 运营型 Ontology | Palantir | 对象、关系、Functions、Actions、权限 | |
数据平台更容易从已有数据和分析资产开始，逐渐补充业务对象和关系；企业应用厂商本身掌握业务对象和交易过程，更容易保留并开放这些业务上下文；Ontology 平台擅长统一对象和复杂关系，往运营方向发展的产品则继续加入权限、规则和 Action。
这些路线正在逐渐靠近，但短期内很难收敛成同一种产品。它们更像是从各自最熟悉的企业资产出发，向 AI 所需要的完整业务上下文扩展。
对企业而言，技术路线只是其中一部分。企业真正需要长期处理的是后面的变化。谁负责修改一项定义，什么时间生效，影响哪些 Agent，旧版本什么时候停止使用。随着 AI 越来越多地依赖这些语义参与业务，这些问题会逐渐从技术维护进入企业日常的业务管理。
粤ICP备14082021号
免费POC，
零成本试错
