过去很多年企业做数仓有一个非常明确的目标把 ERP、CRM、MES、WMS、财务系统里的数据统一接进来经过清洗、加工、建模最后整理成一张张方便使用的主题宽表。销售分析有销售宽表客户分析有客户宽表库存分析有库存宽表财务经营分析再做一张经营宽表。对于传统 BI 来说这套方式一直很好用。换句话说过去数仓主要负责一件事把数据准备好至于数据怎么理解、怎么分析交给人。但 Data Agent 出现以后这个前提正在变化。现在企业希望业务人员直接问“为什么这个月利润下降了”“最近三个月哪些客户的经营情况出现了异常”Data Agent 不仅要找到数据还要理解问题、选择指标、规划分析路径、连续追问甚至调用不同工具完成分析。于是一个很现实的问题来了原来给人用的宽表真的够直接给 AI 用吗答案是宽表依然需要但只靠宽表已经远远不够。如果想更直观地理解这种变化可以看看FineBI Next 的 AI 智能分析。它已经不是简单把“自然语言翻译成 SQL”而是让 AI 围绕业务问题先理解需求、拆解分析步骤再基于已有数据完成指标计算、图表生成和结论总结发现异常之后还能结合上下文继续追问、逐层下钻把一次临时探索进一步沉淀成仪表板、故事板甚至可复用的分析技能。需要自取https://s.fanruan.com/zk65g复制到浏览器这其实也把一个问题摆到了数仓团队面前当 BI 开始从“人操作工具分析数据”走向“AI 自主理解和探索数据”底层到底应该给 AI 准备什么样的数据而这正是本文想讨论的重点。一、宽表没有过时它解决的只是“数据怎么方便使用”先别急着给宽表判死刑。对于大量固定、高频的分析场景宽表依然非常有价值。比如销售分析经常需要同时使用订单、客户、商品、渠道、区域、销量、销售额、折扣、成本和毛利。如果每次分析都从十几张业务明细表重新关联不仅 SQL 会越来越复杂查询性能也很难保证。所以数据团队提前把这些数据按照业务主题整理好本身没有任何问题。宽表解决的主要是减少复杂关联、提高查询效率、降低数据使用门槛。但它解决的是数据怎么更方便地被取出来。而 Data Agent 面对的问题则是这些数据是什么意思、什么时候应该使用、不同数据之间应该怎么组合。这是两个完全不同的问题。二、有字段不等于AI真正理解业务假设一张经营宽表里面同时存在sales_amount、invoice_amount、recognized_revenue、net_sales、refund_amount。业务人员问“今年收入是多少”Agent 应该选择哪个字段是销售额、开票金额、会计确认收入还是扣除退款后的净销售收入对于熟悉公司业务的人来说这可能并不难。但如果数据层只告诉 AI 字段名、类型和表之间的关系那么它很可能根据字段名称挑出一个“看起来最合理”的答案。SQL没有报错计算过程也完全成立最后的业务结果却可能是错的。这也是很多智能问数项目最容易忽略的问题SQL正确不等于业务答案正确。因为企业里大量指标本身就带有业务语境。“客户数”到底是注册客户、成交客户还是有效客户“利润”指毛利、经营利润还是净利润“本月”按照自然月还是财务期间销量是否排除取消订单和退货订单过去这些规则大量存在于人的经验里。而 Data Agent 出现以后企业必须开始把这些藏在人脑里的业务规则显性化。三、但在讨论语义之前很多企业还有个更基础的问题数据根本没连起来这也是不少 Data Agent 项目真正落地时最先遇到的问题。架构图上可以同时出现大模型、RAG、语义层、知识库、Agent、MCP看起来很完整。但到了企业现场往往第一步就卡住了订单在 ERP客户在 CRM库存放在 WMS生产数据在 MES财务数据又在另一套系统中间还夹着 Excel、数据库、API 和一堆历史系统。业务人员问一句“为什么这个月利润下降了”背后可能需要同时调用销售、客户、成本、费用、订单和回款数据。如果这些数据还依赖人工导表、临时脚本拼接不同系统的数据一天一更、一周一更甚至同步失败了都没人知道那么后面的智能分析自然很难稳定。所以真正开始搭 Data Agent 之前通常还是要先把这条基础链路理顺业务系统 → 数据采集与同步 → ODS → DWD → DWS → 数据服务这一阶段做的事情其实一点也不“AI”。接数据源、处理增量、清洗转换、配置调度、检查任务、处理异常。但恰恰是这些最传统的数据工程工作决定了后面的 AI 能不能用。实际做这条链路时像 ERP、CRM、MES、数据库、API、Excel 这些不同来源的数据我们会通过 FineDataLink 统一做采集、同步和加工至少不用再给每个系统单独维护一套脚本和定时任务。系统少的时候写几个脚本问题不大真正到了集团型企业几十套系统、几百个数据任务长期运行以后更麻烦的反而不是“第一次把数据接进来”而是谁在失败、哪里延迟、上游字段改了之后哪些任务受到影响。所以 Data Agent 的第一层基础其实一点也不性感先保证数据能够按时进来、正确加工、持续更新。这一步做不好后面的语义层和 Agent 都只是空中楼阁。四、宽表提供了数据却不会告诉AI“这个问题应该怎么分析”即使底层数据已经稳定还有第二个问题。用户问“为什么这个月利润下降了”这不是简单查询一个“利润”字段就能回答的。Agent首先需要判断是收入下降还是成本费用增长。如果收入下降还要继续分析销量、价格、产品结构、客户结构如果成本上涨又可能继续拆采购价格、材料消耗、人工、制造费用和物流成本。这一整套过程本质上是一套经营分析方法。为什么过去 BI 用户能够完成因为分析师已经把这些方法装在脑子里。他知道利润和收入、成本、费用之间的关系也知道一个指标异常以后应该沿哪些维度继续拆。但是 Data Agent 不具备企业内部天然的业务经验。所以未来数仓需要交付的不应该只是一张字段很多的宽表。还应该逐渐包含指标之间的关系、业务规则以及面对某类问题时可调用的分析能力。否则就会出现一个很尴尬的现象企业有几百张表、几千个字段、上万个指标但AI 根本不知道应该先看哪个。五、宽表越宽Agent反而可能越容易选错过去做 BI经常会遇到一句话“这些字段都放进去吧以后肯定用得到。”于是几十个字段逐渐变成几百个甚至上千个。对人来说问题还没有那么严重因为真正做分析的时候通常只会使用自己熟悉的一部分字段。但对于 Agent 来说候选字段越多意味着选择空间越大。一笔订单可能同时存在创建时间、支付时间、发货时间、签收时间、开票时间、收入确认时间。用户问“今年销售收入趋势怎么样”究竟应该按哪个时间统计如果没有明确的业务语义大模型完全可能选出一个技术上能运行、业务上却不成立的字段。而这种错误最麻烦的地方在于它通常不会报错。数字看起来甚至很合理只是口径悄悄错了。因此Agent时代的数据准备逻辑会逐渐从“尽量把所有字段都给它”变成“围绕当前问题只提供正确、可信、符合口径的数据。”六、真正的Data Agent也不是“自然语言转SQL”很多智能问数 Demo 的流程很简单用户问“本月销售额是多少”AI生成 SQL。数据库返回结果。结束。但真实企业的问题往往不是这样。用户可能先问“华东为什么没有完成利润目标”发现收入下降以后继续问“哪个产品影响最大”接着问“这个产品是销量下降还是价格下降”然后再追问“主要集中在哪几个客户”最后甚至要求“把需要销售重点跟进的客户整理出来。”这个过程已经从一次查询变成了一条完整分析链路问题理解 → 任务拆解 → 指标调用 → 数据查询 → 异常识别 → 原因分析 → 连续追问 → 形成结论 → 推动行动宽表能够很好地支撑其中的“数据查询”。但任务规划、上下文继承、业务分析方法、工具调用已经超出了宽表本身能够解决的范围。七、所以AI时代的数仓不是不要宽表而是还要往上补几层更实际的架构并不是把 ODS、DWD、DWS、ADS 全部推倒重来。经典数仓四层依然有自己的价值。ODS负责承接原始数据DWD统一业务事实DWS沉淀公共主题模型ADS面向具体应用提供稳定的数据集。真正发生变化的是ADS 之上还需要增加一些能力业务系统 ↓ 数据采集与集成 ↓ ODS → DWD → DWS → ADS ↓ 指标与语义 ↓ 知识与上下文 ↓ AI Serving / Tool ↓ BI、智能问数、Data Agent、业务工作流过去做到 ADS基本已经可以认为数据交付完成。但到了 Agent 时代ADS不再是唯一的数据终点。因为 AI 需要的不只是“数据已经准备好了”还需要知道这些数据意味着什么、应该如何使用。八、第一层升级从字段升级到业务语义过去数据团队告诉系统的是order_amount 是 decimalcustomer_id 是 stringorder_date 是 date。但 Data Agent 真正需要知道的是customer_id代表客户客户和订单是一对多关系销售收入按照收入确认口径统计取消订单不能计入销量退款需要冲减净销售收入集团、区域、公司之间存在组织层级品类、品牌、SKU之间存在产品层级。也就是说企业需要逐渐把业务语言沉淀下来。主要包括业务实体、指标定义、维度层级和业务规则。有了这些东西以后Agent面对的就不再是“数据库里有1000个字段。”而是“企业有客户、商品、订单、收入、成本、利润等业务对象它们之间存在明确关系。”这是从技术模型到业务模型的一次升级。九、第二层升级从宽表升级到统一指标另一个特别现实的问题是企业里的指标本身就很乱。财务报表算一套毛利率经营看板算一套分析师自己的 SQL 里还有一套现在再加一个 Data Agent如果它每次重新理解字段、重新生成计算逻辑很容易再制造出第四个版本。所以Agent 越往生产环境走指标治理反而越重要。像营业收入、毛利率、库存周转率、回款率、人效这些高频指标不能只作为某一张报表里的计算公式存在而应该把定义、计算逻辑、维度关系和适用范围统一沉淀下来让报表、BI 和 AI 共用。这一点放到实际分析过程中会很明显。比如在FineBI Next里已经搭好了经营分析看板业务人员看到某个区域毛利率连续下降过去可能要重新找分析师取数。现在可以直接围绕当前数据继续问为什么下降主要是哪几个产品是销售价格下降还是成本上涨影响最大的客户是谁如果这些分析以后还会反复使用再把其中有价值的表、图和分析路径继续沉淀下来。这样就形成了一条比较自然的分析闭环看板发现异常 → AI继续探索 → 找到原因 → 沉淀分析资产 → 后续持续监控这里真正重要的不是 AI 会不会“自动画图”。而是BI 和 AI 能不能尽量建立在同一套数据资产和指标口径上。否则智能问数做得越多口径反而可能越来越乱。十、第三层升级从“查询数据”升级到“调用分析能力”Data Agent 和普通智能问数最大的区别之一就在这里。一个真正能进入企业业务流程的 Agent不应该只会临时生成 SQL。很多成熟、高频的分析方法本来就应该逐渐被封装成工具。比如用户问“利润为什么下降”Agent可以调用统一指标查询利润变化再调用趋势分析判断异常时间然后按区域、产品、客户拆贡献度最后调用利润归因模型把变化拆成价格、销量、产品结构、成本和费用因素。这时候Agent承担的是理解问题、规划步骤、选择工具、组织结论。真正的计算则由企业已经治理好的数据和分析服务完成。这会比让大模型每次都从底表开始自由探索可靠得多。因为企业最怕的从来不是 AI 不会分析。而是它每次都用不同的方法分析。十一、第四层升级数仓以后还要为AI准备“上下文”这是传统数仓很少显式考虑的一层。用户问“为什么本月利润下降”知道“利润”的定义还不够。Agent还需要知道当前用户属于哪个组织、能够看到哪些公司、本月指哪个财务期间、利润目标是多少、应该与预算还是同比比较、数据更新到什么时间、当前有哪些已知异常、允许调用哪些分析工具。这些信息共同决定了这一次问题到底应该怎么回答。所以未来的数据架构不只是把整个数据库交给模型。更合理的方式是根据问题、身份、权限和任务动态准备一份正确的上下文。这也是为什么“上下文工程”会逐渐成为企业 Data Agent 落地里非常关键的一环。十二、权限也会从“能看什么”变成“能做什么”传统数仓权限大多围绕数据展开。谁能看哪张表谁能看哪些字段谁只能查看自己区域的数据。但 Agent 不只是查数据。它还可能调用工具、生成文件、访问企业知识甚至触发后续业务流程。于是权限边界需要进一步扩展。例如销售经理可以查询自己区域的客户收入但不能看到全集团薪酬数据采购 Agent 可以分析供应商交付情况却不能直接修改供应商主数据经营分析 Agent 可以生成预算调整建议但真正修改预算仍然需要人工确认。所以未来的权限体系实际上会从数据访问权限扩展成数据权限 工具权限 行动权限。这也是 Data Agent 真正进入企业以后和普通聊天机器人最大的区别之一。十三、宽表以后还建不建当然建Data Agent并不会消灭宽表。对于稳定、高频、确定性的业务场景宽表和 ADS 依然是非常高效的方案。销售日报、库存监控、生产运营、财务月报、经营驾驶舱这些东西根本没有必要每天让 AI 重新推理一遍。因此未来更可能形成两条并存的数据消费路径确定性问题DWS → ADS / 宽表 → BI / 经营看板动态问题DWS → 指标与语义 → AI Serving → Data Agent前者强调稳定、性能和持续监控后者强调动态组合、上下文和推理分析。底层依然共享同一套企业数据。十四、BI也不会因为Agent出现而消失“有了AI以后还要不要BI”这个问题其实也问偏了。企业大量经营问题并不是临时提问而是需要持续监控。销售完成率、利润率、库存周转、现金流、回款率、项目进度这些指标每天、每周、每个月都要看。没有必要每天问一句“今天库存有没有问题”更合理的方式是FineBI Next这类 BI 继续承担固定、高频的监控分析当看板出现异常以后再进入 AI 分析和连续追问。所以未来很可能不是BI和Agent二选一。而是已知问题交给BI持续监控未知问题交给Agent动态探索。BI负责告诉你“哪里出问题了”Agent进一步帮助回答“为什么”。而当某类“为什么”不断重复出现以后又可以重新沉淀成指标、分析模板或者看板。AI并不是 BI 的终点。很多时候AI分析出来的结果最终还是要重新沉淀回企业的数据资产体系里。十五、数据团队接下来真正要补的也不只是AI技术如果企业已经有 ODS、DWD、DWS、ADS其实完全没有必要为了 Data Agent 推倒重建。更实际的做法是沿着现有的数据体系逐层补能力。先检查底层数据链路。哪些数据还靠人工导 Excel哪些系统同步不稳定哪些任务经常失败哪些数据更新延迟严重先通过FineDataLink这类数据集成能力把ERP、CRM、MES、WMS、数据库、API等数据源真正串起来让数据稳定进入数仓。再往上看数仓模型。DWD有没有统一业务事实DWS有没有沉淀公共分析模型核心指标是不是还散落在各种 SQL 和报表中。继续往上再补指标语义、业务规则、分析方法和 AI 可调用的数据服务。到了最终使用端则不是简单再增加一个聊天机器人而是让 FineBI Next 原来承担的固定分析、经营监控与 Agent 的动态探索连接起来。这样整个数据链路会变成数据稳定进入 → 数仓统一加工 → 指标语义统一 → BI持续监控 → Agent动态分析 → 结果再次沉淀这才比较接近 Data Agent 真正进入企业以后的样子。写在最后Data Agent来了以后真正改变的并不是 ODS、DWD、DWS、ADS 这些经典数仓分层。变化最大的是数仓的使用者变了。过去数仓主要服务人。所以只要把数据整理成宽表剩下的业务理解、指标选择、分析路径可以交给分析师完成。现在 AI 开始成为新的数据消费者。那么过去藏在人脑里的很多东西都必须逐渐被数据架构显性化指标是什么意思业务对象之间是什么关系面对一个问题应该沿什么路径分析哪些数据可以调用哪些工具可以执行结果如何沉淀和复用。所以 AI 时代数仓真正需要升级的并不是从100张宽表变成200张更宽的表。而是从“给人准备数据”逐步升级成给人和AI共同提供可理解、可调用、可治理的数据能力。宽表不会消失。但它会越来越像整个数据供应链中的一个环节而不再是数据建设的最终交付物。下一代数仓真正要回答的问题也将从“报表需要哪些字段”变成“当企业的数据使用者不再只有人而开始包括 Data Agent我们到底应该给它准备什么”