SeaTunnel + AI：一句“我要做什么”，能不能直接变成一份能跑的配置？

围绕 Apache SeaTunnel Discussion #10651 的一些思考：AI 写配置，难的从来不是“写出来”，而是“写出来以后真能用。”

这两年，几乎所有数据工具都会被问到一个问题：配置，能不能别再手写了？

放到 SeaTunnel 里，这个问题会更具体一点：

一句“我要做什么”，能不能直接变成一份配置？

再进一步，这份配置能不能不是“看起来差不多”，而是真的能跑、能审、能改？

手写 SeaTunnel 配置这件事，很多人都不陌生。真正麻烦的，往往不是“把配置写出来”，而是下面这些事：

• 写完能不能跑；
• 出错以后好不好排查；
• 换个人接手能不能看懂；
• 需求一变，能不能低成本改。

AI 当然可以帮忙。但如果目标只是“生成一段 HOCON”，价值其实没那么大。因为真正麻烦的，从来不是把字敲出来，而是写完以后别坑自己，也别坑下一个接手的人。

所以更值得做的，不是“AI 帮我写配置”这件事本身，而是把自然语言里的“我要做什么”，稳定地翻成一份能跑、可审、可迭代的 SeaTunnel 配置。

这篇文章主要想讲三件事：

• 为什么这件事值得做；
• 一条比较稳的实现路径是什么；
• 社区最近的讨论和原型，已经走到了哪一步。

1. AI 写配置这件事，真正的需求在哪里

1.1 手写配置为什么会成为瓶颈

SeaTunnel 的任务配置本质上是一门 DSL（常见为 HOCON，也支持 JSON/SQL），由env / source / transform / sink四段拼成一条可执行的数据管道。它的表达力很强，但也正因为表达力强，配置编写天然带有“工程门槛”。当团队规模、数据源种类、任务数量一起上来后，手写配置几乎一定会稳定地产生四类成本：

• 语法细节密集：嵌套层级、数组/对象结构、字段类型、引号与转义，任何一个点错了都在运行时爆炸。
• 易错且难排：错误往往体现在“任务启动失败”或“运行中失败”，定位时需要同时理解引擎侧约束、连接器参数语义、变量替换规则与默认约定。
• 学习成本高：新人要学 HOCON 写法、SeaTunnel 约定（如plugin_output/plugin_input）、连接器能力边界、以及引擎差异。
• 多源异构适配慢：一旦从“单表同步”升级到“多源 join / 入湖 / CDC / 多表同步”，配置复杂度非线性增长，模板很快失效。

SeaTunnel 官方对配置文件结构与变量替换的说明见：
Intro To Config File | Apache SeaTunnel

1.2 Discussion #10651 真正在问什么

Discussion #10651 里提到的问题，我理解核心是这一类工程诉求：

我不想再从 0 开始写 DSL；我希望输入“我要做什么 + 我有什么数据源 + 我有哪些约束”，系统就能生成一份能跑、可审、可迭代的 SeaTunnel 配置，并在失败时给出可操作的修复建议。

讨论入口：
[Discussion] Support AI generation for SeaTunnel task config files · Issue #10651 · apache/seatunnel · GitHub

1.3 我先说结论

我不太关心“AI 能不能直接写一段 HOCON”。这个问题演示起来不难，难的是生成结果能不能进入日常使用。我的判断是，这件事要走一条更工程化的路：先把自然语言变成结构化 IR，再渲染成 SeaTunnel HOCON，最后补上可机器检查的校验报告。这样做，至少有三个直接好处：

• 能跑：生成结果满足 SeaTunnel 配置结构、连接器必填参数和引擎约束。
• 可审：敏感信息变量化，关键决策进入 IR，默认值和待确认项清晰可见。
• 可迭代：校验失败时能回到 IR 或 patch 层做最小修复，而不是重新生成整份配置。

有了这个判断，下面的问题就比较清楚了：这条链路到底该怎么搭。

2. 真要做，这条链路该怎么搭

2.1 先别急着让模型直接吐 HOCON

直接让模型吐一段 HOCON，演示效果通常会不错，但工程上不太够。更稳的做法，是把配置生成拆成几个明确阶段，每个阶段都能检查。一个最小闭环大概是这样：

1. 意图识别（Intent Parsing）：从自然语言提取任务类型、源/目标、模式（批/流）、SLA、容错需求。
2. 元数据感知（Metadata Awareness）：获取源端 schema、主键/增量位点、目标端约束（字段类型、分区、写入模式）。
3. 连接器推荐（Connector Resolution）：根据“意图 + 引擎 + 环境约束”选择连接器组合，并确认版本兼容。
4. 参数自动补全（Auto Fill）：填充必填项与合理默认值；不确定项输出“待确认清单”，而不是瞎猜。
5. 语法与语义校验（Lint + Semantic Check）：HOCON 语法、连接器参数 schema、变量替换、敏感信息合规；失败时生成可执行的修复 patch。

模型负责先给方案，系统负责兜底和校验。

2.2 从结构上看，这套方案其实就是两条链路

