AI 原生数据治理:Agent 正在重构数据中台运营方式

我认识一个数据治理负责人。周一早上九点，她以前到公司的第一件事是打开一个 Excel，里面列着上周要推的三十件事。催业务填字段描述，催开发改表命名，催运维补调度日志。

现在她打开的是一份治理日报。昨晚 Agent 跑了一轮全量扫描，发现了三个真实问题，已经把证据、影响面和修复建议写成工单，分别推给了对应的负责人。她早上要做的，只是扫一眼，确认有没有判错。

同一份工作，以前是一周的排期，现在是一个早上的闭环。

这件事让我开始重新理解「AI 原生数据治理」。它不是在数据中台里加一个聊天框，让你用自然语言查数。那只是入口变了。真正的变化在于，Agent 正在从一个「被中台服务的对象」，变成「中台本身的运营者」。

1

数据治理的老问题，是「人不够用」

数据治理这件事，说起来都对，做起来没人配合。

它要求每个生产者做一件反人性的事。建表时写清字段含义，改口径时同步更新文档，出问题时主动上报。这些事对当事人没有直接收益，却要花他的时间。所以默认状态就是拖，拖到治理团队来催。

治理团队因此成了夹心层。上面要合规、要审计、要资产清单。下面嫌麻烦、嫌打扰、嫌多此一举。中间是几个永远不够用的人，靠开会和催单维持着这套系统的运转。

所以中台建得越完整，治理反而越吃力。表越多，要登记的元数据越多。链路越复杂，要维护的质量规则越多。消费方越广，要回答的口径问题越多。而治理团队的人数，永远跟不上数据量的增长。

数据治理最大的成本，从来不是工具，是「让人配合治理」。只要这一点没变，治理就永远是一场靠人硬推的运动，推一阵好一阵，松一阵又回去。

这些年数据治理工具也不少，元数据平台、数据目录、质量平台，一个接一个。但大多数上线半年后就开始过期，因为维护它们的还是人。工具把流程搬上了线，没把动力搬上线。没有人愿意每天花十分钟更新字段描述，哪怕工具做得再好用。

很多公司的中台项目上线时热热闹闹，半年后治理报告就再也没人点开。不是治理不重要，是治理的成本结构注定了它靠人推不动。

2

Agent 进来后，治理从「推」变成「拉」

方向一换，治理就从一个项目，变成了一套持续运转的系统

Agent 带来的变化，表面上是自动化了一些动作，骨子里是改变了治理的方向。

以前是「推」。治理团队把规则推给业务，把工单推给开发，把整改要求推给各个系统的 owner。所有动力都来自治理团队这一个点，人少一点，整条链就动不起来。

现在是「拉」。Agent 把治理动作拉进每个人的日常流程里，让配合治理的摩擦低到几乎感觉不到。

元数据不再靠人填。Agent 从 SQL、调度日志、表结构变更里自动解析出字段含义、数据流向、上下游关系。解析不出来的，它会带着上下文去找 owner 确认一句话，而不是甩一张空表让人填。

质量规则不再靠人配。Agent 看历史数据的分布、波动、完整性，自动生成规则建议。主键应该唯一，金额不该为负，分区不该缺。人只需要看一眼建议，批准或驳回。

整改不再靠人催。问题一出现，Agent 直接把工单推到责任人的工作群里，附上证据、影响面和建议改法。责任人不用理解治理，他只需要判断这个建议对不对。

三件事加起来，治理的主体其实变了。从「治理团队在治理」，变成「每个数据生产者都在被 Agent 服务着完成治理」。人没消失，只是摩擦被 Agent 吃掉了。

举个具体的例子。一张订单表新增了一个字段，以前没人会主动写说明，直到下游有人问起来。现在 Agent 会自动解析这个字段在哪些 SQL 里被使用、被怎么聚合，然后生成一段候选描述，@给表的 owner：「这个字段看起来是优惠后金额，单位分，对吗？」owner 回一个「对」，元数据就更新了。整个过程，owner 的成本是点一下确认。

3

AI 原生治理和传统治理，差在哪

把两种模式摊开看，差的不是工具先进不先进，是整套假设。

衡量指标的变化，最能说明两件事的本质差别

我最看重最后一行。传统治理衡量「做了多少」，AI 原生治理衡量「解决了多少」。前者容易堆出一堆没人看的登记，后者逼你真的把问题关掉。

传统治理把治理做成「项目」，AI 原生治理把治理做成「持续运行的系统」。项目有终点，系统没有。

