用 Google Cloud Data Lineage…

当你需要梳理某个 BigQuery/GCS 资产的上游来源与下游流向，并把复杂血缘图整理成直观的 Markdown 报告时使用。

适用场景

解决思路

1. 通过 MCP 工具分别发起两次 search_lineage 调用：一次 direction 设为 UPSTREAM，一次设为 DOWNSTREAM，从焦点资产双向获取血缘图。
2. 位置策略：必须先用 read_url 工具从 Knowledge Catalog Locations 链接动态获取完整的受支持区域列表，并在 locations 数组中填入所有受支持的物理区域，以避免遗漏跨区域血缘；可选用 bq show 或 gcloud storage ls 额外确定资产的具体活跃区域。
3. 调用 search_lineage 时使用稳健默认参数：maxDepth = 10、maxResults = 5000、maxProcessPerLink = 10；例如 DOWNSTREAM 调用格式为 {"parent": "projects/project_id/locations/us", "locations": ["us", "us-central1", "us-east1", "us-west1", "europe-west1", "asia-northeast1"], "rootCriteria": {"entities": {"entities": [{"fullyQualifiedName": "bigquery:project.dataset.table"}]}}, "direction": "DOWNSTREAM", "limits": {"maxDepth": 10, "maxResults": 5000, "maxProcessPerLink": 10}}，并以同样方式发起 UPSTREAM 调用。
4. 列级血缘（CLL）：在 rootCriteria 的实体中配置 field 数组；若需要表级血缘（TLL），用 "*" 通配符同时获取 CLL 与 TLL 链接，例如 "field": ["*"]；若分析特定列，则将 "*" 替换为具体列名（如 "efficiency_score"）。
5. 以专家数据血缘分析师的角色生成摘要，输出从左到右、简洁易懂的数据流走查。
6. 摘要结构：直接以摘要文本开头，依次包含——整体流程类型（推断的工作流类型与数据域，如“这看起来是一个特征工程工作流……”）；系统概览（先列出涉及的主要系统；若为列级血缘，必须在一开始明确声明分析范围仅限于指定字段）；上游血缘（使用精确加粗标题 **Upstream Lineage:**，叙述数据如何到达焦点资产，提及关键源系统、项目和加工任务，如 Spark on Dataproc）；下游血缘（使用精确加粗标题 **Downstream Lineage:**，描述数据从焦点资产流向最终消费系统的路径）；分析元数据（展示 API 调用参数以说明摘要边界，必须包含：Locations Searched: {list_of_locations_queried}、Parent Location: {parent_path}、Depth Limit: {maxDepth}、Process per Link Limit: {maxProcessPerLink}，以及一条提示用户可要求扩大位置范围或深度重跑的 Tip for User）。
7. 粒度约束：优先描述系统、项目、数据集之间的流转，而非单个文件/表；当具体资产（源表、中间视图、消费表）少于 5 个时必须逐一列出名称，不得只给数量；达到或超过 5 个时按数量聚合（如“5 GCS buckets”）；只对最终来源、最终消费者和资产总数提及数量；若只涉及一个项目，不要为每个数据集重复项目名。
8. 语气：避免术语和“There are distinct factual points”之类的空泛表述，直接清晰；最终输出为 Markdown。
9. 将最终摘要输出返回给用户。

适用边界 · 注意事项

• 不要用于通用 BigQuery 查询、编辑血缘关系或下游弃用处理。
• 不要用于下游爆炸半径影响分析（应改用 datalineage-bigquery-asset-impact-analysis 技能）。