从结构上看，这套方案可以拆成两条链路：控制链（意图→计划）和产物链（计划→配置→执行）。这么拆，读起来和实现起来都会更清楚。

2.2.1 模块划分

• Intent Parser：自然语言 →IntentSpec（结构化 JSON）
• Metadata Provider：从 JDBC/Catalog/信息模式拉取 schema 与约束
• Connector Resolver：连接器能力矩阵匹配（引擎兼容、是否支持 CDC、是否支持 Exactly-Once 等）
• Plan Builder：生成JobPlanIR（强类型 IR，类似 AST）
• Config Renderer：JobPlanIR→ HOCON/JSON（默认 HOCON）
• Config Linter：语法 + 参数校验 + 安全策略校验
• Submitter（可选）：提交作业、查询状态、停止作业、回滚

2.2.2 执行流程图（文字时序）

1. 用户输入自然语言 + 环境约束
2. Intent Parser 输出IntentSpec
3. Metadata Provider 拉取 schema/主键/增量位点/目标约束
4. Connector Resolver 选择 Source/Sink/Transform 组合
5. Plan Builder 输出JobPlanIR
6. Config Renderer 生成seatunnel.conf
7. Config Linter 输出validation_report（通过/失败 + 修复建议）
8. 通过后 Submitter 提交；失败则基于 report 进入“修复-再校验”循环

执行端这块其实不用从零开始。SeaTunnel MCP server 已经演示了 LLM 如何通过工具提交和管理 SeaTunnel 任务，做 MVP 时可以直接参考：
GitHub - apache/seatunnel-tools: SeaTunnel is a multimodal, high-performance, distributed, massive data integration tool. · GitHub

2.3 社区里已经有人开始往前走了

PR #10789 做了一个独立的seatunnel-cli原型，用 Python CLI 把“自然语言 → 配置生成 → 校验 → 执行”串了起来。对我来说，它的意义很直接：这件事已经不是停留在想法上了，社区里已经有人开始把它做成工具。

这个 PR 对本文方案有几个很强的印证：

• 交互形态不一定要先做 Web，CLI + REPL 对 MVP 来说反而更顺手。
• 生成链路适合拆成多阶段 Agent，而不是单轮直接产出配置；PR 中采用的是 Planner → Generator → Validator → Auto-fix。
• 连接器知识库不必完全手工维护；PR 展示了“运行时 REST API → 自动生成 catalog → 关键词路由”的三层知识来源。
• 校验不能只做静态 lint；PR 已把本地语法检查、引擎--check和 REST API 校验串起来，这比“只生成不校验”更接近真实使用场景。
• 如果想让大家真用起来，光会生成还不够，/check、/run、自动修复、自动保存这些也得一起补上。

这个 PR 还顺手提醒了另一件事：一旦系统支持会话记忆、连接信息记忆，安全约束必须一起跟上。默认脱敏、默认变量化、外部密钥管理，这些不能往后放。

方向说清楚了，再往下就不是“能不能做”，而是“先怎么落地”。

3. 如果做一个 MVP，第一版应该长什么样

3.1 输入输出格式：先把协议定下来

MVP 最怕的是输出一会儿一个样，字段今天这么叫、明天那么叫，出了问题也没法回放。最省事的办法，还是先把 I/O 协议定下来。

3.1.1 输入：IntentSpec（JSON）

{ "intent": "把 mysql.shop.orders 全量同步到 Doris ods.orders，每天跑一次", "engine": "zeta", "mode": "BATCH", "source": { "type": "mysql", "jdbc_url": "${MYSQL_URL}", "username": "${MYSQL_USERNAME}", "password": "${MYSQL_PASSWORD}", "database": "shop", "table": "orders" }, "sink": { "type": "doris", "fenodes": "${DORIS_FENODES}", "username": "${DORIS_USERNAME}", "password": "${DORIS_PASSWORD}", "database": "ods", "table": "orders" }, "constraints": { "parallelism": 4, "no_plaintext_secret": true, "target_ddl_policy": "validate_only" } }

3.1.2 输出：配置 + 校验报告

• seatunnel.conf：HOCON（默认），敏感信息必须变量化${...}
• validation_report.json：错误/告警/待确认参数清单/修复建议（可生成 patch）

3.2 提示词不是主角，边界才是

这里没必要把提示词讲得太玄。重点只有一个：把不确定性关进可验证的范围里。MVP 用“三段式 Prompt”就够了：

3.2.1 Prompt A：意图 → 计划（只产 IR，不产配置）

目标：输出JobPlanIR（JSON），固定字段、固定枚举、禁止自然语言解释。

关键约束：

• 明确job.mode、引擎、source/sink plugin_name
• 确定plugin_output/plugin_input引用关系；旧版result_table_name/source_table_name只作为兼容输入处理
• 不允许出现明文密钥
• 不确定项必须落在todo_items[]

3.2.2 Prompt B：计划 → HOCON 渲染

目标：只输出 HOCON，并严格限制段落为env/source/transform/sink。

关键约束：

• 所有敏感字段必须写${VAR}或${VAR:default}
• 不允许输出不存在的参数名（参数名必须来自规则库）

3.2.3 Prompt C：自检（Lint + Semantic）