Model Hardware Standard od Anthropic: jak MHS umožňuje AI agentům ovládat hardware a čím se liší od MCP

Dne 27. srpna 2026 Anthropic spustil research preview Model Hardware Standard (MHS), sdílené specifikace, která má AI agentům umožnit bezpečněji objevovat, popisovat a obsluhovat programovatelná fyzická zařízení.^[1]

MHS vznikl původně ve spolupráci Anthropic s HHMI Janelia Research Campus. První piloty připojovaly mikroskopy, liquid handlery, robotická ramena, plate readery a části laserového systému kvantového počítače.^[1]

Dosud většina běžných AI agentů pracovala hlavně v digitálním světě:

soubory
repozitáře
terminál
API
prohlížeč
databáze
SaaS systémy

MHS se snaží standardizovat další vrstvu:

senzory
kamery
mikroskopy
laboratorní roboty
robotická ramena
lasery
měřicí zařízení
výrobní zařízení

Oznámení však neznamená, že „Claude teď umí ovládat každý stroj“. MHS je v současnosti omezený research preview, přístup je na základě žádosti a standard ještě nebyl veřejně vydán jako open source. Anthropic uvádí, že ho chce otevřít po preview a dalším bezpečnostním testování, ale k 30. srpnu nezveřejnil datum ani licenci budoucí otevřené verze.^[1][2]

MHS také není nový AI model a nenahrazuje Model Context Protocol (MCP). Anthropic jej označuje jako model-agnostic. MCP je jedním ze tří způsobů, jak může agent ovládat hardware popsaný MHS; dalšími jsou CLI a soubory kódu/API.^[1]

Hlavní závěr: MHS není „MCP 2.0“ ani robot. Je to pokus vytvořit společnou vrstvu driverů, popisu zařízení a fyzických bezpečnostních limitů, díky níž může agent používat různá zařízení přes konzistentnější rozhraní.

Stav informací: 30. srpna 2026.

TL;DR

Otázka	Ověřená odpověď
Co Anthropic oznámil?	Research preview Model Hardware Standard
Kdy?	27. srpna 2026
Co je MHS?	Sdílená specifikace a vrstva driverů pro programovatelný hardware
Je MHS nový model Claude?	Ne
Je MHS už open source?	Ne
Plánuje Anthropic open source?	Ano, po preview a bezpečnostních pracích
Známe datum?	Ne
Známe budoucí licenci?	V ověřených oficiálních materiálech není uvedena
Nahrazuje MHS MCP?	Ne
Jak využívá MCP?	MCP je jedním z mechanismů řízení MHS hardwaru
Další mechanismy	CLI a code/API files
Funguje MHS jen s Claude?	Ne, je model-agnostic
Jaký hardware?	Zařízení s programovatelným rozhraním; piloty zahrnují laboratoře a robotiku
Nejsilnější veřejný pilotní výsledek	QuEra: 695/700 úspěšných relocků laseru, 99,3 %
Je to nezávislý benchmark?	Ne, výsledek partnerského pilotu
Největší riziko	Chyba agenta může mít fyzické následky
Klíčové bezpečnostní pravidlo	Limity a interlocky musí být vynuceny mimo samotný model

Co přesně je Model Hardware Standard?

Anthropic popisuje MHS jako shared specification for AI agents to safely operate physical devices.^[1]

Problém je známý. Laboratoř nebo výrobní linka používá zařízení od různých výrobců a každé má vlastní SDK, API, datový formát, desktopovou aplikaci, dokumentaci a model chyb.

Propojení více zařízení do jednoho workflow proto často vyžaduje individuální glue code.

Anthropic tvrdí, že takové integrace mohou trvat týdny nebo měsíce a MHS může část práce zkrátit na hodiny nebo minuty.^[1] Jde o tvrzení výrobce, ne o nezávislý benchmark celého trhu.

MHS není robot ani model

MHS není:

• nový model Claude,
• operační systém pro roboty,
• nový typ robota,
• náhrada firmware,
• samostatný algoritmus motion planning,
• průmyslový síťový protokol nahrazující všechny řídicí systémy.

