Model Hardware Standard від Anthropic: як MHS дозволяє AI-агентам керувати обладнанням і чим відрізняється від MCP

27 серпня 2026 року Anthropic відкрила research preview Model Hardware Standard (MHS), спільної специфікації, покликаної дозволити AI-агентам безпечніше знаходити, описувати та керувати програмованими фізичними пристроями.^[1]

MHS спочатку виник у співпраці Anthropic з HHMI Janelia Research Campus. У ранніх пілотах стандарт використовували з мікроскопами, liquid handlers, роботизованими маніпуляторами, plate readers та компонентами лазерної системи квантового комп’ютера.^[1]

Дотепер більшість популярних AI-агентів працювали переважно у цифровому середовищі:

файли
репозиторії
термінал
API
браузер
бази даних
SaaS-системи

MHS намагається стандартизувати ще один рівень:

сенсори
камери
мікроскопи
лабораторні роботи
роботизовані маніпулятори
лазери
вимірювальні прилади
виробниче обладнання

Але анонс не означає, що «Claude тепер може керувати будь-яким пристроєм». MHS наразі є обмеженим research preview, доступ надається після подання заявки, а стандарт ще не опублікований як open source. Anthropic заявляє, що планує відкрити MHS після preview та додаткової роботи над безпекою, але станом на 30 серпня не опублікувала дату релізу чи ліцензію майбутньої відкритої версії.^[1][2]

MHS також не є новою AI-моделлю і не замінює Model Context Protocol (MCP). Anthropic описує MHS як model-agnostic. MCP є одним із трьох механізмів, через які агент може керувати обладнанням, описаним MHS; два інші — CLI та code files/API.^[1]

Головний висновок: MHS не є «MCP 2.0» і не є роботом. Це спроба створити спільний рівень драйверів, опису можливостей пристроїв та фізичних обмежень безпеки, через який агент зможе взаємодіяти з різним обладнанням через більш узгоджений інтерфейс.

Стан інформації: 30 серпня 2026 року.

TL;DR

Питання	Перевірена відповідь
Що анонсувала Anthropic?	Research preview Model Hardware Standard
Коли?	27 серпня 2026
Що таке MHS?	Спільна специфікація та рівень драйверів для програмованого обладнання
Чи є MHS новою моделлю Claude?	Ні
Чи є MHS вже open source?	Ні
Чи планує Anthropic open source?	Так, після preview та роботи над безпекою
Чи відома дата?	Ні
Чи відома майбутня ліцензія?	У перевірених офіційних матеріалах не вказана
Чи замінює MHS MCP?	Ні
Як MHS використовує MCP?	MCP є одним із механізмів керування MHS-обладнанням
Інші механізми	CLI та code/API files
Чи працює MHS лише з Claude?	Ні, Anthropic називає його model-agnostic
Яке обладнання?	Пристрої з програмованим інтерфейсом; пілоти охоплюють лабораторне та робототехнічне обладнання
Найсильніша публічна метрика	QuEra: 695/700 успішних relock лазера, 99,3%
Чи це незалежний benchmark?	Ні, це результат партнерського пілота
Найбільший ризик	Помилка агента може мати фізичні наслідки
Ключове правило безпеки	Ліміти та interlocks мають застосовуватися поза самою моделлю

Що саме таке Model Hardware Standard?

Anthropic описує MHS як shared specification for AI agents to safely operate physical devices.^[1]

Проблема добре відома. Лабораторія або виробнича лінія може містити обладнання різних vendors, кожне зі своїм SDK, API, форматом даних, desktop application, документацією та моделлю помилок.

Поєднання кількох пристроїв в один workflow часто потребує індивідуального glue code.

Anthropic заявляє, що такі інтеграції можуть тривати тижні або місяці, а MHS може скоротити частину цієї роботи до годин чи хвилин.^[1] Це твердження виробника, а не незалежний benchmark усієї галузі.

MHS не є роботом і не є моделлю

MHS не є:

• новою моделлю Claude,
• операційною системою для роботів,
• новим типом робота,
• заміною firmware,
• самостійним алгоритмом motion planning,
• промисловим мережевим протоколом, що замінює всі наявні системи керування.

