Studio MCP 操作多表实时同步任务

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

Studio 托管 MCP Server 支持多表实时同步任务中的一组核心结构化操作，包括创建任务、保存同步配置，以及把任务推进到可提交状态。

这类任务和普通 SQL、Shell、Python 任务不同。它不是一次性执行完成的批任务，而是持续运行的流式同步任务，因此配置方式、启动方式和运维入口都不同。

如何向 Agent 提问

在多表实时同步任务场景里，最重要的不是一开始就要求 Agent “直接启动同步”，而是先把源端、目标端、同步对象和当前阶段说清楚。

如果你还没有完全确认要同步哪些对象，或者还不知道当前任务是否已经存在，建议先探索：

帮我看看当前目录里有没有现成的多表实时同步任务可以复用。
帮我看看这个源数据源当前适不适合做多表实时同步。
帮我先看一下这份任务现在已经配置到什么阶段了。

如果源端、目标端和同步对象已经明确，就可以直接执行：

帮我创建一个多表实时同步任务，把这个源数据源同步到目标端。
帮我保存源端、目标端和同步对象配置。
保存以后告诉我这份任务是不是已经进入可提交状态。

如果已经进入提交或运维阶段，也可以直接这样说：

帮我先看一下这个任务当前是待提交、已提交，还是已经运行中。
帮我看看最近的执行日志里，任务现在卡在拉起、部署还是同步阶段。

对这类任务来说，更自然的使用方式通常是：

先探索任务和配置状态
再保存结构化配置
最后回到页面做启动方式选择和持续运维观察

适合用 MCP 处理的部分

在多表实时同步任务里，MCP 更适合承担这些结构化动作：

创建
```
281
```
281
类型的任务对象
保存源端、目标端和同步对象配置
帮用户把任务推进到可提交状态

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

任务类型的基本理解

多表实时同步任务对应的是

task_type=281

task_type=281

。

这类任务的目标不是“跑一遍 SQL”或“按某个 cron 调度一次”，而是：

从源端持续接收变更
按配置把变更同步到目标端
在运维页中长期观察其状态、日志和对象级进展

因此，理解这类任务时，重点不在“如何执行一次”，而在：

如何正确保存同步配置
如何把任务提交并启动
如何在专属运维页里观察运行状态

用 MCP 创建并保存多表实时同步任务

通常会先创建一个

281

任务，再通过 MCP 保存多表实时同步配置。

配置里通常需要明确三类信息：

源数据源
目标数据源
同步对象

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

保存后的页面表现

当

281

任务配置保存成功后，回到 Studio 打开任务，会进入专属配置视图。

页面通常会直接展示这些信息：

源端类型
目标端类型
同步模式
同步对象
表映射
字段查看入口

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

提交不是启动

在

281

任务里，提交和启动是两个不同动作。

提交

提交的作用是把当前编辑态任务推进到可运维状态。
提交之后，任务会从“待提交”进入“已提交”状态。

同时，IDE 顶部会出现

运维

运维

入口。

启动

启动的作用是把这份实时同步任务真正拉起，让它开始进入持续运行状态。
提交之后，下一步通常是进入专属运维页启动任务，而不是按普通批任务的方式再做一次执行。

启动时需要关注的选择

从运维页点击

启动

启动

时，页面不会直接无提示地拉起任务，而是会弹出启动对话框。

启动对话框里，通常需要重点关注这些选项：

启动方式
- 无状态启动
- 从上次保存状态恢复
- 自定义起始位置
是否在增量同步前先做全量数据同步

这些选项会影响任务从哪里开始接收变更，以及是否需要先补一轮全量，因此它的启动语义和普通批任务明显不同。

启动后的状态变化

启动之后，页面状态通常会经历这样的变化：

未运行
启动中
运行中

如果任务刚启动后还没有立刻进入“运行中”，并不代表失败，也可能仍处在资源拉起和作业部署阶段。

专属运维页的信息结构

多表实时同步任务有自己的专属运维页，而不是复用普通任务实例页。

这页通常包含以下几个部分：

```
任务详情
```
任务详情
```
执行日志
```
执行日志
```
操作日志
```
操作日志
```
源端表变更记录
```
源端表变更记录

同时，顶部还会有和当前状态对应的动作，例如：

编辑
启动
停止

执行日志适合看什么

执行日志

执行日志

更适合看任务拉起和运行层面的过程。

启动之后，这里通常会出现启动和部署相关信息：

等待资源或 Pod 创建
任务已经 ready
开始准备作业内容
开始提交作业
在集群上部署作业

如果需要确认任务是否已经真正开始运行，这一页通常比只看顶部状态更直接。

操作日志适合看什么

操作日志

操作日志

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

例如：

提交
启动
停止

这类记录更接近运维审计视角，而不是运行细节视角。

任务详情适合看什么

任务详情

任务详情

更适合看这份任务当前的整体健康度和对象级状态。

页面上通常会提供：

任务基础信息
实例监控
同步对象总数
各对象的同步状态
延迟、速率、Failover、黑名单等指标入口

这部分适合在任务启动后，用来判断：

任务有没有开始真正处理对象
当前是否还只是拉起阶段
对象级状态有没有从“暂未启动”推进到同步中

如何理解源端表变更记录

源端表变更记录

源端表变更记录

不是“任务一启动就一定有内容”的页面。

是否有记录，取决于源库是否真的发生了 CDC 变更事件。
如果源端没有新增、更新或删除等变化，那么这里没有新记录是正常现象，不应据此判断任务配置失败。

更适合的使用顺序

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

用 MCP 创建
```
281
```
281
任务
用 MCP 保存源端、目标端和同步对象配置
回到页面确认映射与配置落点
在页面中提交任务
从专属运维页启动任务
在执行日志、操作日志和任务详情中持续观察状态

这种分工通常更清晰：

MCP 负责结构化创建和保存
页面负责启动控制、监控观察和持续运维

什么时候优先回到页面

对多表实时同步任务，以下场景通常更适合回到页面：

需要检查表映射和字段映射时
需要选择启动方式时
需要观察对象级状态、日志和监控趋势时
需要确认源端变更记录时

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