Nejlépe jej lze chápat jako interoperabilní vrstvu mezi agentem a programovatelným fyzickým hardwarem.

Agent stále potřebuje model, harness nebo aplikaci, oprávnění, driver zařízení, skutečné rozhraní hardwaru a nezávislé fyzické ochrany.

Jak MHS funguje?

3.1. Standardizovaný driver

MHS zavádí standardizovaný driver, který překládá operace mezi počítačem a zařízením.^[1]

Anthropic uvádí jednoduché primitivní operace:

read
write

například:

read temperature
write temperature

Neznamená to, že zařízení má jen dva příkazy. Složitější funkce lze stavět nad malou konzistentní sadou základních operací.

3.2. Standardní popis zařízení

MHS má zařízení zpřístupnit v jednotném discoverable formátu, aby agenti a jiná zařízení mohli zjistit jeho schopnosti.^[1]

Popis může obsahovat:

• co zařízení měří,
• co lze změnit,
• fyzické vlastnosti,
• důležitá omezení,
• vynucené bezpečnostní hranice.

Anthropic jako příklad uvádí hmotnost robotického ramene.^[1]

3.3. Tagy v přirozeném jazyce

Uživatel může důležité vlastnosti popsat natural-language tagy, přímo nebo prostřednictvím agenta, který se na setup doptá.^[1]

Driver pak vytvoří referenční soubor s vlastnostmi zařízení, měřeními, nastaveními a safety limits.

Veřejný článek není kompletní specifikací schématu. Dokud je MHS v omezeném preview, neměly by se vymýšlet názvy polí ani syntaxe a vydávat je za oficiální.

Tři způsoby řízení hardwaru

Anthropic popisuje tři mechanismy:^[1]

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

MCP

Agent může přistupovat k hardwaru přes Model Context Protocol. MCP servery mohou vystavovat tools, tedy spustitelné funkce, které model objeví a zavolá.^[4][5]

CLI

Zařízení lze ovládat i přímo přes příkazovou řádku, což je užitečné pro operátory, skripty, debugging a integrační testy.

Kód a API

Agent může kombinovat příkazy více zařízení do běžného programu. Anthropic to zdůrazňuje pro rychlé, opakovatelné nebo dlouhotrvající operace, kde LLM nemá rozhodovat o každém mikrokroku.^[1]

Agent se může proceduru naučit a pak opustit řídicí smyčku

Generativní model nemusí hardware řídit každou milisekundu.

V jednom příkladu Claude:

1. měnil nastavení laseru,
2. sledoval výsledek kamerou,
3. opakoval experiment,
4. naučil se vztahy,
5. zapsal proceduru jako deterministický kód.^[1]

Poté mohl skript běžet bez průběžného reasoning modelu.

Produkční vzorec:

AI zkoumá
   ↓
AI vytvoří proceduru
   ↓
lidé / testy ověří
   ↓
deterministický kód vykoná

QuEra tento princip použila u laserového relock controlleru. Agent pomohl kód vyvinout a ověřit, ale finální logika je inspectable deterministický software bez online modelu v runtime.^[7]

MHS vs MCP: hlavní rozdíl

Prvek	MCP	MHS
Hlavní cíl	Propojit AI aplikace s tools, daty a systémy	Standardizovat popis a řízení fyzického hardwaru
Typický cíl	Software, API, data, tools	Programovatelná fyzická zařízení
Model	Host, client, server, JSON-RPC	Driver + popis hardwaru + řídicí mechanismy
Tools	Ano	Mohou být vystaveny přes MCP
CLI	Není hlavním modelem protokolu	Jeden dokumentovaný způsob MHS
API/code files	Mohou existovat za MCP	Jeden dokumentovaný způsob MHS
Fyzické limity	Nejsou hlavní scope MCP	Součást MHS semantiky
Open source dnes	Ano	Ještě ne
Stav	Otevřený protokol	Omezený research preview

Anthropic vydal MCP v roce 2024 jako otevřený standard pro obousměrná spojení mezi AI systémy, zdroji dat a nástroji.^[4] Dokumentace MCP popisuje host-client-server, capability negotiation, tools, resources a prompts.^[5][6]

MHS tuto vrstvu nenahrazuje.

