Agentic AI 的预算，不能只花在模型上

上周我们撰文介绍了过去几个月海外数据基础设施市场的一系列动作：

Gartner 在 2026 年 5 月的伦敦 D&A 峰会上明确指出：缺少语义和上下文，会让 AI Agent 更容易出错、带来无效支出，并增加 AI 治理风险。Snowflake 推出 Horizon Context 和 Cortex Sense，把语义、血缘、BI 定义、查询历史等上下文放入平台；Databricks 在 Unity Catalog 里强调 Glossary、Domains、Metrics 和 AI Gateway，让 catalog 从记录资产的系统，走向约束 Agent 行为的治理层；Microsoft 也明确提出，缺少语义上下文的 AI 只是一个“自信的猜测者”。

这些动作清晰传递了同一个信号：语义层和上下文层，正在成为 Agentic 时代的战略级基础设施。

再回到国内，我们看到很多企业的数据团队并不缺少对语义层价值的理解，但苦于缺乏组织共识和资源投入。技术团队知道指标口径不统一会出问题，知道自然语言问数不能直接建立在裸表之上，也知道没有可追溯证据的 AI 分析很难进入经营决策。但在预算讨论和项目规划里，语义层、指标治理、数据上下文建设常常被当作“能不能省”“能省则省”的负担。

今天我们撰文就是想针对这个误区，帮助企业正视一个事实：大模型的出现，不仅不意味着数据治理的消失，反而要求在既有数据治理的基础上，进一步投入语义和上下文的治理。

语义层一直都存在，过去它是「人肉」的，现在要变成「机器可读」的

过去，企业的数据消费主要由人完成。数据平台负责加工数据，BI 负责交付看板，理解业务含义的是分析师、财务 BP、运营负责人、数据产品经理和各个部门的业务专家。报表里的数据口径，分析需求的上下文，某个字段为什么不能直接相加，一个地区为什么要排除某类门店……这些都靠人来解释和兜底。

但这些隐性知识 Agent 不会天然继承。

当 AI Agent 开始成为新的数据消费者，它要查询数据、组合指标、解释变化、生成报告、发起追问，甚至进入销售、财务、供应链、客服、经营管理等具体业务流程：销售 Agent 需要理解客户、合同、商机和回款；供应链 Agent 需要理解库存、履约、预测和异常；财务 Agent 需要理解收入、成本、预算和经营口径；运营 Agent 需要理解活动、人群、转化和渠道归因。

这些 Agent 要工作，企业就必须把过去依赖人来补全的语义和上下文，沉淀成机器可以读取、调用、校验和更新的资产。

所以，语义层在本质上是一项新的治理投入。

如果企业希望 AI 能准确问数、自动归因、生成经营报告、支持业务决策，就必须投入资源建设指标口径、维度体系、权威数据源、业务术语、权限规则、样例问题、评测集和纠错机制。没有这些投入，AI 只能在不完整的上下文里猜测。猜得像，不等于答得对；答得顺，不等于能进决策。

这也是海外厂商和分析机构正在共同塑造的市场共识：AI-Ready Data，是指把数据变成可理解、可治理、可追溯、可被 Agent 使用的资产。

语义治理天然容易获得业务参与

但这也不是说企业要回到那种漫长、沉重、容易失去业务支持的数据治理工程。

语义治理有一个重要变化：它可以从业务使用中生长出来。

传统数据治理，对象是物理表、字段、ETL 任务和技术元数据。治理动作容易变成事后补文档、补标准、补流程。业务方感受不到短期收益，参与度自然有限。时间一长，治理就变成技术团队的单向负担。

语义层则把治理对象变成了业务能理解的指标、度量、维度、限定条件和分析口径。一个分析口径，定义一次，就可以被报表、问数、下钻、归因、Agent 报告反复调用。

这类治理更容易获得业务参与，因为它直接关系到业务能不能问清楚、用明白。

在 Aloudata Agent 和 Aloudata CAN 的语义层架构里，指标和维度的定义过程，本身就是核心业务实体和术语标准化的过程，也是分析视角的组装过程（即我们过去常讲的“管、研、用一体”）。业务需求变化了，直接调整语义，不用反复重写底层 ETL 和报表 SQL。查询由语义引擎做确定性编译，分析结果可以回溯到指标查询、SQL 这些证据来源上。

因此，语义治理的组织感受是不同的，它不再只服务于“合规”，而是为了让业务更快、更准地使用数据而治理。治理成果能直接被业务看见。

务实的方案：边用边治，以用促治

当然，语义资产也不可能一天建成。务实的路径一定是渐进式的。

就像我们反复说的，先选一个高价值业务域，治理一组最常被问、最容易出错、最影响决策的核心指标。围绕这些指标整理基础度量、维度、口径、权限、样例问题和标准答案。让业务先在真实场景中使用起来，再根据 Agent 的回答错误、业务追问、报告反馈，持续补语义、补上下文、补评测集。

这就是“边用边治，以用促治”。

这要比一次性规划全域数据治理更现实，也更符合 Agentic 应用的演进方式。Agent 用得越多，暴露的语义缺口越具体；缺口越具体，治理就越容易形成优先级。治理成果一旦回到高频业务场景，价值也更容易被管理层看见。

Agentic 深水区，预算不能只花在模型上

但我们在实践中最常看到的，是企业期待 AI 成为数字员工，却不愿意为语义和上下文建设投入资源。

这种情况下，浅层 AI 应用可以做，比如知识问答、文案生成、辅助查询、低风险办公自动化。但深水区的 Agentic 分析和业务决策自动化，要谨慎推进，因为企业还没有给 AI 准备好正式工作的条件。

对管理层来说，这里有一个朴素判断：

如果 AI 只是帮人写得快一点，模型预算可能是主预算。

如果 AI 要替人使用企业数据，解释业务变化，支持经营动作，语义和上下文治理就要进入主预算。

这笔投入不能被藏起来，也不能被误解成技术团队的额外要求。它是企业把 AI 从演示环境推向生产环境时必须投入的基础设施成本。

好消息是，这个成本正在被技术持续降低。

无论是 Snowflake 用自动化方式从查询历史、BI 定义和元数据中补上下文，还是 dbt/Fivetran 把指标定义、语义模型、血缘和业务文档沉淀成 Agent 可用的共享上下文，方向都很明确：语义和上下文治理不会永远依赖人工从零录入。未来，AI 会更多参与语义生成和定义补全的工作。

Aloudata Agent 的语义层方案也会沿着这个方向继续演进。我们会进一步降低语义生成和治理的门槛，让企业能从已有报表和真实业务问答中提炼语义资产。

模型平权之后，语义层会成为竞争壁垒

但无论工具怎么进化，企业需要承认语义和上下文是 AI 时代的新型数据资产。

模型可以购买，算力可以租用，工具可以接入。企业自己的指标口径、业务语言、组织经验、决策规则和数据使用边界，只能在自己的业务现场里长出来。

AI 时代的竞争，可能要看谁先把自己的业务语义治理成 AI 可以可靠使用的基础设施。