这段时间聊 Data Agent、ChatBI、本体论和语义层聊得比较多，背后其实还有一个更底层的问题，值得单独拿出来讲。
未来企业里的数据基建，还能不能继续沿用过去那套数仓建模范式？
或者说，企业把过去十几年建设出来的数仓、数据集市、指标平台、BI 报表直接接给大模型，再补一点 Prompt、补一点 Agent Harness，是不是就能完成从“大数据基建”到“AI 数据基建”的升级？
我先来谈谈我的看法吧。
AI 时代的数据基建，不是把旧数仓接上大模型，而是要把企业业务世界重建成一套 Agent 可以理解、可以调用、可以追溯、可以执行的语义系统。
传统数仓不会消失，甚至会继续承担很重要的存储、计算、治理和性能底座。
但如果企业还以过去“给人用 BI”的方式去建设数据资产，再期待 Agent 能自动理解里面所有历史债、口径差异和业务潜规则，这件事大概率会走向一地鸡毛。
这不是一个纯概念判断。
这次我也专门看了一圈 2026 年仍在更新的主流厂商资料，发现如下结论：
• 微软 Fabric IQ 在 2026 年已经把 Ontology 作为 Fabric 里的预览能力； • Snowflake Cortex Analyst 强调 Semantic Views； • Databricks Genie 要求领域专家维护 datasets、sample queries、text guidelines 和 knowledge store； • dbt Semantic Layer 继续把指标定义、semantic graph、MetricFlow 往统一语义层上推进； • Google Looker 也在 2026 年把 Looker semantic layer 通过 MCP 接给 Gemini CLI 和其他 Agent 工具。
这些厂商路线不完全一样，产品成熟度也不一样，但方向很一致：大模型要进入企业数据生产场景，不能只靠模型自己猜，也不能只靠 Prompt 让它“懂业务”。
模型之外，必须有一层机器可读、可治理、可复用的业务语义基座。
01 过去的数仓为什么能用？因为人在替系统补洞
很多企业的大数据基建，今天看起来问题很多。
指标口径不统一，字段命名混乱，业务含义缺失，烟囱式系统长期并存，ODS、DWD、DWS、ADS 各层里都有历史包袱。一个“销售额”，财务有财务口径，运营有运营口径，销售有销售口径；一个“客户”，CRM、订单、合同、售后系统里可能都有一套自己的定义；一个“有效订单”，到底按支付、发货、签收还是扣除退款算，不同团队可能默认规则都不一样。
但过去这套东西为什么还能运行？
原因很简单，因为使用对象主要是人。
人是会脑补的。
一个熟悉业务的数据分析师，看到一张表名不规范的表，也能大概知道它来自哪个系统；看到一个字段没有注释，也能凭经验猜出它是状态、类型还是金额；业务同学问“本月新客转化”，分析师脑子里会自动补上“这个部门通常按注册后首单算，不能按首访算”；老板问“华东区利润”，数据团队也知道到底该拿财务月结口径，还是运营日报口径。
这些都不是系统能力，而是人的隐性知识在兜底。
更现实一点讲，业务部门也被迫接受了很多数据基建的不完美。因为大家磨合了很多年，知道哪些报表能信，哪些报表只能参考，哪些指标到了月底要等财务关账，哪些字段虽然名字一样但不能混用。只要核心业务人员、数据开发、分析师之间形成了默契，系统不完美也能被组织协作掩盖掉一部分。
但 AI 时代的问题在于，Agent 不会天然继承这些默契。
你把一堆历史债喂给大模型，它看到的是表、字段、注释、样例、查询记录和 Prompt。至于某个字段为什么虽然叫 amount
，但其实已经扣过退款；某张宽表为什么只能用于日报，不能用于月结；某个客户标签为什么市场部能用，风控部门不能用，这些东西如果没有被显性化，Agent 就不会真正理解。
于是过去被人类经验填平的坑，到了 Agent 面前就会变成幻觉源。
02 面向人建设数据基建，和面向 Agent 建设数据基建，是两码事
这句话听起来有点抽象，但也它其实是今天很多 AI4Data 项目失败的根本原因。
传统数仓和 BI 时代，数据基建默认服务的是“懂业务的人”和“懂数据的人”。系统只要把数据加工出来、把指标算出来、把报表展示出来，后面很多解释、判断、归因和行动，其实由人来完成。
所以传统数仓最关心的是数据怎么分层，链路怎么加工，指标怎么沉淀，查询怎么加速，权限怎么控制，报表怎么交付。
这些当然都重要。
但 Agent 时代，数据基建的使用者多了一个新对象：AI。
AI 不是一个懂业务但不懂 SQL 的普通业务人员，它也不是一个可以靠十年经验补齐系统缺陷的数据分析师。它需要系统把过去散落在人脑、文档、SQL、报表、会议纪要里的业务知识，尽可能变成结构化、可调用、可推理、可验证的上下文。
这时候，数据基建要解决的问题就明显变了：
• 第一，语义要明确。Agent 不能靠猜来理解“毛利”、“有效订单”、“高价值客户”、“履约完成”这些业务词。 • 第二，关系要明确。客户和订单、订单和商品、商品和活动、活动和渠道、渠道和预算、预算和组织之间，到底是什么关系，不能都藏在 Join 逻辑和人的经验里。 • 第三，指标计算逻辑要明确。原子指标、派生指标、复合指标、同环比、累计值、去重口径、时间窗口，都要能被系统稳定表达。 • 第四，业务隐性知识要显性化。哪些业务规则只在文档里，哪些例外只在老员工脑子里，哪些口径只在某个 SQL 里，都要被抽出来。 • 第五，维护成本要低。业务变化是常态，如果每次指标变更、组织调整、字段新增都要重写 Prompt、重调模型，那这套系统很快就会成为新的维护黑洞。 • 第六，查询响应速度和并发能力要跟得上。Agent 可以规划，可以拆任务，可以多轮追问，但最终仍然要落到查询、计算、验证和返回结果。没有高性能的数据底座，上层智能也会被拖垮。
所以 AI 时代的数据基建，不能只问“这个数据给人看够不够用”，还要问“这个数据给 Agent 用是否足够明确”。
03 2026 年的行业趋势，不是模型更强了就能自动补债
如果只看国内很多项目的宣传，会觉得大家还在争论 ChatBI、Data Agent、指标平台、知识库、Prompt 工程到底谁更重要。
但把视角放到 2026 年，全球的主流厂商其实已经在用产品路线给出答案：模型当然要更强，但企业级数据 AI 的短板，越来越明显地落在模型之外。
我们以微软为例：
微软 Fabric IQ 把 Ontology 做成 Fabric 里的业务上下文层，让 entity、property、relationship 这些概念和 OneLake、Lakehouse、Power BI semantic model 等数据资产绑定，再供 Data Agents 和 workflow 使用。这个动作的意义不在于微软也开始讲“本体论”这个词，而在于它把 Agent 所需的企业上下文，从 Prompt 里拿出来，放到一层可治理、可复用、可绑定真实数据源的业务模型里。
Snowflake、Databricks、DBT、Looker 走的名字不完全一样，但本质上都在补同一件事。
这些主流厂商真正值得看的只有一个共同点：大家都在把“业务语义”从应用层、报表层、Prompt 层里抽出来，变成一层能被 Agent 调用的基础设施。
当然有人会提到说看 Skills、MCP 和 OpenAI Agents SDK 这类 Agent 工程能力，仔细研究你会发现它们解决的是另一个问题：
MCP 定义 AI 应用和外部工具、资源、Prompt 之间的上下文交换方式；OpenAI 在 2026 年 4 月更新 Agents SDK，也在强化 harness、sandbox、MCP、Skills、instructions、tools、durable execution 这些能力。
这些能力当然重要，但它们更多是在解决 Agent 如何安全、标准、稳定地使用工具和执行任务。
它们不会自动把企业混乱的指标口径、业务关系、权限规则和历史 SQL 变成可信事实。
所以这一轮行业变化给企业的启发很直接：AI4Data 的竞争，正在从“谁的模型更会说”转向“谁能把企业业务世界更准确地表达给模型”。
语义工程决定输入材料是否可靠，Harness 工程决定执行过程是否可控，两者缺一不可。
04 只做 Prompt 和 Harness，本质上是在用胶带修地基
现在很多企业做 AI4Data 项目，最容易走进一个误区：觉得只要 System Prompt 写得足够细，Agent 框架设计得足够复杂，就能让大模型理解整个业务系统。
这个思路看起来很快，也很符合当下 AI 项目的交付节奏。
先把数据库 Schema 扔进去，再补一段业务说明；系统答错了，就继续加 Prompt；某个部门口径特殊，就再加一条规则；某个角色权限不同，就再加一段约束；遇到复杂问题，再让 Agent 先 plan，再调用工具，再自检。
短期 Demo 可能能跑，长期生产大概率会失控。
原因在于，Prompt 和 Harness 更像过程控制，而不是事实建模。它可以告诉模型“你应该怎么做”，但不能保证模型拿到的材料本身就是对的。
举个很简单的例子。
如果你和你的舍友之间的关系，在系统里被明确建模成“舍友关系”，并且这个关系有来源、有约束、有时间范围，那大模型基于这份材料去推理，就不会把你们理解成“父子关系”。
但如果系统里只有几段含糊的文本、几个不完整字段、几条历史聊天记录，再靠 Prompt 告诉模型“请仔细判断人物关系”，那它再怎么认真，也只能在不确定材料上做概率推断。
数据项目里的情况也是一样。
如果“有效订单”、“高价值客户”、“华东区”、“渠道归因”、“活动转化”这些概念没有被建模清楚，关系没有被表达清楚，权限没有和业务对象自动联动，指标口径没有版本化管理，那后面的 Harness 再复杂，也只是把一个不稳定输入包装成更复杂的执行过程。
很多人最近都在讲 Harness 工程，我也认同它很重要。
Agent 当然需要 plan，需要工具调用，需要约束，需要沙箱，需要审计，需要中间步骤，需要失败重试，也需要 Skill、Prompt、知识库、数字人这类能力作为粘合剂。
但 Harness 解决不了“旧数仓喂进去的东西到底是不是可靠事实”这个问题。
材料有幻觉，过程越复杂，幻觉扩散得越隐蔽。
05 两种看起来相反的路线，其实都会踩坑
在 AI4Data 落地里，经常能看到两种看起来完全相反的解决思路。
一种是重治理路线。
企业意识到 AI 用不起来的根因是数据质量，于是花很大代价请咨询公司做治理，梳理指标、清理数据、统一口径、重建标准。这个判断本身没有错，AI4Data 应用跑不起来，很多时候确实是数据质量和语义质量问题。
但难点在于，传统治理项目往往周期太长，业务变化又太快。
做了一年两年，历史问题解决了一部分，新业务、新系统、新指标、新口径又出来一堆。等治理项目阶段性验收时，业务侧的真实问题已经换了一批。结果就是，企业花了很多钱，文档沉淀了不少，真正能给 Agent 持续使用的结构化语义资产却不多。
另一种是走极简路线。
既然治理太重，那干脆只做指标层，把高频指标全部算好，放进一个指标池。上层 AI 只在这个池子里回答问题，不让它自由查库，这样幻觉自然会少很多。
这个思路在局部场景里有价值。
如果业务问题高度标准化，指标口径稳定，问题范围有限，指标池确实能降低风险。比如固定经营周报、固定管理驾驶舱、固定 KPI 问答，这条路可以快速见效。
但一旦目标变成 Data Agent，指标池的天花板就会很明显。
• 第一个问题是维护成本。一个业务条线 200 个指标，全集团几千个指标并不夸张。每个指标都要定义、开发、校验、解释、授权、版本管理、上下线管理，这很容易变成另一种形式的数仓维护老路。 • 第二个问题是泛化能力。指标池擅长回答“看什么”，但很难回答“为什么”。因为“为什么”往往需要实体与实体、事件与事件、事件与实体、事件与指标之间的关系。只把指标预先算好，并不能让系统理解业务发生了什么。 • 第三个问题是深加工和校验。一个复合指标经过多层计算以后，如果系统不能回到对象、事件、关系和原始口径做逆向追溯，那么后续分析越复杂，越难判断结论是否可靠。大模型要么从几百个指标里随机筛一部分来讲故事，要么在二次加工时引入新的不准确。
还有一种极端，是直接拿 ODS 或原始明细喂给模型，试图用“全量数据 + 大上下文 + 强模型”解决问题。
这条路看起来最自由，实际最危险。
原始数据里没有统一业务语义，没有稳定 Join 关系，没有指标口径，没有角色约束，没有质量约束。Agent 面对这样的数据世界，就像一个外部顾问被扔进企业几十套系统里，还没人告诉它哪张表可信、哪个字段过期、哪个口径是老板会议默认口径。
这不叫智能，这叫盲人摸象。
06 本体化语义层真正解决的，是 Agent 的“世界模型”
所以问题最后会回到一个更根本的东西：企业到底要给 Agent 一个什么样的数据世界？
所谓本体化语义层，更准确说，是以本体建模的方法去建设语义层。它不是简单给表和字段补中文注释，也不是只做一个指标字典，而是把企业业务中的对象、关系、事件、指标、规则、权限、状态、动作，用机器能理解和执行的方式表达出来。
客户是对象，订单是对象，商品是对象，门店是对象，仓库是对象，活动是对象，渠道是对象，组织也是对象。
对象之间有关系。
客户下订单，订单包含商品，商品参与活动，活动投放在渠道，渠道归属于预算，预算归属于组织。订单有支付、发货、签收、退款这些事件，事件会改变对象状态，也会影响指标计算。不同角色看同一个对象，能看到的字段和能采取的动作也不一样。
当这些东西被显性化以后，Agent 拿到的就不再是一堆表和字段，而是一套业务世界的地图。
这张地图至少有几个价值：
• 第一，它能降低幻觉源。因为投喂给模型的材料本身更明确、更可信、更结构化。 • 第二，它能收敛推理空间。模型不需要在无限 Schema 里乱猜，而是在已经定义好的对象、关系、指标、权限和动作空间里做规划。 • 第三，它能支持角色差异。同一个问题，财务、运营、销售、制造可能需要不同口径、不同路径、不同权限。把这些差异放进语义层和本体化模型里，比写进一段超长 Prompt 更可维护。 • 第四，它能支撑归因和行动。只看指标，系统只能回答“掉了多少”；理解对象、事件和关系以后，系统才有机会回答“为什么掉、影响了谁、下一步能做什么”。 • 第五，它能和 RBAC、审计、数据血缘、质量校验形成工程闭环。Agent 每一次回答，都可以追溯到哪些对象、哪些关系、哪些指标、哪些查询、哪些权限约束，而不是只留下一个自然语言结论。
从这个角度看，Data Agent 真正需要的不再是一个更会聊天的前端，应该是一套能把企业世界翻译给 AI 的中间层。
这也是为什么 NL2SQL 直接生成很容易失控，而 NL2LF2SQL 这类中间逻辑形式路线更有生产价值。
自然语言先转成 Logical Form，明确对象、指标、条件、时间、关系和权限，再映射到 SQL 或 API，系统才有机会在复杂业务问题里保持可解释、可审计和低幻觉。
07 AI 时代的数据治理，不应该只停留在“清洗历史债”
讲到这里，必须补一个现实问题。
如果企业真的要建设面向 Agent 的数据基建，那数据治理也要升级。
过去的数据治理，很多时候是在补历史债：字段命名不规范就改命名，指标口径不统一就出标准，报表没人用就下线，数据质量不稳定就加校验。
这些事情仍然要做。
但 AI 时代的数据治理，不能只停留在“把过去的问题清一遍”。因为 Agent 面临的不是静态系统，而是一个持续变化的业务世界。
组织会变，渠道会变，产品会变，业务规则会变，权限会变，指标口径会变，系统 Schema 也会变。只靠阶段性治理，很难支撑长期生产。
更合理的方向，是把治理能力变成语义层和本体化模型的一部分。
比如，字段变化时，系统能自动感知哪些对象、指标、关系可能受影响；指标定义变化时，能知道哪些 Agent 技能、报表、问答样例、验证集需要回归；角色权限变化时，能自动影响对应对象、属性、指标和动作的可见范围；数据质量异常时，能阻断某些答案生成，或者显式告诉业务“当前结果不可用于决策”。
这时候的数据治理，就不再只是写标准、出制度、补文档，而是进入 Agent 工作流本身。
它的价值不在于企业一定要照搬某个标准，而在于提醒我们：AI 时代的数据资产，不能只有物理字段，还要有业务定义、质量约束、变更责任和可追溯来源。
面向人，很多信息可以放在文档里。
面向 Agent，这些信息最好能被系统读取、理解、验证和执行。
08 传统数仓不会被抛弃，但它需要被重新定位
所以这篇文章并不是要说传统数仓没有价值。
恰恰相反，传统数仓、湖仓、实时数仓、OLAP 引擎，在 AI 时代仍然非常重要。（尤其OLAP引擎）
因为 Agent 最终也要查数据、跑计算、做聚合、做下钻、做并发、做低延迟响应。没有稳定的数据工程和高性能查询能力，语义层建得再漂亮，上层应用也会卡在性能和成本上。
但传统数仓需要被重新定位。
过去它主要是面向 BI、报表和分析师的交付层；未来它更像面向 Agent 的物理数据底座。
在这个底座之上，企业需要新增一层面向 AI 的解释层，也就是以语义层为起点、逐步本体化的业务世界表达。
再往上，才是 Harness 工程：Plan、Tool Calling、MCP、Skill、Prompt、Guardrail、Sandbox、Memory、Evaluation、Workflow。
最后才是应用层：ChatBI、Data Agent、经营分析助手、多智能体协作、数字员工、动作派发。
如果把这几层关系说清楚，路线就会变得很简单：
底层要快、稳、准。
中间要懂业务、懂关系、懂口径、懂权限。
上层要会规划、会调用、会追问、会解释、会执行。
企业最怕的是只做最上层。
上来就做一个很酷的 Agent 界面，下面还是一堆语义混乱、关系不清、口径不明、权限割裂、质量不可控的数据资产。这样的系统短期能演示，长期很难承担生产责任。
09 企业应该怎么走这条路
如果从落地角度看，不建议企业一上来就搞一个全集团、全域、全流程、强本体、强动作的超级工程。
那样很容易做成另一个巨大的平台项目，周期长、投入大、收益慢，最后又变成新的历史债。
更现实的路径，是从一个高价值业务域切进去。
比如销售经营、供应链、财务分析、门店运营、生产制造、客户增长，先选一个业务问题足够高频、数据链路足够关键、组织愿意参与共建的领域。
第一步，不是先接模型，而是先梳理这个领域里最核心的对象、事件、关系和指标。
比如销售经营域里，客户、订单、商品、活动、渠道、组织、销售人员、合同、回款，哪些是对象；支付、发货、签收、退款、拜访、转化、续约，哪些是事件；GMV、净销售额、毛利、复购率、客单价、转化率，哪些是指标；财务、运营、销售分别用什么口径；哪些数据能看，哪些数据不能看。
第二步，把这些内容沉淀成可维护的语义模型，而不是散落在 Prompt 和文档里。
表字段和业务概念要绑定，指标公式和口径要版本化，对象关系要显性化，角色权限要联动，关键业务规则要能被查询链路和 Agent 运行时读取。
第三步，建立从自然语言到逻辑形式再到 SQL/API 的中间表达。
不要让模型直接在复杂 Schema 上自由发挥。让它先把问题翻译成可检查的业务逻辑表达，再由确定性引擎映射到查询和动作。这样一旦结果不对，企业能知道错在意图理解、语义映射、指标口径、Join 路径，还是底层数据质量。
第四步，把验证集和评估体系做起来。
Snowflake 的 verified examples、Databricks 的 benchmarks 和 Inspect，其实都在说明一件事：生产级自然语言分析不能只靠感觉好不好，而要有持续评估机制。企业也应该沉淀自己的黄金问题集、标准答案、典型追问、异常样例和回归测试。
第五步，再把 Harness 工程接上来。
Plan、Tool、MCP、Skill、Prompt、Guardrail、Sandbox、Memory、Workflow 都很重要，但它们应该站在可信语义基座上发挥作用。否则 Agent 看起来会做很多事，实际每一步都可能建立在不可靠材料上。
这条路线不一定最性感，但最符合企业生产现实。
写在最后
过去十几年，企业数据基建的核心目标，是让人更容易看到数据、分析数据、管理数据。
未来十年，企业数据基建会多出一个非常重要的目标：让 AI 能够正确理解企业的业务世界，并基于可信数据去分析、推理和执行。
这个变化会重写很多东西。
它会重写数仓建设的目标，因为表、字段、指标不再只是给人看，也要给 Agent 用。
它会重写数据治理的重点，因为治理不再只是历史债清理，而要变成 Agent 可持续使用的语义资产建设。
它会重写 BI 和 Data Agent 的边界，因为自然语言问答只是入口，真正的差距会出现在语义建模、逻辑表达、关系推理、低幻觉执行和业务动作衔接上。
它也会重写数据团队的角色。
过去的数据团队像“报表工厂”和“取数中心”，未来会越来越像企业业务世界的建模者、解释者和运行时维护者。
谁能把企业隐性知识变成机器可读的语义资产，谁就能真正把 AI4Data 从演示拉进生产。
所以，AI 时代最值得重做的数据基建，不是再造一个更大的指标池，也不是把所有希望压在下一代大模型上，更不是用一段越来越长的 Prompt 去包住所有业务复杂性。
真正值得建设的，是一套面向 Agent 的本体化语义层，再配合高性能数据底座、Harness 工程、Skill、Prompt、知识库、权限治理和持续评估体系。
只有这样，企业未来的 Data Agent、多智能体协作、数字员工和经营动作派发，才不是漂浮在旧数仓历史债之上的幻觉应用，而是长在可信业务语义基座上的生产系统。
如果你的企业也想基于这样的方向来做面向AI未来的数据基座，那可以文末扫码了解一下亿问Data Agent产品。
还是那句话，只有经历过，才知道什么是最合理的。
最后看到这里了，来个点赞、转发和在看吧，这是唯一更新的动力来源了～
下一篇我来拆解给大家看看，本体语义层和指标语义层到底有什么不一样。
参考资料
• Microsoft Fabric IQ：What is ontology (preview)? • Snowflake Cortex Analyst Documentation • Databricks：What is a Genie space • dbt Semantic Layer Documentation • Google Looker：Use Looker with MCP, Gemini CLI and other Agents • Model Context Protocol：Architecture overview • OpenAI：The next evolution of the Agents SDK • Open Data Contract Standard：Schema