Koncepční stack:

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

Jde o diagram POLPROG, nikoli oficiální diagram Anthropic.

Je MHS „MCP pro fyzický svět“?

Jako zkratka je to užitečné, technicky ale příliš jednoduché.

Oba projekty snižují počet bespoke integrací a vytvářejí společné rozhraní.

Zásadní rozdíl: MCP je komunikační protokol pro AI systémy a nástroje. MHS přidává semantiku fyzického zařízení, jeho stav, schopnosti a limity.

MHS navíc může MCP používat.

Přesnější formulace:

MHS doplňuje MCP o vrstvu určenou pro fyzický hardware.

MHS je model-agnostic

Anthropic výslovně uvádí, že MHS je model-agnostic a může jej používat libovolný agent harness přes standardní protokoly, například MCP.^[1]

Není tedy formálně omezen na Claude nebo Claude Code.

Veřejné case studies se soustředí hlavně na Claude, protože pocházejí od Anthropic a partnerů preview. Zatím neexistuje široký nezávislý benchmark více modelů na stejném hardwaru se stejným driverem.

Bezpečnost musí fungovat pod vrstvou modelu

Ve světě software může špatný tool call smazat soubor. Ve fyzickém světě může způsobit kolizi, rozlití vzorku nebo poškození zařízení.

Prompt v přirozeném jazyce proto nemůže být jedinou ochranou.

MHS může předávat vynucované safety limits.^[1] QuEra navíc uvádí, že bounds, interlocky a emergency stops byly vynucovány na hardwarovém rozhraní nezávisle na modelu.^[7]

Správný směr:

MODEL
navrhne akci

POLICY / APPROVAL
povolí nebo odmítne

DRIVER / CONTROLLER
vynutí limity

HARDWARE INTERLOCK
ochrání i při chybě software

Genentech: fyzický problém, který agent nejprve špatně pochopil

Genentech testoval MHS při BCA protein assay s liquid handlerem, robotickým ramenem a microplate readerem.^[1]

Při míchání vznikaly bubliny a způsobovaly runtime errors. Claude problém nejprve řešil jako software a opakoval operaci ve stejném well s jinými parametry, čímž vytvářel další bubliny.^[1]

Lidé museli vysvětlit fyzickou příčinu, potřebu čistého well a jemnějšího míchání. Znalost pak tým převedl do reusable liquid-handling skills.^[1]

Důležitý závěr:

Model může správně chápat error message, ale špatně chápat fyziku za ním.

University of Washington: šest zařízení za méně než týden

Laboratoře Baker a Pinglay používaly MHS pro vzdálený monitoring, agentem sledované qPCR a koordinaci robotického ramene s liquid handlerem.^[1]

Při plate handoff liquid handler dokončil práci, agent obdržel signál a asi o deset sekund později spustil rameno. Podle popisu během opakovaných testů nedošlo ke kolizi.

Připojení šesti zařízení včetně driverů údajně trvalo méně než týden.^[1]

Jde o jeden pilot, ne obecnou garanci času.

Carnegie Mellon: šest záměrně vyvolaných bezpečnostních stavů

Tým Carnegie Mellon použil MHS pro serial dilution dose-response experimenty.^[1]

Setup kombinoval liquid handler, plate reader, robotické rameno, kamery a tři počítače s nekompatibilním ovládáním.

Výzkumníci vyvolali šest stavů:

1. chybějící plate,
2. otočená plate,
3. reader busy,
4. odpojená kamera,
5. nedostupné zařízení,
6. aktivní emergency stop.^[1]

Podle reportu systém všech šest zablokoval ještě před pohybem zařízení.

Je to dobrý proof of concept, nikoli formální bezpečnostní certifikace.

Autonomní korekce experimentu

První run měl:

R² < 0,9

Agent snížil maximální koncentraci:

200 µg/mL
→
100 µg/mL

Druhý run dosáhl:

R² > 0,98

bez zásahu člověka.^[1]

Tým uvádí přibližně 8 hodin od připraveného, ale neautomatizovaného vybavení k hotové křivce včetně autonomního rerunu a porovnává to s týdny typické vendor integrace.^[1]

