工信部印发《“人工智能+软件”专项行动实施方案》。这份文件并不只是讲“大模型怎么赋能软件”，而是把软件产业的生产方式、产品形态和服务模式，都纳入了重构范围。到 2028 年，提出覆盖 2 万家规模以上软件企业、实施 100 项软件企业智能化技改项目、打造 100 个重点行业智能体软件标杆应用、孵化 5 个以上重点开源项目；到 2030 年，智能编程、智能体软件、智能服务等新业态将进一步成为软件产业新的增长点。

     如果只把这理解成“鼓励软件企业多用大模型”，其实低估了这份方案释放出来的信号。因为这一轮“人工智能+软件”，真正发生变化的，可能并不只是软件里多了一个 Copilot、多了一个聊天框，或者多接了几个大模型。

它正在触碰一个更根本的问题：

软件本身，正在被重新定义。

     过去的软件，核心是菜单、页面、流程、接口和数据库；而今天，随着大模型、Agent、Skill、Tool 等能力逐步进入生产系统，软件开始从“用户操作系统完成任务”，向“用户提出目标，系统理解、规划并执行任务”演进。这也意味着，企业真正需要重新思考的，不再只是“要不要接入大模型”，而是：未来的企业软件，到底应该用什么方式组织业务能力？这也是本文真正想讨论的问题。

     这两年，大模型几乎被塞进了所有企业软件里，数据治理也不例外。很多产品开始强调“AI 数据治理”“智能治理”“数据治理 Copilot”，最常见的形态是在原来的平台上加一个对话入口：用户问“这个字段是什么意思”“这个指标从哪里来”，系统给出解释或者查一遍血缘。

这些能力当然有价值，但如果 AI 数据治理最后只做到这一层，我觉得其实低估了这轮技术变化。

     企业数据治理真正难的，从来不是缺少一个可以聊天的界面，而是整个治理过程长期高度依赖人工。数据要人盘点、字段要人理解、标准要人制定、质量规则要人配置、问题要人发现、责任人要人寻找、整改过程要人推动，处理完成之后还要有人回来验证。

很多大型企业的数据治理已经做了多年，元数据、数据标准、数据质量、主数据、数据目录、指标、血缘、安全平台陆续都建起来了，但一个现实问题始终存在：平台越来越多，治理工作却没有明显变轻。

原因很简单，工具数字化了，但治理方式并没有真正变化。

所以我更关注的问题不是“能不能用大模型解释字段”，而是：AI 能不能开始承担过去那些依赖人工理解、判断和协调的数据治理工作。

一旦这件事成立，变化的就不只是某个功能，而是数据治理的产品形态、技术架构，甚至治理组织本身。

一、数据治理正在从“工具驱动”走向“Agent 驱动”

如果把企业数据治理的发展简单划分，我更愿意把它看成三个阶段。

第一阶段解决的是“有没有治理能力”；第二阶段开始解决“这些能力能不能更智能”；第三阶段真正改变的是“治理工作能不能被机器组织和执行”。

这也是我认为 AI 对数据治理最大的价值所在。

未来的数据治理很可能不再只是“人治理数据”，而会逐渐变成一种新的分工：AI 负责理解数据、发现问题、组织任务和执行低风险动作，人负责治理规则、责任体系、高风险决策以及 AI 本身的边界。

这并不是说治理人员会消失，而是治理人员的工作重心会发生变化。过去大量时间花在查问题、找数据、对口径、催整改，未来更可能转向标准制定、治理策略、责任机制、复杂冲突处理以及 AI 运行监督。

二、AI 数据治理平台，产品形态首先要变

传统数据治理平台往往按照专业能力组织菜单：元数据、数据标准、数据质量、主数据、指标、血缘、安全、数据目录。对数据治理团队而言这种结构没有问题，但对业务人员来说门槛一直很高。

例如，一个业务负责人想搞清楚“为什么经营驾驶舱里的销售收入和财务报表不一致”，他实际上需要跨多个系统查定义、查口径、查血缘、查质量异常。问题是，他并不关心应该先打开指标平台还是血缘平台，他只关心一个问题：为什么数字不一样？

