数据平台接 MCP 时，最吸引人的 Demo 是让 Agent 直接“重跑这个任务”或“补最近七天数据”。但执行链涉及对象歧义、生产权限、依赖、资源和覆盖风险，任何一层不成熟都会把模型错误变成真实操作。

我更愿意从元数据查询开始：找表、看字段、解释 owner、查函数、展开一两层血缘。它是低副作用场景，同时能逼出 MCP Server 最关键的基础能力：稳定对象身份、权限过滤、版本、新鲜度、分页和证据返回。

做统一 Catalog 时，团队通常先讨论要接哪些数据源、搜索框怎么做、血缘图画到字段还是表。我更愿意先追问一个看起来很基础的问题：prod 和 test 里都叫 sales.orders 的两张表，到底是不是同一个对象？

这个问题没答清楚，后面所有治理功能都会漂。采集任务重复跑一次可能多出一张表；集群迁移后，原来的标签和负责人找不到了；表重命名既可能把历史血缘切断，也可能错误地把两个对象合并。Catalog 不是把各种名称塞进一个搜索索引，它首先是一套对象身份系统。

血缘项目最容易交付的是一张很大的图：点开一张表，左边几十张上游表，右边几十张下游表，连线铺满屏幕。演示时很直观，真正遇到问题却常常答不出来。

“改这个字段会影响谁”需要字段与表达式；“昨晚这批数据为什么错”需要运行实例、代码版本和输入输出水位；“这张表有哪些上游”用表级关系就够。把三种问题都塞进同一张表级拓扑，图再完整也只能回答资产发现。

Apache Atlas 2.1 的模型本身已经给出几种层次：基础 Process 通过 inputs/outputs 连接 DataSet；Hive 还有 hive_column_lineage，保存字段依赖和 expression；模型里也有 ProcessExecution 与 hive_process_execution 表达具体执行。关键不在于有没有这些类型，而是采集和查询时是否保留了问题需要的证据。

做元数据平台时，很容易先把精力花在资产目录、业务术语和页面分类上。界面做得很完整，任务失败时却还是有人在群里问：这张表谁负责，今天是哪段代码写的，改字段会影响哪些任务？

我更愿意从这些运维问题反推元数据模型。它们有明确答案，也能用一次真实故障检验。平台先把表、任务、实例和运行证据串起来，资产目录才不会只剩一棵需要人工维护的树。

下面用 Apache Atlas 2.1.0 的源码模型做参照。对应提交是 da35519，打包时间在 2020 年 7 月。Atlas 已经提供了实体唯一标识、Process 输入输出、实体变更审计和血缘查询；运行实例仍需要平台自己建模。