HHMI Janelia: jedna stavová vrstva pro sedm programů

V jednom projektu Janelia musela výzkumnice dříve spouštět sedm programů v přesném pořadí.

MHS nahradil point-to-point spojení sdíleným state dictionary v shared memory.^[1]

Podle case study:

• nová kamera se přidala během minut místo dnů,
• start experimentu se změnil ze sedmi kroků na jednu akci,
• datové streamy bylo možné analyzovat opakovaně použitelnými tools bez ohledu na vendor aplikaci.^[1]

MHS také vynucoval limity, například maximální výkon laseru, aby agent nemohl překročit bezpečný rozsah pro vzorek.^[1]

QuEra: 695 úspěšných relocků ze 700

Nejvíce kvantifikovaný veřejný pilot pochází od QuEra Computing.

QuEra využila MHS, aby Claude získal přístup k části laserového systému kvantového počítače.^[1][7][8]

Po experimentální fázi vznikl deterministický controller.

QuEra provedla:

700 testů
7 tříd poruch
100 testů na třídu

Výsledek:

695 / 700
=
99,3 %

^[7]

Jednodušší chyby:

0,9–5,4 s

nejobtížnější:

10–14 s

oproti:

5–10 minut

u lidského experta.^[7]

Nejde o 99,3% benchmark Claude

V závěrečném blind testu agent neřídil laser online.

Správně:

Agent s MHS pomohl vyvinout controller, který následně dosáhl 99,3 %.

Nesprávně:

Claude ovládá hardware s přesností 99,3 %.

Rozpor mezi zdroji

Anthropic popisuje starší ručně vytvořený skript QuEra jako práci na „several months“.^[1]

QuEra uvádí přibližně 2–3 týdny.^[7]

Proto tuto dobu nepoužíváme jako tvrdou srovnávací metriku.

Omezení odhalená pilotem QuEra

Veřejné popisy uvádějí i slabiny.

Claude:

• neuměl diagnostikovat některé čistě fyzické závady,
• chápal rig hlavně přes programatickou reprezentaci,
• potřeboval mnoho kontextu,
• občas experiment zastavil a čekal na lidské potvrzení i při mírně rizikové akci.^[1]

U fyzického hardwaru může být taková opatrnost vhodnější než přehnaná jistota.

Tetsuwan: jedno zařízení problém detekuje, jiné jej řeší

Tetsuwan spojil MHS s ResearchOS v qPCR workflow souvisejícím se San Pedro Creek.^[1]

Kamera detekovala bubliny. Robot držící vzorek je nedokázal odstranit.

Systém:

1. detekoval problém,
2. prohledal MHS zařízení,
3. našel centrifuge,
4. Claude navrhl její použití,
5. po approval odeslal příkazy.^[1]

Jde o ukázku cross-device recovery místo úplně hard-coded workflow.

Partnerský ekosystém

Anthropic uvádí mimo jiné:^[1]

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

AWS plánuje podporu přes Strands Robots, Hugging Face pracuje na LeRobot a Raspberry Pi na integracích vybraných produktů.^[1]

To neznamená, že každá integrace je už dnes veřejně production-ready.

MHS ještě není open source

Oficiální web projekt označuje jako limited research preview.^[2]

Anthropic chce nejprve získat zkušenosti partnerů, vytvořit safety evaluations, best practices a posílit safeguards.^[1]

K 30. srpnu 2026 nejsou v ověřených oficiálních materiálech:

• veřejné datum open-source vydání,
• finální licence,
• kompletní veřejná specifikace s vyspělostí dokumentace MCP.

Proto je správně:

Anthropic plánuje MHS vydat jako open source.

Nikoli:

MHS už je open source.

Jsou výsledky nezávislé benchmarky?

Ne.

Veřejné hodnoty pocházejí hlavně od Anthropic a partnerů preview.

Reuters nezávisle potvrzuje spuštění preview, obecný rozsah projektu a plán pozdějšího open source.^[3]

Dosud neexistuje benchmark se stejným hardwarem, stejnými drivery, více modely, jedním harnessem a nezávislým gradingem.

Čísla jako:

