MHS 让 AI Agent 有了“手”，你的产品仍需要一份物理效果契约

Anthropic 与 HHMI Janelia 开放了 Model Hardware Standard（MHS） 的研究预览。它希望用一套共享接口，让 AI Agent 能发现并操作可编程的物理设备。官方材料列出的对象包括显微镜、移液工作站、摄像头、激光器、机械臂，以及其他实验室或制造设备。Agent 不仅可以读取设备状态、修改参数、协调多台仪器，还能把学到的操作步骤封装成确定性代码。

这不是普通的 API 更新。过去，AI 应用大多停留在“提出建议”或“修改数字记录”；现在，它越来越可能直接引发运动、加热、加压、液体转移、光照或机器状态变化。

但 MHS 目前仍是申请制的有限研究预览，官方计划后续再开源。它不是已经发布的安全认证，也不是覆盖所有设备的最终 schema，更不能证明模型理解每一台机器背后的物理规律。Anthropic 自己公布的 Genentech 案例恰好说明了这一边界：Claude 找到了合理的液体流速，但遇到气泡相关错误时，最初选择在同一个孔位重试，反而让真实的物理情况变得更糟。

因此，对非技术创始人和小型 AI 产品团队来说，今天最重要的问题不是“Agent 能不能连上硬件”，而是：在软件获准造成物理效果之前，哪些条件必须持续成立？

本文把 MHS 热点转化为一份可执行的上线工具：物理效果契约。它把设备身份、校准状态、允许动作、审批、独立安全控制、执行证据与恢复路径绑定在一起，并给出一个完整实验室场景、一张决策矩阵、八项故障演练，以及明确的“观察、建议、仿真、执行”边界。

MHS 改变了什么，又没有证明什么

Anthropic 的发布说明把 MHS 描述为面向可编程设备的标准驱动层。驱动提供简单的读写原语，例如“读取温度”或“设定温度”；同时让设备可被发现，并生成一份参考文件，描述设备特性、可调参数、测量能力和会被强制执行的安全限制。Agent 可以通过 MCP、命令行或代码访问设备。

这能减少真实存在的集成成本。一台显微镜、一台酶标仪、一只机械臂和一台移液工作站，可能分别使用不同厂商 API、数据格式和控制程序。统一接口让一个编排层看到所有设备，不必为每一对设备都新写一层“翻译器”。MHS 也支持长任务：Agent 可以把多个驱动调用组合成代码，让设备流程不需要模型在每一个毫秒都在线推理。

不过，这个预览仍有清晰边界。MHS 官网说明目前需要申请访问，并邀请参与者在开源前共同完善安全评测和最佳实践。现有公开材料还没有给出稳定的开放规范、完整的一致性测试套件、认证流程、威胁模型、版本兼容矩阵或独立复现包。

团队尤其要拆开四个容易被混为一谈的结论：

可互操作：控制端能通过规定接口与设备交换命令和状态。
可控制：请求的变化确实能到达执行器或设备流程。
操作正确：在当前物理条件下，动作产生了预期结果。
安全：即便模型、驱动、传感器、网络、设备、环境或人工流程出错，可预见的后果仍落在已接受的风险范围内。

MHS 明显推进了前两项；早期案例为特定流程中的第三项提供了有价值但有限的证据。第四项仍然是具体应用与整套系统的责任。

连接设备前，先把术语说清楚

物理产品最危险的时刻，往往是团队用同一个词代替了多个完全不同的控制。至少要统一以下定义：

能力（capability）：软件接口能够请求的动作，例如设定温度、移动机械臂、打开阀门或停止一次运行。
运行边界（operating envelope）：针对某个已批准任务，设备、材料、工作空间和人员条件允许落入的范围。它通常远窄于设备的全部技术能力。
联锁（interlock）：不依赖 Agent 判断、能够阻止或中断危险状态的控制，例如防护门开关、力限制、行程限制或独立温控断路器。
审批（approval）：具名责任人对具体动作计划、设备、材料、参数范围和时间窗口的授权。“把实验跑一下”这样的聊天消息不算审批。
执行收据（execution receipt）：记录什么命令在什么状态与限制下到达哪台设备，以及实际观察到什么结果。它不是 Agent 自己写的总结。
安全状态（safe state）：发生停止、超时、断网或故障后，系统应进入的物理状态。设备“不动了”未必安全，因为热量、压力、储能或危险样本可能仍未受控。
恢复权限（recovery authority）：为了控制故障而授予的有限权限。它不能悄悄扩大为“临场设计一套新实验”的权限。

