⭐️
设计思路
本页说明 AI CLI 如何把一句自然语言变成可运行的配置，以及它为什么被设计成"多智能体 + 分层校验"的流水线，而不是一次 LLM 调用。
为什么不是一次 LLM 调用
SeaTunnel 配置生成是一个领域 DSL 问题，有几类"单次生成"无法可靠处理的失败模式：
- 150+ 连接器、每个 20–50 个选项 —— 没有任何模型对每个选项名和类型有完整、最新的知识；
- 条件选项依赖 —— 比如 text 格式专属的选项出现在 PARQUET 格式的配置里会导致运行时错误；
- DAG 接线语义 ——
plugin_output/plugin_input标签必须在 source/transform/sink 块之间精确配对； - 模式推断 —— CDC 源必须是 STREAMING 模式；有界源不应携带流式专属选项。
因此 CLI 用权威连接器元数据为模型"接地"，对每一份候选配置做校验，并用真实报错驱动修复。
多智能体流水线
用户输入（自然语言）
│
▼
┌─────────────────┐ ┌──────────────────────┐
│ Planner Agent │───▶│ 连接器知识库（工具） │
│ （意图识别 + │◀───│ │
│ 必要时追问） │ └──────────────────────┘
└────────┬────────┘
│ 结构化计划
▼
┌─────────────────┐
│ Config Agent │ 生成 HOCON 配置
└────────┬────────┘
▼
┌─────────────────┐ ┌──────────────────────┐
│ Validator Agent │───▶│ 本地校验 + │
│ │ │ 引擎 --check │
└────────┬────────┘ └──────────────────────┘
│
通过 ── 是 ─▶ 输出并自动保存
│
否（最多 3 轮）
▼
┌─────────────────┐
│ Fix Agent │ 修正错误，重新校验
└─────────────────┘
后续 /check 或 /run 失败时
▼
┌─────────────────┐
│ Repair Agent │ 诊断真实引擎/运行时报错，修补配置
└─────────────────┘
Planner 负责意图分类（新建管道 / 提问 / 错误诊断）、选择连接器，只在没有合理默认值时才向用户追问。Config Agent 基于注入 prompt 的连接器元数据编写 HOCON。Validator 结合确定性本地检查与 LLM 语义审查。Fix/Repair Agent 接收真实错误文本——生成阶段的校验结果，或 /check、/run 之后的真实引擎堆栈——在原配置上修补，而不是从头重新生成。
连接器知识库
两级解析让选项知识保持准确，无需人工维护 prompt 文本：
- 运行时 API —— 运行中 SeaTunnel 引擎的 option-rules 接口（始终最新）；
- 内置元数据 ——
connector_metadata.json，通过反射从引擎导出并随 CLI 打包，包含 source/sink/transform 的必填与可选选项、条件选项组和取值约束。
Prompt 按请求动态组装：只注入 Planner 选中的连接器元数据，条件选项按触发条件显式分组（"仅当 format = text 时包含"）——这是对抗模型编造选项、误放选项最有效的单项措施。
三层生成策略叠加其上：Skill 场景手册（批同步、CDC 实时、多管道等剧本）→ 黄金样例（常见组合的已验证配置）→ 连接器元数据（权威选项规则）。
校验管道
| 阶段 | 方式 | 能抓住什么 |
|---|---|---|
| 1. 本地校验 | HOCON 语法、结构、必填项对照元数据、路由标签配对、未解析的 ${VAR} 占位符（字段级豁免：file_name_expression 中的 ${now} 等引擎模板变量不误报）、安全检查 | 语法错误、缺失/未知选项、接线错误 |
| 2. 引擎 dry-run | seatunnel.sh --check / --dry-run static —— 引擎的真实解析路径 | 插件可加载性、选项类型、未知 key、DAG 拓扑 |
| 3. 真实执行 | /run 走 REST API 或 seatunnel.sh | 一切运行时问题：连接、schema、CDC 前置条件 |
三层逐级递进；任一层失败都会把该层的真实报错喂给修复循环。
设计原则
- 接地，不轻信：prompt 里每一条连接器知识都来自引擎元数据，不依赖模型记忆。
- 确定性校验，LLM 修复：结论由解析器和引擎给出；LLM 只负责生成与修复，从不担任裁判。
- 真实报错是最好的提示词：修复 Agent 接收实际校验输出和堆栈。实测证明结构化、具体的错误信息比原始噪声的修复成功率高得多（见基准测试）。
- 默认安全：生成的配置对所有凭证使用
${ENV_VAR}占位；会话存储脱敏；/remember拒绝敏感值。
用数据说话，不靠假设
这套架构由专门的基准测试持续度量——100 个任务、包含真实执行在内的多层判定门、覆盖 7 个大模型。基准结果直接驱动改进路线（连接器知识注入、修复循环的结构化错误解析），并且未来对 prompt 或元数据的每次修改都可以在同一任务集上做 A/B 对照。