
作者 | 张鑫

## 背景：从一个问题开始
每个数据工程师都经历过这样的场景：业务方说"帮我把 MySQL 的用户表同步到 S3"——你心里知道这件事本质上就是从 A 搬到 B。但接下来你要查文档、学参数、写 HOCON、调试报错，一个"简单"的需求花了两小时。

SeaTunnel 拥有 100+ connectors，覆盖了几乎所有主流数据源。但每个 connector 有 20-50 个配置参数，这些参数有必填/可选/条件依赖/枚举约束等复杂规则。这个参数空间的复杂度，恰恰是用户上手最大的门槛。

我们想解决的问题很直接：能不能用一句话就生成一个可以直接运行的 Pipeline 配置？

```
$ seatunnel "同步 MySQL users 表到 S3，Parquet 格式"

✅ 配置已生成，验证通过。保存到 mysql_users_to_s3.conf
```
![](https://developer.qcloudimg.com/http-save/yehe-11851421/cfee4c9295b9850b0a02eabc2662ff12.jpg)

![](https://developer.qcloudimg.com/http-save/yehe-11851421/a422de7cc46da4fef1ee20943e3d20a3.jpg)

这就是 SeaTunnel AI CLI 在做的事。这篇文章将介绍我们在设计和实现这个功能时，真正面对的几个核心问题和思考。


## 设计思路：围绕"准确"展开的所有决策
AI 生成配置这件事，核心挑战只有一个字——**准**。

配置文件不像自然语言文本，有一点模糊也能被人理解。一个 Pipeline 配置要么 100% 能跑，要么就是报错。字段名写错一个字母、必填项漏一个、类型给错一个——全部是致命错误。

我们所有的架构决策，都是围绕"如何让生成结果从第一次就是准确的"这个目标展开的。

### 1. 参数知识的准确：为什么必须用 Runtime 反射
LLM 生成配置的质量完全取决于它对 connector 参数的理解。如果你告诉 LLM "Jdbc Source 需要 `connection_url` 字段"，它就会老老实实生成 `connection_url`——但 SeaTunnel 实际需要的是 `url`。一个字段名的偏差，整个 Pipeline 就跑不起来。

**我们踩过的坑**：第一版用 Python 脚本解析 Java 源码来提取参数定义。结果大面积出错：

![](https://developer.qcloudimg.com/http-save/yehe-11851421/c70d60af8791c905abfb04e1a501a682.jpg)

最终结果：生成的 metadata JSON 准确率只有约 30%。LLM 拿着错误的知识，生成的配置基本跑不起来。

**正确方案：让 JVM 告诉我们真相。**

SeaTunnel 的每个 connector 都实现了 `factory.optionRule()` 方法——这是引擎在运行时真正使用的参数校验规则。我们直接在 Java 层实例化所有 Factory，调用这个 SPI：
```
ServiceLoader 发现所有 Factory
    → 逐个调用 factory.optionRule()
    → 获得完整规则（required / optional / conditional / bundled / exclusive）
    → 序列化为结构化 JSON
```
这样拿到的参数定义和 SeaTunnel 引擎使用的是**同一份数据**。不存在"解析偏差"这回事——因为根本没有解析，是直接读取。

**一个关键的子决策：Source 和 Sink 必须分开存储。**

同一个 connector 名（比如 Jdbc）作为 Source 和 Sink 时参数完全不同——Sink 有 `schema_save_mode`、`data_save_mode`，Source 没有；Source 有 `query`、`partition_column`，Sink 没有。如果合在一起，LLM 会给 Source 生成 Sink 才有的参数，反之亦然。

我们用` (connector_type, connector_name) `作为存储 key：
```
{
  "source:Jdbc": { "required": ["url", "driver"], "optional": ["query", "partition_column", ...] },
  "sink:Jdbc":   { "required": ["url", "driver"], "optional": ["schema_save_mode", "data_save_mode", ...] }
}
```
Planner 识别出"用户需要 Jdbc 作为 Source"后，只注入 `source:Jdbc` 的参数知识给 Config Generator。Sink 的参数对这次生成完全不可见，从根源上消除了混用的可能。

**构建时生成，不提交到 Git：**

这份 JSON 不应该是手动维护的文件。我们在 CI 构建过程中自动执行反射，生成的 JSON 直接打进构建产物。Git 仓库里只有生成工具的代码，没有 JSON 文件。Connector 加了新参数，下次构建自动更新，零人工干预。
### 2. 场景覆盖的准确：Skill + Golden Sample 设计
参数知识准确了，但 LLM 仍然可能生成结构错误的配置——因为 SeaTunnel 的 Pipeline 拓扑不止一种模式。

我们分析了用户实际使用的场景，发现可以归类为三大类，每一类的配置结构完全不同：
#### 场景一：单链路（Single Pipeline）
最简单的场景——一个 Source 到一个 Sink：
```
MySQL ──→ S3
```
配置结构清晰，无歧义：
```
source { Jdbc { ... } }
sink { S3File { ... } }
```
这类场景 LLM 的直觉基本正确，准确率较高。
#### 场景二：单链路 + Transform
中间加了数据处理逻辑：
```
MySQL ──→ SQL Transform (过滤/脱敏/聚合) ──→ S3
```
配置需要正确的 `plugin_output / plugin_input` 路由：
```
source { Jdbc { plugin_output = "raw_data"; ... } }
transform { Sql { plugin_input = "raw_data"; plugin_output = "cleaned"; query = "..." } }
sink { S3File { plugin_input = "cleaned"; ... } }
```
LLM 容易犯的错：忘记写 `plugin_output` / `plugin_input`，或者使用已废弃的 `result_table_name` / `source_table_name`。
#### 场景三：复杂多分支链路（Multi-Pipeline）
多个 Source、多个 Sink、分支路由：
```
MySQL (orders)    ──┐
                    ├──→ Console
MySQL (audit_log) ──┘

MySQL (users) ──────────→ Assert
```
这是 LLM 最容易出错的场景。我们在真实测试中发现了一个典型问题——**LLM 会自己发明 connector 名称**：
```
# ❌ LLM 生成的错误配置
source {
  Jdbc1 { ... }   # "Jdbc1" 不存在！只有 "Jdbc"
  Jdbc2 { ... }   # "Jdbc2" 也不存在！
}
```
LLM 的"直觉"是：两个同类 connector 需要不同的名字来区分。这在很多编程语言里是合理的（变量名不能重复），但 SeaTunnel 的 HOCON 配置允许同名 key 重复出现，通过 plugin_output 来区分：
```
# ✅ 正确写法
source {
  Jdbc {
    plugin_output = "orders_stream"
    query = "SELECT * FROM orders"
    ...
  }
  Jdbc {
    plugin_output = "users_stream"
    query = "SELECT * FROM users"
    ...
  }
}
sink {
  Console { plugin_input = "orders_stream" }
  Assert { plugin_input = "users_stream" }
}
```
#### Skill SOP：场景化的生成指导
为了解决不同场景的结构差异问题，我们引入了 **Skill SOP（Standard Operating Procedure）** 机制——为每类场景定义一套明确的生成规则和约束。

Skill 的核心思想是：**不要指望 LLM 从通用知识中推理出 SeaTunnel 的特定配置规范，而是把规范显式地告诉它。**
```
Skill: "multi_source_same_connector"
触发条件: 检测到用户需要多个同类型 Source

约束规则:
  1. 绝不修改 connector 标识符（永远用 "Jdbc" 而非 "Jdbc1"）
  2. 每个同类型实例必须有不同的 plugin_output
  3. 下游通过 plugin_input 指定消费哪个流
  4. 禁止使用 result_table_name / source_table_name（已废弃）
  
生成模板:
  source {
    ${connector} {
      plugin_output = "${stream_name_1}"
      ...
    }
    ${connector} {
      plugin_output = "${stream_name_2}"
      ...
    }
  }
```
#### Golden Sample：用正确示例锚定 LLM 的输出格式
每个 Skill 配套一组 **Golden Sample**——经过人工验证、确认可以直接在 SeaTunnel 上运行的完整配置示例。

Golden Sample 的作用不是让 LLM 去"模仿"，而是让它理解 **"这类场景正确的输出长什么样"**：
```
Golden Sample: single_jdbc_to_s3.conf
场景: 单表从 MySQL 同步到 S3 Parquet
验证状态: ✅ 在 SeaTunnel 2.3.9 上运行通过

env { job.mode = "BATCH" }
source {
  Jdbc {
    url = "${MYSQL_URL}"
    driver = "com.mysql.cj.jdbc.Driver"
    user = "${MYSQL_USER}"
    password = "${MYSQL_PASSWORD}"
    query = "SELECT * FROM users"
  }
}
sink {
  S3File {
    bucket = "${S3_BUCKET}"
    path = "/data/users/"
    file_format_type = "parquet"
    ...
  }
}
```
```
Golden Sample: multi_jdbc_to_multi_sink.conf
场景: 同一个 MySQL 实例的多张表路由到不同 Sink
验证状态: ✅ 在 SeaTunnel 2.3.9 上运行通过

env { job.mode = "BATCH" }
source {
  Jdbc {
    plugin_output = "orders_data"
    url = "${MYSQL_URL}"
    driver = "com.mysql.cj.jdbc.Driver"
    user = "${MYSQL_USER}"
    password = "${MYSQL_PASSWORD}"
    query = "SELECT * FROM orders"
  }
  Jdbc {
    plugin_output = "users_data"
    url = "${MYSQL_URL}"
    driver = "com.mysql.cj.jdbc.Driver"
    user = "${MYSQL_USER}"
    password = "${MYSQL_PASSWORD}"
    query = "SELECT * FROM users"
  }
}
sink {
  Console { plugin_input = "orders_data" }
  S3File { plugin_input = "users_data"; ... }
}
```
##### Skill + Golden Sample 的组合效果：
![](https://developer.qcloudimg.com/http-save/yehe-11851421/bcfea0c464b402fac14a363e985b1f0a.jpg)

#### 为什么不只用 Golden Sample 而需要 Skill SOP？
Golden Sample 解决的是"正确的输出长什么样"——这是示例层面的。但 LLM 面对的用户请求千变万化，它需要**理解规则背后的逻辑**才能泛化。

Skill SOP 提供的是**可泛化的约束规则**：
- "当有多个同类型 connector 时→ 必须用 plugin_output 区分"
- "当用户提到'实时同步'或'变更捕获'时→ 使用 CDC connector 而非普通 Jdbc"
- "当有 Transform 时→ 整条链路必须有完整的 plugin_output → plugin_input 串联"
Skill = 规则（可泛化）+ Golden Sample = 锚点（确保格式正确）。两者缺一不可。
### 3. 验证闭环的准确：结构化错误反馈 + 自愈
即使有了精确的参数知识和场景化 Skill，LLM 仍然可能出错——这是概率模型的本质特征。我们不追求"一次生成永远正确"，而是设计了一个**确定性验证 + 结构化反馈**的闭环：

```
LLM 生成配置
     ↓
Validator 检查（纯规则，不用 LLM）：
  ├── Connector 名是否存在？     → 拦截 "Jdbc1" 这类幻觉
  ├── 所有 required 字段齐全？   → 拦截遗漏
  ├── Key 是否在合法集合中？     → 拦截拼写错误
  ├── 值类型是否匹配？           → 拦截类型错误
  └── plugin_output/input 链路完整？ → 拦截断链
     ↓
  有错误？
  ├── YES → 结构化错误描述回传 LLM 重新生成
  │         "Missing required 'url' in Jdbc source.
  │          Unknown key 'Jdbc1', did you mean 'Jdbc'?
  │          Use plugin_output for multi-instance routing."
  │         （最多 3 轮）
  │
  └── NO → ✅ 输出可运行配置
```
#### 关键设计：错误信息必须是结构化的、可操作的。
不是给 LLM 一个模糊的 "config invalid"，而是精确告诉它**哪里错了、应该是什么、怎么改**。这让自愈的成功率大幅提升。

实测数据：
- 第 1 轮直接通过：~65%
- 经过 1 轮自愈后通过：+28%（累计 93%）
- 经过 2 轮自愈后通过：+5%（累计 98%）
- 3 轮仍未通过：~2%（通常是极端复杂场景，回退到人工）
#### 4. Multi-Agent 协作：为什么要拆开
把"理解意图""生成配置""验证结果"拆成独立的 Agent，除了前面提到的 Context Window 和角色混淆问题，还有一个更根本的原因——**每个环节的准确性要求和保障手段不同**：

![](https://developer.qcloudimg.com/http-save/yehe-11851421/6191980f9bca2148f76aea8378901702.jpg)

拆开后，确定性的部分（Metadata Loading、Validator）用确定性手段保障；不确定的部分（Planner、Generator）用 LLM + 约束 + 闭环修正保障。不让不确定性在链路中无限制地传播。


## 安全设计：Apache 项目的红线
这个 feature 的安全挑战比一般的 AI 工具更严峻，因为数据集成场景天然充满敏感信息——数据库密码、Cloud Access Key、API Token。
### 1. 威胁模型

```
风险 1: 用户密码通过 LLM Prompt 发送到第三方 API → 密钥泄漏给 LLM 供应商
风险 2: 生成的配置文件包含明文密码 → 被误提交到 Git / 被其他人读取
风险 3: Session Memory 持久化了敏感上下文 → 跨会话 / 跨用户泄漏
```
### 2. 设计原则：Secure by Default
核心原则只有一条——**敏感信息绝不离开用户本地环境**，除非用户显式要求。

具体实现是全链路脱敏：任何匹配 `password|token|secret|api_key|access_key|private_key` 模式的字段值，在所有路径上自动替换为环境变量占位符：
```
用户输入 "password=mySecret123"
    ↓
发送给 LLM 的 Prompt: password = "${JDBC_PASSWORD}"
    ↓
生成的配置文件: password = "${JDBC_PASSWORD}"
    ↓
Session Memory 持久化: password = "${JDBC_PASSWORD}"
```
LLM 从头到尾看不到真实密码。生成的配置文件天然安全，用户通过环境变量在运行时注入真实值。

作为 Apache 顶级项目，这是不可妥协的红线。社区 review 中，安全问题被明确标记为 Blocking——不解决这个问题，功能再好也不会被合并。

## 未来方向讨论
AI CLI 不是孤立存在的。它和社区正在推进的 Dry-Run 验证（PR #10763）形成闭环——AI 生成配置 → dry-run 的 Layer 0-3 做渐进验证 → 结构化错误回传 → AI 自修复。
往前看，AI 配置生成只是起点。我们在思考几个方向：
- AI 理解数据：不只生成连接参数，还能读取源 Schema、自动做类型映射、用自然语言描述 Transform 逻辑
- AI 运维管线：Pipeline 出了问题自动诊断，CDC 源表 DDL 变更自动适应
- AI 优化一切：分析运行瓶颈，建议调优方案，规划最优 Pipeline 拓扑
这些方向目前还在构想阶段。我们公开出来，是希望和社区一起讨论优先级和设计方案。


## 加入我们
**试用与反馈**：用 AI CLI 生成各种场景的配置（MySQL→S3、Kafka→Jdbc、CDC→Hive...），告诉我们哪些场景成功、哪些失败。每一个真实的失败案例都是改进方向。

**Skill 和 Golden Sample 补充**：为更多场景编写 Skill SOP 和经过验证的 Golden Sample。这是提升覆盖度最直接的方式。

**设计讨论**：在 dev@seatunnel.apache.org 或 GitHub Issue 中参与未来方向的技术讨论。好的设计来自多元视角的碰撞。
* GitHub: https://github.com/apache/seatunnel
* PR: https://github.com/apache/seatunnel/pull/10789
* 邮件列表: dev@seatunnel.apache.org

数据集成是每个企业都依赖的基础设施。让它变得更易用、更智能、更安全——这件事值得我们一起做。

每个数据工程师都经历过这样的场景：业务方说"帮我把 MySQL 的用户表同步到 S3"——你心里知道这件事本质上就是从 A 搬到 B。但接下来你要查文档、学参数、写 HOCON、调试报错，一个"简单"的需求花了两小时。

杀疯了！SeaTunnel AI CLI 解锁数据集成新玩法

大数据

人工智能

开发工具

SeaTunnel AI CLI实现用自然语言生成可直接运行的数据同步配置，解决传统方式需查文档、调试参数等耗时问题。通过反射获取准确参数定义、场景化Skill规则和GoldenSample示例确保生成配置100%可运行，支持MySQL、S3等100+数据源，大幅提升数据工程效率。

数据集成

数据库

流数据

路由

GitHub

Python

MySQL

Kafka

Agent

JSON

Hive

Java

2026采购季 | AI焕新·智启新局

bigdata-class

腾讯云数据库特惠，新用户首单0.5折起


datainlong

tencentdb-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

杀疯了！SeaTunnel AI CLI 解锁数据集成新玩法-腾讯云开发者社区-腾讯云

杀疯了！SeaTunnel AI CLI 解锁数据集成新玩法

杀疯了！SeaTunnel AI CLI 解锁数据集成新玩法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