这些区分很重要。模型可能正确选择 API 调用，却依赖了过期传感器数据、错误夹具或错误样本；也可能在有人进入工作区时移动设备，或在第一次失败已经改变材料后继续重试。

把 MHS 当作接口，不要把它当作安全控制器

当前的 MCP 工具规范说明工具由模型控制，建议让人类保留拒绝调用的能力，并要求客户端把工具 annotation 视为不可信信息，除非它来自可信服务器。规范还要求输入校验、访问控制、限流，并建议对敏感操作进行确认、设置超时和保留审计日志。

这些都是重要的软件控制。但物理设备多了一条更硬的边界：模型、MCP host、MHS 驱动和自然语言设备标签，不应成为唯一能阻止人身伤害或设备损坏的组件。一个看起来可信的工具说明不是安全等级电路；JSON schema 可以拒绝 temperature: "hot"，却不能证明温度读数足够新、传感器校准有效、阀门真的动作了，或人员已经离开危险区域。

成熟的机器人安全资料更强调控制的独立性和后果。OSHA 技术手册的机器人章节讨论了安全等级监控停止、速度与距离监控、功率与力限制。OSHA 那份较早但仍有参考价值的机器人安全指南指出，紧急停止应覆盖其他控制；如果机器人可能造成严重危险，应采用冗余和备份系统。

对 AI 产品而言，原则很简单：Agent 在批准的边界内操作，独立控制负责强制守住边界。 联锁不应依赖模型是否注意到、是否同意、是否在线，也不应依赖模型能否正确描述现场。

建立七层物理效果契约

创始人不需要阅读运动控制代码，也能审查一个 AI 硬件功能。要求团队为每个生产流程完成以下七层：

层级	必须提供的证据	必须停止的情况
1. 设备身份	资产 ID、驱动版本、固件、负责人、物理位置	设备未知或被替换
2. 状态有效性	校准 ID、传感器时间、夹具/材料身份、人员占用状态	状态过期、缺失、矛盾或越界
3. 动作边界	允许命令、单位、范围、速率、顺序、工作空间	单次命令或累计效果超出边界
4. 计划校验	仿真/空跑、碰撞或约束检查、预期状态转移	计划无法评估或偏离已批准任务
5. 权限	具名审批人、精确参数、过期时间、必要时双人审批	审批过宽、已过期或没有绑定可执行计划
6. 独立保护	防护装置、限位、PLC/安全控制器、断路、急停	保护不可用、被绕过、未测试，或只由 Agent 控制
7. 效果与恢复	命令日志、设备确认、独立观察、安全状态结果	结果不明确，或恢复需要扩大权限

顺序是刻意设计的。身份先于遥测：来自错误设备的“新鲜数据”依然是错的。状态先于计划：依据昨天夹具地图得出的正确路径，今天可能并不安全。审批必须发生在可执行计划形成之后：用户不能先批准一个模糊意图，再在机器开始动作后才知道具体参数。收据同时需要命令证据和观察证据，因为“设备接受了请求”不等于物理效果真的发生。

不要只把这些内容放进政策文档。它应成为应用在执行前编译、执行后补全并保存的产品对象。

复用这份契约模板

下面的例子刻意采用创始人、操作员、安全负责人和工程师都能读懂的结构。它不是 MHS schema，也不应冒充 MHS 官方格式；它是产品侧的控制记录，可以引用团队实际采用的驱动和协议版本。

yaml

