企业官网建设流程全解析

PyLabRobot 硬件后端与受支持机型指南：0.2.1 稳定版后端命名、支持级别与安全实机运行门控

【免费下载链接】scientific-agent-skillsTurn any AI agent into an AI Scientist. The #1 Agent Skills library for science, used by 190,000+ scientists worldwide. 165 ready-to-use validated skills plus 100+ scientific databases covering biology, chemistry, medicine, and drug discovery. Compatible with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard.项目地址: https://gitcode.com/GitHub_Trending/cl/scientific-agent-skills

PyLabRobot 通过"前端 + 后端 + 资源树"的分层架构将液站控制抽象化，本文以官方验证快照PyLabRobot 0.2.1（2026-07-23 验证）为基准，系统梳理稳定版液路后端的正确命名、各机型支持级别、离线 chatterbox 后端、免连接能力检查工具、可选 transport extras，以及实机运行前必须由训练有素操作员逐项确认的"实机运行门控"清单。读完本文，你将能准确写出 0.2.1 下可用的后端导入语句、正确评估任意一台设备在当前版本的受支持程度，并安全地把规划工作与物理执行隔离开。

架构：前端、后端与资源树的分工

PyLabRobot 的核心设计是三段式分离：

• 前端（如LiquidHandler）：负责校验并记录标准操作，例如取放吸头、吸液、分液、转移；
• 后端（backend）：把前端的标准操作翻译成某一设备家族能执行的指令；
• 资源/台面树（resource/deck tree）：为几何和状态提供支撑，包括载架、适配器、板、吸头架、坐标与追踪器。

一个共同的前端并不保证不同的后端拥有相同的通道数、工具、操作、参数、校准方式、错误语义、时序或固件支持。因此，凡涉及后端专属的关键字参数（backend kwargs），必须回到精确的稳定机型页面逐一核对，不能想当然地在机型之间平移。

0.2.1 验证过的稳定液路后端命名

以下导入语句经过 0.2.1 稳定版验证，是当前唯一推荐的写法：

from pylabrobot.liquid_handling import LiquidHandler from pylabrobot.liquid_handling.backends import ( EVOBackend, LiquidHandlerChatterboxBackend, OpentronsOT2Backend, STARBackend, VantageBackend, )

废弃的旧命名（不要照抄旧技能文本）

这些命名约束在仓库技能文件中同样被固化。例如 SKILL.md 明确列出当前名称集合，后端检查脚本 也只从固定白名单导入这五个类。

稳定液路支持级别

以下是上游"stable supported machines"页面给出的支持标签（不是市场宣传口径）：

• Hamilton STAR(let)：Full（完整）。稳定类STARBackend；台面定义包括STARDeck与STARLetDeck。
• Hamilton Vantage：Mostly（大部分）。稳定类VantageBackend；需要核对未支持的命令与已安装选件。
• Hamilton Prep：WIP（开发中）。
• Hamilton Nimbus：WIP（开发中）。
• Tecan Freedom EVO：Basic（基础）。稳定类EVOBackend；不能把它描述成完整支持，也不能说它与 STAR 后端等价。
• Opentrons OT-2：Mostly（大部分）。稳定类OpentronsOT2Backend(host, port=31950)；网络/API/固件兼容性因具体机型而异。

上游对标签的定义是：

• WIP：开发中；
• Basics/Basic：核心功能已集成并有文档；
• Mostly：大部分能力可用，但存在已知的缺失命令；
• Full：上游认为至少 90% 的硬件/固件能力已支持且文档充分。

需要强调的是：这些标签并不验证某台具体的固件版本、附件、计算机、传输方式或协议。标签只是机型级别的能力声明，落到现场仍要逐项复核。

离线后端：不连机器也能练手

LiquidHandlerChatterboxBackend是推荐的全离线液路测试后端。它把每次操作打印出来并更新软件状态，不连接机器人、也不建模机器物理。以下代码来自仓库的软件专用示例骨架：

from pylabrobot.liquid_handling import LiquidHandler from pylabrobot.liquid_handling.backends import LiquidHandlerChatterboxBackend from pylabrobot.resources.hamilton import STARLetDeck lh = LiquidHandler( backend=LiquidHandlerChatterboxBackend(num_channels=8), deck=STARLetDeck(), ) await lh.setup() try: # 仅在此处构建资源并演练规划中的操作。 ... finally: await lh.stop()

