Studio MCP 操作普通数据集成任务

这篇文档适合已经完成 MCP 接入、并希望通过 Agent 创建和配置普通数据集成任务的用户。如果还没有完成接入，先看接入配置指南。

普通数据集成任务对应的是

task_type=10

task_type=10

。它适合处理一次运行完成的数据搬运场景，例如把 MySQL、PostgreSQL、SQL Server、MongoDB 等外部数据源中的单表数据同步到 Lakehouse，或者在不同数据源之间完成一次结构化同步。

和 SQL、Shell、Python 任务不同，普通数据集成任务不是以代码编辑器为中心，而是以来源端、目标端、字段映射和同步规则为中心。因此，它更适合让 Agent 负责结构化创建和配置，再由用户在页面中确认映射、运行结果和实例状态。

适合用 MCP 处理的部分

在普通数据集成任务里，MCP 更适合承担这些结构化动作：

创建
```
10
```
10
类型的任务对象
指定源数据源、源表和目标表
保存数据集成配置
帮用户把任务落到可以直接运行的页面形态

这些动作本身高度结构化，适合由 Agent 协助完成。

如何向 Agent 提问

在普通数据集成任务场景里，最关键的是把来源、目标和“现在处在哪一步”说清楚。

如果来源表、目标表、目录位置或现有任务情况还不清楚，建议先探索：

帮我看看当前工作区里有哪些数据源适合做这次同步。
帮我看看
```
aliyun_mysql
```
aliyun_mysql
下面有没有我要同步的那张表。
帮我看看当前目录里有没有现成的普通数据集成任务可以复用。

如果来源、目标和任务意图已经明确，就可以直接执行：

帮我创建一个普通数据集成任务，把
```
源数据源.源表
```
源数据源.源表
同步到
```
目标数据源.目标表
```
目标数据源.目标表
。
帮我把这个任务保存到
```
临时开发
```
临时开发
目录下。
保存以后先让我确认一下来源目标配置，再决定是否运行。

如果已经进入运行确认阶段，也可以直接这样说：

帮我看一下这次运行读了多少条、写了多少条。
如果有脏数据，也一起告诉我。

更自然的使用方式通常不是一开始就要求 Agent 完成整条同步链路，而是先确认对象和配置落点，再进入运行与结果确认。

任务类型的基本理解

普通数据集成任务的重点不是编写脚本，而是配置同步关系。通常需要明确四类信息：

源数据源
源表
目标数据源
目标表

在此基础上，页面还会进一步承接：

字段映射
写入模式
过滤条件
分片字段
同步规则

因此，理解这类任务时，重点不在“任务内容写了什么”，而在“数据从哪里来、写到哪里去、如何映射、按什么规则运行”。

用 MCP 创建并保存普通数据集成任务

通常会先创建一个

任务，再通过 MCP 保存数据集成配置。

配置里至少需要明确这些信息：

源数据源名称
源 Schema 或 Database
源表名
源数据源类型
目标数据源名称
目标 Schema
目标表名
目标数据源类型

源数据源和目标数据源都应先是 Studio 中已经可用的数据源对象。
保存成功后，任务会在 Studio 中呈现为专门的数据集成配置界面，而不是普通代码编辑器。

保存前后的关键判断

普通数据集成任务的配置保存，不只是把一组参数写进任务对象。

在保存过程中，更关键的判断通常包括：

源表是否存在
目标表是否已经存在，或者是否已经准备好
这份配置是否已经形成有效的数据集成任务定义

因此，如果源表名、Schema 或数据源名不正确，保存阶段就可能直接失败。
这类报错通常意味着需要先回到源端对象本身，确认表名和库名，而不是先去怀疑运行环境。

保存后的页面表现

当普通数据集成任务配置保存成功后，回到 Studio 打开任务，会进入专属的数据集成配置视图。

页面通常会直接展示这些区域：

```
来源目标配置
```
来源目标配置
```
字段映射配置
```
字段映射配置
```
同步规则配置
```
同步规则配置

这意味着 MCP 保存的配置和页面中的任务对象共享同一份数据，两者可以互相查看和修改。

来源目标配置适合确认什么

来源目标配置

来源目标配置

适合确认一条同步关系是否已经落对。

页面中通常可以直接看到：

源数据源类型与名称
源 Database
源 Table
目标数据源类型与名称
目标 Schema
目标 Table
数据写入模式
过滤条件
分片字段

对普通数据集成任务来说，这一屏最适合回答的是：“这份任务到底要把哪张表，从哪里同步到哪里。”

字段映射配置适合确认什么

字段映射配置