physical_effect_contract:
  contract_id: pec-2026-08-28-0042
  product_workflow: protein-assay-transfer
  risk_owner: lab-operations-lead

  device:
    asset_id: liquid-handler-lh07
    location: lab-a-cell-3
    driver_version: mhs-preview-build-verified-in-test
    firmware: 5.12.4
    permitted_capabilities: [aspirate, dispense, read_status, stop]

  state_requirement:
    calibration_id: cal-lh07-2026-08-27
    max_sensor_age_seconds: 2
    material_lot: bsa-lot-184
    plate_id: plate-96-8841
    workspace_occupancy: clear

  envelope:
    volume_microliters: {min: 5, max: 100}
    flow_microliters_per_second: {min: 8, max: 15}
    max_retries_per_well: 0
    allowed_wells: [A1, A2, A3, A4]
    forbidden_conditions: [foam_detected, tip_pickup_uncertain]

  authority:
    approved_plan_hash: sha256:...
    approver: operator-217
    expires_at: 2026-08-28T11:30:00+09:00

  independent_protection:
    interlock_check_id: preflight-55018
    emergency_stop_tested_at: 2026-08-28T08:45:00+09:00
    safe_state: motion_stopped_and_pressure_released

  outcome:
    command_receipt_required: true
    observation_required: [plate_image, pressure_trace, volume_check]
    ambiguous_effect_action: stop_and_quarantine_plate

这份记录里最重要的并不是模型名或 prompt，而是具体物理资产、当前状态、累计动作范围、已批准计划的哈希、独立保护和“效果不明确时怎么办”。其中任何一项改变，都应生成新契约或让旧契约失效。

具体场景：一个气泡，如何让“重试”变成进一步破坏

假设一家小型生物科技团队正在做自然语言实验助手。研究员要求它把黏稠蛋白样本转移到 96 孔板，再读取吸光度。产品通过标准设备驱动，把语言模型连接到移液工作站和酶标仪。

在环境干净的演示里，Agent 选择正确孔位、转移指定体积并记录读数。团队很容易顺手加入自动重试，因为软件 API 遇到瞬时故障时，重试往往能恢复。

真实物理系统并非如此。过快混匀产生了气泡，液位传感器报错。继续在同一个孔位重试会进一步搅动样本，所以故障后的状态已经不同于第一次动作前的状态。原先的幂等假设不成立。

这不是我们强加在发布材料上的假想风险。在 Anthropic 公布的 Genentech 案例中，Claude 一开始为水和黏稠的 BSA 样本使用通用流速，随后才分别优化出不同参数。案例还说明，出现由气泡导致的运行错误时，它最初倾向于在同一个孔里更换参数重试，结果产生更多气泡。人类需要告诉它换到干净孔位并减少混匀；这些经验后来才被写进可复用 skill。

这个场景带来的产品结论远超移液：

失败的数字调用可能没有留下效果；失败的物理调用可能改变材料、能量、几何位置、污染状态或人员占用条件。
一个设备错误码只说明某个控制器检测到了什么，不一定解释真实的物理根因。
恢复是在已经变化的状态上执行新动作，不是原始意图的自然延续。
skill 可以改善默认参数，但它不能替代压力限制、防护区域、材料规则或独立停止装置。

因此，模板里的 max_retries_per_well: 0 是明确的产品决策。Agent 可以停止、保留证据并提出恢复计划，但不能擅自假设样本仍与失败前一样。

把观察、建议、仿真和执行拆成四种发布模式

许多团队会从“Agent 能读取仪器”直接跳到“Agent 应该控制仪器”。更稳妥的做法是采用四级发布：

模式	Agent 可以做什么	最低证据要求	合适的第一步
观察	读取状态并告警	设备身份、时间戳、数据质量	远程监控和异常分诊
建议	提出参数或动作顺序	证据链接、参数边界、具名审核人	专家决策支持
仿真	在数字或无害环境里执行	模型保真度、场景覆盖、仿真到现实差距	计划与碰撞测试
执行	造成真实物理效果	完整契约、独立保护、收据和恢复路径	狭窄且已验证的生产任务

