作者 | 张鑫，Apache SeaTunnel Contributor
摘要：
大模型正在快速进入数据工程领域，承担理解自然语言需求、生成 ETL 任务配置、校验配置，以及在执行失败后协助定位和修复问题等工作。对团队而言，真正困难的并不是让模型"生成一份配置"，而是避免选到一个只会生成看似正确、却无法在生产环境中稳定运行的模型。
对 ETL 来说，配置能够生成、甚至通过静态校验，都不等价于数据管道能够连接真实数据源、满足 CDC 等运行前置条件，并完成端到端的数据同步。若仅依据通用榜单或一次生成结果做选型，团队可能把后续的失败重试、人工排障与不可控成本带入生产环境。
本文以 Apache SeaTunnel AI CLI 项目为基础，对主流的 7 个模型完成 100 个 ETL 任务的分层评测：不仅衡量配置生成和静态校验结果，也在真实数据环境中验证执行。实验显示，模型在静态校验阶段的表现不能直接预测其真实执行成功率。
本文的目标不是给出一份通用模型排行榜，而是提供一套面向 AI 辅助 ETL 的评测与选型方法：团队应结合自身任务复杂度、运行时成功率、错误修复能力和总体成本，持续选择并验证最适合自身数据环境的模型组合。
背景：Apache SeaTunnel AI CLI 项目与准确性评估
Apache SeaTunnel 是 Apache 软件基金会的顶级数据集成项目，提供面向批处理、流处理和 CDC 场景的数据集成能力，并形成了覆盖 JDBC、Kafka、S3、Hive、各类数据库与消息系统的 100+ connector 生态。生态的丰富性带来了广泛的适用范围，也带来了显著的使用复杂度：单个 connector 往往涉及 20--50 个配置参数，用户还需要理解参数类型、必填约束、参数组合、运行模式和上下游系统的前置条件；配置文件采用 HOCON 格式，进一步提高了初学者在复杂场景下的上手门槛。
社区中反复出现的一类问题可以概括为：
我知道 SeaTunnel 可以完成数据集成，但看了很多文档，配置文件还是反复写不对。
SeaTunnel AI CLI 因此而生。它的目标不是简单地为用户生成一段配置文本，而是让用户能够以自然语言表达数据集成需求，例如"将 MySQL 中的订单表通过 CDC 同步到 StarRocks，并按照时间字段进行分区"；随后由 AI CLI 结合 SeaTunnel 的 connector 知识、配置规则和运行反馈，生成、验证并迭代修复对应的数据管道配置。
从用户体验角度看，我们希望将配置创建过程从"查阅文档、拼装参数、反复试错、阅读日志、人工修复"转变为"描述需求、生成配置、验证执行、根据反馈修复"。理想目标并不是让 AI 生成一份"看起来合理"的 HOCON 文件，而是尽可能让用户首次获得一份可运行、可验证、可维护的 SeaTunnel 配置。但这远不止于"接入一个 LLM API"。要让 AI CLI 在生产级 ETL 场景中有效工作，模型需要理解 100+ connector 的参数语义、数据类型约束、参数依赖关系、CDC 前置条件和复杂 DAG 的组合逻辑；同时，系统还需要能够把 SeaTunnel 的 Java connector 实现、OptionRule、配置校验结果与运行时错误，转化为模型可理解且可行动的上下文。任何一处参数幻觉、隐含条件遗漏或错误修复方向偏差，都可能让生成结果在真实环境中失败。
这类工作具有高复杂度和多维度交叉的特征：它既要理解已有 Java connector 的实现机制，又要在 Python CLI 中构建稳定的 Agent 流程；既要利用模型生成能力，又不能把 connector 正确性建立在模型"猜对"的基础上；既要快速迭代，又必须通过真实数据环境验证每一次改动。
这也决定了 AI CLI 的核心质量指标不应是"配置是否生成"或"静态校验是否通过"，而应是准确性 ：模型生成的配置能否在给定数据源、目标端和运行条件下完成真实的数据集成任务。 为此，本文后续将以从静态配置、CLI 校验到真实执行的三层验证框架，对不同模型在 SeaTunnel AI CLI 场景中的表现进行评估，并据此讨论面向生产 ETL 的模型选型与工程改进方向。
评测设计：从静态校验到真实执行的三层验证
传统的配置生成评测往往停留在语法正确性、文本相似度或人工抽查层面。但对于 SeaTunnel 这类面向真实数据集成的平台，配置文件是否"看起来正确"，并不能直接说明数据管道能够在目标环境中成功运行。
因此，本次评测没有将"生成一份 HOCON 配置"作为终点，而是将模型输出放入一个逐层收紧的验证流程中：先检查配置的基础结构，再检查 SeaTunnel CLI 和 connector 规则，最后在 Docker 化的真实数据环境中启动并验证完整任务。我们将这三个层次分别定义为 L1 静态验证、L2 CLI 验证和 L3 真实执行验证。
任务集与覆盖范围
本次 benchmark 共包含 100 个 SeaTunnel ETL 任务，并按任务复杂度分为三个层级：
任务覆盖了 batch ETL、CDC、格式处理、字段映射、转换逻辑和复杂 DAG 等场景；真实执行环境涉及 MySQL、PostgreSQL、Kafka、ClickHouse、Elasticsearch、MinIO、Doris、StarRocks 等组件。每个任务由自然语言需求描述、预期的数据流向、运行环境以及成功判定条件组成。整体测试流程如图：
L1：静态配置验证
L1 验证关注模型是否能够根据自然语言需求，生成一份结构上合法的 SeaTunnel 配置。该层主要检查：
- HOCON 语法是否可解析；
env、source、transform、sink等基础结构是否完整；- connector 名称、必填字段和字段类型是否符合基本要求；
- 配置是否能够通过基础的静态规则检查。
L1 回答的问题是：
模型能否生成一份"看起来正确"的 SeaTunnel 配置？
这一层速度快，适合用于大规模初筛和日常回归检查。但它的局限也很明显：HOCON 能够被解析、基础字段存在，并不代表 connector 参数组合正确，更不代表外部系统连接、CDC 前置条件或数据读写行为能够成功。
L2：CLI 与规则验证
L2 在静态配置的基础上，引入 SeaTunnel CLI 的 dry-run 或 --check 验证，并结合 connector 的 OptionRule、参数约束和 DAG 结构规则进行进一步检查。
与 L1 相比，L2 更关注配置是否符合 SeaTunnel 运行前可验证的规则，例如：
- connector 参数是否完整，是否存在不合法的组合；
- source、transform 与 sink 的配置关系是否满足要求；
- DAG 结构和运行模式是否合理；
- 部分 CDC、format、schema 或 checkpoint 配置是否满足已知约束。
L2 回答的问题是：
这份配置除了语法正确外，是否符合 SeaTunnel 和 connector 已知的运行规则？
这一层可以发现大量"文本上合理、规则上错误"的配置。例如，模型可能生成一个正确的 MySQL source 和 StarRocks sink，但遗漏某个 connector 的必要参数，或为 CDC 场景使用不兼容的参数组合。尽管如此，L2 仍然无法完全替代真实运行，因为很多问题只有在连接外部服务、读取真实数据或执行任务拓扑时才会暴露。
L3：Docker 化真实执行验证
L3 是本次评测的核心。对于通过前两层验证的配置，我们使用 Docker Compose 启动完整的测试环境，包括数据源、消息系统、目标存储或数据库，以及 SeaTunnel 运行环境；随后实际提交 SeaTunnel 作业，并验证任务是否完成预期的数据同步。
以 CDC 任务为例，真实运行会涉及数据库 binlog 或 logical replication、权限、publication、server-id、checkpoint 和 connector 版本兼容性等条件。以复杂 DAG 为例，只有真正启动 source、transform 和多个 sink 后，才能确认数据流是否按预期连接、转换和落库。
L3 的验证流程包括：
- 启动任务所需的 Docker Compose 环境；
- 准备源端测试数据、CDC 状态或消息数据；
- 使用模型生成的配置提交 SeaTunnel 作业；
- 观察作业启动、运行和退出状态；
- 校验目标端数据是否被正确写入；
- 对失败任务保留日志、错误信息与修复记录。
因此，L3 成功并不等同于"进程没有报错"，而是要求配置能够在真实组件和真实数据条件下完成预期的数据读写与结果验证。
三层设计的意义
三层验证刻意区分了三个不同的问题：
通过这种设计，我们可以同时观察模型在"生成配置""遵守规则"和"真实执行"三个阶段的表现差异。更重要的是，它能够避免将 L1 或 L2 的通过率直接误认为生产可用性：对于 AI 辅助 ETL，真正有价值的指标是配置能否穿透静态检查、CLI 规则和运行环境，最终让数据管道真实运行起来。
为保证每次测试结果可追溯，benchmark 运行时还应记录模型 ID、调用日期、推理参数、提示词版本、SeaTunnel AI CLI commit、任务 ID、Docker 镜像版本、每层验证结果、失败原因和修复轮次。这样，后续当模型版本、connector 规则、prompt 或 CLI 功能发生变化时，团队才能准确判断改动是否真正提升了真实执行成功率。
评测结果分析：主流模型在 ETL 任务中的真实表现与选型建议
公开工程能力对照
在进入 SeaTunnel ETL 实测前，先以公开的代码 Agent、命令行和软件工程评测作为能力背景。由于不同厂商使用的 harness、推理配置、工具环境与模型版本并不完全一致，下表只展示可参考的公开成绩，不将这些分数直接视为横向排名或 ETL 成功率预测。
备注：
SWE-Bench Pro / SWE Verified / DeepSWE：衡量在真实或近真实代码仓库中定位问题、修改代码并通过测试的能力。
Terminal-Bench：衡量模型在终端环境中完成多步命令行任务的能力，与 CLI Agent 的交互模式更接近。
Coding Agent Index：综合衡量代码 Agent 任务能力，但其运行框架和评测设置并不等同于 SeaTunnel AI CLI。
MCP-Universe、Tool-use 与 scaffold 格式测试：更接近工具调用协议遵循、多步骤执行和不同 Agent 框架适配能力。
测试与总结
本次实验在统一的 100 个 SeaTunnel ETL 任务上，对 7 个模型进行测试。任务覆盖 20 个 Tier 1 基础同步任务、45 个 Tier 2 转换/CDC/参数约束任务，以及 35 个 Tier 3 复杂 DAG 任务；验证依次经过 L1 静态配置校验、L2 CLI/OptionRule 校验和 L3 Docker 化真实执行环境验证。
L1 静态验证结果
L1 用于验证模型能否生成可解析、满足基础 HOCON 结构和 connector 规则的配置。表中"首次通过"表示模型首次生成即通过 L1 的任务数；"修复通过"表示经过失败反馈和后续修复后额外通过的任务数；"总通过率"是两者之和除以 100 个任务。
从 L1 结果看，GPT-5.6 Terra 具有最高的静态配置通过率，GPT-5.6 Sol 和 Claude Opus 4.8 紧随其后。Claude Opus 4.8 的特点是首次通过率最高：100 个任务中有 87 个无需修复即可通过静态验证；Terra 与 Sol 则更多依赖后续修复来提高静态通过率。
开放模型的结果也呈现不同特征：Qwen3-Coder-Next 首次通过 53 个任务，但可通过修复额外恢复 14 个任务；DeepSeek-V3.2 的 58 个通过任务均来自首次生成，测试中未观察到额外修复成功。
L3 真实执行结果
L3 要求模型生成的配置在 Docker Compose 启动的真实环境中完成任务运行和结果验证，环境涉及 MySQL、PostgreSQL、Kafka、ClickHouse、Elasticsearch、MinIO、Doris 和 StarRocks 等组件。该层不仅检查任务是否启动，还验证数据是否按预期从 source 经 transform 写入 sink。
当前实验资料明确给出了三款领先模型的 L3 完整结果：
数据口径说明： L3 "首次执行成功"与"修复后成功"按报告中的 L3 成功任务拆分整理；L3 总成功为最终通过真实执行和结果校验的任务数。L1 至 L3 衰减以百分点计算，即 L3 成功率−L1 通过率L3 成功率 - L1 通过率L3 成功率−L1 通过率。
这组数据呈现出明显的排名反转：
- GPT-5.6 Terra： L1 第一，L3 第三。其静态通过率为 93%，但真实执行成功率为 74%，共有 19 个任务在从"配置可校验"走向"真实可运行"的过程中失效。
- Claude Opus 4.8： L1 第三，L3 第一。其静态通过率为 89%，真实执行成功率为 85%，静态到真实执行的损失最小，仅为 4 个百分点。
- GPT-5.6 Sol： L1 第二，L3 第二。其真实执行成功率为 81%，比静态通过率低 9 个百分点，整体介于 Opus 的稳定性与 Terra 的高静态生成率之间。
静态与真实执行对照
关键测试发现
第一，静态配置通过率会高估生产可用性，且高静态分数不必然对应高真实执行率。 GPT-5.6 Terra 在 L1 中达到 93%，是静态校验表现最好的模型，但进入 L3 后成功率降至 74%，静态到真实执行相差 19 个百分点；相反，Claude Opus 4.8 的 L1 为 89%，L3 达到 85%，仅下降 4 个百分点，并由静态阶段第三升至真实执行第一。OpenAI 官方将 Terra 定位为日常生产工作流的平衡层模型，强调其在代码生成、结构化数据提取等场景下以更低成本逼近上一代旗舰模型的能力，并支持 Programmatic Tool Calling 架构，适合快速产出结构完整、可通过规则校验的输出。 但这类偏重"生成效率与规则合规"的技术特点，并不天然覆盖 SeaTunnel 真实执行所需的隐含运行条件，例如 CDC 前置配置或 connector 参数组合，因此高静态通过率与高真实执行率出现了背离。
第二，首次通过率和修复能力必须分开统计，对应两种不同的模型技术特征。 Opus 4.8 的 89 个 L1 通过任务中，87 个是首次通过，仅 2 个来自修复；Terra 和 Sol 则分别通过 14 次和 10 次修复扩大了 L1 通过范围。Anthropic 官方对 Opus 4.8 的技术描述指出，该模型相较前代大约减少四倍"让自身代码缺陷未被标注就直接通过"的情况，这种经过校准的审慎判断能力，与其在测试中首次生成即高比例通过、无需大量修复的表现相吻合。 相对地，OpenAI 官方强调 Terra 与 Sol 所在的 GPT-5.6 系列具备较强的调试评测表现------在 OpenAI 内部研究调试评测中，Terra 得分 67.8、Sol 得分 68.3，且两者均支持 Programmatic Tool Calling 用于多步骤工具协调；这类面向诊断与迭代修正的技术设计，与它们在测试中依赖较多修复轮次来提升通过率的现象相符。 这说明"第一次写对"与"从报错中改对"是两种不同的模型能力来源，分别对应审慎判断类技术特征与调试迭代类技术特征。
第三，L3 失败主要暴露 connector 与运行环境的隐含语义，且这与通用工程能力的技术定位边界有关。 典型问题包括 Doris/StarRocks 参数组合、PostgreSQL CDC 的 publication 配置、逻辑复制和权限前提，以及多输入多输出 DAG 关系，这些问题往往不能仅依靠 HOCON 解析或基础静态校验发现。无论是 Anthropic 强调的复杂任务规划与长程 Agent 一致性，还是 OpenAI 强调的工具密集型工作流与调试能力，这些公开技术特点主要面向通用代码仓库任务、终端操作和工具调用场景，官方材料中并未提及针对特定数据集成 connector 语义或 CDC 运行前提的专项优化。 因此，即便模型具备较强的通用 Agent 技术基础，仍需要依赖 SeaTunnel AI CLI 自身注入的 connector metadata、OptionRule 和结构化错误诊断，才能将这类通用能力转化为对隐含运行时约束的正确处理，这也是本次 L3 失败集中于 connector 语义层面的技术原因。
选型建议
结合三层验证的结果看，模型选型不应只看 L1 静态通过率，而要根据任务复杂度、修复预算和生产容错度做组合决策。
- 高价值、强 CDC/复杂 DAG 场景(Tier 3）：优先选择静态到真实执行衰减最小的模型，如 Claude Opus 4.8，因为它在 L1 到 L3 之间仅损失 4 个百分点，首次生成即可运行的比例最高，更适合缺乏充足人工排障资源的团队。
- 高吞吐、低复杂度批同步场景(Tier 1/Tier 2 基础任务)：可以优先选择成本更低、静态生成效率更高的模型，例如 GPT-5.6 Terra，配合较强的修复循环弥补真实执行阶段的衰减，通过 SeaTunnel CLI 自带的
--checkdry-run 机制在提交前拦截明显的规则违规。 - 修复预算充足、允许多轮迭代的团队：GPT-5.6 Sol 和 Terra 在实验中都表现出较强的"从报错中改对"的能力，依赖 14-19 次修复补齐 L1 到 L3 的差距，适合有自动重试与日志分析流程的工程环境。
- 数据主权或本地部署要求较高的团队：Qwen3-Coder-Next 和 DeepSeek-V3.2 作为开放权重模型可以满足合规约束，但由于 L1 基线较低(67% 和 58%)，需要叠加更强的静态规则校验和人工复核，不建议直接用于无监督的生产发布。
- 追求成本与稳定性平衡的团队：可以采用分层路由策略，先用低成本模型(如 Terra)完成 L1/L2 初筛和批量生成，对 Tier 3 复杂 CDC 或多 sink 任务再切换到 Opus 4.8 复核和修复，兼顾整体调用成本与真实执行成功率。
后续优化：SeaTunnel CLI 能力演进
从测试暴露的问题看，后续优化的重点不是替换模型，而是让 SeaTunnel AI CLI 把更多隐含的运行时约束前置为结构化上下文和规则，减少对模型"猜对"的依赖。
- 加强 connector 知识注入：将 CDC 前置条件(binlog、逻辑复制、publication、权限、server-id)、Doris/StarRocks 参数组合等隐含语义，以结构化 metadata 的形式提供给模型，而不是仅依赖模型自身的通用知识，同时引入动态检索增强（RAG），根据用户的自然语言需求动态挂载相关的 Connector OptionRule 和约束，而非一次性静态注入"。
- 扩展 L2 规则覆盖面：把 L3 阶段反复出现的失败模式(多输入多输出 DAG 关系、CDC 参数组合)沉淀为新的 OptionRule 和静态检查项，把发现问题的时间点从"真实运行后"提前到"CLI 校验阶段"，利用现有的 dry-run/--check 机制承载更多规则。
- 构建失败案例反馈闭环：将 L3 阶段保留的日志、错误信息和修复记录系统化整理，反哺 prompt 知识库和规则引擎，形成"真实执行失败→规则补全→再评测"的持续迭代机制。
- 结构化错误诊断：把 Java 运行时抛出的原始异常栈，转换为模型可直接行动的修复指令(例如明确指出缺失的必填参数或不兼容的参数组合)，降低模型在修复轮次中"猜方向"的成本，同时引入错误摘要机制（Error Summarization），提取 Root Cause，避免长篇 Java 异常栈淹没模型的核心 Prompt。
- 建立可追溯的回归评测体系：延续本次记录模型 ID、prompt 版本、CLI commit、Docker 镜像版本和各层验证结果的做法，持续跟踪同一套 100 个任务在模型、connector 规则或 prompt 变化后的表现漂移，判断改动是否真正提升了 L3 真实执行成功率。
- 引入分层模型路由与人工复核门槛：对 Tier 3 复杂 DAG 和 CDC 任务，即便模型给出通过 L1/L2 的配置，也建议默认经过一次真实环境预跑或人工复核后再进入生产，降低单一模型误判带来的生产风险。
参考资料：