Anthropic MHS 能直接接实验设备吗？2026 试点验收清单

设备已经能被 MHS 发现，Agent 也能发出命令，但你还不确定一次错误调用会不会变成真实的物理故障。
最快解法：不要直接开放自动控制，先按“离线模拟 → 只读监控 → 单设备有限写入 → 多设备编排 → 无人值守”逐级验收，并把硬件限位、人工批准和紧急停止放在模型之外。

谁应该看这份 Anthropic MHS 验收清单

科研实验室负责人，可以用它判断现有仪器是否具备进入 MHS 试点的接口和安全条件。
自动化与机器人工程师，可以用它核对驱动、设备状态、写操作和物理限位是否闭环。
Agent 平台负责人，则需要重点关注隔离控制环境、远程监控、日志留存和故障恢复。

最后更新于 2026 年 9 月 2 日，状态核实自 Anthropic 的 MHS 公告 与 MHS 官方申请页面。

先看清 MHS 的开放边界，再决定是否接入实体设备

Anthropic 于 2026 年 8 月 27 日宣布 MHS 进入限量研究预览。官方定位是：让 AI Agent 通过标准化驱动操作具备可编程接口的物理设备，并通过 MCP、命令行和代码文件完成控制与编排。MHS 还没有正式开源，完整规格、公开 SDK 和商业化范围也不能自行推测。

这意味着“能连接”只证明通信链路可能成立，不证明以下条件已经成立：

• 设备能力、单位和状态字段都被正确解释；
• Agent 生成的参数会被设备层拒绝越界值；
• 多个设备之间的先后关系不会被错误重试打乱；
• 控制节点断线后，设备会自动进入安全状态；
• 物理故障不会被模型误判为软件异常。

Anthropic 公布的案例已经说明了最后一个风险。Genentech 的液体处理测试中，黏稠蛋白溶液产生泡沫，Claude 初始倾向于在同一孔位重试，结果反而加剧了气泡问题；研究人员必须明确告诉它，这是液体物理状态导致的失败，而不是普通软件错误。

因此，你的验收对象不是单独的模型，也不是单独的 MHS 驱动，而是下面这条完整链路：

Agent 决策 → MCP 或其它通信层 → MHS 设备驱动 → 设备控制器 → 物理限位与急停系统。

其中，MCP 主要解决 AI 应用如何连接外部工具、数据源和工作流；MHS 更接近设备驱动和硬件能力描述层。两者不能互相替代。(MCP 官方说明)

按权限提升选择试点路径

这张表的关键不是“最终能不能全自动”，而是每一级都要有可保存的证据。NIST 的 AI 风险框架同样强调，AI 系统应在部署前和运行中持续测试，并通过监控、人工介入、修改或关闭机制处理偏离预期的行为。(NIST AI 风险管理框架)

离线模拟：先证明驱动不会把错误带到设备层

第一阶段不要接真实执行器。你可以使用模拟器、虚拟设备状态、厂商测试接口，或者只返回状态而不执行动作的沙盒驱动。

验收时，先确认团队手里的材料到底属于哪一种：

• MHS 研究预览资格；
• 官方公开说明；
• 合作方提供的示例；
• 自行编写的兼容层。

不能把公告里的概念验证当作已经开放下载的正式标准。官方页面当前仍显示 MHS 处于研究预览阶段，不能据此推断正式开源日期、完整 SDK 或普遍商业可用范围。

模拟阶段至少测试四类输入：

• 设备发现：能否识别设备名称、能力、单位和状态；
• 命令格式：缺字段、错类型、空值和未知命令如何处理；
• 异常返回：设备忙碌、超时、状态不一致时是否明确报错；
• 状态转换：启动、暂停、完成、失败和取消是否能形成可追踪记录。

要保存驱动清单、状态转换记录、原始命令、返回值和失败日志。只要 Agent 需要“猜测”某个字段的含义，或者错误返回只显示成模糊的文本，就不要进入实体设备阶段。

单设备只读：先验证状态，再谈自动动作

