Anthropic Model Hardware Standard задает новую границу безопасности для физических AI agents

Anthropic Model Hardware Standard легко принять за новость о robotics. Operators, которые отвечают за router, должны читать ее как сдвиг границы полномочий: тот же agent, который вызывает search tool или записывает файл, теперь может обнаруживать microscopes, liquid handlers, robotic arms, cameras и quantum laser controls через общий driver layer. Когда model переходит от текста к оборудованию, routing policy должна покрывать physical authority, а не только cost или latency.

The boundary moved from API response to device action

27 августа Anthropic открыла research preview для Model Hardware Standard. Спецификация дает programmable devices стандартизированный driver с примитивами read и write, machine-readable discovery, natural-language hardware tags и reference files, где описано, что device может измерять, что может регулировать и какие safety limits обязан применять. Agent может управлять device через MCP, command line interface или code files.

Именно code files меняют операционную модель. В примере Anthropic с laser alignment Claude исследовал hardware loop, смотрел результат через camera, затем упаковал найденную процедуру в deterministic code, чтобы alignment запускался одной командой. Для gateway это две разные категории requests. Interactive reasoning turn можно мониторить token by token. Generated code file, который сцепляет driver commands, может работать быстрее, чем online review. Этим путям нужны разные правила approval, logging и rollback.

Preview ограничен research labs и advanced manufacturers, а Anthropic отдельно указывает, что MHS работает только с devices, у которых есть programmable interface. Но это уже те среды, где ошибки agent дорого обходятся: wet labs, robotics cells, electronics lines, microscopy rigs и quantum hardware.

Why this is more than another MCP surface

MCP уже дал agents общий способ добраться до software tools. MHS переносит тот же pattern в hardware. Это полезно, но ломает привычное допущение multi-provider routing: если плохой call только расходует tokens или возвращает неверный JSON, fallback и retry могут удержать большую часть ущерба. Плохая hardware command может потратить reagents, повести robotic arm к collision path, испортить biological sample или destabilize experiment.

Из-за этого control plane должен сохранять больше данных. Model choice становится только частью route. Route также должен кодировать device class, allowed command set, maximum run time, human approval thresholds и право agent выпустить code file, который выполнит несколько write operations без нового model decision в цикле.

Cross-provider context здесь важен. Anthropic связывает MHS с MCP и примерами Claude, AWS уже указан среди участников preview через Strands Robots, а Hugging Face планирует поддержку в LeRobot. Если MHS станет open source, он вряд ли останется single-model island. Teams должны ожидать, что agent harnesses начнут показывать hardware tools как обычные tools. Вопрос для gateway звучит так: каким providers, models и identities разрешен доступ к конкретному device namespace.

The routing policy should name devices, not just models

Практичная policy начинается с разделения observation и actuation. read commands можно маршрутизировать шире, потому что они раскрывают state. write commands меняют физический мир и требуют более узкого route. Первая production policy должна быть похожа не на model allowlist, а на operations matrix:

• read access для cameras, plate readers, logs и environmental sensors может идти через standard agent models с обычным audit logging.
• Low-risk write access, например изменение query parameter или перемещение virtual stage, должен требовать approved device profile и bounded values.
• High-risk write access, включая robot motion, liquid handling, thermal cycling или laser control, должен требовать explicit approval step, signed code artifact и device-side safety limit, который model не может переопределить.
• Generated scripts, которые сцепляют несколько device commands, нужно рассматривать как deployments. До execution сохраняйте script, model, prompt, operator identity и driver versions.

Migration path получается конкретным. До MHS во многих labs human operator или bespoke integration решали, когда model suggestion становится device command. После MHS agent harness может показать device как normal tool. Более безопасный route ставит gateway или policy broker между harness и MHS driver, поэтому request меняется с direct device access на checked call с route metadata:

{
  "model": "claude-opus-5",
  "tool": "mhs.write",
  "device": "laser_controller_3",
  "operation": "set_frequency",
  "approval": "required",
  "max_duration_seconds": 30
}

Это та же mental model, что и model routing, но fallback rule меняется. Если hardware operation fails, не нужно автоматически retry on another model. Retry policies должны принадлежать device profile и различать network failure, safety refusal, physical fault и model uncertainty.

What TheRouter users should watch now

TheRouter users не обязаны уже сегодня routing physical devices, чтобы извлечь урок из MHS. Важный сигнал в том, что agent tools становятся более разнородными, а gateway должен переносить больше контекста, чем model, messages и stream. Если команда уже маршрутизирует coding agents или MCP tool calls, проверьте, отвечают ли logs на четыре вопроса: какая model предложила action, какая identity его approved, какой tool namespace его executed и какая policy allowed или blocked его.

Для текущего API traffic стабильная отправная точка TheRouter остается прежней: OpenAI-compatible routing через developer docs и model discovery через model catalog. Для будущей hardware-agent работы стоит следить за тем, дадут ли MHS drivers достаточно structured metadata, чтобы gateways могли enforcement policy до того, как write дойдет до device. Если дадут, hardware operations можно будет govern как high-risk tools. Если нет, MHS сократит integration time, но вернет safety в bespoke lab software.