默认应该一次只升级一级。一个监测 qPCR 曲线接近阈值的 Agent，可以先提醒研究员；之后再建议停止。只有团队理解误报、漏报、传感器新鲜度、用户响应时间和安全 fallback 后，才应给它狭窄的停止权限。

仿真很有用，但不是魔法。模拟器可能没有气泡、电缆拖曳、磨损夹爪、脏镜头、机械回差、校准漂移或现场人员的临时操作。AWS 与 Hugging Face 的 Strands Robots 示例默认让机器人构造器进入仿真，只有显式指定 mode="real" 才连接真机。团队应把这个开关当作一次正式 promotion：两种模式使用不同凭证、审批、网络路径和日志，而不是把它看成一个无害参数。

真实试点前，先做八项故障演练

不要一上来只测对抗 prompt。先测试那些普通、常见、而且“热心的 Agent”最容易处理错的物理故障。

错误设备演练： 换成同型号但资产 ID 或固件不同的设备。系统必须在读取状态或产生运动前拒绝。
状态过期演练： 冻结传感器时间戳，但保留看起来合理的数值。Agent 不能因为数值正常就推断数据足够新。
单位演练： 用另一种单位或数量级提交有效参数。换算必须显式、有范围限制，并在审批界面可见。
批准后变更演练： 计划获批后移动夹具或更换材料批次。旧计划哈希必须立即失去执行权限。
通信中断演练： 在流程中途断开 Agent、驱动或网络。设备必须在没有模型推理的情况下进入或维持已定义的安全状态。
效果不明演练： 设备接受命令后，让调用端收到超时。系统必须先观察，再决定是否重试，并隔离不确定结果。
联锁缺失演练： 在软件路径完全健康时，让防护门、停止装置或限位报告不可用。真实执行必须保持禁用。
恢复越权演练： 让修复方案需要新孔位、新工具、新路线或更大参数范围。系统必须创建新契约，不能拉伸旧授权。

演练应保持无害：使用惰性材料、低速度、低作用力、空工作区、模拟故障，并由受训人员操作。目标不是让通用模型“证明安全”，而是证明系统会在可预见的不确定性出现时限制模型权限。

把停止、安全状态和重新启动设计成三个动作

很多场景确实需要红色急停按钮，但“停下”没有一种适用于所有设备的结果。机械臂可能需要切断动力；样本舱可能仍要维持温度；加压管线可能要受控泄压；激光器可能需要关闭发射，但保留冷却。

合并后的欧盟机械法规要求在能降低风险的场景配置紧急停止装置，规定停止控制优先于启动控制，并明确解除急停本身不得导致设备重新启动。对于遥控机械，它还描述了在失去控制、收到停止信号、安全相关部件故障，或规定时间内没有验证信号时自动停止。

把这套系统逻辑转成三个独立产品状态：

已请求停止： 某个控制要求危险运动或流程结束。
已验证安全状态： 独立观察确认系统已经进入针对该任务定义的受控状态。
已授权重启： 人员或另一套政策在检查原因、设备状态、工作空间与新契约后，批准产生新的动作。

不要允许 Agent 把“设备已确认停止”改写成“现场安全”，也不要把“故障已清除”改写成“允许重启”。执行界面应分别展示三个状态，并标明证据来自哪套系统。

衡量被接受的物理结果，不要只数成功的工具调用

MHS 调用返回成功，是有用的运行遥测，但它不是产品结果。

每个流程都要定义独立验收方式。一次液体转移可以要求质量、压力、图像或下游实验数据；一次机械臂交接既要两台设备报告兼容状态，也可以要求摄像头或夹具传感器确认孔板位置；一次激光对准应验证实测输出落入公差，而不是只看电机动作序列完成。

至少追踪以下指标：

每次尝试产生的被接受物理结果；
因效果不明确而被隔离的次数；
安全控制器介入次数；
执行前后的人类纠正；
每个被接受结果消耗的材料、能源、设备与操作员时间；
需要扩大权限的恢复尝试；
按设备、驱动、固件、模型、计划版本和环境条件拆分的故障。