Найкраще розуміти його як рівень інтероперабельності між агентом і програмованим фізичним обладнанням.

Агент усе одно потребує моделі, harness або застосунку, дозволів, driver пристрою, реального hardware interface та незалежних фізичних засобів захисту.

Як працює MHS?

3.1. Стандартизований driver

MHS вводить стандартний driver, що перекладає операції між комп’ютером і пристроєм.^[1]

Anthropic наводить прості primitives:

read
write

наприклад:

read temperature
write temperature

Це не означає, що кожен пристрій має лише дві команди. Складніші функції можуть будуватися поверх невеликого узгодженого набору базових операцій.

3.2. Стандартний опис пристрою

MHS має робити пристрої discoverable в єдиному форматі, щоб агенти та інші системи могли знаходити їх у мережі та розуміти доступні можливості.^[1]

Опис може містити:

• що пристрій вимірює,
• які параметри можна змінювати,
• фізичні характеристики,
• важливі обмеження,
• примусово встановлені межі безпеки.

Anthropic наводить масу роботизованого маніпулятора як приклад фізичної характеристики, важливої для безпечного використання.^[1]

3.3. Теги природною мовою

Користувач може описувати важливі властивості natural-language tags, безпосередньо або через агента, який ставить запитання про setup.^[1]

Driver потім створює reference file з характеристиками пристрою, вимірюваннями, налаштуваннями та safety limits.

Публічний матеріал Anthropic не є повною документацією schema. Поки MHS залишається у limited preview, не слід вигадувати назви полів чи синтаксис і подавати їх як офіційні.

Три способи керування обладнанням

Anthropic описує три механізми:^[1]

1. MCP
2. CLI
3. code files / APIs

MCP

Агент може працювати з обладнанням через Model Context Protocol. MCP servers можуть надавати tools, тобто виконувані функції, які модель може знайти та викликати.^[4][5]

CLI

Обладнання також можна керувати безпосередньо через командний рядок, що корисно для операторів, scripting, debugging та integration tests.

Код і API

Агент може об’єднати команди одного чи кількох пристроїв у звичайну програму. Anthropic підкреслює це для швидких, повторюваних чи тривалих операцій, де LLM не має приймати рішення на кожному мікрокроці.^[1]

Агент може навчитися процедурі, а потім вийти з контуру керування

Generative model не зобов’язана керувати обладнанням кожну мілісекунду.

В одному з прикладів Claude:

1. змінював налаштування лазера,
2. спостерігав результат через камеру,
3. повторював експеримент,
4. виявляв залежності,
5. записав процедуру як детермінований код.^[1]

Після цього script міг працювати без постійного reasoning моделі.

Важливий production pattern:

AI досліджує
   ↓
AI створює процедуру
   ↓
люди / тести перевіряють
   ↓
детермінований код виконує

QuEra використала цей підхід для laser relock controller: агент допоміг розробити й перевірити код, але фінальна логіка є inspectable deterministic software без online model у runtime.^[7]

MHS vs MCP: головна відмінність

Елемент	MCP	MHS
Головна мета	Підключати AI-застосунки до tools, даних і систем	Стандартизувати опис і керування фізичним hardware
Типова ціль	Software, API, дані, tools	Програмовані фізичні пристрої
Модель	Host, client, server, JSON-RPC	Driver + опис обладнання + механізми керування
Tools	Так	Можуть надаватися через MCP
CLI	Не є основною моделлю протоколу	Один із задокументованих шляхів MHS
API/code files	Можуть існувати за MCP	Один із задокументованих шляхів MHS
Фізичні ліміти	Не головна scope MCP	Частина MHS semantics
Open source сьогодні	Так	Ще ні
Статус	Відкритий протокол	Обмежений research preview

Anthropic випустила MCP у 2024 році як відкритий стандарт для двосторонніх підключень між AI-системами, джерелами даних та tools.^[4] Документація MCP описує host-client-server, capability negotiation, tools, resources і prompts.^[5][6]

MHS не замінює цей рівень.

Концептуальний stack:

MODEL / AGENT
      │
      ├── MCP
      ├── CLI
      └── CODE / API
             │
          MHS DRIVER
             │
       DEVICE INTERFACE
             │
        PHYSICAL HARDWARE

Це концептуальна схема POLPROG, а не офіційна схема Anthropic.

Чи є MHS «MCP для фізичного світу»?

Як коротка формула це корисно, але технічно надто спрощено.

Обидва проєкти зменшують кількість bespoke integrations і створюють спільний інтерфейс.

Ключова різниця: MCP є комунікаційним протоколом для AI-систем і tools. MHS додає семантику фізичного пристрою, його стану, можливостей та обмежень.

MHS також може використовувати MCP.

Точніше казати:

MHS доповнює MCP рівнем, призначеним для фізичного обладнання.

MHS є model-agnostic

Anthropic прямо заявляє, що MHS є model-agnostic і будь-який agent harness може отримувати до нього доступ через стандартні протоколи, наприклад MCP.^[1]

Отже, концепція формально не обмежується Claude або Claude Code.

Публічні case studies переважно використовують Claude, оскільки походять від Anthropic та preview partners. Широкого незалежного benchmark різних моделей на однаковому hardware з тим самим driver поки немає.

Безпека має працювати нижче рівня моделі

У software неправильний tool call може видалити файл. У фізичному світі помилка може спричинити зіткнення, пролити sample або пошкодити обладнання.

Natural-language prompt не може бути єдиним захистом.

MHS може передавати примусово застосовувані safety limits.^[1] QuEra також вказує, що bounds, interlocks та emergency stops застосовувалися на hardware interface незалежно від моделі.^[7]

Правильний напрям:

MODEL
пропонує дію

POLICY / APPROVAL
дозволяє або відхиляє

DRIVER / CONTROLLER
застосовує ліміти

HARDWARE INTERLOCK
захищає навіть при помилці software

Genentech: фізична помилка, яку агент спочатку неправильно зрозумів

Genentech тестувала MHS у BCA protein assay з liquid handler, роботизованим маніпулятором і microplate reader.^[1]

Під час змішування виникали бульбашки, що спричиняли runtime errors. Claude спершу сприйняв проблему як software issue і повторював операцію в тому самому well з іншими параметрами. Це створювало ще більше бульбашок.^[1]

Люди мали пояснити фізичну причину, необхідність чистого well і м’якшого mixing. Потім команда закодувала це знання у reusable liquid-handling skills.^[1]

Висновок:

Модель може правильно прочитати error message і водночас неправильно зрозуміти фізику проблеми.

University of Washington: шість пристроїв менш ніж за тиждень

Лабораторії Baker і Pinglay використовували MHS для remote monitoring, qPCR під наглядом агента та координації роботизованого маніпулятора з liquid handler.^[1]

Під час plate handoff liquid handler завершував роботу, агент отримував сигнал і приблизно через десять секунд запускав рух маніпулятора. За описом, у повторних тестах зіткнень не було.

Підключення шести пристроїв, включно з написанням drivers, нібито зайняло менш ніж тиждень.^[1]

Це результат одного пілота, а не універсальна гарантія.

Carnegie Mellon: шість навмисно створених станів безпеки

Команда Carnegie Mellon використала MHS у serial dilution dose-response experiments.^[1]

Setup об’єднував liquid handler, plate reader, роботизований маніпулятор, камери й три комп’ютери з несумісними способами керування.

Дослідники навмисно створили шість станів:

1. відсутня plate,
2. повернута plate,
3. reader busy,
4. камера відключена,
5. пристрій недоступний,
6. active emergency stop.^[1]

За звітом, система заблокувала всі шість до початку руху пристрою.

Це хороший proof of concept, але не формальна сертифікація безпеки.

Автономна корекція експерименту

Перший run дав:

R² < 0,9

Агент зменшив максимальну концентрацію:

200 µg/mL
→
100 µg/mL

Наступний run досяг:

R² > 0,98

без втручання людини.^[1]