所以 AI 时代的数据治理入口会逐渐从 Menu Driven 变成 Intent Driven。用户不需要先学习平台能力，而是直接表达自己的问题，例如“客户域最近有哪些高风险问题”“这个字段改了会影响哪些系统”“目前有哪些敏感数据流入了测试环境”。

从产品角度看，我更倾向于把未来的 AI 数据治理平台概括为四部分：一个统一入口、一个 AI Governance Brain、一组专业治理能力、一套治理闭环。

统一入口负责承接用户意图，AI Governance Brain 负责理解任务、寻找知识、组织能力和生成决策，专业治理模块负责真正完成元数据、标准、质量、指标、主数据、安全、血缘等治理动作，而治理闭环负责把“发现问题”继续推进到“解决问题”。

如果只有一个 AI 入口，没有底层治理能力，最后只是聊天机器人；如果有传统治理能力但没有统一 AI 中枢，本质上还是老平台；如果有 AI 分析能力，却没有任务、审批、Workflow 和验证机制，那么系统最多只能告诉你“这里有问题”，真正的治理依然要靠人自己完成。

三、AI 最先产生价值的，不是“聊天”，而是理解数据

AI 并不适合替代所有治理能力。真正适合 AI 的，是过去高度依赖语义理解和经验判断的环节。

1. 元数据治理：先让机器真正理解数据

企业数据里最常见的问题之一，是同一业务概念存在大量不同命名，例如 cust_id、customer_no、client_code、khbh。如果只看字段名称，传统规则很难判断，但大模型可以综合字段名、表名、字段注释、数据样本、上下游关系、业务术语等信息进行语义推断。

它真正带来的价值不是“帮字段自动补一段中文描述”，而是有机会规模化建立企业长期缺失的一层东西：数据语义层。

过去很多治理工作都是围绕物理表和字段展开，而业务真正关心的是客户、订单、供应商、收入、合同这些业务实体和概念。AI 如果能够把技术对象和业务概念之间的关系建立起来，后面的标准、指标、质量、搜索和 Agent 才真正有基础。

2. 数据标准：从人工映射变成 AI 推荐

过去做标准落标，一个字段究竟对应哪个企业标准，经常需要大量人工比对。AI 可以把这个过程改造成“语义识别 + 标准候选 + 相似度计算 + 血缘验证 + 数据 Pattern 验证 + 人工确认”。

例如系统识别出 crm.customer.cust_no 很可能对应企业标准 Customer_ID，同时给出置信度以及判断依据。治理人员不再从零开始寻找标准，而是审核 AI 推荐结果。

管理层看到的是治理效率提升，技术团队看到的则是 Embedding、Reranker、Metadata、Graph、Rules 的组合。

3. 数据质量：AI 负责推荐，规则引擎负责执行

数据质量平台一直很成熟，但有一个老问题没有完全解决：规则从哪里来。

如果 AI 已经理解 order_amount 是订单金额，它可以自动推荐非空、大于等于 0、异常值检测、分布漂移等规则；如果理解了 order_time 和 pay_time 的业务关系，还可以进一步建议时序一致性规则。

但这里必须把边界划清楚：AI 可以推荐质量规则，真正的质量检测仍然应该由确定性的质量引擎执行。

因为大模型适合语义理解和推理，而“订单金额不能小于 0”一旦成为企业规则，就应该稳定执行，而不是每次让模型重新思考。

4. 指标治理：从“找到指标”走向“解释指标”

大型企业里最常见的问题之一就是指标口径不一致。销售额、销售收入、GMV 看起来相近，但结果完全不同。

AI 可以自动比较指标定义、计算公式、统计周期、过滤条件、数据来源和血缘关系，再告诉用户：销售额统计支付成功订单金额，销售收入统计已确认收入并扣除退款，GMV 可能包含尚未完成确认的交易。

这时候 AI 做的已经不是简单的数据搜索，而是在做业务解释。

数据治理也因此从“数据有没有、数据对不对”，进一步走向“为什么是这个数字”。

四、真正的技术难点，不是选哪个大模型

聊 AI 项目时，很多讨论会迅速进入模型选型：用哪个 LLM、参数多少、私有化还是 API。但如果真正给一家大型企业设计 AI 数据治理平台，大模型只是其中一层。

