数据团队常遇到这样的场景：打开一张表，看到 cust_seg_flg 这样的列名，只能到处问人它是什么意思、能不能用、隔壁团队是不是已经用过。这样的问题乘以几千张表，就是治理债务的真实成本：不是合规失败，而是每个想好好用数据的人每天都要交的税。

现有治理工具大多是反应式的：扫描问题、出报告、开工单、三周后某列才有描述。Governance Agent 项目（构建于 Google Cloud Knowledge Catalog、BigQuery 和列级血缘之上）换了个起点：如果上游表已经被文档化、打标、受信任，为什么下游每个视图都要从零开始靠手工重新建立信任？

问题在于数据经管道流动时，原始上下文本（列的含义、是否含 PII、质量标准）不会跟着走。结果是熟悉的模式：少数金表治理良好，下游层层派生的视图文档越来越少、标签越来越少、信任度越来越低，尽管底层数据本身并没有变差。一张表的治理质量取决于多久前有人关心过它，而非数据如今的实际使用情况。

代理的核心思路是用列级血缘定位列的来源，把上游已存在的治理元数据传播下去，而非让人重新推导。具体处理四件事：

描述。若上游 transactions.customer_id 有清晰描述，下游视图经两三轮 join 引用该列，代理跟踪血缘并建议沿用同一描述。当列不是直接透传（而是 SUM()、CASE WHEN、COALESCE 等转换），代理读取生成它的实际 SQL，写一段反映转换逻辑的描述，而不是复制已不适用的上游描述。

业务术语。技术列名与业务语言不匹配时，代理用语义相似度将列映射到受控术语表，也能读取非结构化文档（PDF 政策、产品规格、markdown 设计文档）寻找显式定义，而不是仅凭列名猜测。

策略标签。这是对风险最关键的一项。若上游列被标记为 PII，代理追踪数据流向并在下游建议相同标签，附上当前有读权限的名单及屏蔽规则。它还会检查转换是“直取”（敏感值原样通过）还是已聚合或匿名化，避免盲目给不再有风险的列盖上 PII 标签。

信任与数据质量评分。代理依据上游源的数据质量与分析结果推导信任分，并检测转换是否改善了质量（去重、空值处理等），给予相应加分。

所有操作都通过置信度阈值后才执行。系统明确不对 PII 状态或术语映射做无根据推断，证据不足时不自动传播。这是刻意设计：代理只快速填补明显缺口，不做应由人做的判断。

主动治理不意味着预测未来，而是在数据流动的同时完成治理，而非等待定期审查或合规事件触发。三种表现：新视图自动继承上下文；敏感数据边流边标记，而不是被十二个不知道需要屏蔽策略的人查过之后才发现；管理员把时间花在判断性工作（歧义映射、新术语）上，而非逐列打标签。治理者的一天变了：少花时间在 UI 里敲描述，多花时间决定什么算业务术语、某种边缘情况是否需要策略豁免。

血缘并非万能。许多表没有干净的上游可继承：新接入的数据集、一次性导入、早于血缘追踪的旧表。代理允许指向自有文档（PDF 政策、产品规格、markdown 设计文档，甚至数据字典的电子表格或截图）作为依据。提供三种喂入方式：短文直接注入全文；长文档（如五十页分类政策）分块嵌入，仅检索与当前列相关的片段；若已有 Vertex AI Search 索引的文档库，可直接查询。

特别值得强调的是依据的保守性：指令明确要求，若文档未明确定义某列，必须说“不知道”并停止，而不是给出看似合理的猜测。策略标签和术语映射上尤其严格——列只有在文档以明确语言（如显式“PII: Y”或具名敏感度章节）说明时才会被标为 PII，不从列名推断，不做“听起来可能敏感”的推测。

血缘是主要信号，但不是唯一。Data Lineage API 只记录作业显式写入的内容，因此覆盖有缺口。代理有第二遍扫描：触发 Knowledge Catalog 数据文档扫描（Gemini 在表或数据集上运行的 AI 分析），在无干净 SQL 轨迹的情况下推断关系和列含义，这些推断结果被提取并缓存，再加载到同一遍历引擎中。顺序有讲究：标准血缘先跑（基于实际记录作业），Insights 后跑，只补充血缘未发现的，且每条推断明确标注来源。

实践效果：不完整或新接入的管道第一天也能获得有效传播，无需等血缘覆盖追上。项目同时提供 Gradio 仪表盘和 CLI，前者供管理员在演示前预览和点选批准，后者供平台团队脚本化 nightly 任务或 CI/CD 流程中的 scan、apply、policy-propagate 命令。

需要明确的是，这不是“设好就忘”的系统。血缘置信度评分可能错误，尤其在重命名列或异常 join 时，语义不匹配检查能抓住明显错误（日期列不应继承 id 列的描述），但只是启发式。每次传播都被设计为先预览再应用，预览不是形式，而是真正的安全机制。诚实的卖点是“治理努力花在正确的 5% 决策上，而非重复性的 95%”。

VodafoneThree UK Datahub 的 GenAI 工程师 Radina-Paola Ivanova 评价说，此前大量数据资产未文档化或标签不一致，代理通过编目、血缘和自动化元数据传播，让团队聚焦治理高价值环节，由血缘将信任上下文扩展至全平台，估计可减少高达 75% 的编目工作量。

治理债务与技术债务一样，悄悄累积，直到某人在最坏的时刻撞上。这类方法的价值不是让治理从视野中消失，而是把工作移到上游，让上下文和控制随数据流动，而不是每次新建视图时从头重建。对坐拥多年未文档化 BigQuery 资产且数据不断快速变化的团队，这正是治理滞后与治理同步的区别。