Studio MCP 能力总览

Studio 托管 MCP Server 为 AI Agent 提供了一组可直接调用的 Lakehouse 与 Studio 操作能力。它不只支持查询数据和生成 SQL，也支持围绕任务对象、运行状态和复杂数据工程对象开展结构化操作。

从使用范围看，这套能力覆盖以下几层对象：

Lakehouse 元数据与对象浏览
Studio 目录、任务与任务配置
发布、执行、实例、日志与统计
多表实时同步、数据集成、回填、任务依赖
Flow 编排、VCluster、知识检索与部分治理能力

从使用方式上看，这些能力并不都适合同一种提问方式。

更自然的使用方式通常是：

对象还不明确时，先让 Agent 做探索式查询
对象已经明确时，再让 Agent 做结构化执行

例如，目录、任务、数据源、表、最近一次运行状态这类信息，更适合先探索；
而目录、任务、参数值、执行目标已经明确后的创建、保存、执行和发布，则更适合直接执行。

环境与元数据能力

这类能力主要用于确认当前环境和可操作对象：

当前连接到了哪个地域、工作空间、VC 和 Schema
当前环境里有哪些数据源、Schema、表、视图、任务对象

典型用途包括：

查看有哪些数据源可用
查看某个数据源下有哪些 Schema
查看
```
public
```
public
下有哪些表
先盘点环境，再决定后续要操作哪个对象

这类能力通常适合作为 Agent 进入 Studio 工作流的起点。
在还没有确认工作空间、数据源和对象范围之前，先做环境盘点，后续的开发和运维动作会更稳。

这一层能力天然最适合探索式提问，例如：

当前有哪些目录、任务和数据源
哪个目录更适合放新的实验任务
当前有哪些表可以作为后续同步或 SQL 建模的输入

除了工作空间内的数据源、Schema 和表，这一层也覆盖工作空间、命名空间和部分元数据对象，便于先明确“当前可以操作什么”。

Lakehouse 查询与对象浏览能力

除了查看元数据，这套 MCP 也支持直接面向 Lakehouse 的查询与对象浏览。

这部分不仅可以列出对象，还可以：

执行 Lakehouse 查询
浏览 Schema 级对象
浏览 Workspace 级对象
查看函数、动态表、外部表、物化视图、VCluster 等对象
查看对象级明细信息

因此，Agent 既可以从 Studio 任务系统切入，也可以先从 Lakehouse 对象切入，再把两边连接起来。

Studio 目录与任务开发能力

这类能力用于让 Agent 直接参与任务开发。

它覆盖的典型动作包括：

创建目录
创建任务
读取任务详情
保存任务内容
读取和保存任务配置

对于日常开发，这意味着 Agent 不只是在对话里生成一段内容，还可以进一步把内容落到真实任务对象中，例如：

在合适的目录下创建一个新任务
把 SQL、Shell、Python 或 JDBC 内容写入任务
再把执行参数、重试策略、超时等配置补进去

这条链路适合用于把“生成内容”和“保存到 Studio 任务对象”衔接起来，减少在对话结果和页面对象之间来回搬运。

这类能力通常更适合在目录、任务对象已经明确之后直接执行。

调度与任务配置能力

这类能力用于把任务从“已有内容”推进到“具备运行约束和调度语义”。

它覆盖的不只是 cron，还包括：

重试策略
超时策略
依赖关系
执行 VC / Schema
调度时间预览
已发布任务调度信息读取
非 cron 执行配置

对普通批任务来说，这部分决定了任务是否具备上线所需的基础条件。
它对应的重点不再是内容本身，而是调度、依赖、执行环境和运行策略。

如果用户还不知道当前任务缺的是参数、非 cron 配置还是调度本身，这一层通常也适合先探索，再执行。

发布与执行能力

这类能力用于把一个已经存在的任务推进到可运行状态，并发起实际执行。

这里有两个需要明确区分的动作：

发布

发布意味着把任务交给调度体系管理。
它解决的是“这个任务是否已经上线、是否进入正式调度对象集合”的问题。

执行

执行意味着立即跑一次。
它解决的是“这段内容现在能不能跑通、运行结果和运行状态是什么”的问题。

这两个动作对应的目的并不相同：

发布更偏生产管理
执行更偏验证、调试和诊断

如果把这两个动作混在一起理解，用户很容易误以为“发布就是跑一遍”或者“执行一次就等于已经上线”。

因此，这一层能力更适合在对象和目标动作已经明确时直接执行；
如果用户还不确定现在是否适合发布，先让 Agent 判断当前状态通常更稳。

运行诊断能力

这组能力主要用于任务运行后的快速诊断与排查。

一旦任务已经运行，Agent 就不必只停留在“执行成功/失败”这一层，而是可以继续往下追：

任务实例详情
attempt 列表
attempt 日志
任务级运行统计
任务运行依赖关系
单次运行关联信息

它适合把诊断过程串起来，例如：

