Anthropic 推出 Model Hardware Standard:让 AI Agent 走进真实硬件

AI Agent 正在从软件界面走向真实设备,但让一个 Agent 同时操作显微镜、液体处理器、摄像头和机械臂,难点通常不在模型会不会调用工具,而在每台设备都有自己的接口、状态和安全限制。8 月 27 日,Anthropic 宣布开放 Model Hardware Standard(MHS)的研究预览,邀请一批科研实验室和先进制造企业共同测试这套面向物理设备的标准。

MHS 的思路很朴素:给设备配一个标准驱动,让它用统一的方式描述能力、读取状态和接受控制,再让 Agent 通过 MCP、命令行或 API 进行编排。它还没有开源,也不是一套拿来即用的通用机器人系统,但已经把一个重要问题摆到台面上:当 AI 开始影响现实世界,模型和硬件之间需要怎样的接口,才能既方便组合,又不把安全责任藏在 Prompt 里。

MHS 试图解决什么问题

实验室和工厂里的设备往往来自不同厂商。显微镜、机械臂、液体处理器和读板机可能分别使用桌面软件、私有 SDK、串口协议或网络服务,设备之间也未必共享状态。要把它们串成一条流程,通常需要为每种组合编写专用的转换程序,集成周期可能以周或月计算。

Anthropic 对 MHS 的描述是,它希望把这类工作压缩到小时或分钟级别。这个时间判断属于项目方对早期方案的介绍,并不代表所有设备都能达到同样效果。MHS 当前只适用于具有可编程接口的硬件,缺少编程接口的设备仍然需要厂商先补上适配层。

它要统一的不是设备内部的控制算法,而是设备对外暴露的方式。设备仍然可以保留自己的驱动、校准逻辑和厂商软件,只要通过 MHS 驱动提供一组可发现、可调用、可验证的能力。

技术结构:驱动、描述和控制分成三层

从 Anthropic 公布的介绍看,MHS 可以拆成三个相互配合的部分。

1. 驱动把设备差异藏在适配层里

MHS 驱动位于操作系统和硬件之间,负责把设备自己的接口翻译成标准化的基本操作。公开介绍中给出的例子是 readwrite:前者可以读取温度,后者可以设置温度。对其他设备来说,同样的原则可以映射到读取位置、调整速度、启动采集或设置曝光等动作。

这里的关键不是把所有设备硬套成同一种模型,而是让 Agent 能以统一方式发现和调用能力。具体动作仍应保留设备自己的参数、单位、状态和错误信息,否则统一接口只是把差异推迟到更难排查的地方。

2. 设备描述把隐含知识变成机器可读信息

仅有函数名还不够。一个机械臂的重量、活动范围和负载限制,可能不会出现在简单的代码签名里,却直接关系到操作是否安全。实验室设备的样品容量、温度上限、耗材要求和校准状态也一样重要。

MHS 允许用户用自然语言标签补充这类设备特征,再自动生成参考文件,说明设备可以测量什么、可以调整什么,以及哪些安全限制会被执行。这个设计的价值,在于把过去藏在纸质手册、个人电脑或专家经验里的信息,放到驱动和设备描述中,成为 Agent 规划时可以读取的上下文。

但自然语言描述不能代替硬限制。标签适合解释用途和约束,温度上限、行程范围、最大负载等关键规则仍应由设备控制器或独立策略层强制执行。只写在文档里的安全边界,对错误的模型输出没有足够约束力。

3. Agent 通过多种入口编排设备

Anthropic 提到的三种控制机制是 MCP、命令行界面和代码文件,也就是 API。它们分别适合不同层次的任务:MCP 可以让支持该协议的 Agent 发现和调用设备能力,命令行适合脚本和人工排查,代码文件则适合把已经验证过的步骤固化下来。

一个实验流程可以抽象成下面这样:

1
2
3
4
5
6
7
8
9
10
11
发现设备与能力

读取状态和安全限制

检查前置条件

按顺序调用多个设备

读取结果并调整参数

把稳定步骤固化为确定性脚本

