你的 AI 现在能写数据管道了。MotherDuck 把它做成了产品

数据管道一直是个"基本被解决但没人觉得好用"的事。从手写 ETL 脚本到 Fivetran/Airbyte 的点选式 UI，再到 dlt 这样的声明式 Python 库——每代工具都更省力一点，但有一个角色始终缺席：写代码的人。

6 月 10 日，MotherDuck 上线了 Flights，一个 agent-native 的数据管道功能。说人话：把你的 AI agent 连到 MotherDuck 的 MCP server，告诉它"帮我从 GitHub API 拉仓库数据，每小时同步一次"，agent 写 Python 代码、部署、设 cron——你不需要动键盘。

Flights 目前是 public preview，在 MotherDuck 文档里有完整的 Flight Plan 模板可以上手。

● ● ●

三种方式来管 Flights

虽然 agent-native 是 Flights 的主打卖点，它其实提供了三种操作入口：

1. MCP Server（Agent 入口）

把 Claude、Cursor、ChatGPT 或任何 MCP 兼容的 agent 连到 MotherDuck 的 MCP server，agent 会得到完整的 Flights 工具集：create_flight、run_flight、schedule_flight、get_logs、edit_flight_source、delete_flight。还有一个内置的 get_flight_guide 工具，告诉 agent 怎么写符合 MotherDuck 规范的 Flight 代码。

你只需要用自然语言描述数据源和目标表，agent 会先探查你已有的 schema，写一个 Python pipeline，部署并设好调度。Secrets 存在 MotherDuck 里，运行时注入，agent 全程看不到。

2. SQL 表函数

每一个 Flight 操作都有对应的 SQL 表函数。创建就是一个 SELECT：

SELECT * FROM md_create_flight(
    name              := 'daily_signups',
    access_token_name := 'prod_token',
    schedule_cron     := '0 9 * * *',
    source_code       := $$
import duckdb

def main():
    duckdb.connect("md:").execute("""
        INSERT INTO analytics.signups
        SELECT * FROM 'https://api.example.com/signups.json'
    """)
$$
);

MD_RUN_FLIGHT、MD_GET_FLIGHT_LOGS、MD_LIST_FLIGHTS 等等——所有操作都是 SQL 一行。你的 BI 工具、dbt、甚至另一个 Flight 都能管 Flights。

3. Web UI

在 MotherDuck 控制台里直接写 Python、设 cron、点一下运行。日志、run history、版本、环境变量、requirements.txt 都有可视化界面。

三个入口底层是同一个原语：一个专用的 Python 运行时，能 pip install 任何包，通过 DuckDB Python client 连到你的 MotherDuck 数据库。

● ● ●

一个真实例子：dlt + Flights

dlt（data load tool）是 Flights 推荐的 ingest 库。它是一个声明式的 Python 数据加载框架，自动处理 schema 演进、增量加载、合并策略，并且有 MotherDuck 的一等公民 destination。

下面是一个完整的 Flight——从 GitHub API 拉仓库元数据，merge 到 MotherDuck 表：

import os
import dlt
import httpx

def repo_rows(repos):
    for repo in repos:
        response = httpx.get(f"https://api.github.com/repos/{repo}")
        payload = response.json()
        yield {"repo": repo, "stars": payload["stargazers_count"]}

def main():
    os.environ.setdefault("HOME", "/tmp")
    pipeline = dlt.pipeline(
        pipeline_name="github_stats",
        destination="motherduck",
        dataset_name="analytics",
    )
    pipeline.run(
        repo_rows(["duckdb/duckdb", "motherduckdb/motherduck-docs"]),
        table_name="repos",
        write_disposition="merge",
        primary_key="repo",
    )

把这个文件保存为 flight.py，attach 一个 cron 调度，dlt 接管后续所有事：建表、schema 演进、按 repo 主键做增量 merge、用 Parquet 做 bulk loading。把 repo_rows 换成 dlt 支持的任何 source——REST API、Postgres、BigQuery、S3、dlt 的 verified-source 目录——你就有了一个生产级的 ingestion pipeline。

完整版（带配置驱动参数、run ledger、schema 校验）在 MotherDuck 的 flight-dlt-ingest Flight Plan 里有模板。

● ● ●

Flights + Dives = 一条龙

MotherDuck 的另一个产品 Dives 是做可视化仪表盘和数据 App 的——React 组件驱动,直接跑在 MotherDuck 数据上。Flights 管摄入和转换，Dives 管探索和可视化。

关键是 同一个 MCP server 同时暴露 Flights 和 Dives 的工具。一个 agent 在一个 chat 里就能完成：拉数据 → 建表 → 写 pipeline → 设调度 → 做仪表盘。

这在传统数据栈里需要至少三个工具（ETL + 数仓 + BI）+ 至少一个人来协调。现在一个 agent 对话就行。

● ● ●

"agent-native" 到底是什么意思

MotherDuck 对 "agent-native" 的定义比较实在，不是什么 buzzword。

传统数据栈的设计对象是人——SQL 编辑器、拖拽 UI、YAML 配置。Agent 需要的东西不一样：工具化的 API surface（不是 UI），清晰的指令文档（get_flight_guide 这种），统一的控制面（compute + secrets + scheduling + observability 在一个 MCP server 里）。

MotherDuck 的论点：把一个 agent 扔到碎片化的数据栈上（一个工具管 ETL、一个管数仓、一个管 BI，各自有各自的 API 和权限），agent 会频繁在工具边界上失败。把 compute、数据、调度、secrets、监控全部收进一个 MCP server，agent 的成功率会高得多。

Flights 是这个论点的第一个产品化尝试。

● ● ●

边界在哪

Flights 不是 Airflow 或 Prefect 的替代品。一个 Flight 就是一个 Python 进程，没有内置的任务队列、分布式状态、DAG 编排。可以一个 Flight 调 MD_RUN_FLIGHT 去触发另一个来做 fan-out，或者在 Python 里用线程池做并行——但编排逻辑要自己写。

Flights 最适合的场景是 MotherDuck 中心化的工作负载：数据、调度和计算全在 MotherDuck 里，不需要跨多个外部系统编排。如果 pipeline 大量依赖外部服务，Airflow/Prefect 仍然是更好的选择。

● ● ●

Bottom line

AI agent 写代码这件事在过去一年已经成了日常。但"写数据管道"一直卡在最后一个环节：写完的代码谁来部署、调度、监控？

MotherDuck 的答案是：同一个 agent，通过同一个 MCP server，写完就能部署，部署完就能监控。从"AI 帮你写代码"到"AI 帮你运行代码"——这一步是数据工程 agent-native 化的分水岭。

motherduck.com/product/flights