先确认任务实例是否真的创建成功
再确认这次运行有几次 attempt
再读取具体日志，看到实际执行内容、执行耗时和底层 job 标识

这组能力尤其适合：

任务执行后的一次快速自检
定位失败点
在回到页面前先缩小排查范围

这类能力通常天然适合探索式提问，因为用户第一次进入排查场景时，往往并不知道该从哪个实例或哪条日志开始看。

统计、依赖与补数据能力

除了逐个查看任务和实例，这套 MCP 也提供了偏管理视角的工具，用来回答“当前整体运行情况如何”。

这部分能力通常包括：

任务统计
任务运行统计
已发布任务依赖关系
任务运行依赖关系
补数据任务与补数据实例
带下游影响范围的补数据创建

因此，Agent 不只适合做单点操作，也适合先做整体盘点，再进入具体排查。

数据集成与实时同步能力

数据集成与实时同步，是这套能力里很重要的一层对象。

Studio 托管 MCP Server 不只支持普通代码型任务，也覆盖数据集成与实时同步任务，包括：

普通数据集成任务
多表实时同步任务
持续运行的 CDC 任务配置
集成任务配置保存

它们与普通批任务的差异在于：

配置结构更复杂
更依赖源端、目标端和映射关系
运行方式不是“一次执行完成”，而可能是持续运行

这部分能力对应的，不只是“多一种任务类型”，而是更接近真实的数据工程工作流。

尤其是多表实时同步这类对象，重点已经不再是“把代码写进去”，而是围绕源端、目标端、同步对象、启动方式和持续运行状态来组织操作。

Flow、组合任务与更复杂编排能力

Studio 托管 MCP Server 还覆盖了组合任务相关能力，例如：

查看 Flow DAG
创建和管理节点
绑定和解绑节点依赖
查看节点详情
保存节点内容和节点配置
提交 Flow
查看 Flow 节点运行情况

它不只支持单任务对象，也覆盖更复杂的任务编排场景。

不过，Flow 这类对象天然更依赖页面语义和节点上下文，通常更适合作为进阶能力引入，而不是第一次接入 MCP 就直接上手的入口。

数据质量与治理辅助能力

这套 MCP 也覆盖了一部分数据质量与治理辅助能力。

这部分通常包括：

数据质量规则创建
VCluster 列表与创建
任务和运行侧的结构化观察
通过日志、统计和依赖关系支持治理与排障

它不等同于完整治理系统，但可以作为治理流程中的一个可调用操作面。

知识、技能与产品知识能力

这部分能力容易被忽略，但对 Agent 的连续工作体验很重要。

Studio 托管 MCP Server 并不只是操作工具集合，它还把一部分知识能力接进来了，包括：

技能检索
技能文档读取
产品知识查询
手工知识写入与检索
分析记忆检索

有了这部分能力，Agent 在操作之前可以先结合平台内的技能、知识和记忆，再执行更贴近产品语义的动作。

扩展对象能力

除了通用的目录、任务、执行和日志能力，Studio 托管 MCP Server 还提供了不少面向复杂对象的工具，例如：

语义视图
动态表
外部表
物化视图
VCluster
连接与部分运行环境对象
回填任务对象

它不只面向简单 SQL 任务，也覆盖更广泛的 Studio 对象。

不过，从使用上讲，这些扩展对象通常比普通 SQL 任务更复杂，也更依赖上下文。因此更适合在掌握了基础链路之后，再逐步引入到日常使用中。

怎么理解“能力总览”

阅读这份总览时，重点可以放在三个判断上：

哪些对象已经可以交给 Agent 做结构化操作
哪些对象虽然已经开放工具，但更适合和页面配合使用
哪些能力值得先进入日常工作流，哪些更适合作为进阶能力逐步引入

如果目标是尽快把这套能力用起来，通常可以先从目录、任务、发布、执行、日志和统计开始；如果目标是把 Agent 引入更复杂的数据工程对象，再继续扩展到数据集成、CDC、回填和 Flow。

MCP 的能力边界

从使用方式上看，这套 MCP 更适合承担结构化操作。

更适合交给 MCP 的

结构化查询
结构化创建和修改
把任务对象的开发、配置、发布、执行、诊断串成可调用链路
让 Agent 先做一次有依据的操作，再由人复核
先盘点环境、对象和状态，再缩小人工处理范围

更适合回到页面的

需要大量视觉判断的复杂页面配置
需要图形化拖拽确认的复杂流程设计
纯粹依赖人工视觉扫描的大段信息浏览

更常见的配合方式是：

先用 MCP 快速做结构化动作
再回到页面做视觉确认和最终调整

建议如何开始使用

建议按下面顺序逐步推进：

先让 Agent 做环境盘点和元数据盘点
再让 Agent 参与目录、任务和内容层的开发
再让 Agent 参与调度配置、发布、执行和日志排查
再逐步扩展到数据集成、CDC、Flow、补数据、数据质量等更复杂对象

这样既能把收益尽快用起来，也能避免一开始就把复杂对象全部交给 Agent，导致使用预期失真。