字段映射配置

适合确认源字段和目标字段之间的映射关系。

页面通常会直接列出：

源字段名
源字段类型
目标字段名
字段映射关系

这部分很重要，因为普通数据集成任务的正确性，不只是“能不能跑”，还包括“字段有没有对齐，类型有没有落对”。

如果字段数量多、字段名相近，先由 MCP 完成基础配置，再回到页面做人工确认，通常更稳。

同步规则配置适合确认什么

同步规则配置

同步规则配置

更适合承接运行行为上的补充设置。

不同源端和目标端的场景下，用户通常会关注：

写入模式是否符合预期
是否需要过滤条件
是否需要通过分片字段提升同步效率
是否有脏数据处理相关选项

这部分更接近任务运行语义，而不是对象定义语义，因此也更适合在页面中做最终确认。

运行入口和运行方式

普通数据集成任务保存成功后，可以直接在 IDE 页面中运行。

它和普通代码任务的区别在于：

页面主体不是脚本编辑器
运行动作直接基于当前集成配置发起
运行结果会在 IDE 底部区域直接回显

这类任务更接近“配置完成后直接执行一次同步”，而不是“保存脚本后再解释脚本逻辑”。

运行后的页面反馈

从 IDE 发起运行之后，页面底部通常会出现实例区域，用来承接当前运行的反馈。

这里常见的信息包括：

```
运行结果
```
运行结果
```
运行时间
```
运行时间
```
总耗时
```
总耗时
```
写入记录
```
写入记录
```
读取记录
```
读取记录
```
读脏数据
```
读脏数据
```
写脏数据
```
写脏数据
```
日志
```
日志
```
实例运维
```
实例运维

这说明普通数据集成任务的运行反馈，已经直接嵌入到 IDE 页面里，不需要第一步就跳到独立运维页。

从 IDE 进入实例运维

如果需要进一步查看实例细节，可以从 IDE 底部区域进入

实例运维

实例运维

。

进入后，通常会跳到普通任务实例运维页。在这个页面里，常见入口包括：

```
实例详情
```
实例详情
```
脚本内容
```
脚本内容
```
执行日志
```
执行日志
```
操作日志
```
操作日志
```
终止
```
终止
```
刷新
```
刷新

这条链路很有价值，因为它把“在 IDE 中启动同步”和“进入标准实例运维页继续诊断”衔接了起来。

实例详情适合看什么

实例详情

实例详情

更适合查看这次运行的基础事实。

页面上通常会提供：

实例 ID
实例类型
任务名称
任务 ID
工作空间
集群
所有者
实例状态
计划时间
运行时间
结束时间
总耗时

这部分适合回答“这次运行是否真的发起了、在哪个环境里跑、当前跑到什么状态”。

执行日志和操作日志适合看什么

执行日志

执行日志

更适合看同步执行过程本身。

操作日志

操作日志

更适合回答“谁做了什么控制动作”。

如果任务运行结果不符合预期，通常可以按下面顺序判断：

先看实例状态是否成功结束
再看读取记录和写入记录是否符合预期
再看是否出现读脏数据或写脏数据
再进入执行日志确认具体执行过程

普通数据集成任务和多表实时同步任务的区别

两者都不是以代码编辑器为中心，但运行模型不同。

普通数据集成任务更接近一次性执行完成的任务：

保存配置后可以直接运行
运行结果在 IDE 底部直接展示
后续进入普通任务实例运维页

多表实时同步任务更接近持续运行任务：

保存配置后还需要提交
启动方式单独选择
后续进入专属的实时同步运维页

如果用户把这两类任务混成同一套心智，最容易产生的误解是：为什么一个任务保存后可以直接运行，另一个却要先提交再启动。

更适合的使用顺序

把 MCP 和页面结合起来时，通常可以按下面顺序使用：

用 MCP 创建
```
10
```
10
任务
用 MCP 保存源端、目标端和目标表配置
回到页面确认来源目标配置和字段映射
从 IDE 直接运行任务
在底部区域查看运行结果、读写记录和脏数据情况
如有需要，再进入实例运维页继续看实例详情、执行日志和操作日志

这种分工通常更清晰：

MCP 负责结构化创建和配置
页面负责映射确认、运行反馈和实例观察

什么时候优先回到页面

对普通数据集成任务，以下场景通常更适合回到页面：

需要检查字段映射是否符合预期时
需要确认写入模式时
需要检查读取记录、写入记录和脏数据情况时
需要从 IDE 跳到实例运维页继续排查时

这类信息本身就更偏执行观察面，而不是单次结构化写入动作。