后端构造必须保持字面量形式——绝不从字符串、插件、环境变量或不可信配置中动态挑选实机类。chatterbox 打印的是规划操作，它不能证明校准、可达性、无碰撞、液体行为或设备状态（这一点在 SKILL.md 的"非协商硬件边界"一节中被反复强调）。

免连接的版本/能力检查

仓库提供了一个零风险的后端能力检查器：

python3 skills/pylabrobot/scripts/inspect_backends.py \ --expected-version 0.2.1 --strict

该检查器（inspect_backends.py）的行为约束如下：

• 只在参数解析之后才导入固定白名单中的稳定类；
• 读取已安装发行版元数据（importlib.metadata）；
• 检查类的签名与关键方法是否存在；
• 创建零个后端实例；
• 绝不调用setup()；
• 不做任何串口、USB、HID、FTDI、Modbus 或网络操作。

它针对每个后端生成 JSON 报告，包含class、import_path、signature、stable_support、transport和declared_methods。测试 test_clis.py 明确断言该检查器运行时connection_attempted与serial_usb_network_access均为False。

注意：方法存在不等于该机型真的实现了此操作——有些后端会故意抛NotImplementedError。方法存在性只能说明 API 表面，能力事实要以机型为准。

Extras 与传输方式：按需精确安装

0.2.1 基础包把硬件依赖保持为可选。稳定安装文档列出的 extras 包括：

serial、usb、ftdi、hid、modbus、opentrons、sila、microscopy、pico、all。

只安装经过核实的、针对具体设备的那个 extra，并保留顶层版本固定：

# 仅示例形式；设备和传输方式获批前不要运行。 uv pip install "PyLabRobot[serial]==0.2.1"

两点重要说明：

• all在稳定 0.2.1 中并不包含microscopy，因为它有独立的 NumPy/SDK 约束；
• 可选传输包安装后可以枚举或与设备通信，但安装并不授权使用它们。设备传输依赖必须等用户明确指定设备并批准其传输依赖后再安装（见 SKILL.md 的"可复现安装"一节）。

实机运行门控：六项人工确认

禁止在训练有素的操作员明确确认以下全部项目之前实例化实机后端或调用setup()：

1. 设备身份：后端类、精确机型/序列号、固件、选件、传输方式；
2. 权限与状态：厂商/机构许可、保修影响、维护状态、访问控制、设备独占；
3. 台面布局：台面定义、载架/适配器、资源、坐标、朝向、间隙、碰撞/运动审查；
4. 校准与参数：校准、示教、吸头/头部兼容性、通道映射、单位、高度、速率、液类、全部后端 kwargs；
5. 液体与耗材：源/死/目标体积、物理液体身份、吸头状态、污染策略、废液、盖/封膜、管路/线缆、操作步骤；
6. 安全：防护罩/门、急停就绪、PPE、围护、干跑计划、中止路径、恢复/续跑规则。

绝不能把实机运行的条件只设为USE_HARDWARE=true、某个 CLI 标志或一个 IP/串口值。确认必须与已审查的方案和当前物理布置绑定。这一原则与 SKILL.md 中"不把仿真方案仅仅通过改环境变量/配置/导入变成实机后端"的硬性边界完全一致。

后端专属注意事项

Hamilton STAR / Vantage

它们是直接固件驱动。上游明确声明 PyLabRobot 未获得机器人厂商背书或支持，使用固件驱动可能影响保修。需要审查：USB 权限、设备选择、盖/臂/头配置、固件范围、液位检测、通道、CO-RE 吸头以及所有设备专属错误。

Tecan EVO

稳定状态是Basic，不是 Full。使用EVOBackend，并核实哪些 LiHa/RoMa 命令、臂、吸头、载架和固件路径已实现。绝不推断 Hamilton 行为或液类。

Opentrons OT-2

OpentronsOT2Backend通过 HTTP 与一个显式配置的 host通信。不要扫描网络或探测机器人。确认机器人软件/API 兼容性与不支持的操作——稳定源码明确拒绝一些特性，例如 96 通道头（96 head）和机械臂方法。

稳定版与开发版之分

• 稳定固定版本/标签是v0.2.1（2026-03-23 发布）；
• 仓库main分支在审查期间（至 2026-07-22）仍在持续变化；
• 开发文档和CHANGELOG.md的Unreleased小节可能描述尚未进入 wheel的类。例如 HighRes MicroSpin 支持尚未发布，不得把它描述成 0.2.1 稳定能力。

当考虑升级到更新的发行版时：

