数据工程师的 Agent 工具箱

这个 pack 包含什么

这是工作中的数据工程师为了让 AI agent 真正能帮上忙而搭起来的栈 — 不是那种「text-to-SQL 演示」一遇到 800 张表、三种方言、和一堆没人写文档的 dbt macro 就崩的玩具。

每个资产在 agent 循环里只干一件事：给 agent schema 感知（数仓 MCP）、给它模型感知（dbt-mcp 套在 dbt/SQLMesh 上）、给它编排感知（Airflow）、给它血缘感知（DataHub），最后给它最缺但谁也没给过的一件 — 方言感知（SQLGlot）。五层都到位之后，agent 不再对着 Snowflake 写 STRING_AGG，模型一次性 compile 通过。

顺序是有讲究的，每一层都是上一层的脚手架。先接好数仓 MCP，再上 dbt-mcp — 连底表都读不到，给 agent 看 dbt manifest 也没用。

推荐安装顺序（原始 SQL → 模型 → 编排 → 质量与血缘）

1. Postgres MCP Pro — Postgres MCP，安全 SQL、EXPLAIN 计划、索引推荐都自带。哪怕 Postgres 不是你的数仓也先装它，因为你的业务库八成是 Postgres，而 agent 驱动的探索一般从那里起步。
2. BigQuery MCP — 带 PHI/PII 保护模式的 BigQuery MCP。GCP 用户的数仓连接器。任何非工程角色一句「列出 top 客户」时，这个保护模式就值回票价了。
3. Trino MCP — Trino/Presto MCP，OAuth 2.1 接入。你有一个 federated 数仓（Iceberg + S3 + 没死透的 MySQL）想用一个 MCP 一打多时上它。
4. MCP Toolbox for Databases — Google 开源的 MCP，一台 server 前置多个数据源，按声明式配置一次给 agent 暴露。比起把五个 MCP 分别接，「这五个源、这几个工具」一次写完更省心。
5. dbt — 模型层。你团队就算已经在用，也装一下让 agent 有官方资产可引，并知道你项目按 dbt 约定走（models/ / schema.yml / dbt_project.yml）。
6. dbt-mcp — 把 dbt 项目上下文（模型、语义层、文档）暴露给 agent 的 MCP。这是关键一跳：agent 回答「fct_orders 都有哪些列」时是去读你的 manifest，不是凭印象编。
7. SQLMesh — 值得了解的 dbt 替代。虚拟数据环境、真正的列级血缘、语义化版本。新项目可以试；已经在 dbt 上稳定运行的团队继续 dbt。
8. Apache Airflow — 编排层。Dagster / Prefect 再香，生产数据流水线绝大多数还是落在 Airflow。给 agent 装上，它写 DAG 时用的就是你团队真在跑的方言。
9. DataHub — 数据发现 + 血缘 + 治理。当 agent 已经能写 SQL、改 dbt 模型，下一个常见故障就是「agent 改了上游字段，把三个下游 dashboard 静默改坏」。DataHub 解决的就是这种可见性缺口。
10. SQLGlot — 纯 Python 的 SQL 解析与转译器。这个 pack 里最不起眼但最关键的英雄。agent 在 Stack Overflow 上学的 SQL 是 Snowflake 和 Postgres 各一半，结果你在 BigQuery 上跑 — SQLGlot 在中间转一道，方言差异直接消失。

它们怎么协同

                  ┌── Postgres MCP Pro ──┐
                  │  （业务库 + 安全 SQL）  │
                  └────────┬──────────────┘
                           │
   BigQuery MCP ──┐        │       ┌── Trino MCP
    （数仓）       │        │       │  （联邦查询）
                  └────────┼───────┘
                           ▼
              MCP Toolbox for Databases
                  （一台 server 多源）
                           │
                           ▼
                  ┌─── dbt / SQLMesh ───┐
                  │      （模型层）       │
                  └──────────┬───────────┘
                             │
                             ▼
                         dbt-mcp
              （agent 读 manifest + 语义层）
                             │
                             ▼
                    ┌──── Airflow ────┐
                    │   （DAG 调度）    │
                    └────────┬─────────┘
                             │
                             ▼
                         DataHub
                  （血缘 + 影响分析）
                             │
                             ▼
                         SQLGlot
             （agent 写错方言时自动转译）

关键连接是 MCP 层 + dbt-mcp：数仓 MCP 暴露物理 schema，dbt-mcp 在上面暴露逻辑模型层。两个都接上之后，agent 才能回答「这个字段是哪个模型产的，底层 SQL 长啥样」 — 这个问题答得出来，agent 才从玩具变成队友。

你会遇到的取舍

• Airflow vs Dagster vs Prefect — Airflow 部署量最大、招人最容易，所以你在大公司当独立数据人多半会继承一套 Airflow。Dagster 资产语义更干净、开发体验显著更好。Prefect 最轻量。除非全新项目，默认 Airflow；agent 对三者都能用。
• dbt vs SQLMesh — dbt 生态全（每个 BI 都集成）但增量模型容易翻车，列级血缘要付费 Cloud 或第三方。SQLMesh 自带虚拟环境、真血缘、语义版本，但社区小。新项目试 SQLMesh；老 dbt 项目稳定运行就别折腾。
• ClickHouse vs BigQuery vs Snowflake — ClickHouse 实时分析、要低延迟、能容忍 schema 不灵活；BigQuery 在 GCP 想要零运维，代价是 join 慢；Snowflake 想要弹性算力、不在乎账单。agent 不关心你选哪个，但它写的 SQL 关心 — 这就是 SQLGlot 进这个 pack 的原因。
• 单数仓 MCP vs MCP Toolbox — MCP Toolbox 一台 server 多源、运维简单但爆炸半径大；分仓 MCP 隔离好但 service 多。先用 Toolbox 起步，等你需要更严格的访问边界再拆。

常见踩坑

• LLM 对着真 schema 瞎编字段 — 典型失败是 agent 把 customer_id 编成 cust_id。补救办法是先把 MCP 接上、再让 agent 查 — 不是反过来。MCP 没接，agent 必猜；MCP 接好，agent 会读。
• 从 Stack Overflow 粘来的 SQL 方言漂移 — agent 在 BigQuery 项目里写出 Postgres 味儿的 SQL（SUBSTRING 不是 SUBSTR、|| 不是 CONCAT、window 语法对不上）。流水线里加一道 SQLGlot 转译，噪声直接降一个量级。
• 过早把 dbt-mcp 当写工具用 — 先只读。让 agent 读你的 manifest、答问题、以 PR 形式提改动。还没看它稳定工作一周就给生产 dbt 项目开写权限，等着周二早上 200 个模型挂掉吧。
• 不出事不上血缘 — DataHub 在没出事前看着像额外负担，等 agent 改了上游字段三个 dashboard 静默给出错数那天就晚了。出事之前装好，运维成本远小于事后排查成本。
• 忘了开 PHI/PII 防护 — BigQuery MCP 的保护模式不是摆设。只要数仓里有任何受监管数据、agent 又会被数据团队以外的人用到，第一天就把列级遮罩打开。别等合规工单来。