Studio MCP 操作 SQL 任务

在 ELT 工作流里，SQL 任务通常是最核心的一层。数据先进入 Lakehouse，再通过 SQL 完成清洗、关联、聚合、口径计算和结果表生成。很多日常数据开发工作，本质上都是围绕 SQL 任务展开的。

Studio 托管 MCP Server 支持独立完成 SQL 任务的一条完整工作链路。对于日常开发、临时验证和发布前检查，用户不需要先切回 Studio 页面，就可以让 Agent 直接完成任务创建、内容保存、参数配置、调度配置、临时执行和运行诊断。

这类场景的核心价值，不是“让 Agent 代替你写一条 SQL”，而是把 SQL 任务从草稿推进到可验证、可复用、可诊断的任务对象。

放在 ELT 背景下看，SQL 任务本身适合承接规则清晰、以库内转换为主的工作，例如定时报表生成、指标口径计算、明细到汇总的数据加工、结果表刷新、数据核对和发布前验证。

在一条典型的数据开发链路里，SQL 任务往往处在 ELT 的主干位置：

上游把数据装载进入 Lakehouse
中间通过 SQL 任务完成清洗、关联、聚合和结果产出
下游再把这些结果提供给报表、分析域、应用查询或后续任务

如果把 ELT 看成一条持续运转的数据生产线，SQL 任务通常就是其中最常见、最稳定、最可复用的一层转换单元。

适合用在什么场景

SQL 任务适合优先通过 MCP 使用的典型场景包括：

新建一个临时验证任务，快速跑通一段 SQL
给已有 SQL 任务补充参数和执行配置
发布前先做一次临时执行确认
在执行后直接读取任务实例和运行状态
把“写 SQL”“保存任务”“查看运行结果”串成一次连续操作

如果你的目标是先让 Agent 参与一条最常见、最稳定的 Studio 工作流，SQL 任务通常是最好的起点。

如何向 Agent 提问

在 SQL 任务场景里，比较自然的提问方式通常不是直接提 tool 名称，而是把任务目标、目录位置和后续动作一起说清楚。

如果目录或任务是否已存在还不清楚，建议先探索：

帮我看看当前目录里有没有现成的订单日报 SQL 任务可以复用。
帮我看一下当前有哪些目录适合放一个临时 SQL 任务。

如果目录和目标已经明确，就可以直接执行：

可以直接这样说：

帮我在
```
临时开发
```
临时开发
目录下新建一个 SQL 任务，名字叫
```
订单日报验证
```
订单日报验证
。
把我接下来给你的 SQL 保存到刚才这个任务里。
再帮我读一下任务详情，确认内容已经保存。

如果还希望继续往下推进，可以直接把后续动作一起说出来：

帮我把这条 SQL 里的
```
biz_date
```
biz_date
改成参数。
用
```
biz_date=2026-06-12
```
biz_date=2026-06-12
先临时跑一次。
如果这次执行正常，再帮我发布。

这类说法的重点，是把“创建”“保存”“执行”“发布”串成连续任务链，而不是让 Agent 停在单一步骤。

一条完整链路包括什么

对 SQL 任务，纯 MCP 可以完成下面这些动作：

创建 SQL 任务
保存 SQL 内容
保存任务参数
保存非周期配置
预览调度时间
保存调度配置
临时执行任务
读取任务实例详情

这意味着 Agent 不只是生成一段 SQL 文本，而是可以把它落到 Studio 的任务对象里，再继续推动到可执行状态。

创建和保存任务

SQL 任务的起点通常是先在指定目录中创建一个任务，再把 SQL 内容写进去。

这一步适合：

新建一次性验证任务
新建带参数的模板任务
在已有目录里补建实验任务

保存内容后，再读取任务详情，可以确认：

任务 ID
任务名称
当前内容
所在目录
对应的 Studio 打开链接

这样做的意义在于，Agent 生成出来的 SQL 不会停留在对话里，而是直接变成一个可继续管理的任务对象。

参数化 SQL 任务

SQL 任务很适合做成参数化模板，例如：

按日期查询
按业务口径切换过滤条件
在不同环境中复用同一条任务逻辑

通过 MCP，可以同时保存：

SQL 内容里的
```
${变量}
```
${变量}
变量对应的参数定义

在执行时，再单独传入这次运行的实际值。

这样可以把“任务模板”和“本次执行参数”分开管理：

模板本身保持稳定
参数值按运行场景变化

这对日常验证、定时运行和跨环境复用都很有帮助。

非周期配置

SQL 内容保存之后，通常还需要补一层执行配置，才能让任务进入更稳定的使用状态。

对 SQL 任务，常见的非周期配置包括：

重试次数
重试间隔
超时时间
自依赖
重跑策略

这些配置解决的不是“SQL 写得对不对”，而是“这个任务失败后怎么处理”“跑太久怎么办”“再次运行时要遵守什么约束”。

对于准备长期保留、反复执行的任务，这一步通常值得在内容保存后立即补齐。

调度配置

如果 SQL 任务不仅用于临时验证，还要成为周期性任务，就需要补调度配置。

比较稳的做法通常是：

先预览 cron 对应的未来触发时间
确认时间计划符合预期
再保存调度配置

这样可以避免把错误的调度计划直接写进任务配置里。

对 SQL 任务来说，这一步尤其有价值，因为很多用户真正关心的不是“会不会写 cron”，而是“这个任务到底会在什么时候触发”。

临时执行

在决定是否发布前，通常先做一次临时执行更稳。

临时执行适合回答这些问题：

这段 SQL 现在能不能跑通
参数展开后是否符合预期
当前 VC 和运行环境是否可用
这次运行的耗时大概怎样

对 SQL 任务来说，临时执行是非常自然的中间动作：

它比只看 SQL 文本更接近实际运行结果
又比直接发布更轻量、更适合验证

运行诊断

SQL 任务执行后，MCP 可以直接返回一组结构化结果，包括：

```
task_instance_id
```
task_instance_id
执行状态
执行耗时
执行参数
所用 VC
任务实例详情
对应运维页面的跳转链接

这使得 Agent 可以承担第一轮运行确认和第一轮排查，而不需要用户先自己去翻任务实例列表。

对很多日常 SQL 任务来说，这已经足够完成一次最小闭环：

创建
保存
配置
执行
回读结果

与 Python 任务的分工

在 ELT 里，SQL 任务和 Python 任务通常不是互相替代，而是自然分工。

更适合交给 SQL 任务的，通常是：

规则清晰的数据转换
表与表之间的关联和聚合
指标口径计算
结果表生成与周期刷新

更适合交给 Python 任务的，通常是：

SQL 不方便直接表达的脚本逻辑
文件处理、接口调用和控制流
基于 Python Connector 的查询与写入
基于 ZettaPark DataFrame API 的程序化数据处理

从协作方式上看，更常见的模式是：

SQL 任务承担 ELT 主干转换
Python 任务承担 SQL 之外的补充逻辑

这样两类任务结合起来，比单独强调某一种任务类型更贴合数据开发工作流。

这类能力带来的实际价值

对 SQL 任务，纯 MCP 最容易交付的价值主要有三类：

把 SQL 从对话结果变成任务对象
把参数、配置、执行和诊断串成一条连续工作流
减少在任务目录、配置面板和运维页面之间反复切换的成本

如果你的团队准备先挑一种任务类型SQL 任务通常是最容易让 Agent 融入开发流程的一类。