1. 确认它在 PyPI 上存在且不是预发布版；
2. 比较Requires-Python、extras、标签、changelog 与源码；
3. 在隔离环境中运行导入/签名与纯软件测试；
4. 重新验证每个目标机型/固件，并重复 commissioning 流程。

仓库侧的版本快照信息可参考 SKILL.md 的"已验证快照"一节。

与前端操作、资源树的配套使用

硬件后端选择不是孤立问题。在实机门控通过之前，完整的离线流程通常如下（详见 liquid-handling.md 与 resources.md）：

from pylabrobot.liquid_handling import LiquidHandler from pylabrobot.liquid_handling.backends import LiquidHandlerChatterboxBackend from pylabrobot.resources import ( Cor_96_wellplate_360ul_Fb, PLT_CAR_L5AC_A00, TIP_CAR_480_A00, hamilton_96_tiprack_1000uL_filter, set_tip_tracking, set_volume_tracking, ) from pylabrobot.resources.hamilton import STARLetDeck set_tip_tracking(True) set_volume_tracking(True) deck = STARLetDeck() tip_carrier = TIP_CAR_480_A00(name="tip_carrier") tips = hamilton_96_tiprack_1000uL_filter(name="tips") tip_carrier[0] = tips plate_carrier = PLT_CAR_L5AC_A00(name="plate_carrier") source = Cor_96_wellplate_360ul_Fb(name="source") destination = Cor_96_wellplate_360ul_Fb(name="destination") plate_carrier[0] = source plate_carrier[1] = destination deck.assign_child_resource(tip_carrier, rails=3) deck.assign_child_resource(plate_carrier, rails=15) source.get_well("A1").tracker.set_volume(100.0) # 规划状态，不是传感 lh = LiquidHandler(backend=LiquidHandlerChatterboxBackend(), deck=deck) await lh.setup() # 仅因后端是纯软件才安全 try: await lh.pick_up_tips(tips["A1"]) await lh.aspirate(source["A1"], vols=[10.0]) await lh.dispense(destination["A1"], vols=[10.0]) await lh.return_tips() finally: await lh.stop()

配套的严格离线检查工具链（全部零硬件访问、固定白名单、JSON 输出）位于 skills/pylabrobot/scripts，对应测试与合成夹具分别位于 tests/pylabrobot/test_clis.py 与 tests/pylabrobot/fixtures/protocol_manifest.json：

python3 skills/pylabrobot/scripts/validate_manifest.py \ --input tests/pylabrobot/fixtures/protocol_manifest.json python3 skills/pylabrobot/scripts/check_deck_geometry.py \ --input tests/pylabrobot/fixtures/protocol_manifest.json python3 skills/pylabrobot/scripts/plan_transfers.py \ --manifest tests/pylabrobot/fixtures/protocol_manifest.json \ --transfers tests/pylabrobot/fixtures/transfers.csv python3 skills/pylabrobot/scripts/generate_simulation_plan.py \ --manifest tests/pylabrobot/fixtures/protocol_manifest.json \ --transfers tests/pylabrobot/fixtures/transfers.csv

inspect_backends.py的--expected-version参数默认值取自 _common.py 中的PYLABROBOT_VERSION = "0.2.1"，并要求X.Y.Z数字形式；--strict在版本不匹配或符号导入失败时以退出码 4 失败。整个工具链的设计目标是：任何一步都无法挑选实机后端，仿真计划输出plan_kind: offline_review_only且live_backend_permitted: false。

小结：选择与安全的一句话准则

选择后端时以稳定支持标签 + 精确机型 + 安装的 extras三者为准；导入命名一律使用STARBackend、VantageBackend、EVOBackend、OpentronsOT2Backend、LiquidHandlerChatterboxBackend；任何实机动作都必须先通过上述六项人工门控，且门控条件永远与已审查方案和物理布置绑定，而不是只依赖一个开关、环境变量或地址。离线环境下，先用 chatterbox 后端和仓库自带检查脚本把规划、几何、转移账本与能力快照全部验证通过，再谈连接设备。

【免费下载链接】scientific-agent-skillsTurn any AI agent into an AI Scientist. The #1 Agent Skills library for science, used by 190,000+ scientists worldwide. 165 ready-to-use validated skills plus 100+ scientific databases covering biology, chemistry, medicine, and drug discovery. Compatible with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard.项目地址: https://gitcode.com/GitHub_Trending/cl/scientific-agent-skills