Back Home

代理系統與科學運算

Anthropic Previews MHS, a Standards-Driven Layer for AI Agents to Operate Laboratory and Manufacturing Equipment

The Model Hardware Standard packages instrument capabilities, natural-language descriptions, and safety constraints into discoverable driver interfaces, enabling agents to coordinate multiple devices through MCP, a CLI, or APIs. It remains an application-only research preview, with the specification, code, and cross-model safety evaluations not yet public.

Прикли · CC0 · Image source
zh-Hant

Anthropic and HHMI Janelia Research Campus have opened a [research preview of the Model Hardware Standard (MHS)](https://www.anthropic.com/news/model-hardware-standard-research-preview?height=512.1&width=921.6), an effort to consolidate the incompatible instrument APIs found in laboratories and factories into a common agent control layer. Target devices include microscopes, liquid-handling workstations, robotic arms, cameras, and quantum computer calibration equipment; in theory, any device with a programmable interface can be connected.

At the core of MHS is not having models generate vendor-specific commands directly, but creating standardized drivers that describe capabilities such as reading temperatures and adjusting parameters through basic operations like `read` and `write`. Drivers publish device information that can be discovered over a network and store data such as weights, adjustable ranges, and mandatory safety constraints in reference files. Engineers can write these labels in natural language, or agents can create them after interviewing users. Higher-level agents can then schedule multiple instruments through MCP, a command-line interface, or a programmatic API. For high-speed or long-running tasks, an agent can first generate a deterministic script, avoiding the need to wait for model inference at every step.

In a Genentech proof of concept, Claude coordinated a pipettor, a robotic arm, and a microplate reader to adjust flow rates for liquids with different viscosities. The test also exposed gaps in physical reasoning: when the model encountered errors caused by air bubbles, it repeatedly retried the operation, making the situation worse, until an expert explained the cause and how to address it. This demonstrates that device-level limits, interlocks, human emergency stops, and replayable logs cannot be replaced by model judgment.

The most important limitation today is that the “standard” has not yet become a public standard that can be implemented independently. The [project page](https://modelhardwarestandard.com/) only accepts applications and does not yet provide a public specification, reference drivers, a compatibility test suite, or a version-governance process. Engineering teams should next examine the permission model, command atomicity, failure recovery, real-time control latency, and whether safety constraints are enforced by drivers, device firmware, or agents. Until these boundaries are made public, MHS is better suited to controlled experiments than safety-critical production lines.

Sources

  1. Previewing the Model Hardware Standard
  2. Model Hardware Standard