当 Agent 触碰物理世界：用 Anthropic 模型硬件标准（MHS）构建设备感知自动化

过去几年，AI Agent 一直活在屏幕里：读代码、写文件、调 API。2026 年 8 月 27 日，Anthropic 开放了模型硬件标准（MHS）的研究预览，目标是把 Agent 从屏幕里放出来，让它们发现并操作显微镜、机械臂、移液工作站这类真实设备。对开发者来说，这与其说是一个新模型，不如说是一套新的接口约定：设备驱动被标准化成 read、write 与 discovery 三组原语，Agent 通过 MCP、命令行或 API 就能与硬件对话。这篇文章拆解 MHS 到底规定了什么、为什么安全边界被放在模型之下、以及你现在就能动手的设备描述、发现服务与 MCP 工具原型。

1. MHS 解决了什么问题

MHS 瞄准的是一个非常朴素但昂贵的痛点：实验室或工厂里的设备来自不同厂商，从没打算互相兼容。每台仪器都有自己的接口，过去只能靠工程师手工编写一对一的翻译层，Anthropic 团队估计这种集成通常要花数周到数月。MHS 的思路是不去统一硬件，而是统一「驱动」这一层：把每台设备的能力折叠成少量标准原语，任何支持这些原语的 Agent 都能直接使用。据 Anthropic 公布，早期试点中集成时间从数周/数月缩短到数小时/数分钟，合作方包括 AWS、Universal Robots 与 Hugging Face；Genentech 用它跑药物发现实验，HHMI Janelia 研究园区把原本要数周的成像实验压缩到一天。

# A minimal MHS-style device descriptor (JSON) for a temperature-controlled stage.
{
  "device": "thermo-stage-01",
  "driver": "mhs.driver.thermo",
  "primitives": ["read", "write", "discover"],
  "limits": {
    "temperature_c": {"min": 4.0, "max": 60.0, "step": 0.1},
    "max_write_rate_per_min": 3
  },
  "read_only": ["sensor_temperature_c", "firmware"],
  "safety": {"interlock": "door_closed", "auto_stop_above_c": 65.0}
}

2. 标准化的核心：read、write 与 discovery

MHS 的驱动抽象刻意做得极小：read 读状态（例如当前温度）、write 改变状态（例如设定温度），discovery 负责让设备与 Agent 在网络中互相发现，不需要中间翻译器。每个设备用一份描述文件声明自己支持哪些原语、量程与限制。这套设计借鉴了操作系统驱动层的经验：对上层暴露稳定接口，对下层屏蔽厂商差异。对 Agent 而言，操作一台温控台与调用一个 API 没有本质区别——只是多了物理世界的约束：量程、联锁、写入频率限制，而这些约束都应该由驱动层强制，而不是靠模型自觉。

# Discovery: advertise a device so agents can find it without a translator.
# mDNS-style announce on the lab network.
import json, socket

def announce(descriptor, port=5353):
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
    msg = json.dumps({"type": "mhs.discover", "device": descriptor["device"], "port": port}).encode()
    sock.sendto(msg, ("255.255.255.255", port))

with open("thermo-stage.json") as f:
    announce(json.load(f))

3. 为什么安全边界要放在模型之下

Anthropic 强调 MHS 以研究预览形式发布，正是因为在安全评估完成之前不想仓促开源。设计上最值得借鉴的一点是：安全限制在驱动层执行，位于 Agent 之下。模型负责规划，驱动负责否决：温度超出量程直接报错，舱门开着就拒绝改动设定点，写入频率超限就等待。这意味着即使模型被提示词注入、输出异常，物理设备仍受到独立于模型的硬边界保护。做任何物理设备自动化，这条原则都应当优先于模型能力本身。

# The driver primitive surface: read, write, and a safety gate.
class ThermoDriver:
    def __init__(self, limits, interlock):
        self.limits = limits
        self.interlock = interlock

    def read(self, name):
        if name == "sensor_temperature_c":
            return self._sample_sensor()
        raise KeyError(name)

    def write(self, name, value):
        lo, hi = self.limits["temperature_c"]["min"], self.limits["temperature_c"]["max"]
        if not (lo <= value <= hi):
            raise ValueError(f"{value}C outside safe range [{lo}, {hi}]")
        if not self.interlock.closed():
            raise RuntimeError("door open: refusing setpoint change")
        self._set_setpoint(value)

4. 设备描述：把能力与约束写清楚

接入 MHS 风格体系的第一步，是给设备写一份机器可读的描述文件：声明驱动类型、支持的原语、每个参数的上下限与步进、只读字段，以及联锁条件。描述文件既是 Agent 的「使用说明书」，也是驱动层校验的蓝本。实践中建议把描述文件纳入版本管理，任何参数或安全策略的变更都走代码评审；用 JSON 校验工具检查格式，用哈希工具给固件与配置清单做校验和，防止设备加载到被篡改的描述。

5. 从描述到可调用：发现服务与 MCP 工具

有了描述文件，第二步是让设备可被发现、可被调用。局域网里可以用类似 mDNS 的广播让设备周期性宣告自己存在，Agent 拿到描述后就知道该连哪个端口。第三步是把驱动方法暴露成模型能调用的工具：Anthropic 明确表示 MHS 与模型无关，可通过 MCP、命令行工具与 API 访问。最稳妥的做法是暴露 MCP 风格的工具定义，并在 description 与 inputSchema 里写清安全范围——工具描述越明确，模型误用的概率越低。用 API 测试工具先行验证每个端点，再交给 Agent。

# Expose the device to an agent through an MCP-style tool definition.
{
  "tools": [
    {
      "name": "set_stage_temperature",
      "description": "Set the heated stage setpoint in Celsius. Fails if outside the safe range or if the chamber door is open.",
      "inputSchema": {
        "type": "object",
        "properties": {"celsius": {"type": "number", "minimum": 4, "maximum": 60}},
        "required": ["celsius"]
      }
    }
  ]
}

6. 给你的团队的三条落地建议

第一，别等标准正式开源：read/write/discovery 三原语今天就能用在自己的设备集成上，成本几乎为零。第二，把「驱动层否决」当成硬性要求：任何写操作都要经过量程检查、联锁检查与频率限制，宁可多写十行防御代码，也不要赌模型的判断。第三，为 Agent 操作加审计：记录谁在什么时间把设备从多少度改到多少度，最好与现有 API 流量日志走同一条管道，出了问题能回放、做安全审查时有证据。建议先挑一台不影响生产的仪器（测试台或开发腔体）试点两周，把描述、发现与审批闭环跑顺，再推广到接触生产工作的设备。物理世界没有 Ctrl+Z，慢一点、稳一点，才是真正的快。

# Agent-side guardrails: never call write twice without a read, and cap write rate.
class WritePolicy:
    def __init__(self, max_per_min=3):
        self.max_per_min = max_per_min
        self.times = []

    def allow(self):
        import time
        now = time.time()
        self.times = [t for t in self.times if now - t < 60]
        if len(self.times) >= self.max_per_min:
            return False
        self.times.append(now)
        return True

assert WritePolicy(max_per_min=2).allow() is True