

## 一、先说结论

我们有一套数仓，需要用 FineDataLink（下称 FDL）把 DWD 层的表批量搬到 ADS 层，一共 **93 张表**，每张表一个「脚本 → SQL脚本」节点，每个节点里是一段 `INSERT ... SELECT ... WHERE NOT EXISTS`。
以前的做法是：打开 FDL 设计器 → 新建节点 → 从 Excel 里抄表名 → 拼 SQL → 改字段名 → 存 → 下一个。熟练工一张表也要 2～3 分钟，93 张就是 **4 个多小时**，而且抄错一个字段名要等运行时才炸。
接入 WorkBuddy 的 FDL MCP 之后，整条链路变成：**把 Excel 清单丢给 WorkBuddy，说一句「生成新定时任务」，剩下的它自己跑完**。

| | | |
|:-:|:-:|:-:|
|指标|手工|WorkBuddy + FDL MCP|
|93 个节点创建|≈ 4.5 小时|**约 4 分钟**|
|字段注释对齐|逐个手抄，易漏|自动从 Oracle 数据字典拉取|
|SQL 语法错误|运行时才发现|写入前 93/93 Oracle 解析预校验|
|节点备注|基本不写|93/93 自动回写|
|可重复性|换一批清单重来一遍|换一份 Excel 重跑脚本|
后来同一套方法还顺手做了另一件事：往一个已存在的空任务里**批量追加 27 个「数据同步」节点并串行连线**，全程 3 分钟。
## 二、为什么要在 WorkBuddy 里接 MCP

WorkBuddy 的 MCP（Model Context Protocol）连接器机制，本质是**把外部系统的能力注册成 Agent 可以调用的工具**。接入 FDL 之后，FDL 的画布、节点、注释、调度这些原本只能点界面的操作，全部变成了可编程的 tool call。
配置很简单，在 `~/.workbuddy/mcp.json` 里加一段（**注意是 `mcp.json`，不是带点的 `.mcp.json`**）：
```

```FDL 侧的 Token 在「管理系统 → 开放平台 / MCP 服务」里生成，**权限至少要勾 `task:read` + `task:write`**，只读权限会在写入节点那一步报错。
配好之后回到 WorkBuddy 的工具连接器页面，找到 `fdl` 点一次「信任」——**新加的 MCP 不会自动生效，必须手动信任这一步**，这是第一个坑。
### 验证是否通了

在 WorkBuddy 里直接问一句「fdl mcp 现在正常？」。它会去调 `find_offline_task_resources` 之类的只读工具探活。如果工具索引里搜不到任何 `mcp__fdl__*`，八成是连接器被禁用了，回去看 `mcp.json` 里有没有被自动加上 `"disabled": true`。
## 三、整体流水线

关键设计思路：**不要把所有 SQL 塞进对话里让模型搬运**。
93 条 SQL，光是把它们作为工具参数序列化就要烧掉几万 token，而且极易手误。正确姿势是**让 WorkBuddy 写一套本地 Python 脚本，脚本直连 MCP 的 HTTP 端点批量跑**，WorkBuddy 只负责编排、校验、决定何时写库。
```

![fig1_pipeline.png](https://developer.qcloudimg.com/http-save/yehe-12769217/14763239ae4fc684512d5812bcb966d7.png)

对应到 `fdl-mcp-tasks` 技能里的脚本，一共 8 个文件，全部可以改开头几个常量直接复用：

| | |
|:-:|:-:|
|文件|作用|
|`dump_xlsx.py`|xlsx → UTF-8 文本，用来读清单和「填写说明」sheet|
|`build_pairs.py`|解析任务清单 sheet → `pairs.json`|
|`fetch_meta.py`|批量取元数据 → `meta.json`|
|`gen_sql.py`|生成 `INSERT ... SELECT` → `nodes.json`|
|`validate_sql.py`|Oracle 解析预校验|
|`write_nodes.py`|写入 / 回读 / 回写备注|
|`export_html.py` + `template.html`|生成自包含可打印 HTML 快照|
## 四、分步拆解（含关键 SQL）

### ① 拿元数据：一条 SQL 查三样东西

不要一张表查一次，把 16 对表合并成一条 `UNION ALL`：
```