我更倾向于把整个技术架构拆成六个底座。

这六层里，真正决定企业 AI 能不能“懂业务”的，不是模型参数，而是 Knowledge Layer。

企业级 RAG 不能只依赖向量数据库

现在很多企业知识库仍然是“文档切块 → Embedding → Vector DB → LLM”，用来查制度、查文档没问题，但拿来做数据治理远远不够。

因为数据治理里的大量知识不是文本，而是关系。表和字段之间是包含关系，字段和业务术语之间是语义关系，字段和字段之间是血缘关系，指标和报表之间是依赖关系，数据质量异常和 Schema Change 之间甚至可能存在因果关系。

所以企业级数据治理更适合 Hybrid RAG，而不是单纯 Vector RAG。

例如用户问“销售收入为什么昨天突然下降”，系统不应该只在向量库里搜索“销售收入”。它应该同时查指标定义、上下游血缘、质量异常、任务运行状态、Schema 变更，再由 LLM 把这些证据组织成结论。

所以企业 AI 真正能不能懂业务，关键不是模型本身，而是企业有没有建立一套可检索、可关联、可推理的治理知识底座。

五、当 Agent 开始执行，Tool Gateway 比模型更重要

AI 只回答问题时，风险相对有限；一旦 Agent 开始操作企业系统，问题性质就完全变了。

它可能要执行 SQL、创建工单、触发质量任务、查询 IAM，甚至未来还可能涉及权限修改。这时最危险的做法，就是让 LLM 直接连接生产数据库或者企业系统。

比较合理的架构应该是：Agent → Tool Gateway → 企业系统。

Tool Gateway 负责统一处理认证、鉴权、SQL Guard、字段脱敏、限流、审批、审计。例如 Agent 想查询 customer 表，Gateway 要判断当前用户有没有权限、Agent 有没有相应 Tool 权限、SQL 是只读还是写入、访问的字段是否包含身份证和手机号、一次允许返回多少行数据。

这里有一个我认为非常重要的设计原则：

Agent 负责判断，Tool 负责执行。

模型是“大脑”，不应该同时直接成为“手”。

类似地，Agent 和 Workflow 也应该分工。Agent 擅长理解、分析和决策，但企业治理流程要求状态明确、责任明确、SLA 明确、审批路径明确，因此更适合由 Workflow Engine 管理。

可以简单理解为：Agent 负责智能决策，Workflow 负责确定性流程。

六、为什么大型企业最终更适合 Multi-Agent

理论上，一个足够强的 Governance Agent 可以完成很多事情，但企业生产环境不适合做“万能 Agent”。

Metadata、Quality、Security、MDM、Metric 本身就是不同专业领域，它们使用的知识不同、调用的工具不同、权限不同、风险等级也不同。

所以更合理的结构是一个 Governance Orchestrator 加多个专业 Agent。

Orchestrator 的职责不是替代这些专业 Agent，而是理解任务、拆解任务、选择 Agent、安排执行顺序、处理冲突、汇总结果并形成治理决策。

还有一个经常被误解的概念：Multi-Agent 不等于多个大模型。

多个 Agent 完全可以共享同一个基础模型。真正区分它们的，是 Role、Prompt、Knowledge、Tool、Permission、Policy 和 Workflow。

所以 Multi-Agent 的核心不是模型数量，而是职责边界。

七、一个治理问题，Agent 到底是怎么闭环的

用一个比较真实的场景举例：业务人员问，“客户域最近为什么质量下降？”

表面上只有一句话，背后可能发生的是一整套治理流程。

Governance Orchestrator 先识别任务类型，确定这是“客户域 + 数据质量分析”；Metadata Agent 查询客户域核心资产；Quality Agent 发现手机号完整率从 98% 降到了 82%；Lineage Agent 继续追踪上游来源，发现异常主要集中在 CRM 新接入的一条接口；系统再查看最近变更记录，发现该接口昨日发生过 Schema Change；Security Agent 检查此次变化是否引入敏感数据风险；Governance Agent 汇总证据，判断问题风险级别以及影响范围。