99,3 %
3× rychleji
8 hodin
méně než týden

proto musí zůstat spojena s konkrétními piloty.

Threat model: co se může pokazit?

Chybné reasoning

Model může špatně vyložit senzor, error code, obraz nebo fyzickou příčinu. Genentech ukazuje reálný případ.^[1]

Chybný nebo škodlivý driver

Špatné jednotky, chybný stav nebo absence validace mohou agentovi ukázat nepravdivý obraz reality.

Prompt injection

Text z kamer, dokumentace nebo síťových dat může obsahovat škodlivé instrukce.

Confused deputy

Agent s přístupem k více zařízením může použít správný tool ke špatnému účelu.

Race conditions

Dva agenti mohou současně měnit stejný fyzický stav.

Ztráta spojení

Systém musí mít safe state při výpadku modelu, MCP, sítě, driveru nebo senzoru.

Bezpečnější produkční architektura

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

Jde o doporučení POLPROG, ne oficiální diagram Anthropic.

LLM by nikdy neměl být jedinou komponentou rozhodující, zda je fyzická operace bezpečná.

Co má vynucovat deterministická vrstva?

Například:

• teplotní rozsahy,
• maximální výkon,
• rychlost ramene,
• pracovní prostor,
• pořadí pohybů,
• collision zones,
• tlakové limity,
• stav ochranných krytů,
• emergency stop,
• maximální dobu operace.

Požadavek mimo povolený rozsah musí být odmítnut bez ohledu na reasoning modelu.

Human-in-the-loop zůstává důležitý

Specifikace MCP Tools doporučuje, aby uživatel mohl tool invocation odmítnout.^[5]

Pro hardware:

READ
automaticky

LOW-RISK WRITE
automaticky v úzkém rozsahu

MEDIUM-RISK
policy + validace

HIGH-RISK
human approval

EMERGENCY / UNSAFE
vždy zablokováno

Proč je deterministický fallback důležitý?

QuEra ukazuje praktický pattern:

AI objeví řešení
→ vytvoří se kód
→ testy a lidé ho ověří
→ produkce spouští deterministický software

To snižuje inference cost, latency, nondeterminism, závislost na API a riziko nečekaných rozhodnutí.

MHS a průmyslové řídicí systémy

MHS není náhrada PLC, SCADA, OPC UA, safety PLC nebo real-time controllerů.

Realističtější pozice:

agent
↓
orchestration
↓
MHS
↓
stávající controllery
↓
hardware

Anthropic sám ukazuje, že rychlé nebo dlouhé operace lze zabalit do kódu, takže LLM nemusí reasoning provádět při každém kroku.^[1]

Kdo by měl MHS sledovat už nyní?

Především:

• laboratoře s multi-vendor vybavením,
• biotech a pharma,
• microscopy,
• robotika,
• quantum computing,
• advanced manufacturing,
• R&D týmy s velkým množstvím bespoke integration code.

Kdo by měl být opatrný?

Pokud:

• systém je safety-critical,
• potřebujete stabilní veřejnou specifikaci,
• požadujete známou open-source licenci,
• jsou nutné certifikované průmyslové standardy,
• hardware nemá automatizovatelné rozhraní,
• chybí nezávislé interlocky,
• tým neumí auditovat drivery.

Research preview není vyzrálý průmyslový standard.

Jak může firma připravit infrastrukturu?

Krok 1: inventář

vendor
model
SDK/API/GUI
jednotky
stavy
příkazy
limity
E-stop
závislosti

Krok 2: oddělit read a write

Definujte, co lze číst, měnit, automatizovat a co vyžaduje approval.

Krok 3: bezpečnost nesmí být jen v promptu

Nespoléhejte na:

"nikdy nepřekračuj 80°C"

Skutečný limit musí vynucovat kód nebo hardware.

Krok 4: logovat vše

Agent/model, operace, parametry, stav před/po, výsledek, timestamp, policy a approval.

Krok 5: nejprve simulace

digital twin / mock driver

a až potom:

real hardware

Minimální testovací plán

Driver

• jednotky,
• ranges,
• timeouts,
• reconnect,
• neplatné odpovědi,
• restart.

Agent

