Hardware MCP：自进化实验室的硬件标准
TECHNICAL REPORT · HARDWARE MCP
大模型已经会读论文、写代码、设计实验。但在绝大多数实验室里，它仍然是一个“只能动口、不能动手”的顾问，因为仪器不会说它的话。本文介绍 Hardware MCP：一套让 Agent 能够发现设备、理解设备能力边界，并在真实实验中持续积累设备知识的硬件标准。
这套能力不是从概念设想开始的。过去几年，我们的平台已经支持多种大模型通过 αLab Studio，按照统一的设备描述和调用方式，连接并操控实验室设备，并在 SE-Fab 等实际场景中验证多设备协作与实验迭代。
涌生智能 CEO 杨梦博士在 2025 年 8 月的专访中曾提到：未来 3—5 年，生命科学 AI 将聚焦实验室自动化与 AI 的深度融合，通过自然语言交互简化实验设计，让科研人员只需提出假设，系统就能自动生成并执行实验方案，并逐步构建生命科学的硬件 MCP 与软件 MCP。
这正是我们持续建设 Hardware MCP、αLab Studio 和 SE-Fab 的长期方向：让 AI 从理解科学目标开始，进入真实实验室，调用设备、执行实验，并根据结果推动下一轮实验。
先看实际运行：
Physical AI 走进生命科学实验室，起点不是让模型变得无所不能，而是让每一台设备都能被 AI 理解、调用，并在实验过程中持续回应。
01 / 一个看似不需要思考的动作
撕膜这个动作，对人类实验员而言不过是一秒钟的事：眼睛扫一眼，确认封膜是否翘边，手指一捏一撕即可完成。这个“看一眼、捏一下、撕掉”的过程，早已通过视觉、触觉和背景知识内化为人的世界模型。
但对自动化实验室而言，“撕膜”需要一台专用设备“自动化撕膜机”、61 页手册、RS-232 串口通信协议、十几个指令、三个电机、一个封膜检测传感器和一套安全联锁。要让它稳定运行，一位资深工程师需要花上两天时间理解状态机、处理异步消息、解析三槽位错误码、标定传感器阈值，并对接安全联锁。
而这还只是“让设备动起来”。AI 真正需要解决的是“什么时候应该撕膜”：样本是否已经准备好，下游分析何时需要，封膜类型是否匹配当前参数。这些上下文不在撕膜机里，也不在单个设备脚本里，而是在完整的实验计划和流程状态中。
因此，AI 走进物理实验室的复杂度，不只是让模型学会操作设备，而是让设备的知识、状态、上下文与经验能够被 AI 理解、积累和传承。这正是涌生智能希望解决的问题。
人可以凭借直觉完成一个动作；Agent 必须通过接口、状态、约束、反馈和经验，才能可靠地完成同一个动作。
两个工程师的视角
硬件工程师： “我希望交付的是一台有清晰能力、状态和安全边界的设备，而不用为不同的上层应用都开发特定的接口。”
AI 工程师： “我希望像在 Codex 里调用 tool 一样调用实验室设备，而不是为每台仪器重新读手册、写驱动、猜状态。”
软件 Agent 调用工具时，通常只需要理解工具的能力以及输入和输出，而不必了解背后的服务、函数或机器。MCP、Function calling 等机制屏蔽了实现细节。实验室仪器的功能也需要类似的机制：driver 负责让设备可连接、可控制，中间层则负责让设备的能力、状态和安全边界能够被 Agent 理解，并围绕实验目标与其他设备协作。
中间层的价值，就是让硬件工程师交付可理解的设备能力，让 AI 工程师获得像调用软件工具一样调用硬件的体验。
一台撕膜机就把一个经常被忽略的事实暴露出来：自动化的终点不是“替人按下按钮”，而是把一个物理动作转化为可发现、可理解、可验证、可追溯、可复用的机器能力。
而这只是实验室中最简单的一类设备。真实的生命科学实验往往还要同时协调液体处理、机械臂、读板、成像、温控、测序和数据分析。要让 AI Agent 真正进入实验室，首先必须让 Agent 能够可靠地理解和控制这些硬件。
02 / 从设备控制到自进化实验室
AI4S 最终想要的，不只是一个能够执行固定 SOP 的自动化实验室。
更理想的形态是：人类提出一个科学问题或实验目标，AI Agent 自主设计实验，协调实验室中的各种设备完成执行，分析实验结果，根据结果调整策略，再开始下一轮实验。实验室不再只是执行人类已经写好的步骤，而是能够在约束和监督下持续探索、验证和迭代。
这就是 Physical AI 进入实验室的真正含义：AI 不再只存在于论文、代码和聊天框里，而是进入样本、试剂、设备、环境和实验结果组成的物理世界。
生命科学实验室尤其适合也尤其需要这种能力。因为生命科学实验通常具有多步骤、多设备、强状态依赖和高不确定性的特点。一个看似简单的实验目标，背后可能涉及样本准备、液体转移、温度控制、成像、读数、质量控制和结果解释。任何一个环节的状态变化，都可能影响后续决策。
这五个阶段变化的不是设备数量，而是实验中的控制权和智能位置：
从人操作工具，到人定义任务；再到人定义目标；最终由 AI 在干湿实验室中持续提出、验证和解决问题。
涌生智能当前的技术探索，位于从 AI 辅助实验室向 Agentic 实验室演进的过程中，SE-Fab 自进化实验室系统则是面向更高阶干湿闭环和自进化实验室的主要技术方向。
但从“AI 可以提出实验目标”到“AI 可以自主完成实验并持续迭代”，中间还有一个不能绕过的工程问题：软件层面的 AI 必须能够方便、可靠、安全地控制物理硬件。
这意味着我们需要一个位于 Agent 与设备 driver 之间的中间层。它把实验意图和实验指令转换成设备能够执行的动作，把设备状态、样本状态和实验结果反馈给 Agent，并将权限、约束、异常、日志和经验纳入同一条链路。
自进化实验室的终局由 AI 定义问题，但它的起点是让 AI 能够可靠地进入物理世界。中间层，正是连接这两端的关键基础设施。
现在，涌生智能已经支持多种大模型基于 αLab Studio，根据 Hardware MCP 描述发现和调用实验室设备。
在单设备层面，Agent 可以连接液体处理设备、机械臂等硬件，理解它们的能力、状态和约束；在系统层面，Agent 可以通过 ProtoPilot 的实验语义与编排能力，协调多个设备完成实验任务，并在 SE-Fab 中进一步根据执行结果调整后续实验。
这意味着，Agent 不再只是生成一段设备脚本，而是开始进入真实的实验执行链路：从理解实验目标，到生成实验指令，再到调用设备、接收状态、分析结果，并决定下一步行动。
03 / 为什么设备互联不等于实验室自治
过去的实验室自动化，主要围绕三个问题展开：设备如何被控制，设备之间如何互联，以及一个固定工作流如何被自动执行。
SiLA 2、OPC UA/LADS 等协议，让不同厂商的设备能够以更统一的方式通信、暴露能力和交换状态；各种工作流引擎和集成平台，则让多台设备可以按照预先定义的流程协作。这些能力是实验室从单机自动化走向任务自动化，再走向实验流程自动化的必要基础。
但当实验室进入 Agentic 和自进化阶段，问题发生了变化。
系统不再只是执行一个已经写好的工作流，而需要理解实验目标，实时感知设备、样本和环境状态，动态调整实验计划，并根据结果决定下一步。实验室不再只是“按照指令完成动作”，而是要在实验过程中持续地观察、判断、修正和学习。
这意味着，我们需要解决的已经不只是更多的设备命令，而是一种新的交互关系。
传统的设备集成通常是单向的：
软件或调度系统
↓ 发送命令
设备
↓ 返回结果
软件或调度系统
这种方式足以支持许多固定任务，但还不足以支撑真正的实验自治。面向高阶自治的实验室，需要的是一个持续运行的双向环境：
Agent
↕ 实验目标、状态、事件、约束、反馈
实验语义与编排层
↕
设备 A ↔ 设备 B ↔ 设备 C
在这个环境中，Agent 不只是向设备发送命令，也要持续接收设备的状态、事件和异常；设备之间不只是交换数据，还要围绕同一个实验目标共享状态、资源和约束；实验结果也不应停留在一次性的输出，而要反馈到下一轮实验计划中。
因此，一个具备 Agent Ready 能力的实验室至少需要回答以下问题：
- 这台设备在当前实验中承担什么角色？
- 样本、试剂和耗材现在处于什么状态？
- 下一步动作的前置条件是否满足？
- 多台设备如何围绕同一个目标协作？
- 设备异常是软件问题、设备问题，还是物理实验失败？
- 实验结果如何改变后续策略？
- 本次实验中积累的经验，如何被下一次实验和下一个 Agent 复用？
这也是为什么，设备“连得上”不等于实验室“能自治”。
Anthropic 的 Model Hardware Standard（MHS）是这一方向上的重要尝试。它为物理设备提供面向 Agent 的统一表达，使设备能够以更一致的方式暴露能力、状态、约束和安全信息，让 AI 更容易接入和编排不同类型的物理设备。
我们提出的 Hardware MCP 沿着类似的方向，进一步面向生命科学实验室组织设备上下文：除了描述设备能做什么，还要描述设备当前处于什么状态、如何与其他设备协作，以及执行结果如何反馈到实验流程中。
这背后是我们对硬件标准的判断：技术与产业，各要过一道关。技术上，设备要天然可被 Agent 理解：操作收敛为一套最小的读写词汇，学一次即可操作所有设备；设备可被自动发现，接入无需逐台手写适配；负载上限、安全边界这些散落在说明书和工程师经验里的知识，一并交给 Agent；能力同时向 MCP、命令行和代码开放，编排多台与操作一台，代价几乎相同。
产业上，它会重新分配设备价值的话语权：厂商的约束力相当程度来自私有调度软件而非机械本身——流程一旦围绕它搭建，换设备就得推倒重来；标准将这层绑定松开，比较的尺度回到设备的性能与价格，固守私有软件层的设备则会被挡在自动化实验室的门外。好的硬件标准，改变的不只是设备接入方式，更是设备价值的定价权——它把选择权从调度软件手里，还给实验室。
设备互联解决的是设备之间能不能说话；实验室自治解决的是设备、Agent 和实验状态能不能共同完成一件事。
04 / 涌生智能的方案：从命令转发层走向实验协作层
Hardware MCP 不试图替代已有的设备 driver，也不重新发明 SiLA 2、OPC UA、ROS 或厂商 SDK。
我们的技术命题是：在设备 driver 与 AI Agent 之间，建立一层面向生命科学实验的中间层，把不同设备、不同协议和不同 Agent 连接到同一个实验目标上。
可以将它概括为：
Driver 让设备可控制，Hardware MCP 让设备围绕实验目标协作。
传统的中间层，更多承担命令转发和流程调度的功能。我们希望把实验室中间层推进为一个能够理解实验、管理状态、组织设备、处理反馈并积累经验的实验闭环层。
-
实验意图理解
系统首先要理解的不是某个设备命令，而是实验目标，并将实验意图转化为机器能够执行、检查和追踪的实验任务。
-
设备能力抽象
不同厂商、不同接口和不同集成方式的设备，应该以统一的能力被 Agent 发现和调用，使 Agent 无需直接理解具体设备的底层协议、SDK、状态机和错误码。
-
设备与 Agent 的双向通信
Agent 不只是向设备发送命令，也要持续接收设备反馈，使系统能够从“调用工具”进一步进入“管理实验过程”。
-
设备之间的协作
实验不是多个孤立动作的简单相加。设备之间需要围绕实验目标共享样本、资源、空间、步骤依赖和安全约束等状态。
-
动态编排与重规划
真实实验不会永远按照最初的计划顺利进行。系统需要根据设备异常、样本状态和 QC 结果等实时信息，动态调整后续计划。
-
经验沉淀和技能复用
实验结束后，日志、异常和人工判断不应该消失在一次性任务中，而应沉淀为可复用的设备知识和实验技能。
-
安全与证据治理
物理世界中的安全不能依赖模型“自己小心”。参数限制、硬联锁、权限、审批、模拟运行、异常升级、操作日志和实验溯源等能力，都需要成为系统设计的一部分。
一段话，一群 Agent，一套接口，一整个实验室。科学家提出意图 → AI Agent (SE-Fab、ProtoPilot harness)规划执行 → Hardware MCP 统一驱动每台硬件 → 结果实时回流、自动调优。从想法到实验结果，真正实现全闭环。
我们不是让 Agent 控制一台设备，而是让不同协议、不同厂商和不同设备，围绕同一个实验目标协作起来。
05 / 核心设计：型号是 Skill，实例是档案
Hardware MCP 的整体架构只有一句话：Agent → Hardware MCP → 仪器。Agent 不直接面对仪器，而是面对一个结构化的文件系统：HardwareType 承载可分享的型号知识，HardwareInstance 承载这台设备的活档案。
目录树
Hardware MCP/
├── HardwareType/ # 型号库：可分享、跨 Agent 复用
│ └── AlphaTool/
│ ├── type.md # 型号元数据 + 自然语言说明
│ ├── protocol.yaml # 通信协议（MCP / CLI / SDK 绑定）
│ ├── capabilities.yaml # 功能清单（get/set 能力表）
│ ├── safety.yaml # 安全边界（驱动层强制执行）
│ ├── references/ # 说明书与接口文档
│ └── simulation/ # 驱动模拟验证
└── HardwareInstance/ # 实例库：环境相关
└── AlphaTool-01/ # 以 AlphaTool 移液工作站实例为例
├── instance.md # 实例元数据（必须关联 type）
├── connection.yaml # IP / 端口 / 串口
├── relations.yaml # 仅机器人持有：本机器人可与哪些仪器交互
├── experience.md # 沉淀的经验（可追加、可更新）——自进化的载体
└── log/ # 仪器操作过程日志（自进化的原料）
文件即标准：任何编辑器可读，任何 Agent 框架可解析，git 可版本化。
Type（型号库 · 类）：可分享、跨 Agent 复用，型号不变则不变。
Instance（实例库 · 对象）：环境相关，必须关联 type，承载经验与日志。
HardwareType · 五个文件
| 文件 | 角色 | 内容 | 设计来源 |
|---|---|---|---|
| type.md | 型号身份证 | YAML frontmatter（name / vendor / class / version）+ Markdown 正文承载代码无法推断的物理知识。 | 沿袭 Agent Skills 的 SKILL.md 惯例 |
| protocol.yaml | 通信协议 | 传输层协议（TCP / 串口 / SDK）+ 三种绑定（MCP server / CLI / SDK）+ 设备发现。 | 借鉴 MCP 的传输层设计 |
| capabilities.yaml | 功能清单 | 用 get/set 统一词汇声明 Agent 可读取和可设置的能力、前置条件与副作用。 | 与 SiLA 2 的特征定义同层，但面向 Agent 语义 |
| safety.yaml | 安全边界 | hard_limits、interlocks、e_stop、审计开关。声明在类型层、执行在驱动层、独立于模型存在。 | Hardware MCP 核心原则：安全不依赖模型的自觉 |
| references/ + simulation/ | 参考与验证 | 说明书、接口文档和模拟验证。新 Agent 接入前先跑通标准用例。 | 让驱动质量从隐式信任变成显式验证 |
HardwareInstance · 五个文件
| 文件 | 角色 | 内容 |
|---|---|---|
| instance.md | 实例身份证 | type 字段强制关联 HardwareType；序列号、位置、运行状态。 |
| connection.yaml | 连接信息 | host / port 或串口参数；凭证以 secret_ref 引用，不记录明文。 |
| relations.yaml | 协作拓扑 · 仅机器人 | 声明机器人能与哪些仪器交互，以及可达位置和转运关系。 |
| experience.md | 自进化的结晶 | 五段式条目：现象、排查、结论、建议、来源。 |
| log/ | 自进化的原料 | JSON Lines 运行日志，错误单独归档；驱动写入，Agent 只读。 |
Hardware MCP 设计原则：安全边界声明在类型层、执行在驱动层、独立于模型存在。模型可以犯错、可以被误导，但无法通过对话绕过 hard_limits。
06 / 交互流程：Agent 认识一台仪器的七个步骤
从“发现”到“沉淀”，Hardware MCP 把人类实验员熟悉一台仪器的过程形式化为七步。第 3 步与第 7 步是静态标准里没有的环节，也是自进化闭环的接口。
| 步骤 | 名称 | 英文 | 描述 |
|---|---|---|---|
| 01 | 发现 | DISCOVER | 扫描 HardwareInstance 目录，沿 type 字段加载对应 HardwareType，Agent 第一眼看到的是结构化档案。 |
| 02 | 理解 | UNDERSTAND | 读取 type.md、capabilities.yaml 和 safety.yaml，理解型号能力、限制和安全边界；机器人额外读取 relations.yaml。 |
| 03 | 读档 | LOAD | 读取 instance.md 和 experience.md，了解这台设备的状态、脾气与历史教训。 |
| 04 | 连接 | CONNECT | 读取 connection.yaml 建立会话；新 Agent 可先在 simulation/ 上跑通标准用例，再触达真机。 |
| 05 | 执行 | EXECUTE | 经 MCP、CLI 或 SDK 调用 get/set；驱动层逐项检查硬限制与联锁，模型无法绕过。 |
| 06 | 记录 | LOG | 所有操作的参数、结果、耗时自动写入 log/，错误单独归档。 |
| 07 | 沉淀 | DISTILL | 异常结论由 Agent 提议追加进 experience.md，人工确认后入库，闭环回到第 3 步。 |
七步中有两步值得单独强调。第 3 步「读档」：Agent 在连接真机之前，先读这台设备的 instance.md 与 experience.md——就像新员工上岗前，师傅会告诉他「这台仪器冬天要预热、左侧通道有点漂移」。第 7 步「沉淀」：操作结束后，异常与排查的结论由 Agent 提议写回经验库，人工确认入库。这两步让「认识一台仪器」从一次性动作变成持续过程——这是下一节自进化闭环的入口。
与静态标准的差异：在传统的设备标准里，集成完成即终点——特征定义与信息模型在部署时写入，之后不变。Hardware MCP 在流程里显式加入了读档（读经验）与沉淀（写经验）两个环节，使设备知识成为流程内的一等公民，而不是流程外的旁注。
07 / 第一性设计哲学：自进化——标准本身是一个活系统
大多数标准解决“连接”问题，Hardware MCP 还要解决“成长”问题。一个为 Agent 时代设计的硬件标准，不能只是被动描述设备，它必须能从每一次使用中学习，让设备知识像人类实验员的经验一样持续积累。
自进化闭环
| 阶段 | 英文 | 描述 |
|---|---|---|
| 使用设备 | USE | Agent 经 MCP、CLI 或 SDK 操作仪器，完成真实实验任务。 |
| 沉淀原料 | LOG | log/ 自动记录每次操作的参数、结果与耗时，成为设备的“记忆神经元”。 |
| 分析提炼 | ANALYZE | Agent 分析日志，把异常与排查过程提炼为五段式经验条目。 |
| 确认入库 | CONFIRM | 人工确认后追加进 experience.md，可追加、可更新。 |
| 反哺进化 | FEEDBACK | 多个实例共有的通用经验经审核上浮至 HardwareType。 |
log/ 是自进化的原料。 驱动自动以 JSON Lines 记录每次操作的参数、结果与耗时，错误单独归档——这是设备的「记忆神经元」，完整、客观、永不遗忘。 experience.md 是自进化的结晶。 它可追加、可更新，每条经验遵循五段式：现象、排查、结论、建议、来源。当技术员发现「这台温控模块冬天达不到 37°C 的理论值」，这条经验被记录；当 Agent 在日志中发现通道 3 的小量程漂移规律，它提议追加新经验，经人工确认后入库。
这套机制有一个更广为人知的名字：干湿闭环。模型在「干」的一侧提出假设、设计实验、生成方案与代码；自动化设备在「湿」的一侧完成执行、记录结果、暴露问题；真实数据再回流给模型，推动下一轮更准确的设计。ProtoPilot 的私有化部署已经在这条链路上走出了实在的一步：AI 生成的协议或用户上传的既有协议，先送到设备侧解析校验，检查通过后由人确认下发，执行中持续回传当前指令、运行时间与异常信息，任务全程留痕可回放。Hardware MCP 的 log/ 与 experience.md，正是这套闭环在设备侧的载体：没有它们，湿侧的每一次失败都只是噪音，无法变成干侧下一轮变强的信号。
三个质变
第一，设备越用，Agent 越懂这台设备。 第一次遇到温控偏差，Agent 可能要排查半小时；第二次，它读一眼经验库就知道该提前预热。
第二，经验可以跨 Agent 继承。 今天接入 Agent A，明天换成更强的 Agent B，它不需要重新踩坑，因为经验存在设备档案里，而不是某个 Agent 的记忆里。
第三，经验可以反哺型号库。 当多个实例的 experience.md 记录了同一条规律，这条经验可以经人工审核上浮到 HardwareType。实例层是个体的学习，类型层是种群的进化。
08 / 落地路径：让每一台仪器都 Agent Ready——三条路径
标准再好，也要面对存量仪器的现实。我们分三档，让任何年代、任何接口形态的仪器都能进入 Hardware MCP 生态，并接入自进化闭环。
TIER 1 · 原生 Agent Ready 设备（NATIVE）
PrepALL、AlphaTool、Opentrons 等液体处理工作站、αCube BioXpert 生信 AI 推理一体机，以及 αBrain 伴侣大脑，出厂即内置完整 HardwareType 包：能力表、安全边界和模拟器随设备交付。伴侣大脑支持私有化部署，协议经设备侧校验和人工确认后执行，任务全程留痕、可暂停、继续或停止。
体验完整度：100%。这是体验上限，也是对“仪器应该长什么样”的回答。
TIER 2 · 平台自动生成（GENERATED）
对有接口文档但尚未 Agent 化的设备，平台解析说明书与接口文档，自动生成符合 Hardware MCP 规范的 HardwareType：协议绑定、能力清单和安全边界初稿，再由工程师审核确认。设备接入从“天”压缩到“小时”。
体验完整度：70%。把一次性集成工程变成可复用的平台能力。
TIER 3 · GUI Agent + 机器人兜底（FALLBACK）
对只有按键和屏幕的老仪器：GUI Agent 像人一样「看屏幕、点按钮」，自主操作机器人物理执行开关门、放样品。操作日志同样写入 log/，经验同样沉淀进 experience.md。理想地说，对 Agent 而言，一台 1998 年的老离心机与原生新设备看起来没有任何区别。
体验完整度：35% · 存量设备的全覆盖。