一家金融公司的AI项目，准确率从40%飙升至87%，关键改变并非模型或算力，而是元数据。这需要从一个真实案例说起。
一家头部金融机构去年上线了一套AI智能问答系统，旨在让业务方直接通过提问获取数据答案，例如“东南区上季度销售额下降了多少”或“这个产品线退货率为何突然变高”。技术团队采用了主流方案：用户提问 → 大模型转SQL → 数据仓库执行 → 返回结果。团队选用了最好的模型，并调整了三轮提示词，信心满满地完成了上线。
然而，两周后，准确率却不足40%。问题究竟出在哪里？并非模型不够智能，而是大模型根本不认识这家公司的数据。公司里有多张表都叫“销售相关”，大模型不知道该选择哪一张；“东南区”按哪个字段定义？是省份还是大区代码？“销售额”是含税还是不含税，是已开票还是已回款？这些信息，人类分析师依靠经验和部门内的口口相传就能轻松搞定，但AI Agent没有同事可以询问。它唯一能依赖的，就是结构化的、机器可读的、能在毫秒内被检索到的元数据。
团队重构了系统，将所有业务定义、字段口径、表归属、质量标签、血缘关系全部喂进元数据平台，并让Agent在生成SQL之前先进行“上下文检索”——从元数据系统中拉取相关上下文。准确率从40%跃升至87%。
这个故事揭示了一个正在发生的深刻变化：元数据，这个被行业嫌弃了十几年的“仓库管理员”，正在AI时代迎来第二春。用四个字形容就是——死灰复燃。
一、元数据是怎么“死”的
先说“死”的部分。元数据——关于数据的数据——在数据领域已经存在了三十多年。但长期以来，它在企业里的处境可以用三个词概括：重要、无聊、没人管。
上世纪90年代，元数据就是数据库的“说明书”。管理员手工录入字段描述，批量更新，年度审计。开发者改了表结构，没人去同步元数据系统。三个月后去看，发现里面描述全是错的。整个行业都接受了这个现实——元数据是“参考资料”，不是“事实”。
到了大数据时代，LinkedIn做了DataHub，Lyft做了Amundsen，Uber做了Databook。这些工具解决了“数据资产有哪些”的问题，但本质依然是被动的、给人查询的。一个数据分析师有需求 → 去目录里搜 → 找到表 → 写SQL。整个流程由人发起，元数据只是中间的导航工具。数据管道跑得再快，元数据更新依然周期性同步、有时差、有遗漏。两条轨道，互不干扰。
于是，元数据管理变成了一个典型的“吃力不讨好”的活：花钱做没人看，不做也没人投诉。很多企业的数据治理团队，元数据页面常年挂着“建设中”的横幅，最终沦为摆设。但就在大家以为元数据会这样温水煮青蛙般沉沦下去时，AI来了。
二、四个时代，一次反转
元数据的“死灰复燃”不是突然爆发的，而是一场三十年的量变引发的质变。我们可以清晰地看到四个时代：
第一代：说明书时代（1990s-2000s）
代表产品是Informatica、IBM InfoSphere。元数据本质上是给IT部门用的数据库schema文档系统。纯文档、手工录入、和数据运行完全解耦。一句话总结：给IT人看的说明书。
第二代：治理入口时代（2010s-2020s初）
Hadoop和数据湖兴起，数据量从TB跳到PB。LinkedIn做了DataHub，Apache Atlas成为治理框架。元数据从“文档”变成“治理入口”——开始有数据目录、有血缘关系、有数据资产盘点。但依然是被动记录，主要给人搜索用。
第三代：协作层时代（2020s中）
Snowflake、dbt、Airflow等工具组合流行，数据团队不再只有工程师，分析师、产品经理都参与进来。Gartner提出“主动元数据”概念——元数据通过事件流实时更新，不只是给人看，机器也在消费。元数据变成了“数据基础设施的神经系统”。
第四代：上下文图谱时代（2026至今）
大模型和AI Agent进入企业。元数据不再只是治理工具，而是AI理解企业数据的“上下文层”。OpenMetadata 1.13版本直接内置了知识图谱，把表、字段、血缘、Owner、术语、分类全部放成一张可推理的网络。Google Cloud把Knowledge Catalog定位为“面向AI Agent的企业上下文引擎”。
四个时代的演变可以用一张表概括：
注意最后一行的变化——服务对象从“人”变成了“AI Agent为主”。这不是渐进式改良，而是范式反转。
三、数据变成了元数据的副产品
这句话听起来很反直觉，但站在AI Agent的视角看，它极其准确。过去三十年的工作流程是这样的：业务需求 → 设计数据模型 → 建数据仓库 → 跑管道 → 产生数据 → 写文档 → 录入元数据。元数据永远是流程的最后一步、补救步、可选步。“数据优先，元数据其次”。
但在AI Agent落地的场景里，流程悄悄变成了：业务需求 → 设计Agent任务 → 定义Agent需要的上下文 → 检查元数据是否完备 → 不完备的部分回头补元数据 → Agent跑起来 → 数据被消费。元数据反而变成了第一公民。Agent能不能跑、跑得好不好、结果能不能信，根本不取决于“数据是否存在”——数据早就存在了。它取决于“元数据是否完备到Agent能正确理解和使用这些数据”。
数据是燃料，元数据是导航+油表+仪表盘+副驾驶。没有元数据，再多的数据对Agent来说都是“无法消费的暗物质”。Gartner有个很扎心的预测：到2026年，60%的AI项目会被放弃，主要原因不是模型质量，而是上下文和数据准备的差距。更有说服力的证据来自Meta。2026年4月，Meta发布了一篇博客——他们为了让AI Agent能正确修改一个跨4个代码库、3种语言、4100+文件的大规模数据管道，专门搞了一套“50+个AI Agent组成的预计算引擎”。这些Agent唯一的工作就是读所有代码，然后生成59份结构化文件，把工程师脑子里的“部落知识”转化成AI可读的上下文。最终效果：AI Agent的工具调用次数减少40%，覆盖率从5%提升到100%。在Meta这种顶级技术公司，已经开始投入巨大的工程资源，专门为AI Agent生产元数据。不是为了人，是为了Agent。这就是范式反转的最清晰证据——元数据的生产，已经从“数据团队的副业”变成了“AI项目的主线工作”。
四、从“主动”到“自主”：下一站是Agentic Metadata
第三代元数据的关键词是Active（活的、实时的），而第四代的关键词正在变成Agentic（自主的、可推理的、双向交互的）。三个信号说明这个趋势已经发生：
信号一：MCP正在成为元数据系统的标准接口。DataHub在2026年初已经把MCP Server作为元数据系统的标准API之一，Atlan也跟进了。这意味着以后所有AI Agent框架都可以通过MCP直接查询企业的元数据系统。元数据系统正在变成“企业数据的USB-C接口”——任何AI工具都能即插即用。
信号二：元数据系统开始嵌入Agent自身。DataHub自己在目录里跑Agent，用来自动做schema推断、自动写表描述、自动检测异常血缘、自动给字段打敏感数据标签。Atlan的AI Copilot在做同样的事。元数据系统不再只是被动响应查询，而是主动产出和维护自己的元数据——它本身变成了一个Agent。
信号三：Context Engineer正在变成一个独立工种。DataHub的2026报告显示，95%的数据团队计划在2026年投资Context Engineering培训。Context Engineer的工作不是写SQL、不是建仓库，而是设计“Agent应该看到什么上下文、什么时候看到、如何被维护更新、如何在多步推理中动态裁剪”。更有意思的是——这个角色最有竞争力的人选，不是来自AI圈，是来自数据工程圈。因为做Context Engineering需要的核心能力是：理解企业数据怎么组织的、各表的真实业务含义、数据质量陷阱在哪、不同系统如何串联。这些能力，AI工程师没有，但每一个有5年经验的数据工程师都有。
五、元数据市场数据
市场数据也在印证这一趋势：全球元数据管理工具市场规模在2024年已达116.9亿美元，预计到2030年增长至364.4亿美元，年复合增长率20.9%。Gartner在时隔五年后重新发布了元数据管理魔力象限报告，明确将元数据定位为“AI就绪的基础”。市场上也出现了一系列并购整合：ServiceNow收购了data.world，Coalesce收购了CastorDoc，Salesforce正在收购Informatica。微软与Informatica和Solidatus建立生态合作，GCP与Atlan和Collibra深度绑定。Gartner还预测，到2027年，采用主动元数据实践的组织将能把新数据资产的交付时间缩短70%。而到2026年，采用主动元数据的组织将增加到30%。元数据市场正在从“可选项”变成“AI战略的必选项”。
六、五类元数据，缺一不可
现代元数据管理已远不止“表结构描述”那么简单。企业需要管理五类元数据，每类服务不同场景：这五类元数据中，“行为元数据”是最新出现的——它记录的是人和AI Agent如何实际使用数据。当你知道某个数据集被AI Agent每周调用500次，而另一个数据集三个月没人碰过，治理优先级就不用争论了。
七、AI时代的血缘革命
元数据“死灰复燃”的另一个维度，是血缘关系的革命性扩展。传统血缘只回答一个问题：数据从哪来，流向哪去。但AI时代新增了两类完全不同的血缘：机器学习血缘：训练数据 → 特征 → 模型版本 → 推理服务 → 业务决策。模型输出错了，需要知道它用了哪些数据训练。RAG知识血缘：知识文档 → Chunk → Embedding → 向量库 → RAG应用 → 回答结果。AI回答错了，需要知道它引用了哪些文档、哪些切片、哪个版本的向量索引。这意味着未来企业需要管理的血缘类型从“数据血缘”一种，扩展到至少六种：数据血缘、模型血缘、特征血缘、知识血缘、Prompt血缘、Agent行为血缘。元数据平台从“数据目录”被推向更广泛的企业上下文图谱。Databricks的Unity Catalog已经走在了前面——它把数据和AI治理放在统一框架下，能够捕获查询运行时血缘，支持到列级，包含Notebook、Job、Dashboard等上下文。这是行业方向。
八、三个判断和一个窗口
最后，我对元数据未来三年的发展做几个判断。
判断一：元数据系统的预算将从CDO转移到CAIO。过去元数据系统的预算来自首席数据官，是数据治理项目的一部分。未来预算会越来越多来自首席AI官——因为AI项目能否落地，前置条件就是元数据是否完备。没有完备的元数据层，所有AI Agent都只能停留在Demo阶段。
判断二：“上下文层”会成为继数据湖、湖仓之后的下一个基础设施层。企业数据架构经历了：数据仓库（面向报表）→ 数据湖（面向多样化数据）→ 湖仓（融合分析与机器学习）→ 上下文层（面向AI Agent）。上下文层不替代湖仓，而是建在湖仓之上，专门用于服务AI Agent的语义、治理、上下文供给。未来三年，所有头部企业都会有一个“首席上下文架构师”或类似角色。
判断三：元数据的消费者会发生结构性转移——从人为主，到机器为主。今天元数据系统的查询量可能95%是人发起的。三年后，这个比例会反过来——95%的查询是AI Agent发起的。这个转变会带来元数据系统设计的根本性变化：从“UI优先”变成“API优先”，从“自然语言搜索”变成“结构化上下文检索”，从“被人浏览”变成“被Agent消费”。而最重要的一点是——传统数据工程师转型Context Engineering的窗口期只有18个月。做Context Engineering需要的核心能力——理解企业数据怎么组织的、各表的真实业务含义、数据质量陷阱在哪——AI工程师没有，但每一个有5年经验的数据工程师都有。两年后这个角色会被新一代AI原生人才填满，传统数据工程师的转型优势会消失。
最后三条建议
给数据工程师：从今天起，把你写的每一段SQL、每一个dbt模型、每一个管道，都加上“AI Agent友好”的元数据。表注释要详细，字段口径要清晰，业务定义要落实到文档里。这些东西过去是“加分项”，未来是“准入门槛”。
给AI应用开发者：停止在Prompt里硬编码业务上下文。把所有业务知识沉淀到元数据系统里，让Agent在运行时去查询。好处是Prompt短了、维护成本低了、知识可复用了。唯一代价是前期搭建一个上下文层——两个月内就能回本。
给技术决策者：把企业里“数据治理”和“AI项目”两条原本平行的预算线合并。它们不再是两件事——AI项目能否成功，本质上就取决于数据治理的成熟度。把元数据投资当成AI投资来做。
过去三十年，我们建设的所有数据基础设施都围绕一个假设：最终消费者是人。未来三十年，所有数据基础设施会围绕一个新假设重建：最终消费者是AI Agent。连接这两个时代的关键基础设施，叫元数据。它过去是仓库角落的目录卡片。它现在是企业AI战略的中枢神经。它未来会是整个数字世界的语义底层。所谓的“死灰复燃”，不过是烈火终于找到了它该烧的地方。