MHS 协议入门介绍
边学边练请访问 7 天学会 MHS 协议 子站，涵盖 Physical AI 课表、设备模拟器、闭环编排实验与 Driver 开发路径。
什么是 MHS？
MHS（Model Hardware Standard，模型硬件标准） 是面向 Physical AI（物理人工智能） 的 开放协议层。它解决的核心问题是：当大模型驱动的 Agent 不再只调用「返回文本的 API」，而是要真正改变物理世界——调节激光功率、移动位移台、控制离心机转速——时，数字世界的工具协议（如 MCP）为什么不够用，我们又需要什么样的新抽象。
MHS 的哲学可以概括为：状态作为一等公民，操作即协议。设备不是「黑箱 REST 端点」，而是可观测、可预测、可约束的动力学系统。Agent 通过极简原语 read（读取状态向量）与 write（执行物理操作并验证）与设备对话，而不是依赖「发送指令 → 收到 OK 文本 → 假设成功」的开环模式。
为什么需要 MHS：MCP 的物理盲区
Model Context Protocol（MCP） 在数字工具编排上已经非常成熟：文件系统、数据库、搜索、代码执行都可以包装成 MCP Server 的 tools/resources。但 MCP 的默认交互语义是开环的：
result = await mcp.call("laser.set_power", {"watts": 2.5})
# result == "OK" ← 只证明「指令被收到」
# 激光器真的到了 2.5 W 吗？样品是否过热？无人知晓。
await mcp.call("camera.capture", {}) # 直接下一步，假设上一步成功
在物理世界里，「OK」不等于「物理状态已达成」。传感器漂移、执行器卡死、互锁未满足、样品气泡——这些都不会出现在纯文本返回值里。MHS 引入闭环：write → read → 验证 → 修正，让 Agent 像控制工程师一样工作，而不是像聊天机器人一样「发完就算」。
| 维度 | MCP（数字层） | MHS（物理层） |
|---|---|---|
| 交互对象 | 软件工具、API、文件 | 传感器、执行器、实验室仪器 |
| 成功语义 | 调用返回无异常 | 状态向量达到目标区间 |
| 状态表示 | 文本/JSON 快照 | 带单位、置信度、时间戳的物理量 |
| 安全 | 权限与沙箱 | 硬边界、软边界、互锁条件 |
| 失败模式 | 超时、4xx/5xx | 通信中断、物理故障、越界 |
MHS 不是替代 MCP，而是互补分层：MCP 管数字工具，MHS 管物理设备；MHS Driver 可以暴露为 MCP Server，让现有 Agent harness 无缝接入。
历史脉络：从 ROS 到 Physical AI
Physical AI 并非凭空出现。其思想脉络可以追溯：
- ROS / ROS 2（机器人操作系统）：为机器人领域提供了话题、服务、动作的中间件，强在实时控制与多节点通信，但面向机器人栈而非通用实验室仪器 。
- OPC-UA（工业互操作）：平台无关的工业数据交换，擅长 MES/SCADA 集成，但缺少 Agent 语义层（任务拆解、闭环验证、与人机回环）。
- MCP（2024–）：Anthropic 推动的数字上下文协议，统一 LLM 与工具的连接方式。
- MHS（2026–）：在 MCP 之上补齐物理层，形成「数字工具 + 物理设备」的完整 Agent 栈。
Anthropic 在 2026 年发布 MHS 研究预览时，与 QuEra、CMU、Janelia、Genentech 等机构完成了现场实测。这些案例证明：Physical AI 的瓶颈不在「会不会写脚本」，而在状态是否可信、边界是否可执行、失败是否可恢复。
四大支柱：Driver、设备描述、状态向量、安全边界
MHS 把复杂硬件世界压缩为四个可工程化的概念：
| 支柱 | 职责 | 典型内容 |
|---|---|---|
| Driver（驱动） | 硬件方言翻译 | Modbus 寄存器 → 状态向量；CAN 帧 → 结构化量 |
| Device Description（设备描述） | 机器可读能力声明 | 可调参数、量程、分辨率、互锁规则 |
| State Vector（状态向量） | 物理世界的「当前快照」 | 值 + SI 单位 + 置信度 + 时间戳 |
| Safety Boundary（安全边界） | 内嵌物理约束 | 硬极限、软建议、模式约束、互 锁 |
四者关系：Driver 负责读写；设备描述告诉 Agent「能做什么、不能做什么」；状态向量是 read 的返回值；安全边界在 write 前强制执行。
# 状态向量 read 返回示例（概念结构）
power_w:
value: 2.48
unit: W
confidence: 0.97
timestamp: "2026-03-05T10:00:00.123Z"
source: primary_sensor
三层架构概览
- 硬件方言翻译层：Modbus RTU/TCP、USB-CDC、CAN-FD、GPIB、EtherCAT、MQTT 等 27 种工业协议的统一适配。
- 状态语义中枢：将电压、转速、像素坐标、激光相位等映射为结构化向量；处理单位换算、噪声估计、时间戳对齐。
- Agent 接口层：通过 MCP、CLI 或代码 API 暴露标准化接口，任何 Agent harness 都能以统一方式与设备对话。
与 MCP / ROS / OPC-UA 的边界
| 技术 | 核心定位 | MHS 与之关系 |
|---|---|---|
| MCP | LLM ↔ 数字工具 | MHS Driver 可注册为 MCP Server；数字与物理分层协作 |
| ROS 2 | 机器人实时中间件 | 机器人底层控制走 ROS；跨领域编排与 Agent 语义走 MHS |
| OPC-UA | 工业数据互操作 | OPC-UA 负责通信与信息模型；MHS 负责 Agent 闭环与安全语义 |
| SCADA | 监控与数据采集 | SCADA 偏人机监控；MHS 偏自主闭环执行与审计 |
| PyVISA / 厂商 SDK | 单厂商仪器控制 | 可作为 Driver 底层，需再封装为 MHS 原语 |
选型口诀：要 Agent 理解物理后果并闭环验证 → MHS；要 μs 级运动控制 → ROS/EtherCAT；要 MES 集成 → OPC-UA；要读文件查数据库 → MCP。
MHS vs ROS：分工而非替代
ROS 2 擅长机器人栈内的实时控制：关节轨迹、SLAM、导航。它的消息类型（sensor_msgs、geometry_msgs）面向机器人领域。MHS 则是跨领域的 Agent 语义层：同一套 read/write 可以描述激光器、离心机、质谱仪和 CNC 机床。典型集成模式：机器人底层关节控制仍走 ROS 2 Action；跨设备实验编排（加热 → 取样 → 成像）走 MHS 编排器，通过 ROS-MHS 桥接 Driver 访问机器人。
MHS vs OPC-UA：语义层 vs 通信层
OPC-UA 提供了 excellent 的工业信息模型与跨平台通信。但它没有定义「Agent 如何闭环验证 write 是否成功」「置信度 低于阈值时是否请求人工」等 Physical AI 语义。MHS 可以在 OPC-UA 之上作为 Agent 接口：Driver 内部用 OPC-UA 读写节点，对外暴露 MHS 状态向量与安全边界。
闭环 vs 开环：范式差异
MHS 闭环的核心价值：文本返回值无法证明物理动作真的发生。只有 read 回来的状态向量才是 ground truth。QuEra 的激光锁频案例（99.3% 成功率）正是依赖这种闭环微调，而非一次性下发设定值。
一线实测案例摘要
| 机构 | 场景 | 结果 | 工程启示 |
|---|---|---|---|
| QuEra Computing | 量子激光锁频 | 99.3% 成功率，最难案例 10–14 秒 | 闭环验证替代人工微调 |
| CMU | 药物剂量反应 | 数周实验压缩至 8 小时 | 6 种故障条件自动拦截 |
| Janelia (HHMI) | 脑成像流水线 | 11 小时 → 23 分钟 | 3 相机 + 激光 + 2 位移台亚微米同步 |
| Genentech | 蛋白质样品处理 | 物理故障识别与恢复 | LLM 需引导区分气泡 vs 配置错误 |
| Cold Spring Harbor | 神经突触追踪 | 全自动闭环成像 | 状态语义层统一多厂商设备 |
Janelia 案例尤其说明多设备编排的价值：传统脚本按固定时序 sleep，无法应对设备个体差异；MHS 编排器每步 read 验证，温度未稳定则等待，位移未到位则重试，整体 wall-clock 反而大幅缩短。
27 种工业协议：统一原语的力量
MHS 不要求 Agent 理解 Modbus 功能码或 CAN 帧格式。Driver 层完成翻译，向上只暴露 read/write。协议矩阵（节选）：
| 协议 | 典型设备 | Driver 关注点 |
|---|---|---|
| Modbus RTU/TCP | PLC、温控、功率计 | 寄存器映射、字节序、超时 |
| CAN-FD | 机器人关节、汽车 ECU | 帧 ID、多主仲裁、DBC 解析 |
| USB-CDC | 实验室串口仪器 | 命令字符串、响应解析 |
| OPC-UA | 工厂产线 | 节点订阅、证书、信息模型 |
| EtherCAT | 运动控制 | 周期同步、CoE/SoE |
| GPIB/IEEE-488 | 示波器、源表 | SCPI 命令、寻址 |
| MQTT | IoT 传感器 | QoS、主题命名、保留消息 |
统一原语降低 Driver 开发门槛：任何可编程硬件，最终都能映射为「读状态、写动作」。
技能实验室与工具体系
MHS 学习生态包含五类实验室（详见 7 天 MHS 子站）：
| 实验室 | 用途 |
|---|---|
| 设备模拟器 | 虚拟激光器 read/write 与闭环修正 |
| 设备描述编辑器 | YAML/JSON 能力声明与安全边界配置 |
| 编排器可视化 | 多设备时序与验证节点实时状态 |
| 状态监控面板 | 状态向量、置信度、通信报文诊断 |
| Driver 工作台 | 协议解析、HIL 测试、边界条件用例 |
本站文档聚焦 MHS 协议概念与工程方法，不是 mhs_frontend 部署教程。子站提供交互演示；文档提供可复用的设计模式。
战略定位：「AI 的 USB-C」
MHS 不绑定硬件厂商：今天接显微镜，明天指挥 CNC 机床。它提供的是Agent 与物理世界之间的标准化语义接口，类似 USB-C 统一充电与数据传输——底层协议可以各异，上层体验一致。
与 MCP 的关系可以类比：
- USB-C 物理口 ↔ MHS 物理层
- 上层应用协议 ↔ MCP 数字层
- 两者协同，而非二选一
谁应该学习 MHS？
| 角色 | 背景 | 目标 |
|---|---|---|
| 软件工程师 | 熟悉 MCP/API | 读懂设备描述，完成第一次闭环控制 |
| AI 应用工程师 | 需接实验室/工业硬件 | 独立开发 Driver，设计安全边界 |
| 架构师 | Physical AI 系统设计 | 多设备编排、生产部署、合规审计 |
学习路径建议
- 建立范式：理解 MCP 开环 vs MHS 闭环（Day 1）。
- 读设备描述：解析能力、边界、互锁（Day 2–3）。
- 写最小 Driver：Modbus 温控 read/write（Day 4）。
- 编排闭环：样品扫描、故障恢复策略（Day 5）。
- 混合智能：神经符号 + 人机回环（Day 6）。
- 生产化：审计、零信任、与 LIMS/MES 集成（Day 7）。
推荐顺序阅读本站文档：
核心设计原则（六条）
- 极简原语：只有 read 与 write，降低 Driver 与 Agent 认知负担。
- 描述驱动：能力与安全来自 Device Description，而非硬编码。
- 闭环默认：write 后应 read 验证，除非 Description 显式声明 fire-and-forget。
- 安全内嵌：边界校验在 Driver 层强制执行，硬件固件为最后防线。
- 协议无关：Agent 不感知 Modbus/CAN，只感知状态向量。
- 可审计：每次 write、越界尝试、人工覆盖必须留痕。
常见问题速览
- MHS 是机器人框架吗？ 不是。它是通用物理设备标准，机器人底层仍可用 ROS 2。
- 需要替换现有 SCADA 吗？ 不需要。MHS 负责 Agent 自主编排；SCADA 仍可做人机监控。
- 规范开源了吗？ 当前为研究预览，规范开源路线见 Day 7 主题。
更多问题见 FAQ。
下一步
完成本文后，建议：
Physical AI 思维模型：设备即动力学系统
传统软件 API 思维把设备当作「函数」：set_power(x) 返回 bool。Physical AI 思维把设备当作有惯性、有噪声、有约束的动力学系统：
- 惯性：write 后状态不会瞬间跳变；激光器热稳定、位移台机械到位都需要时间。
- 噪声：传感器读数有抖动；confidence 字段量化这种不确定度。
- 约束：物理极限与互锁不可绕过；Agent 的规划必须在可行域内。
这种思维转变是 MHS 教育的第一课。Day 1 晚间挑战「激光器 + 位移台 + 相机」多设备场景，正是训练：哪些步骤必须闭环（出光、移动、温控），哪些可以开环（写实验日志到 LIMS）。
状态向量的语义设计深度
状态向量不是简单的 key-value。每个通道应包含：
| 字段 | 含义 | 编排器用途 |
|---|---|---|
| value | 当前测量值 | 与目标比较 |
| unit | SI 或标准派生单位 | 跨设备换算 |
| confidence | 0–1 置信度 | 低于阈值则暂停或人工 |
| timestamp | ISO8601 采样时刻 | 判断新鲜度 |
| source | 主/备传感器标识 | 冗余切换 |
| quality | good/degraded/fault | 快速过滤不可用通道 |
当 confidence 因校准过期而下降时，编排器应自动插入「请求重新校准」节点，而非盲目继续 write。Genentech 案例中 Agent 误把样品气泡当软件错误，部分原因就是缺少对 quality 字段的语义理解。
MCP-MHS 协同架构示例
Agent 调用 MCP tool laser.set_power 时，Bridge 层自动：校验 schema → 映射为 MHS write → read 验证 → 更新 MCP resource laser/state。Agent 看到的仍是熟悉的 tool 接口，底层已是物理闭环。
研究预览与开源路线图
当前 MHS 处于研究预览阶段，面向申请通过的研究机构与先进制造企业。规范完 整开源仍在路线图中（参见 Day 7「生产部署与生态」）。学习阶段应：
- 以概念与模式为主，避免绑定某一未定型 API 细节；
- 用子站模拟器与本文档示例建立心智模型；
- 关注 Driver 与 Device Description 的可移植设计。
与数字孪生的关系
MHS 状态向量可作为数字孪生的实时输入边：物理设备 read → 孪生体同步 → 离线仿真优化参数 → 经审计的 write 回写物理设备。ISO/IEC JTC 1/SC 41 物联网与数字孪生标准与 MHS 设备描述可形成互补：前者管孪生体结构，后者管 Agent 操作语义。
术语对照（中英）
| 中文 | 英文 | 说明 |
|---|---|---|
| 状态向量 | State Vector | read 返回的结构化物理量集合 |
| 设备描述 | Device Description | 能力与安全声明文件 |
| 安全边界 | Safety Boundary | 硬/软限制与互锁 |
| 闭环 | Closed-loop | write → read → verify → correct |
| 人机回环 | Human-in-the-loop | 关键决策点人工确认 |
| 硬件在环 | HIL | 用真实或仿真硬件验证 Driver |
阅读地图与文档关系
建议首次阅读顺序：intro → getting-started → from-zero-to-one（制定计划）→ development → best-practices。github-projects 与 faq 可按需查阅。
结语
MHS 不是要再造一个 ROS 或 OPC-UA，而是为 Physical AI 时代补全最后一块拼图：让 Agent 像经验丰富的实验员一样，先看仪表，再动手，动完再确认。当你能在模拟器里完成一次完整的 write-read-verify 循环，并解释为何 MCP 的 "OK" 不够用时，你就已经踏上了 MHS 工程师之路。