如果只是普通 Copilot，到这里通常会给出一句“建议联系 CRM 团队修复”，然后结束。

但真正的 Agentic Governance 应该继续往下走：Action Agent 自动生成治理工单，定位 CRM Data Owner，发送通知；责任人修复之后，系统再次触发质量检测；验证通过后关闭工单，并把问题原因、处理方式和结果沉淀进治理知识库。

整个过程形成完整闭环：

发现问题 → 分析原因 → 判断影响 → 定位责任 → 创建任务 → 处理修复 → 自动验证 → 关闭沉淀。

这也是 Agent 和普通问答最大的区别。普通 AI 给出答案，Agent 开始参与工作。

八、AI 可以自动化治理，但不能决定治理边界

Agent 能做很多事情，但并不意味着企业应该把数据治理完全交给 AI。

大型企业里，至少有几类动作长期都应该保持严格控制：修改企业数据标准、合并主数据、修改生产数据、修改用户权限、删除数据、高风险安全处置。

所以 AI 的自动化程度不能由“模型有多聪明”决定，而应该由企业治理政策决定。

可以把 Agent 权限简单分成几级。

这里最重要的是 Human-in-the-loop。

企业真正要管理的已经不只是“AI 输出对不对”，而是“AI 能做到哪一步，哪些动作必须有人承担责任”。

九、做企业级 AI 数据治理，我会坚持六个原则

如果把前面的架构压缩成几条原则，我认为至少有六条值得长期坚持。

这里最容易被忽略的是“能用规则解决的，不用 AI；能用算法解决的，不用 LLM”。

AI 项目很容易出现一种倾向：既然大模型什么都能做，就让它什么都做。实际上恰恰相反，企业系统最需要的是稳定、便宜、可控。手机号格式校验用正则就够，SQL 血缘能够通过 Parser 获得就不要让模型猜，异常检测有成熟算法就优先使用算法。

LLM 最应该留给传统规则和算法最难解决的部分：语义理解、复杂上下文判断、任务规划和跨系统推理。

十、管理层真正应该关注的是治理自动化率

AI 数据治理最终还是一个企业项目，所以最后一定要回答 ROI。

如果做了一年，结果只是多了一个智能问答入口，很难证明它值得持续投入。

我更建议从三个方向衡量。

其中第三类指标未来会越来越重要，可以定义为Governance Automation Rate。

管理层真正应该关注的，不是模型调用了多少次、消耗了多少 Token，而是：过去必须依赖人工完成的数据治理工作，有多少被安全地自动化了。

十一、大型企业落地，不建议一开始就做“万能 Agent”

这类项目最容易犯的错误，就是一开始目标太大。元数据、知识图谱、RAG、Agent、质量、主数据、安全全部一起做，架构图很完整，实施却往往推进困难。

更现实的做法，是分阶段建立能力。

我尤其不建议第一天就做十几个 Agent。优先选择 Metadata Agent、Quality Agent、Lineage Agent 更现实，因为这些场景基础相对成熟、风险可控、价值也比较容易量化。

最终目标也不是所谓“无人治理”，而是受控自治。

写在最后

过去十几年，企业建设数据治理平台，主要解决的是“治理能力有没有”。有没有元数据、有没有标准、有没有质量规则、有没有血缘、有没有安全能力。

AI 出现之后，问题正在发生变化。

未来真正值得思考的是：这些治理能力能不能被机器理解、组合和执行。

当元数据成为 AI 的记忆，知识图谱成为它理解企业关系的方式，治理规则成为制度，大模型提供语义理解和推理能力，Agent 负责组织任务，Workflow 和 Tool Gateway 负责控制执行风险之后，数据治理平台才真正有可能从一个后台管理系统，变成企业数据运行体系中的治理大脑。

AI 不会简单替代数据治理人员，但一定会改变数据治理人员的工作方式。过去大量时间用来查问题、找数据、对口径、催整改，未来人会更多负责定义规则、制定标准、处理复杂冲突、判断高风险事项，以及决定 AI 到底能够走多远。

所以如果用一句话概括我对 AI 数据治理的判断，我更愿意这样说：

下一代数据治理，不是 AI 替人治理，而是 AI 开始治理数据，人开始治理 AI。