Studio MCP 操作 Python 任务

在 ELT 工作流里，SQL 通常负责主干的数据转换，但总会有一部分环节不适合直接用 SQL 表达，例如文件处理、外部接口调用、脚本化预处理和带控制逻辑的任务编排。这类工作通常会落到 Python 任务上。

Studio 托管 MCP Server 支持独立完成 Python 任务的核心工作链路。对于脚本验证、轻量数据处理和任务原型开发，用户可以直接让 Agent 在 Studio 中创建 Python 任务、写入代码、发起执行并读取运行结果。

这类场景的重点，不是把 Agent 当成一个单纯的代码生成器，而是把它接进任务开发与验证流程。

放在 ELT 背景下看，Python 任务本身适合承接 SQL 不方便直接表达的逻辑，例如脚本化数据处理、外部接口调用、文件读写、轻量控制流程和任务原型实验。

在 Lakehouse 中，Python 任务并不只是“运行一段普通 Python 脚本”。它可以配合两类原生能力来处理 Lakehouse 数据：

Python Connector：适合执行固定 SQL、做脚本式查询与写入，或通过 SQLAlchemy / PEP 249 方式访问 Lakehouse
ZettaPark DataFrame API：适合用类 PySpark / DataFrame 的方式做数据处理，由系统把 DataFrame 逻辑翻译为 SQL 在 Lakehouse 中执行

适合用在什么场景

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

新建一个临时 Python 任务做快速验证
让 Agent 直接把一段 Python 代码写进 Studio 任务
在脚本保存后立刻发起一次执行
在执行后直接读取任务实例和运行状态
用 Python 任务承接一次轻量数据处理或开发原型

如果目标是让 Agent 不只“给代码建议”，而是直接参与任务对象的创建和验证，Python 任务是很合适的一类起点。

如何向 Agent 提问

在 Python 任务场景里，提问时最好把任务目录、任务目标以及希望使用的技术路径一起说出来。

如果你还没确定该不该建新任务，或者还没确定该走 SQL 还是 Python，建议先探索：

帮我看看当前目录里有没有现成的订单清洗任务可以复用。
我想做一个订单数据清洗任务，先帮我判断更适合用 SQL 任务还是 Python 任务。

如果目录、任务类型和技术路径已经明确，就可以直接执行：

可以直接这样说：

帮我在
```
临时开发
```
临时开发
目录下新建一个 Python 任务，名字叫
```
订单清洗脚本验证
```
订单清洗脚本验证
。
用 Python Connector 写一个查询
```
public.orders
```
public.orders
的脚本，并保存到这个任务里。
用 ZettaPark DataFrame API 写一个按天聚合订单数据的脚本草稿，保存到这个任务里。

如果你已经有代码，也可以直接说：

把我接下来给你的 Python 脚本保存到刚才那个任务里。
保存后先临时执行一次，看看能不能跑通。

这里最有帮助的信息通常是：

任务要建在哪个目录
任务是做查询、清洗还是原型验证
希望使用 Python Connector 还是 ZettaPark DataFrame API

这样 Agent 更容易贴近你真正想走的开发路径。

适合纯 MCP 完成的动作

对 Python 任务，纯 MCP 适合完成下面这些动作：

创建 Python 任务
保存基于 Python Connector 或 ZettaPark 的 Python 代码
保存基础执行配置
发起临时执行
读取任务实例详情

这使得 Agent 可以把“写代码”和“运行验证”接成一条连续链路，而不是停留在对话中给出一段未落地的脚本。

创建和保存任务

Python 任务通常从目录中的一个新任务开始。

创建后，Agent 可以直接把 Python 代码写入任务内容中，再回读任务详情，确认：

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

这一点很重要，因为它把“生成代码”变成了“生成并保存任务对象”。
对于需要反复修改、反复验证的 Python 任务，这比只在对话里给出代码片段更有实际价值。

Python Connector 和 ZettaPark 分别适合什么

如果你的 Python 任务主要是：

执行一组固定 SQL
做脚本化查询与写入
通过连接对象访问 Lakehouse 或外部数据库

那么更适合使用 Python Connector 这条路径。

如果你的 Python 任务主要是：

用 DataFrame 风格组织转换逻辑
做多步清洗、关联、聚合
希望保留接近 PySpark 的开发习惯
让 Python 负责控制流，Lakehouse 负责分布式执行

那么更适合使用 ZettaPark DataFrame API。

简单理解就是：

Python Connector 更像“在 Python 里调用数据库”
ZettaPark 更像“在 Python 里写 DataFrame，再交给 Lakehouse 执行”

代码保存后的意义

对 Python 任务来说，代码一旦保存进任务对象，就意味着后续很多动作都能围绕同一个对象继续进行，例如：

继续改代码
调整基础执行配置
直接执行
回看任务实例

这让 Agent 可以参与一条更完整的开发流程，而不是每次都从零重新生成脚本。

基础执行配置

Python 任务除了代码内容，通常还需要一层基础执行配置。

这类配置主要用于控制任务的运行行为，例如：

重试次数
重试间隔
超时时间
重跑策略

它们决定的是脚本作为一个任务对象如何运行，而不是脚本本身写得是否正确。

对于临时验证任务，这些配置可以保持简洁；对于准备长期保留的 Python 任务，建议在代码保存后补齐基础配置。

临时执行

Python 任务最有价值的一个动作，就是保存后立即做一次临时执行。

这一步适合回答这些问题：

代码能不能正常跑通
当前运行环境是否可用
脚本大概会执行多久
当前任务对象是否已经进入可验证状态

和只看脚本内容相比，临时执行能更快把问题暴露出来，也能让 Agent 直接回收结构化运行结果。

运行诊断

Python 任务执行后，MCP 可以直接返回：

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

这意味着 Agent 不只负责“提交一段代码”，还可以继续负责“把这次执行的结果拿回来”。

对于很多原型开发和临时脚本任务来说，这已经能交付一条很有价值的闭环：

创建任务
写入基于 Connector 或 ZettaPark 的代码
发起执行
回读状态

适合怎样引入到日常工作流

把 Python 任务纳入日常 MCP 工作流，比较自然的顺序是：

先让 Agent 创建一个临时任务
再让 Agent 写入一版脚本
补保存基础执行配置
发起一次临时执行
读取任务实例和执行状态

这套方式适合先从小场景开始，例如：

做一次脚本验证
做一次轻量数据处理实验
让 Agent 帮你快速搭一个任务原型

等这条链路用顺之后，再逐步扩展到更稳定、更长期的 Python 任务管理。

这类能力带来的实际价值

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

把 Python 代码直接落到任务对象里
把代码保存和执行验证连成一条连续动作
让 Agent 在执行后直接返回任务实例和运行状态

这使得 Python 任务不只是“支持一种脚本类型”，而是成为 Agent 参与任务开发的一条真实入口。

如果你的团队在 ELT 流程里既需要 SQL 主干转换，也需要一部分脚本化处理，那么 Python 任务可以和 SQL 任务形成很自然的分工：

SQL 任务负责规则清晰、以库内转换为主的环节
Python 任务负责 Connector 查询、ZettaPark DataFrame 处理和 SQL 难以直接表达的脚本逻辑