4

落地的三个关键动作

Agent 不是中台里的一个功能，是跑在中台之上的调度者

方向和模式讲清楚了，落地其实有几个绕不开的关键动作。

第一，治理 Agent 要有足够的上下文权限。它得能读血缘、能读调度、能调质量平台、能发消息、能查日志。权限不够，它就是个只能聊天的机器人，干不了真活。这一步往往卡在安全评审，但没有它，后面全是空谈。

第二，所有治理动作必须可审批、可回滚。Agent 可以推荐规则、建议改口径，但不能直接改生产环境。每一个变更都要走工单，留痕，可撤回。这不是对 Agent 不信任，是治理本身的底线。Agent 越能干，闸口越要清楚。

第三，把治理能力本身做成可调用的服务。不只是治理 Agent 在用，取数 Agent、报表 Agent、决策 Agent 都该能调它。「这个数可信吗」「这个字段从哪来」「这个指标的口径是什么」，这些问题不该每次都去问人，应该有一个统一的治理服务接口来回答。

这一步是很多人忽略的。他们把治理 Agent 当成一个内部工具，只服务治理团队自己。但真正的价值在外部，当其他 Agent 也能消费治理能力时，治理才从成本中心变成了基础设施。

还有一个容易被忽略的点，治理 Agent 要有反馈闭环。它推荐的规则被驳回了，要记下来为什么；它分派的工单判错了，要更新判断依据。没有反馈，Agent 会一直犯同样的错；有反馈，它才会越用越准。治理不是一次性配置，是一个不断学习的过程。

也有两个常见的坑。一个是把 Agent 当聊天机器人，只问不做，最后变成一个更贵的搜索框。另一个是只做元数据补全，不做闭环，补完就完了，问题该出还是出。Agent 不是来替治理团队的，是把治理团队从「执行者」变成「规则制定者」。

5

组织和考核，也得跟着变

工具变了，考核不变，团队就不会真的变。

治理团队的 KPI 要换。从「治理覆盖率」「登记了多少元数据」「配了多少条规则」，换成「问题闭环率」「平均修复时长」「关键资产的可信程度」。前一类指标容易注水，后一类指标才真正反映治理有没有起作用。

业务团队的感受也要变。他们不该再被要求「配合治理」，而应该被 Agent 自动服务。填表、登记、解释口径，这些事尽可能不让人做。人只在需要判断的时候出现。

数据资产的 owner 机制也要落到系统里。每张核心表、每个核心指标都要有明确的 owner，Agent 出问题时直接找他，而不是在群里问「这是谁的表」。owner 不是荣誉头衔，是责任，也是 Agent 能闭环的前提。没有 owner 的资产，出了事只能开会。

这里有个挺反直觉的结论。当治理变成基础设施，越来越多人感觉不到治理的存在，反而说明治理做到位了。以前治理团队存在感很强，天天开会催单；现在他们隐身了，问题却少了。

最好的治理，是让人感觉不到治理的存在。这句话以前像口号，Agent 让它第一次变得可执行。

6

中台的主角，又换了一次

回看数据中台这十几年，主角其实换过好几轮。

报表时代，主角是 BI 工程师，价值是把数据画成图。指标时代，主角是数据产品经理，价值是把口径统一成指标。到了 Agent 时代，主角变成了治理 Agent，价值是让每一个数据能力都可信、可追溯、可调用。

中台的衡量方式也跟着变。最早看存了多少数据，后来看出了多少报表，再后来看有多少指标。现在看的是，有多少治理问题被自动关掉了，有多少数据能力被其他 Agent 放心调用了。

那位治理负责人跟我说，她现在团队的人没增加，但管的数据资产翻了一倍。不是因为大家更努力了，是因为 Agent 把那些重复的、靠人硬推的活接走了。她的团队终于有时间去想「该治理什么」，而不是天天在「怎么催别人治理」里打转。

我觉得这就是 AI 原生治理最本质的东西。它不是让治理变得更激进，而是让治理变得更安静。安静到你感觉不到它，但每一个数字背后都有它在托底。

当然，这条路也有风险。Agent 会幻觉，会把一条不存在的血缘关系说得很肯定，会推荐一条看起来合理但其实错误的规则。所以人工审批闸口不能省，关键口径的变更必须人来拍板。Agent 负责把信息备齐，人负责最后那一下判断。这个分工不能反过来。

当治理从「人推着走」变成「Agent 自动转」，数据中台才算真正进入了下半场。