Команда вказує приблизно 8 годин від готового, але неавтоматизованого обладнання до завершеної кривої з автономним rerun і порівнює це з багатотижневою vendor integration.^[1]

HHMI Janelia: один рівень стану для семи програм

В одному проєкті Janelia дослідниці раніше доводилося запускати сім програм у визначеному порядку.

MHS замінив point-to-point connections спільним state dictionary у shared memory.^[1]

За case study:

• нову камеру додали за хвилини замість днів,
• запуск експерименту скоротився з семи кроків до однієї дії,
• data streams можна було аналізувати reusable tools незалежно від vendor application.^[1]

MHS також застосовував обмеження, наприклад максимальну потужність лазера, щоб агент не міг вийти за безпечний для sample діапазон.^[1]

QuEra: 695 успішних relock із 700

Найбільш кількісний публічний пілот належить QuEra Computing.

QuEra використала MHS, щоб надати Claude доступ до частини лазерної системи квантового комп’ютера.^[1][7][8]

Після експериментальної фази було створено deterministic controller.

QuEra провела:

700 тестів
7 класів збурень
100 тестів на клас

Результат:

695 / 700
=
99,3%

^[7]

Простіші помилки:

0,9–5,4 s

найскладніші:

10–14 s

порівняно з:

5–10 хвилин

для human expert.^[7]

Це не 99,3% benchmark Claude

У фінальному blind test агент не керував лазером online.

Правильно:

Агент з MHS допоміг розробити controller, який пізніше досяг 99,3%.

Неправильно:

Claude керує hardware з точністю 99,3%.

Розбіжність між джерелами

Anthropic описує старіший вручну написаний QuEra script як роботу на “several months”.^[1]

QuEra говорить приблизно про 2–3 тижні.^[7]

Оскільки джерела розходяться, цей час не використовується як тверда порівняльна метрика.

Обмеження, показані пілотом QuEra

Публічні матеріали описують і слабкі сторони.

Claude:

• не міг діагностувати деякі суто фізичні несправності,
• розумів rig переважно через програмне представлення,
• потребував багато контексту,
• іноді зупиняв експеримент і чекав human confirmation навіть для дещо ризикових дій.^[1]

Для фізичного обладнання така обережність може бути кращою за overconfidence.

Tetsuwan: один пристрій виявляє проблему, інший її вирішує

Tetsuwan поєднав MHS з ResearchOS у qPCR workflow щодо San Pedro Creek.^[1]

Камера виявила бульбашки. Робот, який тримав sample, не міг їх прибрати.

Система:

1. виявила проблему,
2. переглянула MHS-пристрої,
3. знайшла centrifuge,
4. Claude запропонував використати її,
5. після approval надіслав команди.^[1]

Це приклад cross-device recovery замість повністю hard-coded workflow.

Партнерська екосистема

Anthropic згадує, зокрема:^[1]

• Amazon Web Services,
• Automata,
• Danaher,
• Doosan Robotics,
• MBF Bioscience,
• QIAGEN,
• Tecan,
• Universal Robots,
• Hugging Face,
• Raspberry Pi.

AWS планує підтримку через Strands Robots, Hugging Face працює над LeRobot, а Raspberry Pi — над інтеграціями для вибраних продуктів.^[1]

Це не означає, що кожна інтеграція вже є публічною та production-ready.

MHS ще не є open source

Офіційний сайт прямо називає MHS limited research preview.^[2]

Anthropic хоче спочатку зібрати досвід партнерів, створити safety evaluations, best practices та посилити safeguards.^[1]

Станом на 30 серпня 2026 року в перевірених офіційних матеріалах немає:

• публічної дати open-source релізу,
• фінальної ліцензії,
• повної відкритої специфікації рівня зрілості документації MCP.

Отже:

Anthropic планує відкрити MHS як open source.

правильно.

MHS уже є open source.

неправильно.

Чи є нинішні результати незалежними benchmark?

Ні.

Публічні цифри походять переважно від Anthropic і preview partners.

Reuters незалежно підтверджує запуск preview, загальний scope та план майбутнього open-source релізу.^[3]

Але ще немає публічного benchmark з однаковим hardware, однаковими drivers, кількома моделями, єдиним harness та independent grading.

