一、实验流程的抽象模型
在设计编排方案之前，需要先为实验流程建立统一的抽象模型。
1. 核心概念
一个实验流程可以抽象为以下要素：
- 节点：实验的最小执行单元。每个节点接收一组输入参数，执行特定的操作（数据处理、模型训练、指标计算等），并产出一组输出产物；
- 边：定义节点之间的依赖关系与数据流向。边是有向的，从上游节点的输出指下游节点的输入；
- 参数：实验的可变要素。包括超参数（学习率、批次大小）、数据路径、随机种子等；
- 产物：节点执行后生成的文件或数据，如模型权重、评估报表、绘制的图表；
- 运行时配置：计算资源需求（GPU 数量、内存大小）、环境依赖（Python 版本、依赖包列表）。
这套抽象足够通用，可以覆盖从单机脚本到分布式训练的实验类型。
2. 有向无环图约束
实验流程必须是一个 DAG——不存在循环依赖。这不仅保证了执行的可终止性（不会陷入无限循环），也使得拓扑排序、并行调度、断点续跑等操作在算法层面可高效实现。
在编排层，DAG 的合法性校验是入口关卡。校验内容包括：是否存在环路（通过拓扑排序检测）、所有依赖节点是否存在、参数类型是否匹配、资源申请是否超出配额。
二、可视化 DAG 编排：所见即所得
1. 前端渲染技术选型
可视化 DAG 编辑器的核心挑战在于大规模节点图的渲染性能。一个复杂的实验可能包含 50-100 个节点和数百条边，若渲染引擎性能不足，拖拽和缩放会出现明显卡顿。
当前主流的渲染方案有两类：
- Canvas 渲染：自建渲染管线，直接操作 Canvas API 绘制节点与连线，适合节点数量多且交互密集的场景。劣势是开发工作量大，需自行处理事件命中检测、视口裁剪、动画过渡等细节；
- 基于图形库的封装：利用成熟的图编辑框架进行二次开发。框架内置了节点拖拽、连线、缩放手势、小地图等基础功能，研发团队可将精力集中于业务逻辑——节点模板定义、参数表单渲染、边条件配置等。
建议采用后者作为起步方案，在节点规模突破一定量级后评估 Canvas 自建渲染的必要性。
2. 节点模板体系
可视化编排的效率取决于节点模板的丰富度与可复用性。体系的设计要点包括：
- 内置节点库：覆盖科研常见操作——数据读取（CSV、HDF5、数据库查询）、数据变换（归一化、缺失值填充、特征编码）、模型操作（训练、评估、推理）、可视化（折线图、热力图、散点图矩阵）、通知（发送报告、写入日志）；
- 自定义节点：允许用户将一段已调试通过的脚本封装为节点，定义其输入参数 schema 和输出产物列表。封装后的节点可加入模板库，供后续实验复用；
- 模板版本管理：节点模板应支持版本化——使用者在实验流程中引用的模板版本是固定的，不会因模板更新而影响已有实验的复现性。
3. 交互设计的关键细节
可视化编排工具的用户体验往往体现在边缘细节上：
- 连线自动推断：当用户将节点 A 的输出拖到节点 B 时，系统自动匹配类型吻合的参数对，并提供默认映射建议；
- 参数批量编辑：选中多个同类型节点后，支持批量修改共享参数，如将所有训练节点的随机种子统一设为 42；
- DAG 校验实时反馈：在编辑过程中持续检查连线合法性——类型不匹配的连线用红色标注，循环依赖的连线禁止建立——而非等到"提交运行"时才报错；
- 子流程折叠：将一组节点折叠为单个复合节点，折叠后在画布上仅显示输入/输出端口，降低视觉复杂度。
三、YAML DSL：声明式的实验描述
可视化编排适合构建实验的拓扑骨架，而 YAML DSL 适合精确描述节点的执行细节。两者是互补关系，而非替代关系。
1. DSL 的职责边界
DSL 的核心职责是完整、精确、可版本化地描述一个实验的所有信息，使得任意一个实验都能从 YAML 文件被精确复现。其设计原则包括：
- 声明式：描述"要什么"，而非"怎么做"。例如描述"使用 Adam 优化器，学习率 0.001"，而非描述"调用 torch.optim.Adam，传入 lr=0.001"；
- 可读性优先：DSL 的主要读者是研究者，语法应接近自然语言描述，规避嵌套过深的 YAML 结构；
- 可扩展：允许研究团队自定义节点类型与参数 schema，DSL 解析器能自动读取并校验。
2. DSL 结构设计
一个典型的实验 DSL 包含以下模块：
- 元数据区：实验名称、创建时间、负责人、标签；
- 参数区：全局参数定义，可在后续节点中引用。支持参数模板（如"标准 ResNet 训练参数集"）；
- 节点区：列出所有节点，每个节点指定类型、输入参数、资源需求、失败重试策略；
- 依���区：定义节点间的数据依赖关系，常用
depends_on字段或显式的边列表表示；
- 输出区：指定哪些产物需要持久化保存，哪些可丢弃以节省空间。
3. DSL 与可视化的双向同步
理想的设计是 YAML 与可视化画布保持双向同步：
- YAML→可视化：解析 YAML 文件，自动在画布上生成节点与连线，并根据布局算法自动排列；
- 可视化→YAML：在画布上的每一次编辑操作（添加节点、修改参数、调整连线）都即时反映到 YAML 文件中。
实现这一同步机制的技术关键在于统一的 AST（抽象语法树）——可视化前端和 YAML 解析器共享同一份 AST 模型，各自从 AST 渲染 UI 或序列化为文本。任何一方的修改都转化为对 AST 的操作，然后向另一端推送更新。
四、引擎层：从描述到执行
编排和 DSL 定义了"做什么"，引擎负责"怎么做"。
1. 拓扑排序与并行调度
引擎解析 DAG 后执行拓扑排序，将节点划分为多个执行层级。同一层级内的节点无相互依赖，可以并行调度到可用的计算资源上执行。
调度的关键优化点是关键路径分析——识别出从起始节点到终止节点的最长路径，优先调度关键路径上的节点，以缩短实验的总执行时间。
2. 断点续跑与增量执行
科研实验极少一次成功。断点续跑机制允许在修复某个节点的参数后，仅重新执行该节点及其全部下游节点，上游已完成的节点结果直接复用，省去大量等待时间。
实现增量执行的基础是产物的内容寻址——每个节点的输出产物以输入参数和输入数据的哈希值作为标识。当检测到某节点的输入哈希与上次执行一致时，直接跳过执行，使用缓存产物。这类似于构建系统中的增量构建原理。
3. 执行记录与复现
每次实验运行生成一份完整的执行记录，内容包括：DSL 快照、各节点的实际参数、开始/结束时间、输出产物的哈希值与存储路径、错误日志（如有）。这份记录是实验复现的基础——在任意时刻，都能根据记录重新运行出完全一致的结果。
低代码实验搭建的本质是降低实验设计与执行之间的认知鸿沟。可视化编排让复杂拓扑一目了然，YAML DSL 让实验描述可版本化、可审查、可复现，引擎层则将这些描述翻译为可并行的计算指令。三者配合，才能让研究者从流程管理的事务中抽身，将心力投注于真正的科学探索。