实体试点应从风险最低、接口最清楚的设备开始。第一步只开放温度、位置、液位、运行状态、传感器读数和日志读取，不开放移动、加热、加液、激光调节等写操作。

你需要把 MHS 描述的设备能力逐项对照厂商手册和现场标定记录：

• 单位是否一致；
• 量程是否一致；
• 状态标签是否对应真实状态；
• 传感器时间戳是否可靠；
• 设备报告的“空闲”是否真的代表可以接收命令；
• 数据延迟是否会让 Agent 使用过期状态。

不要把自然语言安全标签当成不可绕过的物理防护。标签可以帮助 Agent 理解设备，但真正的保护必须由设备控制器、硬件限位、独立联锁或急停回路执行。

出现状态漂移、字段无法解释、时间戳倒退或读数延迟异常时，动作只有一个：停止升级权限，回到日志和设备手册核对。不要让 Claude Code 通过试错推断设备含义。Claude Code 可以帮助生成驱动、测试代码和诊断脚本，但它仍然是 Agent 的工作台或执行入口，不是设备安全系统。(Claude Code 官方入门说明)

单设备有限写入：把硬校验放在模型之外

当只读阶段稳定后，才可以开放有限写入。参数必须来自预先批准的范围，例如固定的温度区间、速度区间、位置窗口或单次操作上限。具体范围应由设备工程师和实验负责人定义，不能让模型从自然语言描述中自行推导。

设备层至少要拒绝以下情况：

• 参数低于或高于允许范围；
• 同一命令在短时间内重复提交；
• 设备处于忙碌、维护或报警状态；
• 前置条件未满足；
• 通信超时后无法确认命令是否已经执行。

测试时不要只跑成功样例。故意提交越界值、重复命令、设备忙碌命令和通信中断，确认设备会拒绝、暂停或进入安全终止状态。高风险动作仍然需要人工批准、物理急停和独立控制台。

⚠️ 经验提醒：如果“安全”只写在系统提示词、MHS 标签或 Agent 规则里，而设备控制器本身接受任何数值，那么这不是硬件安全边界，只是一个可能被错误调用绕过的软件约束。

多设备编排：验证交接顺序，而不是只看单机成功

液体处理器、机械臂、读数设备和相机单独运行正常，不代表组合运行安全。多设备阶段真正要测的是状态依赖：

• 前一步未完成时，后续设备是否仍会动作；
• 工件缺失时，机械臂是否会继续移动；
• 读数设备离线时，流程是否会错误地把空结果当成合格结果；
• 一个设备返回旧状态时，调度器是否会重复执行；
• 设备顺序冲突时，系统能否阻断交接。

Anthropic 的公开案例中，MHS 被用于连接液体处理器、机械臂和微孔板读数设备，也被用于显微镜、相机和激光系统等组合场景。但这些都是特定合作环境下的概念验证，不能外推成普遍兼容性或安全保证。

你应当把责任拆开记录：

• MCP：负责 Agent 与工具或服务之间的通信；
• MHS 驱动：负责设备能力、状态和读写命令的标准化表达；
• Agent：负责计划、判断和高层次编排；
• 确定性脚本：负责已批准的高速、重复和可恢复步骤；
• 设备安全系统：负责限位、联锁、急停和不可接受动作的阻断。

MHS 的公开说明还提到，长任务或高速操作可以把驱动命令串成代码文件，让设备在不需要 Agent 每一步重新推理的情况下执行。你应把这类脚本当成受控执行单元，而不是让 Agent 在每个物理动作上自由重规划。

长任务与无人值守：先验证失败后还能不能恢复

一次演示成功，不能证明长时间实验可以无人值守。你至少要模拟：

• 上下文丢失；
• Agent 进程崩溃；
• 控制节点断线；
• 重复重试；
• 目标在多轮对话中发生偏移；
• 设备已经执行动作，但返回结果丢失。

关键步骤应写入可恢复的确定性脚本，并设置运行时限、重试上限和人工接管条件。重试必须区分“命令未发送”“命令已发送但未确认”和“命令已执行但返回丢失”，不能把三种情况都当成普通失败再执行一次。