Такі числа як:

99,3%
3× швидше
8 годин
менше тижня

мають залишатися прив’язаними до конкретних пілотів.

Threat model: що може піти не так?

Неправильне reasoning

Модель може неправильно інтерпретувати sensor, error code, image або фізичну причину. Genentech показує реальний приклад.^[1]

Помилковий або зловмисний driver

Неправильні units, хибний state або відсутність validation можуть дати агенту неправильне уявлення про реальність.

Prompt injection

Текст з камер, документації чи network data може містити зловмисні інструкції.

Confused deputy

Агент із доступом до кількох пристроїв може використати правильний tool для неправильної мети.

Race conditions

Два агенти можуть одночасно змінювати один фізичний state.

Втрата зв’язку

Система має мати safe state при відмові моделі, MCP, мережі, driver або sensor.

Безпечніша production architecture

MODEL / AGENT
      ↓
POLICY + APPROVAL
      ↓
MCP / CLI / API
      ↓
MHS DRIVER
      ↓
DETERMINISTIC CONTROLLER
      ↓
HARDWARE INTERLOCK / E-STOP
      ↓
PHYSICAL HARDWARE

Це рекомендація POLPROG, а не офіційна схема Anthropic.

LLM не має бути єдиним компонентом, який визначає, чи безпечна фізична операція.

Що має застосовувати deterministic layer?

Наприклад:

• температурні діапазони,
• максимальну потужність,
• швидкість маніпулятора,
• робочу зону,
• порядок рухів,
• collision zones,
• pressure limits,
• стан захисних елементів,
• emergency stop,
• максимальну тривалість операції.

Запит поза дозволеним діапазоном має відхилятися незалежно від reasoning моделі.

Human-in-the-loop залишається важливим

MCP Tools specification рекомендує, щоб користувач міг відмовити tool invocation.^[5]

Для hardware:

READ
автоматично

LOW-RISK WRITE
автоматично у вузькому діапазоні

MEDIUM-RISK
policy + validation

HIGH-RISK
human approval

EMERGENCY / UNSAFE
завжди заблоковано

Чому deterministic fallback важливий

QuEra демонструє практичний pattern:

AI знаходить рішення
→ генерується код
→ тести та люди перевіряють
→ production виконує deterministic software

Це знижує inference cost, latency, nondeterminism, залежність від API та ризик несподіваних рішень моделі.

MHS і промислові системи керування

MHS не слід вважати заміною PLC, SCADA, OPC UA, safety PLC чи real-time controllers.

Реалістичніше розмістити його вище:

agent
↓
orchestration
↓
MHS
↓
існуючі controllers
↓
hardware

Anthropic сама показує, що швидкі або тривалі операції можуть переноситися у код, щоб не використовувати LLM reasoning на кожному кроці.^[1]

Хто має стежити за MHS уже зараз?

Насамперед:

• лабораторії з multi-vendor обладнанням,
• biotech і pharma,
• microscopy,
• робототехніка,
• quantum computing,
• advanced manufacturing,
• R&D команди з великою кількістю bespoke integration code.

Кому варто бути обережним?

Якщо:

• система safety-critical,
• потрібна стабільна публічна специфікація,
• потрібна відома open-source ліцензія,
• потрібні сертифіковані промислові стандарти,
• hardware не має автоматизованого інтерфейсу,
• відсутні незалежні interlocks,
• команда не може аудитувати drivers.

Research preview не є зрілим промисловим стандартом.

Як компанії підготуватися до MHS?

Крок 1: інвентаризація

vendor
model
SDK/API/GUI
units
states
commands
limits
E-stop
dependencies

Крок 2: відокремити read від write

Визначити, що можна читати, змінювати, автоматизувати, а що потребує approval.

Крок 3: безпека не повинна жити лише у prompt

Не покладатися на:

"ніколи не встановлюй температуру вище 80°C"

Реальний limit має застосовувати код або hardware.

Крок 4: логувати все

Agent/model, operation, parameters, state до/після, result, timestamp, policy та approval.

Крок 5: спочатку симуляція

