围绕 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 SeaTunnel1.2 Discussion #10651 真正在问什么Discussion #10651 里提到的问题我理解核心是这一类工程诉求我不想再从 0 开始写 DSL我希望输入“我要做什么 我有什么数据源 我有哪些约束”系统就能生成一份能跑、可审、可迭代的 SeaTunnel 配置并在失败时给出可操作的修复建议。讨论入口[Discussion] Support AI generation for SeaTunnel task config files · Issue #10651 · apache/seatunnel · GitHub1.3 我先说结论我不太关心“AI 能不能直接写一段 HOCON”。这个问题演示起来不难难的是生成结果能不能进入日常使用。我的判断是这件事要走一条更工程化的路先把自然语言变成结构化 IR再渲染成 SeaTunnel HOCON最后补上可机器检查的校验报告。这样做至少有三个直接好处能跑生成结果满足 SeaTunnel 配置结构、连接器必填参数和引擎约束。可审敏感信息变量化关键决策进入 IR默认值和待确认项清晰可见。可迭代校验失败时能回到 IR 或 patch 层做最小修复而不是重新生成整份配置。有了这个判断下面的问题就比较清楚了这条链路到底该怎么搭。2. 真要做这条链路该怎么搭2.1 先别急着让模型直接吐 HOCON直接让模型吐一段 HOCON演示效果通常会不错但工程上不太够。更稳的做法是把配置生成拆成几个明确阶段每个阶段都能检查。一个最小闭环大概是这样意图识别Intent Parsing从自然语言提取任务类型、源/目标、模式批/流、SLA、容错需求。元数据感知Metadata Awareness获取源端 schema、主键/增量位点、目标端约束字段类型、分区、写入模式。连接器推荐Connector Resolution根据“意图 引擎 环境约束”选择连接器组合并确认版本兼容。参数自动补全Auto Fill填充必填项与合理默认值不确定项输出“待确认清单”而不是瞎猜。语法与语义校验Lint Semantic CheckHOCON 语法、连接器参数 schema、变量替换、敏感信息合规失败时生成可执行的修复 patch。模型负责先给方案系统负责兜底和校验。2.2 从结构上看这套方案其实就是两条链路从结构上看这套方案可以拆成两条链路控制链意图→计划和产物链计划→配置→执行。这么拆读起来和实现起来都会更清楚。2.2.1 模块划分Intent Parser自然语言 →IntentSpec结构化 JSONMetadata Provider从 JDBC/Catalog/信息模式拉取 schema 与约束Connector Resolver连接器能力矩阵匹配引擎兼容、是否支持 CDC、是否支持 Exactly-Once 等Plan Builder生成JobPlanIR强类型 IR类似 ASTConfig RendererJobPlanIR→ HOCON/JSON默认 HOCONConfig Linter语法 参数校验 安全策略校验Submitter可选提交作业、查询状态、停止作业、回滚2.2.2 执行流程图文字时序用户输入自然语言 环境约束Intent Parser 输出IntentSpecMetadata Provider 拉取 schema/主键/增量位点/目标约束Connector Resolver 选择 Source/Sink/Transform 组合Plan Builder 输出JobPlanIRConfig Renderer 生成seatunnel.confConfig Linter 输出validation_report通过/失败 修复建议通过后 Submitter 提交失败则基于 report 进入“修复-再校验”循环执行端这块其实不用从零开始。SeaTunnel MCP server 已经演示了 LLM 如何通过工具提交和管理 SeaTunnel 任务做 MVP 时可以直接参考GitHub - apache/seatunnel-tools: SeaTunnel is a multimodal, high-performance, distributed, massive data integration tool. · GitHub2.3 社区里已经有人开始往前走了PR #10789 做了一个独立的seatunnel-cli原型用 Python CLI 把“自然语言 → 配置生成 → 校验 → 执行”串了起来。对我来说它的意义很直接这件事已经不是停留在想法上了社区里已经有人开始把它做成工具。这个 PR 对本文方案有几个很强的印证交互形态不一定要先做 WebCLI REPL 对 MVP 来说反而更顺手。生成链路适合拆成多阶段 Agent而不是单轮直接产出配置PR 中采用的是 Planner → Generator → Validator → Auto-fix。连接器知识库不必完全手工维护PR 展示了“运行时 REST API → 自动生成 catalog → 关键词路由”的三层知识来源。校验不能只做静态 lintPR 已把本地语法检查、引擎--check和 REST API 校验串起来这比“只生成不校验”更接近真实使用场景。如果想让大家真用起来光会生成还不够/check、/run、自动修复、自动保存这些也得一起补上。这个 PR 还顺手提醒了另一件事一旦系统支持会话记忆、连接信息记忆安全约束必须一起跟上。默认脱敏、默认变量化、外部密钥管理这些不能往后放。方向说清楚了再往下就不是“能不能做”而是“先怎么落地”。3. 如果做一个 MVP第一版应该长什么样3.1 输入输出格式先把协议定下来MVP 最怕的是输出一会儿一个样字段今天这么叫、明天那么叫出了问题也没法回放。最省事的办法还是先把 I/O 协议定下来。3.1.1 输入IntentSpecJSON{ 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.confHOCON默认敏感信息必须变量化${...}validation_report.json错误/告警/待确认参数清单/修复建议可生成 patch3.2 提示词不是主角边界才是这里没必要把提示词讲得太玄。重点只有一个把不确定性关进可验证的范围里。MVP 用“三段式 Prompt”就够了3.2.1 Prompt A意图 → 计划只产 IR不产配置目标输出JobPlanIRJSON固定字段、固定枚举、禁止自然语言解释。关键约束明确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
)