NIST 的机器人 Physical AI 与数据生成项目强调，真实表现取决于 AI 算法、机器人系统和任务三者的组合。这才是合适的衡量单位。“模型成功了”会隐藏真正决定结果的硬件、夹具、校准、控制器、环境与验收规则。

避免最危险的产品误读

以下说法都超出了今天已有证据：

“标准会强制执行安全限制，所以流程已经安全。” 限制可以很有价值，但还要看它是否完整、配置正确、独立实现、经过具体应用验证，并且能应对组件故障。 “自然语言设备标签已经包含专家知识。” 标签能把隐性知识显式化，也可能不完整、过期、含糊，或由无权决定的人填写。它需要版本、审批和边界行为测试。 “Agent 能从错误中恢复，所以以后可以少安排人。” 能处理已知软件或设备错误，不等于能正确处理已经变化的物理状态。Genentech 案例同时展现了自主性和物理直觉的局限。 “模型写出的确定性脚本比在线推理更安全。” 经过审核的脚本确实可以减少运行时波动，也可能更快、更持久地重复错误动作。它仍需绑定计划哈希、运行边界、当前状态和独立中断路径。 “开源后，这套标准自然就获得认证。” 开源有利于检查与集成，但不会自动带来一致性认证、安全完整性、责任分配或对具体设备与任务的验证。 “操作员点一下确认，动作就安全了。” 人可能批准了错误目标、忽略变化条件，或习惯性点击确认。界面必须展示具体物理资产、参数、工作空间、材料、预期效果和不可逆边界；硬控制仍要独立于确认流程。

这套框架适用于哪里，又不适用于哪里

当 AI 功能能够控制或编排可编程设备，并可能影响人员、贵重设备、样本、库存、设施或环境时，应该使用物理效果契约。典型场景包括实验室自动化、工业机器人、无人机、可移动视场的摄像设备、楼宇控制、农业设备、测试台架，以及部分消费设备。

如果 AI 生成的代码文件会在稍后被放到硬件上运行，这套框架同样适用。延迟执行并没有消除物理效果，只是把授权时点移到了别处。

本文不是机械安全设计、法规判断，也不能替代合格的系统集成商、安全工程师、实验室操作员或领域专家。高后果设备可能需要认证安全部件、正式危害分析、经验证的程序、培训、防护装备、维护计划和特定司法辖区合规。这些都不是一份应用层契约可以替代的。

如果团队无法明确设备身份、验证状态新鲜度、限制累计效果、独立停止流程、观察真实结果或控制不确定后果，就不要让通用 AI Agent 执行真实动作。此时应停留在观察、建议或仿真模式。

创始人的 48 小时检查清单

如果 MHS 或其他硬件接口让一个物理 Agent 功能突然变得可行，接下来两天最值得做的不是连接所有设备，而是缩小产品边界。

前四小时：

指定一个任务、一台物理资产、一位责任操作员和一个可验收结果。
列出任务可能影响的所有人员、材料、能量、设备和空间。
标记当前发布模式：观察、建议、仿真或执行。

第一天结束前：

为该任务完成七层契约。
标出哪些保护独立于模型、host、网络和驱动。
分别定义停止、已验证安全状态和重启授权。
对任何会改变物理状态的故障，移除自动重试。

第二天：

使用惰性材料、低能量或仿真完成八项故障演练。
验证设备变化、传感器过期、审批过期和联锁缺失都会阻断执行。
生成一份命令收据和一份独立效果观察。
记录谁有权修改设备标签、动作边界、驱动、代码序列和恢复规则。

最后做一个有边界的决定：

决策	证据门槛
继续观察	状态数据有用，但执行控制还不完整
试点建议模式	专家可以在任何物理变化前验证建议
试点执行模式	一个狭窄任务通过完整契约和演练，并有独立保护
暂缓	身份、状态、联锁、结果或恢复仍不明确

MHS 让连接层更容易处理。也正因为如此，产品团队更需要把权限层写清楚。上线问题不再只是“Agent 能不能触达机器”，而是每一个物理效果能否在执行前被限制、执行中被独立中断、执行后被真实验证。

参考资料