• chybný sensor reading,
• konfliktní data,
• neznámý error code,
• prompt injection,
• chybějící kontext.

Hardware

• collision prevention,
• E-stop,
• power loss,
• network loss,
• mechanické blokování,
• out-of-range values.

Multi-agent

• současné writes,
• stale state,
• resource locking,
• retry po timeout.

MHS bezpečnostní checklist

Architektura

• Model neřídí actuatory bez validace.
• Každý driver má explicitní limity.
• Hodnoty mají jednotky a rozsahy.
• Kritické hranice jsou deterministické.
• E-stop funguje nezávisle na AI.
• Safe state po ztrátě spojení.
• Device state má timestamp.
• Retry je bezpečný.

Oprávnění

• Agent vidí jen potřebná zařízení.
• READ a WRITE jsou oddělené.
• High-risk actions vyžadují approval.
• Oprávnění expirují.
• Neexistuje jeden globální admin token.

Monitoring

• Každý tool call se loguje.
• Fyzické změny mají telemetry.
• Alarmy nejsou závislé jen na modelu.
• Operátor vidí aktuální stav.
• Je dostupný event replay.
• Chyby jsou klasifikovány.

Testy

• Mock hardware.
• Physical sandbox.
• Fault injection.
• Prompt injection.
• Race conditions.
• Network partition.
• Agent restart.
• Driver restart.
• Chybné jednotky.
• Out-of-range values.

Produkce

• Rollout začíná read-only.
• Poté low-risk writes.
• Safety-critical actions zůstávají mimo agenta.
• Deterministický kód nahrazuje AI, kde je to možné.
• Drivery procházejí code review.
• Existuje rollback.
• Existuje ruční převzetí řízení.
• Tým zná fyzické důsledky každého příkazu.

Co je potřeba, aby se MHS stal skutečným standardem?

Mimo jiné:

1. veřejná specifikace,
2. stabilní versioning,
3. model kompatibility,
4. veřejná SDK,
5. open-source licence,
6. reference drivers,
7. conformance tests,
8. security evaluations,
9. nezávislé implementace,
10. vendor support,
11. validace driverů,
12. jasný permission model.

MCP získal význam díky interoperabilnímu ekosystému. MHS bude muset projít podobnou cestou.

Změní MHS robotiku?

Možná, ale je příliš brzy.

Nejlepší krátkodobý fit je tam, kde je hardware už programovatelný, integrace je drahá a workflow se často mění:

laboratoře
R&D
biotech
microscopy
quantum
advanced manufacturing

MHS automaticky neřeší robot perception, motion planning, real-time control, safety certification ani fyziku manipulace.

Může však zjednodušit rozhraní, přes které agent používá existující řídicí systémy.

Verdikt POLPROG

Model Hardware Standard je jedním z nejzajímavějších agentních směrů roku 2026, protože přenáší interoperabilitu z digitálního světa do fyzického.

Co je potvrzeno?

• research preview od 27. srpna 2026.^[1][3]
• původ ve spolupráci Anthropic + HHMI Janelia.^[1]
• model-agnostic.^[1]
• řízení přes MCP, CLI a code/API files.^[1]
• driver popisuje zařízení a safety limits.^[1]
• Anthropic plánuje pozdější open-source vydání.^[1][2]
• QuEra potvrzuje 695 úspěšných relocků ze 700 u finálního controlleru.^[7]

Co ještě nevíme?

• finální veřejné schema,
• datum open-source,
• licenci,
• stabilitu API,
• kompatibilitu implementací,
• nezávislé benchmarky,
• výkon různých modelů na stejném hardwaru.

Nejslibnější pattern

Ne:

LLM neustále řídí všechno

ale:

agent chápe cíl
→ zkoumá bezpečný prostor
→ koordinuje zařízení
→ vytvoří nebo vybere proceduru
→ systém ji ověří
→ opakovatelná práce přejde do deterministického kódu

Pokud Anthropic skutečně otevře specifikaci, výrobci nabídnou znovupoužitelné drivery a nezávislé týmy ověří bezpečnost a interoperabilitu, může se MHS stát důležitou vrstvou physical AI.

Ještě tam nejsme.