```一次拿三样：**源表字段列表 / 目标表「字段=>注释」/ 目标表注释**。每批 16 对表，`limit=20, maxCellCharacters=4000, timeoutSeconds=240`。
>这条 SQL 的形态是被 FDL 的 SQL 校验器逼出来的：QUERY 模式**不接受** `WITH ... AS (...)`，也**不接受**派生表 `FROM (SELECT ... UNION ALL ...) P`，会报 `ReadOnlySqlValidator$ReadOnlyQueryVisitor cannot be cast to ...OracleASTVisitor`。只认 `SELECT 常量,(标量子查询)... FROM DUAL UNION ALL ...` 这种形态。

### ② 生成 SQL：按目标表列序走，一个字段都不许漏

核心规范：
```

```生成时**严格按目标表的列顺序遍历**，四种情况：
1. 列在源表里 → `S.<同名列>`

1. 命中改名映射 → `S.<源列名>`（映射字典必须人工维护，元数据推断不出来）

1. 是常量列 → 直接写字面量

1. 都没有 → **跳过**，并在脚本末尾追加一行 `-- 注：目标表独有字段（源表无对应列，本次不写入）：A、B、C`，让用户一眼看到缺口

**增量语义靠 `WHERE NOT EXISTS` 兜住**——重复跑不会产生重复数据，这个模式非常适合挂每日定时。
### ③ 写入前先让 Oracle 校验一遍

这一步是整个流程里性价比最高的：把每条 SQL 的 SELECT 主体（去掉 `INSERT INTO ...(...)` 和尾注）丢回 `preview_data`，`limit=1`，让 Oracle **真解析一次**。
实测 **1 秒/条**，93 条全部通过只花了约 8 秒。但就是这 8 秒，能提前拦下表名写错、字段不存在、函数用错、括号不配对这类问题——比等任务跑起来再炸要省太多事。
### ④ 分批写库：每批写入前必须重取指纹

这是最容易踩的一个坑：
>**FDL 的 `contextFingerprint` 在每次写入后都会变**。上一批写完后 fp 已经失效，下一批如果沿用旧的 fp，会直接报错。

所以每批（15 个节点）的循环体是：
```