digital twin / mock driver

і лише потім:

real hardware

Мінімальний план тестування

Driver

• units,
• ranges,
• timeouts,
• reconnect,
• неправильні responses,
• restart.

Agent

• хибний sensor reading,
• суперечливі data,
• невідомий error code,
• prompt injection,
• відсутній context.

Hardware

• collision prevention,
• E-stop,
• power loss,
• network loss,
• mechanical block,
• out-of-range values.

Multi-agent

• simultaneous writes,
• stale state,
• resource locking,
• retry after timeout.

Checklist безпеки MHS

Архітектура

• Модель не керує actuators без validation.
• Кожен driver має явні limits.
• Values мають units і ranges.
• Критичні межі deterministic.
• E-stop працює незалежно від AI.
• Safe state після втрати зв’язку.
• Device state має timestamp.
• Retry є безпечним.

Дозволи

• Агент бачить лише потрібні пристрої.
• READ і WRITE розділені.
• High-risk actions потребують approval.
• Дозволи мають термін дії.
• Немає одного глобального admin token.

Monitoring

• Кожен tool call логуються.
• Фізичні зміни мають telemetry.
• Alerts не залежать лише від моделі.
• Оператор бачить current state.
• Є event replay.
• Failed actions класифікуються.

Tests

• Mock hardware.
• Physical sandbox.
• Fault injection.
• Prompt injection.
• Race conditions.
• Network partition.
• Agent restart.
• Driver restart.
• Неправильні units.
• Out-of-range values.

Production

• Rollout починається read-only.
• Потім low-risk writes.
• Safety-critical actions залишаються поза агентом.
• Deterministic code замінює AI, де це можливо.
• Drivers проходять code review.
• Є rollback.
• Є manual takeover.
• Команда розуміє фізичні наслідки кожної команди.

Що потрібно, щоб MHS став справжнім стандартом?

Зокрема:

1. публічна специфікація,
2. стабільний versioning,
3. compatibility model,
4. публічні SDK,
5. open-source ліцензія,
6. reference drivers,
7. conformance tests,
8. security evaluations,
9. незалежні implementations,
10. vendor support,
11. driver validation,
12. чіткий permission model.

MCP набув значення завдяки інтероперабельній екосистемі. MHS має пройти подібний шлях.

Чи змінить MHS робототехніку?

Можливо, але робити сильні висновки ще зарано.

Найкращий короткостроковий fit там, де hardware уже програмований, інтеграція дорога, а workflows часто змінюються:

лабораторії
R&D
biotech
microscopy
quantum
advanced manufacturing

MHS не вирішує автоматично robot perception, motion planning, real-time control, safety certification чи фізику маніпуляції.

Але може спростити інтерфейс, через який агент використовує наявні системи керування.

Висновок POLPROG

Model Hardware Standard є одним із найцікавіших agentic-напрямів 2026 року, оскільки переносить проблему інтероперабельності з цифрового світу у фізичний.

Що підтверджено?

• research preview з 27 серпня 2026.^[1][3]
• походження зі співпраці Anthropic + HHMI Janelia.^[1]
• model-agnostic.^[1]
• керування через MCP, CLI та code/API files.^[1]
• driver описує пристрій і safety limits.^[1]
• Anthropic планує пізніше зробити стандарт open source.^[1][2]
• QuEra підтверджує 695 успішних relock із 700 для фінального controller.^[7]

Чого ми ще не знаємо?

• фінальної публічної schema,
• дати open-source,
• ліцензії,
• API stability,
• compatibility між implementations,
• незалежного benchmark,
• поведінки різних моделей на однаковому hardware.

Найперспективніший pattern

Не:

LLM постійно керує всім

а:

агент розуміє ціль
→ досліджує безпечний простір
→ координує пристрої
→ створює або обирає процедуру
→ система перевіряє
→ повторювана робота переходить у deterministic code

Якщо Anthropic справді відкриє специфікацію, vendors нададуть reusable drivers, а незалежні команди підтвердять безпеку та інтероперабельність, MHS може стати важливим рівнем physical AI.

Ми ще не на цьому етапі.