这条链路里,Agent 更适合负责跨设备的计划、判断和异常分流,设备驱动负责具体控制,确定性代码负责高频、长时间或对时序要求严格的操作。Anthropic 描述了一个激光校准例子:Claude 观察摄像头反馈,调整激光,再根据结果重复尝试,最后把学到的步骤写成无需每一步都经过模型推理的确定性脚本。

这是一种值得借鉴的分工。让模型参与每一次电机移动或采样动作,既慢又难以复现;让模型先探索并生成经过验证的程序,再让程序执行稳定流程,通常更容易控制延迟、成本和风险。

早期案例说明了什么

Anthropic 公布了多个合作方的研究预览案例。Genentech 用 MHS 连接液体处理器、机械臂和读板机,验证自动化 BCA 蛋白检测流程;华盛顿大学 Baker 和 Pinglay 实验室用它做仪器监控、qPCR 流程控制以及机械臂和液体处理器之间的板位交接;卡内基梅隆大学则把分布在三台电脑上的液体处理器、读板机、机械臂和摄像头串起来,进行连续稀释实验。

这些例子有一个共同点:价值来自跨设备协调,而不是单个设备突然变聪明。MHS 把原本分散的控制接口放进同一个 Agent 能够理解的工作空间,Agent 才能观察一个设备的输出,并把它作为另一个设备的输入或下一步决策依据。

QuEra 的案例还提到,Agent 参与了中性原子量子计算机中的激光稳定工作,并在项目方报告的早期测试中有 99.3% 的概率自动恢复激光锁定。这个数字来自 Anthropic 对合作案例的介绍,不能直接当作独立基准,也不能推导出所有物理设备都能达到类似的自动恢复率。它真正说明的是,设备状态、传感器反馈和恢复动作如果被标准化,Agent 就有机会参与传统自动化脚本之外的故障处理。

为什么这不只是另一个工具协议

MCP 已经解决了 AI 应用连接数据和工具的一部分互操作问题,MHS 则把同样的问题带到了物理设备一侧。两者可以叠加,但关注点不同:MCP 主要描述 AI 应用怎样连接服务器提供的上下文和工具,MHS 关心的是物理设备怎样被描述、发现和安全操作。

可以把它们放在一条分层链路里理解:

1
2
3
4
5
6
7
8
9
10
11
物理设备

厂商接口与设备控制器

MHS 驱动、能力描述和安全限制

MCP / CLI / API

Agent Harness

实验流程、制造任务或运维系统

这样的分层能减少模型和厂商接口之间的直接耦合。模型换了,设备不一定需要重写;设备换了,只要能力契约和限制仍然清晰,上层流程也有机会继续使用。

不过,协议只负责互操作,不能自动解决信任问题。一个标准化的写入接口如果没有身份认证、参数校验、权限分级和审计记录,反而可能让错误操作更容易扩散。物理设备的 API 设计,不能只沿用普通 CRUD 接口的思路。

给开发者的落地建议

MHS 目前仍是有限的研究预览,官方计划在进一步测试后开源。开发者现在更适合借鉴它的架构思想,而不是假设公开页面已经包含完整规范,直接在生产系统中依赖某个尚未公开的接口细节。

如果要为自己的设备或实验流程准备类似的适配层,可以先做几件具体的事。

把能力描述做成契约

每个动作都应明确输入类型、单位、默认值、允许范围、前置状态、预期结果和错误码。设备元数据至少要包含测量能力、可调参数、空间或负载限制、校准状态和维护要求。

描述文件可以帮助 Agent 理解设备,但不应成为唯一的安全来源。关键上限要在驱动或控制器中再次校验,避免模型修改文本描述后就能绕过限制。

先提供只读能力,再开放写入

第一阶段可以只让 Agent 读取设备状态、历史数据和能力描述,验证发现、监控和告警流程。之后再开放低风险写入,例如设置一个有硬上限的参数。启动实验、移动机械臂、改变激光功率或处理真实样品,都应有更严格的审批和联锁。

把重复操作移出模型回路

