实验指令被接收，和样品真的完成处理，不是一回事。AI能写出实验方案之后，还需要知道设备开放了什么能力、执行到哪一步、凭什么认定完成。上海AI实验室10月12日介绍的书生SCP-Lab，正把这些问题放进统一交互协议。它的价值不只是让智能体“调用仪器”，还在于明确软件成功与物理成功之间那条容易被忽略的边界。

快速看点：协议连接能力发现、任务提交和执行反馈；公开仓库提供MCP兼容接口、模式文件与软件示例；真实设备仍要接适配器，当前公开运行时也没有持久任务队列，不能把接口演示当作无人实验室已经交付。

统一交互语言，不拿走本地安全控制

实验设备的难点，是不同厂商、不同接口和不同控制粒度同时存在。有的工作站只允许提交完整流程，有的仪器能开放单个操作，有的执行器还可以接收位置与动作命令。只把它们都叫作“工具”，并不能告诉智能体能改哪些参数、能组合哪些动作。

SCP-Lab将科学规划与设备执行分层。智能体规划实验并分析反馈，实验室系统安排能力与任务，本地执行后端负责检查条件和操作设备。协议不替代仪器原有控制系统；安全联锁、运行限制和急停仍属于本地系统，统一接口不等于放开全部底层控制。

其L1至L5框架描述的是调用者可控制的范围，从整套流程逐步细化到步骤、单机能力、设备命令和原子动作。这不是仪器先进程度的排行榜。一台设备也可能开放不同层级，集成者应按实验风险决定开放边界，而不是默认层级越细越好。

45种设备目录，不等于45种硬件已接通

公开仓库列出45个设备模型、89项动作定义，但它们属于离线接口目录，可用于校验请求。随附后端运行在软件中；其中有演示设备、适配模板与OT-2官方模拟路径，连接实际仪器仍需要对应硬件适配器。接口规范、软件模拟和现场接通，应分别验收。

入门示例用一个演示加热器走完整链路：先发现设备，再读取能力说明，提交任务后取得任务ID，随后查询同一次执行。示例成功代表软件流程结束，测得温度字段仍为空，不是加热器真的达到指定温度。这个区别比一张“操作成功”的界面更值得实施团队注意。

开发者因此可以先检查格式、单位和反馈流程，再考虑接入设备SDK。需要明确的是，格式校验不会自动完成单位转换，也不能证明仪器已校准或样品摆放正确。参数合法、位置正确、设备可用和实验满足验收条件，是不同层面的证据。

不确定结果不能靠再发一次指令解决

当前v0.1运行时通过本地MCP连接提供设备访问。结果不确定时，任务会进入unknown状态并保留设备占用，不自动重试；取消也需要后端确认。记录、占用与幂等键只保存在当前服务器进程内存里，服务器重启后旧任务ID和旧键不再提供原来的查询与去重保障。

这意味着，协议思路里需要的可信闭环，不能直接等同于公开运行时已经有跨进程恢复能力。持久队列、重连恢复、跨进程锁和全局样品台账，当前版本尚未提供。真实实验接入时，实施方仍要补齐可靠存储、设备状态核实与人工恢复流程。

为什么不能简单重试？对读取数据的请求，重复调用可能只是多一次查询；对移液、加样或加热的请求，重复调用会改变物理对象。断线后最重要的不是赶快再提交，而是先确定上一次操作是否发生、样品与设备现在处于什么状态，再决定下一步。

一个可行试点，应先选择低风险、结果易观测的单台设备，明确完成证据和取消条件，再测试进程中断、占用冲突与反馈丢失。把操作建议与实际执行权限分开，对不可逆步骤保留人工确认。这里的建议服务于交付验收，不代表仓库已经替用户完成这些工作。

小编判断：自主实验先把“完成”定义清楚

SCP-Lab带来的可复用价值，是让设备能力、控制范围与执行证据进入同一套描述，而不是只展示AI给仪器发命令。官方还介绍了跨机构科研场景的验证，但不能由此推断任意实验室已经具备即插即用条件，更不应据此承诺通用效率提升。

对科研和企业实施团队，最该优先交付的，是一个从请求到样品结果都可追查的小闭环：允许什么操作，谁承担安全检查，怎样核实完成，出现不确定状态后谁接管。只有这些问题能落到设备和记录上，智能体的规划能力才可能变成可依赖的物理实验能力。