先看一个几乎每家公司都演过的场景。季度经营会上，两个人拿着两份报表吵了半小时：一份写「月活 8.6 万」，一份写「月活 12.3 万」。两份都叫月活，区别在于一份按「打开过 App」算、一份按「有过任意操作」算；一份排除了内部账号，一份没排。数据都没算错，错的是没人把口径写下来。
数据仓库这条线，真正难的不是建表，而是让所有人看到同一个数字。而这件事里恰好有一大半是「有规则可依的重复劳动」：结构检查、命名校验、口径登记、变更比对、取数翻译。这些正是可以交给 Agent 的部分。
先说清这篇的位置。站内相邻的几篇都不在这个角度上：用 AI Agent 做埋点方案设计与校验 管的是事件还没产生时怎么定命名与上报规则；AI Agent 数据分析怎么搭 管的是数据已经能取到手之后怎么跑代码算结论出报告；OpenClaw 数据质量门禁怎么设 管的是数据进来之后怎么拦空值、重复和异常波动；用 AI Agent 做数据血缘说明 管的是结论怎么追回来源表和口径；OpenClaw 成本归因报表怎么做 管的是 Agent 自己花的钱怎么拆开算。这一篇管的是中间那一段——流水怎么按层次沉淀成能复用的表，指标口径从哪来，谁用什么权限取数。
一、先把三件事分清：数仓、报表、分析
很多「数仓项目」做不下去，是因为一开始就把三件事混成了一件：
- 数仓解决的是「同一份事实只存一份、只算一次」。它是结构问题。
- 报表解决的是「结论以固定形式、按固定节奏送到该看的人手里」。它是交付问题。
- 分析解决的是「一个新问题能不能用现有数据回答」。它是方法问题。
Agent 在这三件事里的角色完全不同：在数仓里它是登记员和校验员，在报表里它是排版工和跑批工，在分析里才轮到它当助手。角色放错，就会出现「让 Agent 从零设计整套数仓」这种一上来就翻车的做法——它给你的会是一份看起来很完整、但混着大量猜测业务假设的方案。
二、四层分工：ODS、DWD、DWS、ADS 各管什么
分层不用背概念，按「谁在什么粒度上回答什么问题」理解就够：
- ODS（贴源层）：日志和业务库原样落进来，字段不许改名、不许修值。这一层只允许追加、不允许更新，方便任何时候回溯原始数据。
- DWD（明细层）：把同一件事的不同来源对齐——统一用户标识、统一时间字段、统一枚举值，并做必要的清洗。这一层是「一次对齐、到处复用」的地方，也是最该被保护的地方。
- DWS（汇总层）：按常用维度先算好中间结果，比如「用户 × 天」的活跃与行为次数。它存在的唯一理由是减少重复计算。
- ADS（应用层）：完全按报表和看板的需求出表，允许冗余、允许宽表、允许为某块看板单独优化。它只服务于消费方，不承担复用责任。
让 Agent 在这一层干活，重点是三类规则化检查：一是命名规范是否齐全（层次前缀、分区字段、统计周期后缀）；二是是否有人绕过 DWD、从 ODS 直接出报表；三是 DWS 的表有没有被当成 ADS 用、被直接连到看板上。这三类不需要模型判断业务，错判率低、几乎不用人工复核，性价比最高。
三、指标字典：一个指标写清六件事
「同一个词在四份报表里算法不同」只有一个根治办法：把指标写进字典。字典里一个指标至少六项，缺一项就等于没定义：
- 指标名与别名：把历史叫法一起登进去。同一个东西起过三个名字，是口径分叉最常见的起点。
- 业务定义：一句话说清它在业务上代表什么，不许出现「大概就是」「一般指」这类表述。
- 计算口径：分子分母分别是什么、从哪张表来、要不要去重。
- 时间窗口：自然日还是滚动 24 小时，按事件时间还是按入库时间，跨时区怎么算。
- 过滤条件：要不要排除内部账号、测试账号、异常流量。这一项漏掉，月活能差出三成。
- 责任人：谁定义、谁批准变更。最常被省、也最关键的一项。
Agent 在这里的价值，是把字典从一份文档变成一道门禁：新人提报表需求时，指标名先对字典，字典里没有的不许直接进开发队列；有人悄悄改了 SQL 里的分母，比对工具把差异标出来，交给责任人确认。这种「口径变更必须留痕」的思路和 A/B 实验里先把指标口径定死 是同一个道理——口径一旦口头化，后面所有争论都没有裁判。
四、自助取数：Agent 能替人做什么、不能做什么
「让业务同学自己问数据」这件事，Agent 确实能往前推一大步，但边界必须划清楚，否则出来的是一堆没人敢用的数字。
可以交给它的：
- 把业务问题翻成受约束的查询：只允许在 DWS 与 ADS 上取数，字段必须先命中字典，指标必须先命名。它做的是翻译，不是自由创作。
- 给出可复现的取数结果：每次取数都附带用的哪张表、哪一版口径、跑了什么条件，让结果本身可被复核。
- 把重复需求收成模板：同一个人每周都问一次的问题，直接固化成取数模板，减少重复劳动。
不能交给它的：
- 定义新口径。它会把「活跃」理解成最省事的那个版本，而不是业务真正想看的那个版本，而且它不会主动说「你这个定义跟已有指标冲突」。
- 直连生产库。取数一律走仓库，直连业务库跑大查询是最经典的线上事故现场。
- 自己判断敏感字段。哪些字段能出、哪些必须脱敏，要写成规则列表，不能指望它临场判断，思路可以直接沿用 AI Agent 处理个人信息怎么合规 里那套分级加最小字段的做法。
五、行级权限：不能靠自觉，要写进规则
数仓最尴尬的一类事故，是「数据都在，但被不该看的人看到了」。这件事靠文档约束不了，只能靠规则：
- 按角色划分可见范围：区域负责人只看本区域、门店只看本门店。行级条件要和角色绑定，而不是和执行人绑定——人一换岗，权限就该跟着变。
- 敏感列单独授权：手机号、证件号、精确地址这类列，默认不出现在任何自助取数结果里，需要单独申请并留痕。
- 取数行为留日志：谁在什么时候取了哪些表、看了哪些列，要能查。这里的设计可以参考 AI Agent 审计查询字段怎么设计，把「查得回来」当成验收标准。
- 权限和工具白名单一起管：给 Agent 挂的工具越少，越界的方式越少，这条原则见 AI Agent 权限管理怎么做。
六、变更影响：改一张表，谁会受影响
数仓的变更成本，永远比新人估计的高。改一个字段类型、挪一个分区、停一张旧表，受影响的是下游的报表、看板、取数模板和别人的脚本。所以变更流程里要有三个动作：
- 改前先查血缘：这张表被谁引用、引用的哪几个字段。血缘没查清就动手，等于闭着眼睛拆承重墙。
- 给下游一个缓冲期：旧字段先保留双写一段时间，等下游全部切换完再停，别在同一天既改又删。
- 变更后回查一遍：改完不是结束，要确认报表数字没断、没有报表悄悄变成空值。这一步可以交给 Agent 定期跑，把「改了之后有没有人受影响」变成自动检查项。
七、落地四步
如果团队现在还是「人人都能从业务库拉数」的状态，建议按这四步走，不要一次全铺开：
- 先收口子：把取数入口统一到仓库，禁止直连业务库。这一步最难的是说服人，不是技术。
- 再定字典：把已经在用的指标先登记一遍，重点补上分母、时间窗和过滤条件。存量指标登记得越全，后面越省事。
- 然后上规则：命名校验、层次校验、口径比对、权限规则，一条一条加进流程，每条都配一个「怎么验收」。
- 最后开放自助取数：等前三条稳定了，再放开给业务同学自己问。顺序颠倒，就会变成一场没人负责的数据混乱。
八、四条边界
- 不替人定义业务口径。Agent 可以校验一致性，不能决定「算不算」。
- 不做脱敏豁免。敏感字段的例外只能人批，而且要留痕。
- 不自动改生产表。结构变更一律走人工确认，自动化只做检查和建意。
- 不代替数据治理责任人。有人负责的字典才有人维护，没人负责的字典三个月就过期。
九、五个坑
- 口径只活在口头。开会时说清了，文档没改，下个月新人又按自己的理解算一遍。
- 分层只做样子。四层目录都建了，实际还是从 ODS 直接出报表，分层变成文件夹摆设。
- 让 Agent 自由写 JOIN。它会把看起来相关的表连起来，连出来的数字自己都解释不清。
- 权限靠自觉。名单写在文档里，没有落实到行列级规则，等于没有。
- 报表没人认领。看板做出来没人管，半年后没人知道它是怎么算的，也没人敢删。
十、适合谁
这套做法最适合三类团队：一是报表口径已经开始互相矛盾、每天有人为数字吵架的；二是业务同学频繁要数、数据同学被临时取数拖住的；三是已经有人在用 Agent 处理表格和报表（比如 用 AI Agent 处理 Excel 表格），需要一个更稳定的上游数据源的。如果公司规模还小、指标只有十几个、用一份表格就能说清，先别上数仓，把字典写清楚就够了。
一句话总结：数仓的价值不在于「表建得多整齐」，而在于同一个数字只被定义一次、只被计算一次、只被授权一次。Agent 在这条线上最值钱的三个动作是——守着命名和结构不让它乱、守着口径不让它分叉、守着权限和变更不让它悄悄出事。