模型适合处理需要解释和判断的步骤,确定性脚本适合执行已经验证的高频动作。可以给脚本增加版本号、输入检查、超时、幂等性和回滚策略,并保存每一次运行使用的参数与设备状态。这样出了问题,团队能回答它执行了什么,而不只是看到一段模型总结。

为物理世界准备停止条件

软件系统里的错误通常可以重试,但温度过高、机械臂碰撞、样品污染或激光失锁不一定适合重试。运行时应设置最大动作次数、时间预算和参数变化范围,并准备硬件级急停、软件熔断和人工接管入口。

Agent 发现异常时,默认动作可以是暂停并报告,而不是自行扩大操作范围。对于无法从传感器数据判断的物理故障,要把现场专家重新放回决策链路。

安全边界比自动化速度更重要

Anthropic 在公告中也承认,Claude 对物理空间的理解仍有限。合作案例里,研究人员需要帮助 Claude 识别样品起泡造成的是物理故障,而不是软件错误。这个细节很有代表性:日志正常、函数调用成功,并不等于实验真的按预期发生。

因此,AI 操作硬件至少需要四道边界:

  • 能力边界:Agent 只能发现和调用当前任务授权的设备与动作;
  • 参数边界:驱动和控制器强制校验单位、范围、状态和联锁条件;
  • 时间边界:每一步有超时、重试次数和总预算,避免设备被持续驱动;
  • 责任边界:高影响动作需要人工确认,所有命令、反馈和接管过程都可追溯。

此外,还要区分环境仿真和真实设备。新 Agent、更新后的驱动或新的提示词,应该先在模拟设备、空载机械或无样品流程中验证,再逐步扩大真实设备权限。标准化接口降低了集成成本,也可能扩大错误命令的影响范围,这两件事必须同时评估。

这项进展对行业的影响

对硬件厂商来说,设备是否提供 Agent 可发现、可验证、可审计的接口,可能逐渐成为产品能力的一部分。只提供一个只能由人工操作的桌面程序,会让设备很难加入自动化实验和制造流程。

对软件开发者来说,工作重点会从写一次性的厂商适配程序,转向维护设备能力契约、权限策略、模拟器和运行时。真正难的不是把 set_temperature 暴露出来,而是说明它何时可调用、调用后怎样确认结果、失败时能否恢复,以及谁有权让它执行。

对 Agent 平台来说,硬件标准也会迫使 Harness 变得更像一个安全控制系统。它需要把模型的动作提议交给策略层检查,再由受限执行器调用驱动;还需要记录设备状态和外部结果,不能只保存对话历史。

结语

Anthropic 的 Model Hardware Standard 研究预览,试图把 AI Agent 与实验室、机器人和制造设备之间的连接,从一次性的定制集成变成可发现、可组合的标准接口。它最值得关注的地方,不是某个演示里 Agent 完成了多复杂的动作,而是它把设备描述、驱动、协议、确定性脚本和人工监督放进了同一个工程框架。

这套思路能否成为广泛采用的标准,还要看后续规范是否开源、厂商是否持续支持,以及安全评估能否跟上。但方向已经足够清楚:让模型接触现实世界,第一步不是给它更多按钮,而是把每个按钮的能力、限制、状态和责任写清楚。只有这样,Agent 才有可能从会调用工具,走向可控地参与真实工作。

参考资料

文章目录
  1. 1. MHS 试图解决什么问题
  2. 2. 技术结构:驱动、描述和控制分成三层
    1. 2.1. 1. 驱动把设备差异藏在适配层里
    2. 2.2. 2. 设备描述把隐含知识变成机器可读信息
    3. 2.3. 3. Agent 通过多种入口编排设备
  3. 3. 早期案例说明了什么
  4. 4. 为什么这不只是另一个工具协议
  5. 5. 给开发者的落地建议
    1. 5.1. 把能力描述做成契约
    2. 5.2. 先提供只读能力,再开放写入
    3. 5.3. 把重复操作移出模型回路
    4. 5.4. 为物理世界准备停止条件
  6. 6. 安全边界比自动化速度更重要
  7. 7. 这项进展对行业的影响
  8. 8. 结语
  9. 9. 参考资料
|