公开案例中，QuEra 的激光恢复试验在特定开发和盲测条件下报告了 99.3% 的无人干预恢复率；同一案例还披露，早期脚本约 58% 成功、每次约 150 秒，后续开发运行约 6 秒、约 96% 成功。这些数字只适用于该激光系统、测试流程和实验条件，不能直接作为你的设备验收门槛。

远程运行时，持续计算环境应与个人工作区分离。不要让实验控制节点同时保存个人 SSH 密钥、无关项目代码、实验原始数据和设备管理员凭据。长任务 Agent 的工程实践也要求将会话日志、执行环境和工具权限拆开，避免不受信任代码直接接触凭据，并让故障后的会话可以从持久化事件记录恢复。(Anthropic 长任务 Agent 工程说明)

远程控制与恢复：用里程碑决定维持还是回退

最后验收远程控制节点。你需要确认它具备独立账号、最小权限、网络白名单、命令审计和会话回放能力。远程节点断线后，设备不能继续执行不受控的后续动作。

建议按下面的里程碑推进：

里程碑一：离线证据完整。
驱动清单、状态转换、异常返回和失败日志齐全。未完成就不接实体设备。

里程碑二：只读闭环成立。
设备状态与现场读数、手册和日志一致。出现字段漂移就回退。

里程碑三：有限写入可阻断。
越界、重复、忙碌和通信中断都能被设备层或确定性执行器安全处理。

里程碑四：多设备交接可停止。
设备离线、工件缺失和顺序冲突不会触发危险动作。

里程碑五：远程恢复可验证。
模拟控制节点失联、Agent 崩溃和错误参数下发后，设备能进入安全状态，并由人工从独立控制台恢复。

NIST 的相关人机交互与风险管理建议强调，持续监控、人工覆盖、事件响应和恢复都应成为部署后的控制环节。对实体设备而言，这些要求应落到具体命令、具体账号和具体恢复动作，而不是停留在政策文档里。(NIST 人工智能风险管理与人机交互资料)

现场验收可勾选清单

• [ ] 已核对 MHS 访问资格、公开说明和合作方示例的边界。
• [ ] 已确认目标设备具备可编程接口。
• [ ] 已完成模拟器或虚拟设备测试，且未连接真实执行器。
• [ ] 已保存驱动清单、命令记录、状态转换和失败日志。
• [ ] 已完成单设备只读测试，并逐项对照厂商手册。
• [ ] 已验证单位、量程、状态标签和时间戳。
• [ ] 已测试越界参数、重复命令、设备忙碌和通信中断。
• [ ] 已把硬校验、硬件限位和急停放在模型之外。
• [ ] 已区分 MCP、MHS 驱动、Agent、确定性脚本和设备安全系统。
• [ ] 已模拟设备离线、工件缺失和顺序冲突。
• [ ] 已设置运行时限、重试上限和人工接管条件。
• [ ] 已将凭据、实验数据和个人工作区从控制节点隔离。
• [ ] 已完成日志审计、会话回放和人工恢复测试。
• [ ] 已根据证据选择只读、有限写入或暂缓实体试点。

结论：优先选择可回退的控制方案

如果你的现有方案是把 Agent 直接部署在个人电脑、共享服务器或普通云主机上，它通常会有几个真实缺点：凭据和实验数据容易混在一起，断线后不一定能恢复上下文，日志可能无法完整回放，设备权限也容易随着开发工具一起扩大。直接让 Claude Code、MCP 和设备控制脚本共处一个工作区，短期演示很快，长期试点却难以证明边界。

更稳妥的做法是把 MHS 作为受控设备接口，把 Agent 当作高层决策者，把确定性脚本和设备自身安全系统放在更低层，再为持续运行的 Claude Code、模拟驱动和远程监控控制台准备隔离环境。若你需要临时搭建这种远程 Mac 控制节点，可以先查看 MacPng 的远程环境帮助说明，再根据任务持续时间和数据隔离要求了解 MacPng 的 Mac 使用方案。

最终只保留三档结论：证据不足就暂缓；只读稳定就维持只读；有限写入和恢复测试全部通过，才考虑扩大到多设备或无人值守。