元数据的死灰复燃：AI时代，它从仓库管理员变成中枢神经

一家金融公司的AI项目，准确率从40%飙到87%，只改了一样东西——不是模型，不是算力，而是元数据。

问题不在模型，而在“它不认识你”

一家头部金融机构上线AI智能问答系统，目标是让业务人员直接提问：“东南区上季度销售额下降了多少？”“这个产品线退货率为什么突然变高？” 技术团队采用主流架构：用户提问 → 大模型转SQL → 数据仓库执行 → 返回结果。用了最好的模型，调了三轮prompt，信心十足地上线。 两周后，准确率不足40%。 症结并非模型不够强，而是大模型根本“不认识”这家公司的数据：6张表都叫“销售相关”，该选哪一张？“东南区”按省份字段还是大区编码？“销售额”含税与否？已开票还是已回款？这些细节，人类靠经验、靠沟通就能厘清；AI没有同事可问，唯一能依赖的，只有结构化、机器可读、毫秒级可检索的元数据。 团队重构系统：将全部业务定义、字段口径、表归属、质量标签、血缘关系注入元数据平台，并让AI Agent在生成SQL前，先做一步“上下文检索”——从元数据中实时拉取相关语义信息。 结果：准确率跃升至87%。

元数据，三十年沉寂后的范式反转

元数据——关于数据的数据——曾被冷落多年：重要、无聊、没人管。上世纪90年代它是手工录入的数据库说明书；大数据时代它是被动查询的数据目录；直到AI Agent真正落地，它才从“参考资料”升维为“理解前提”。 这不是功能升级，而是服务对象的根本迁移：从“为人服务”转向“为AI Agent服务”。

四个时代，一次质变

第一代（1990s–2000s）：说明书时代。元数据是IT部门的schema文档，与运行系统完全解耦。 第二代（2010s–2020s初）：治理入口时代。DataHub、Atlas等工具实现资产盘点与血缘追踪，但仍以人为主动发起查询。 第三代（2020s中）：协作层时代。“主动元数据”兴起，通过事件流实时更新，开始被机器消费，成为数据基础设施的神经系统。 第四代（2026至今）：上下文图谱时代。元数据不再只是治理工具，而是AI理解企业数据的语义底座。OpenMetadata内置知识图谱，Google Cloud Knowledge Catalog明确定位为“面向AI Agent的企业上下文引擎”。 最后一行变化至关重要：服务对象，从“人”变为“AI Agent为主”。这是范式反转，不是渐进改良。

数据成了元数据的副产品

传统流程：业务需求 → 建模 → 建仓 → 跑管道 → 产数据 → 补文档 → 录元数据。元数据永远滞后，是可选项。 AI Agent流程：业务需求 → 定义Agent任务 → 明确所需上下文 → 检查元数据完备性 → 缺则补 → Agent运行 → 数据被消费。 元数据成了第一公民。AI能否跑、跑得准不准、结果信不信，不取决于数据是否存在——数据早已存在；而取决于元数据是否完备到能让AI正确理解并使用这些数据。 数据是燃料，元数据是导航、油表、仪表盘和副驾驶。没有元数据，再多的数据对AI而言，都是无法消费的“暗物质”。 Meta的实践印证了这一点：为让AI Agent修改跨4个代码库、3种语言、4100+文件的数据管道，他们专门构建50多个AI Agent组成的预计算引擎，专职将工程师脑中的“部落知识”转化为结构化上下文——最终使AI工具调用减少40%，覆盖率从5%提升至100%。 元数据生产，已从数据团队的副业，正式升格为AI项目的主线工程。

从“主动”走向“自主”：Agentic Metadata正在到来

第三代关键词是Active（活的），第四代正迈向Agentic（自主的、可推理的、双向交互的）。 三个信号清晰浮现： 一是MCP（Model Context Protocol）正成为元数据系统的标准接口。DataHub、Atlan均已集成MCP Server，元数据系统正演变为“企业数据的USB-C接口”，任何AI框架即插即用； 二是元数据系统自身开始运行Agent：自动推断schema、撰写表描述、检测异常血缘、打敏感标签——它不再被动响应，而是主动维护自身； 三是“Context Engineer”（上下文工程师）成为独立工种。其核心能力不是写模型、不是搭算力，而是设计“Agent该看什么上下文、何时看、如何更新、如何在多步推理中动态裁剪”。最具竞争力的人选，恰恰是拥有5年经验的数据工程师——因为他们真正懂数据怎么组织、字段真实含义是什么、哪里有质量陷阱、系统间如何串联。

五类元数据，缺一不可

现代元数据管理远不止表结构描述。企业必须统筹管理五类元数据：技术元数据、业务元数据、操作元数据、治理元数据、行为元数据。其中，“行为元数据”最具时代性——它记录AI Agent与人的实际使用行为。一个数据集每周被Agent调用500次，另一个三个月无人访问，治理优先级自然分明。

血缘的革命：从数据流向AI决策链

传统血缘只回答“数据从哪来、到哪去”。AI时代新增至少六类血缘：数据血缘、模型血缘、特征血缘、知识血缘（RAG）、Prompt血缘、Agent行为血缘。Databricks Unity Catalog已支持列级运行时血缘，覆盖Notebook、Job、Dashboard等全上下文，代表行业方向。

三个判断与一个窗口期

判断一：元数据预算将从CDO（首席数据官）转向CAIO（首席AI官）。没有完备元数据层，AI项目只能停留在Demo阶段。 判断二：“上下文层”将成为继数据湖、湖仓之后的下一代基础设施层，建于湖仓之上，专为AI Agent提供语义、治理与上下文供给。 判断三：元数据消费者将结构性转向机器——三年后，95%的元数据查询将由AI Agent发起。系统设计逻辑也将从“UI优先”转向“API优先”，从“自然语言搜索”转向“结构化上下文检索”。 最关键的是窗口期：传统数据工程师转型Context Engineering的黄金时间仅剩18个月。两年后，新一代AI原生人才将填补该角色，先发优势将消失。

三条行动建议

给数据工程师：从今天起，为每一段SQL、每一个dbt模型、每一根数据管道，添加“AI Agent友好”的元数据——表注释要详尽，字段口径要明确，业务定义要沉淀。这不再是加分项，而是准入门槛。 给AI应用开发者：停止在Prompt里硬编码业务知识。把所有上下文沉淀进元数据系统，让Agent运行时按需检索。短期投入两个月搭建上下文层，长期换来Prompt精简、维护成本下降、知识复用增强。 给技术决策者：合并“数据治理”与“AI项目”两条预算线。它们本质是一体两面——AI项目的成败，取决于数据治理的成熟度。元数据投资，就是AI投资。 过去三十年，所有数据基建都默认最终消费者是人； 未来三十年，所有数据基建都将围绕AI Agent重建。 连接两个时代的枢纽，正是元数据。 它曾是仓库角落的目录卡片； 如今是企业AI战略的中枢神经； 未来，将是整个数字世界的语义底层。 所谓“死灰复燃”，不过是烈火终于找到了它该烧的地方。