```93 个节点 = 7 批 × 15（最后一批 3 个），全部写完耗时约 7 秒。
### ⑤ 回写备注 + 回读核对

用 `get_task_annotation_targets` 拿到每个 `COMPONENT_NOTE` 的 `targetId`，`update_task_annotations` 批量提交。93 条一次提交即可。
最后一定要 `get_task_canvas` **回读**一遍，比对节点名单（缺失、多余各列一遍）和备注内容——生成脚本里的数据是「我以为写进去的」，只有回读出来的才是「真实落库的」。
## 五、踩坑清单（这部分最值钱）


| | | | |
|:-:|:-:|:-:|:-:|
|#|坑|现象|解法|
|1|新加的 MCP 不生效|工具索引里搜不到 `mcp__fdl__*`|必须在连接器页面手动点「信任」；另外配置文件是 `mcp.json` 不是 `.mcp.json`|
|2|漏传 `workId`|`workId or exact workName is required`|`workId` 和 `contextFingerprint` 都是必传|
|3|指纹失效|第二批写入直接报错|**每次写入后重新 `get_task_canvas` 取 fp**，不要复用|
|4|`confirmationToken` 拿不到|脚本报「预览未返回 token」|token 是**嵌套**的：优先取 `r["confirmation"]["confirmationToken"]`，再回退顶层 `r["confirmationToken"]`，最后正则兜底|
|5|误判失败|脚本判断「返回文本里有 error 字样」就中断整批|JSON 里 `"error": null` 会被误判。成功判据应该是 `success === true` 且 `len(createdNodes) === 提交数`|
|6|SQL 脚本节点传错字段|`nodes[0] must not contain procedure fields when configType=SQL`|`schema` / `database` 只能用于 PROCEDURE 模式，SQL 模式别传|
|7|预览数据取不到|`AttributeError: 'list' object has no attribute 'get'`|`preview_data` 返回的是 `{columns:[...], rows:[[...]]}`，**列是表头、行是数组**，要自己 `zip` 拼 dict|
|8|Excel 序号是字符串|`TypeError: %d format: a real number is required, not str`|用 `%s`，或直接 `enumerate` 生成 `clientRef`|
|9|WPS 保存的 xlsx 读不了|openpyxl 抛 `TypeError: Fill() takes no arguments`|改用 `zipfile` + `xml.etree.ElementTree` 直接解析 `sharedStrings.xml` 和 `sheet*.xml`|
|10|连线一次最多 50 条|提交更多会被拒|分批提交；N 个节点串行是 N-1 条连线|
|11|连线后画布被「重排」|节点突然排成一横排|服务端 `ENDPOINT_LAYOUT` 机制，**预期行为**，不影响执行顺序|
还有一条经验：**清单里的「任务清单」sheet 和「填写说明」sheet 可能不一致**（比如说明里写 `DB_USAGE=1`，实际 98 行填的都是 2）。以实际填写的为准，并且把差异抛给用户确认，不要自己选一个。
## 六. 第二个场景：往已有任务批量追加「数据同步」节点

同样是 Excel 驱动，但节点类型换成了 **「通用 → 数据同步」(`DATA_SYNC`)**，MySQL 源库 → Oracle 目标库，27 张表全量采集。
流程和上面基本一致，差异点：
- **任务已存在但是空画布**，所以是「往已有任务里加节点」，不是 `batch_create_db_sync_tasks` 建新任务。**先 `find_offline_task_resources` 查重名，别急着新建**。

- 节点配置在顶层：`toTableMode:1`（自动建表）、`writeMode:1`（清空目标表再写入，全量采集常用）。`writeMode=5` 是追加。

- `nodes[]` 每项必须有 `clientRef`（`n01`、`n02`…），返回体用它映射 `nodeId`，后面连线要用。

- **目标表还不存在时取不到目标表注释，改用源表注释**。MySQL 这边查：```
	```

- **数据同步节点只返回 `COMPONENT_NOTE`，不返回 `OPERATOR_NOTE`**，别去找 operator target。

- 连线用 `manage_task_node_connections`，`changes[]` 每项 `{operation:"ADD", fromNodeName, toNodeName, condition:"ON_SUCCESS"}`，用**节点名**比 nodeId 可读性好得多。

## 七、安全边界：两步确认制不要绕

FDL MCP 所有写入类工具都是**两步确认制**：先不带 `confirm` 调一次拿执行计划，展示给用户看，用户确认后才带 `confirmationToken` 真正执行。
这在实际协作里很有用——**用户能在写库前看到完整计划**（要建哪些节点、连到哪个库、用什么写入模式），而不是等出事了才知道。
我在流程里保持了这条：93 个节点的计划先出预览页，27 个同步节点的计划先列清单，用户回「确认」才动手。`execute_offline_task`（会真实写数据）更是必须拿到明确同意才执行。
![fig2_confirm.png](https://developer.qcloudimg.com/http-save/yehe-12769217/3c3a441e0d4a71a040fd4185f09b7284.png)

## 八、效果

跑完之后，服务端回读核对的结果：
![fig3_benchmark.png](https://developer.qcloudimg.com/http-save/yehe-12769217/4413d141c380451a92d4324a72d39cba.png)

**场景一：93 个 SQL 脚本节点**

| | |
|:-:|:-:|
|步骤|结果|
|Oracle 语法校验|93/93 通过|
|节点写入|7 批 × 15 = 93/93|
|备注回写|93/93 UPDATED，0 缺失|
|画布回读|93/93 一致|
**场景二：27 个数据同步节点**

| | |
|:-:|:-:|
|步骤|结果|
|节点写入|27/27 `DATA_SYNC` / `ENABLED`|
|备注写入|22/22（5 张源表本身没维护注释，留空）|
|串行连线|26/26 `ON_SUCCESS`|
|画布回读|27 节点 + 26 连线，顺序与清单吻合|
最后 WorkBuddy 还会自动生成一份**可打印的 HTML 快照页**：全量 SQL 默认展开、每段配一个「复制」按钮、`@media print` 里 `pre` 改成 `pre-wrap`。直接「打印 → 另存为 PDF」就是归档文档。
## 九、一点心得

1. **让 Agent 写脚本，别让 Agent 搬数据。** 上百条 SQL 走对话搬运是 token 黑洞，走本地脚本是几秒钟的事。WorkBuddy 的价值在于「会写脚本 + 会校验 + 会编排」，而不是「当个 API 转发器」。

1. **回读才是真相。** 生成脚本里的数据结构是「我以为的」，`get_task_canvas` / `get_task_annotation_targets` 回读出来的才是「实际的」。每一步写完都回读，问题当场暴露。

1. **把坑沉淀成技能。** 这套流程走完两遍之后，我把它整理成了一个 WorkBuddy 技能（SKILL.md + 8 个可复用脚本）。下次换一份清单，只要改开头几个常量，流程一遍跑通。

1. **写入类操作一定要保留确认环节。** 自动化不等于无人值守，尤其是会真实落库、真实写数据的那几步。


----
本文涉及的 FDL 操作通过 WorkBuddy 的 MCP 连接器完成，工具链为 `mcp__fdl__*` 系列。脚本模板已整理为可复用技能，改常量即可换批次。


----
**标签**：#WorkBuddy# #实操教程# #MCP# #数据集成# #踩坑记录#

我们有一套数仓，需要用 FineDataLink（下称 FDL）把 DWD 层的表批量搬到 ADS 层，一共 93 张表，每张表一个「脚本 → SQL脚本」节点，每个节点里是一段 INSERT ... SELECT ... WHERE NOT EXISTS。以前的做法是：打开 FDL 设计器 → 新建节点 → 从 Excel 里抄表名 → 拼 SQL → 改字段名 → 存 → 下一个。熟练工一张表也要 2～3 分钟，93 张就是 4 个多小时，而且抄错一个字段名要等运行时才炸。接入 WorkBuddy 的 FDL MCP 之后，整条链路变成：把 Excel 清单丢给 WorkBuddy，说一句「生成新定时任务」，剩下的它自己跑完。

用 WorkBuddy 打通 FDL MCP：把上百个 ETL 任务节点的创建从 4 小时压到 4 分钟 #WorkBuddy#

我们有一套数仓，需要用 FineDataLink（下称 FDL）把 DWD 层的表批量搬到 ADS 层，一共 93 张表，每张表一个「脚本 → SQL脚本」节点，每个节点里是一段 INSERT ... SELECT ... WHERE NOT EXISTS。以前的做法是：打开 FDL 设计器 → 新建节点 → 从 Excel 里抄表名 → 拼 SQL → 改字段名 → 存 → 下一个。熟练工一张表

开发工具

后端

利用WorkBuddy的FDL MCP连接器，将93张DWD表批量迁移至ADS层，耗时从4.5小时降至4分钟。通过本地Python脚本调用MCP HTTP端点，自动生成SQL、Oracle预校验、分批写入并回写备注，实现字段注释自动对齐、SQL语法零错误。该方法支持换清单重跑，并可扩展至27个数据同步节点的批量追加场景。

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

利用WorkBuddy的FDL MCP连接器，将93张DWD表批量迁移至ADS层，耗时从4.5小时降至4分钟。通过本地Python脚本调用MCP HTTP端点，自动生成SQL、Oracle预校验、分批写入并回写备注，实现字段注释自动对齐、SQL语法零错误。该方法支持换清单重跑，并可扩展至27个数据同步节点的批量追加场景...

用 WorkBuddy 打通 FDL MCP：把上百个 ETL 任务节点的创建从 4 小时压到 4 分钟 #WorkBuddy#-腾讯云开发者社区-腾讯云

用 WorkBuddy 打通 FDL MCP：把上百个 ETL 任务节点的创建从 4 小时压到 4 分钟 #WorkBuddy#

用 WorkBuddy 打通 FDL MCP：把上百个 ETL 任务节点的创建从 4 小时压到 4 分钟 #WorkBuddy#

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