2. 闭环数据流总体架构

自驱动实验室（Self-Driving Lab, SDL）的核心不是某一台自动化设备，而是一条能够自我修正的数据闭环。这条闭环可以抽象为“感知—决策—执行—反馈”四个环节，但在工程实现上，它必须落到六个具有明确职责边界的层次上：数据采集层、数据管理层、模型层、控制层、实验执行层，以及贯穿其上的反馈协调机制。理解这六层的职责划分与接口设计，是搭建可扩展、可复现 SDL 系统的前提。

一、闭环的四个环节与六层映射

“感知”对应数据采集层，负责把实验过程中的物理量、设备状态、环境参数转化为结构化数据；“决策”对应模型层，负责基于历史数据与当前状态给出下一轮实验条件或参数建议；“执行”对应控制层与实验执行层，前者把决策翻译为设备可识别的指令序列，后者驱动真实硬件完成操作；“反馈”则不是单独一层，而是贯穿数据管理层与模型层的数据回流路径——执行结果被重新采集、入库、标注，并用于更新模型或调整决策策略。

需要强调的是，反馈不是简单的“结果回传”，而是带有质量判断与语义标注的回流。例如，一次合成实验结束后，不仅要记录温度、时间、产率，还要记录该次实验是否有效、是否触发异常、是否被人工干预。这些元数据决定了后续模型训练时样本的权重与可用性。

二、各层职责与接口设计要点

数据采集层的职责是“忠实记录”。它需要对接多种仪器：液相色谱、质谱、pH计、温度传感器、机械臂状态反馈等。接口设计上，建议统一采用“样本ID + 批次号 + 时间戳 + 测量值 + 单位 + 质量标志”的数据模型。质量标志用于标记该数据点是否可信，例如传感器是否超量程、是否发生通信中断。采集层不应做复杂计算，只做必要的单位换算与格式统一，避免引入难以追溯的转换误差。

数据管理层是闭环的“记忆中枢”。它接收采集层的原始数据，完成清洗、去重、缺失值处理与标注，并按实验批次建立索引。一个关键设计是“实验批次”概念：每一轮闭环迭代对应一个批次，批次内包含若干实验样本，每个样本关联其输入参数、执行日志与测量结果。这样，当模型需要训练数据时，可以按批次筛选，避免不同实验条件的数据混用。数据管理层还应提供版本化接口，使得模型训练时能够明确知道使用了哪一版数据。

模型层负责“决策建议”。在 SDL 中，常用代理模型（如高斯过程、随机森林）拟合“参数—性能”关系，再通过贝叶斯优化或进化策略推荐下一轮实验条件。模型层向控制层输出的不应只是单一参数点，而应包含：推荐参数、预测性能、不确定性估计、以及约束条件（如温度上限、浓度范围）。这样控制层才能判断该建议是否在设备安全范围内。

控制层是“翻译官与安全员”。它把模型输出的参数建议翻译为具体设备可执行的指令序列，例如“移液体积 200 μL、加热至 80 ℃、保持 30 min、搅拌 400 rpm”。同时，控制层必须执行安全约束检查：若推荐温度超过设备上限，应裁剪到安全值并记录裁剪事件。控制层还应维护一个状态机，跟踪每个实验任务从“排队”到“执行中”再到“完成/异常”的状态迁移。

实验执行层是“物理动作的承担者”。它由液体处理工作站、加热搅拌模块、机械臂、在线分析仪器等组成。执行层需要向控制层实时反馈状态，例如“移液完成”“温度已到达”“分析数据已就绪”。这些状态信息既是控制层判断任务是否继续的依据，也是数据采集层的重要输入。

反馈协调层是闭环的“调度中枢”。它不直接操作硬件，而是根据执行结果判断是否触发下一轮迭代。判断依据可以包括：当前最优性能是否达到目标阈值、模型不确定性是否已降低到可接受范围、实验预算是否耗尽、是否出现连续异常。反馈协调层还应提供人工干预接口，允许实验人员在必要时暂停闭环、修改约束或注入先验知识。

三、一个简化的接口数据示例

假设某轮实验推荐参数为：温度 75 ℃、时间 40 min、催化剂用量 3 mol%。控制层将其翻译为设备指令，执行层完成后，采集层获得产率 68.5%。数据管理层将该样本写入批次表，模型层读取后更新代理模型，反馈协调层判断“产率未达 80% 目标，且预算剩余 12 次”，于是触发下一轮推荐。整个过程中，各层通过明确定义的接口传递数据，而不是直接耦合。

{
  "batch_id": "B2024-07-15-03",
  "sample_id": "S-031",
  "parameters": {"temperature_C": 75, "time_min": 40, "catalyst_mol_pct": 3},
  "measurement": {"yield_pct": 68.5, "purity_pct": 95.2},
  "quality_flag": "valid",
  "timestamp": "2024-07-15T14:32:10+08:00"
}

四、常见职责混淆与规避

在实际搭建中，最常见的错误是把“数据清洗”放在采集层，导致原始数据被覆盖，后续无法追溯；或者把“安全约束”放在模型层，导致模型承担了它不应承担的硬件保护职责。正确的做法是：采集层保留原始值，数据管理层负责清洗并保留清洗记录；模型层只给出建议与不确定性，控制层负责可行性校验与安全裁剪。这样，当出现异常时，可以快速定位是数据问题、模型问题还是执行问题。

另一个常见问题是反馈路径缺失“质量判定”。如果所有执行结果都被无条件回传并用于训练，那么一次因设备故障导致的无效实验会污染模型。因此，反馈协调层必须结合执行日志与质量标志，决定该样本是否进入训练集、是否降低权重、或是否标记为“仅用于故障分析”。

综上，六层架构的价值在于把复杂的闭环拆解为职责清晰、接口稳定的模块。数据采集层保证“记得准”，数据管理层保证“找得到”，模型层保证“算得对”，控制层保证“做得安全”，实验执行层保证“动得起来”，反馈协调层保证“转得下去”。只有这六层各司其职、接口明确，自驱动实验室才能真正持续运转，而不是停留在单次自动化的演示阶段。