Model Hardware Standard od Anthropic: jak MHS pozwala agentom AI sterować sprzętem i czym różni się od MCP

27 sierpnia 2026 roku Anthropic otworzył research preview Model Hardware Standard (MHS), czyli wspólnej specyfikacji mającej umożliwić agentom AI bezpieczniejsze odkrywanie, opisywanie i obsługiwanie programowalnego sprzętu fizycznego.^[1]

MHS powstał początkowo we współpracy Anthropic z HHMI Janelia Research Campus. W pierwszych wdrożeniach standard został wykorzystany między innymi do łączenia mikroskopów, liquid handlerów, ramion robotycznych, czytników płytek oraz elementów systemu laserowego komputera kwantowego.^[1]

To ważna zmiana w sposobie myślenia o agentach AI. Do tej pory większość popularnych agentów wykonywała działania przede wszystkim w świecie cyfrowym:

pliki
repozytoria
terminal
API
przeglądarka
bazy danych
systemy SaaS

MHS próbuje ustandaryzować kolejną warstwę:

czujniki
kamery
mikroskopy
roboty laboratoryjne
ramiona robotyczne
lasery
urządzenia pomiarowe
sprzęt produkcyjny

Nie należy jednak opisywać premiery jako „Claude dostał dostęp do każdego urządzenia”. MHS jest obecnie ograniczonym research preview, dostęp jest przyznawany po zgłoszeniu, a standard nie został jeszcze publicznie wydany jako open source. Anthropic deklaruje zamiar otwarcia go po okresie testów bezpieczeństwa, ale na 30 sierpnia nie podał publicznej daty wydania ani licencji przyszłej wersji open-source.^[1][2]

MHS nie jest również nowym modelem AI i nie zastępuje Model Context Protocol (MCP). Anthropic opisuje MHS jako model-agnostic, a MCP jest jednym z trzech mechanizmów, przez które agent może sterować sprzętem opisanym przez MHS. Pozostałe to CLI oraz pliki kodu/API.^[1]

Najważniejszy wniosek: MHS nie jest „MCP 2.0” ani robotem. Jest próbą stworzenia wspólnej warstwy sterowników, opisu możliwości urządzeń i fizycznych ograniczeń bezpieczeństwa, dzięki której agent AI może korzystać z wielu różnych maszyn przez spójny interfejs.

Stan informacji: 30 sierpnia 2026 roku.

TL;DR

Pytanie	Zweryfikowana odpowiedź
Co zapowiedział Anthropic?	Research preview Model Hardware Standard
Kiedy?	27 sierpnia 2026
Czym jest MHS?	Wspólną specyfikacją i warstwą sterowników dla programowalnego sprzętu
Czy MHS jest nowym modelem Claude?	Nie
Czy MHS jest już open source?	Nie
Czy Anthropic planuje open source?	Tak, po fazie preview i pracach nad bezpieczeństwem
Czy znamy datę otwarcia?	Nie
Czy znamy przyszłą licencję?	Nie została wskazana w sprawdzonych oficjalnych materiałach
Czy MHS zastępuje MCP?	Nie
Jak MHS korzysta z MCP?	MCP jest jednym z mechanizmów sterowania sprzętem MHS
Pozostałe mechanizmy	CLI i pliki kodu/API
Czy MHS działa tylko z Claude?	Nie, Anthropic opisuje go jako model-agnostic
Jakie urządzenia?	Urządzenia z programowalnym interfejsem; pilotaże obejmują m.in. sprzęt laboratoryjny i robotyczny
Najmocniejszy publiczny wynik pilotażu	QuEra: 695/700 poprawnych relocków lasera, 99,3%
Czy to niezależny benchmark?	Nie, to wynik pilotażu partnera, nie uniwersalny benchmark MHS
Największe ryzyko	Błąd agenta może mieć fizyczne konsekwencje
Najważniejsza zasada bezpieczeństwa	Ograniczenia i interlocki powinny być egzekwowane poza samym modelem

Czym dokładnie jest Model Hardware Standard?

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

Problem, który próbuje rozwiązać, nie jest nowy. Laboratorium lub linia produkcyjna może korzystać z urządzeń wielu producentów. Każde z nich często ma inne SDK, inne API, inny format danych, własny program desktopowy, osobną dokumentację oraz własny model błędów i ograniczeń.

Połączenie kilku urządzeń w jeden workflow wymaga wtedy tworzenia indywidualnego „glue code”.

Anthropic twierdzi, że takie integracje potrafią trwać tygodniami lub miesiącami. MHS ma w idealnym przypadku skrócić część tej pracy do godzin lub minut.^[1] Ta ogólna deklaracja jest jednak twierdzeniem producenta, a nie niezależnym benchmarkiem całej branży.

MHS nie jest robotem i nie jest modelem

MHS nie jest:

• nowym modelem Claude,
• systemem operacyjnym dla robotów,
• nowym rodzajem robota,
• zamiennikiem firmware urządzenia,
• samodzielnym algorytmem sterowania ruchem,
• standardem sieci przemysłowej zastępującym wszystkie istniejące protokoły.

Najbliżej mu do warstwy interoperacyjności między agentem a programowalnym sprzętem.

Agent nadal potrzebuje modelu, harnessa lub aplikacji, uprawnień, sterownika danego urządzenia, interfejsu sprzętowego i fizycznych zabezpieczeń.

Jak działa MHS?

3.1. Standaryzowany driver

MHS wprowadza standardowy driver, który tłumaczy operacje pomiędzy komputerem i urządzeniem.^[1]

Anthropic podaje proste typy operacji:

read
write

na przykład:

read temperature
write temperature

To nie oznacza, że każde urządzenie ma tylko dwie komendy. Chodzi o prosty zestaw prymitywów, na którym można zbudować bardziej złożony interfejs.

3.2. Standardowy opis urządzenia

MHS ma uczynić urządzenie discoverable w jednolitym formacie, aby agent i inne urządzenia mogły odnaleźć je w sieci i zrozumieć dostępne możliwości.^[1]

Opis może zawierać:

• co urządzenie mierzy,
• jakie parametry można zmieniać,
• właściwości fizyczne,
• istotne ograniczenia,
• granice bezpieczeństwa.

Anthropic podaje przykład masy ramienia robota jako informacji ważnej dla bezpiecznej manipulacji.^[1]

3.3. Tagi w języku naturalnym

MHS przewiduje tagi, w których użytkownik może opisać istotne cechy sprzętu językiem naturalnym. Może zrobić to ręcznie albo poprzez rozmowę z agentem, który przeprowadzi go przez konfigurację.^[1]

Na tej podstawie driver generuje plik referencyjny opisujący charakterystykę urządzenia, pomiary, ustawienia i egzekwowane limity bezpieczeństwa.

Publiczny wpis Anthropic nie jest jednak kompletną dokumentacją schematu MHS. Specyfikacja pozostaje w ograniczonym preview, dlatego nie należy wymyślać nazw pól ani publikować pseudokonfiguracji jako oficjalnego formatu.

Trzy sposoby sterowania sprzętem

Anthropic wymienia trzy mechanizmy sterowania urządzeniami MHS:^[1]

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

MCP

Agent może korzystać z urządzeń przez Model Context Protocol. MCP pozwala serwerom wystawiać między innymi tools, czyli funkcje, które model może odkrywać i wywoływać.^[4][5]

CLI

Sprzętem można sterować również bezpośrednio przez interfejs wiersza poleceń. To przydatne dla operatora, skryptów, debugowania i testów integracji.

Pliki kodu i API

Agent może połączyć komendy jednego lub wielu urządzeń w zwykły program. Anthropic podkreśla, że jest to szczególnie ważne dla szybkich operacji, powtarzalnych sekwencji i zadań długotrwałych, gdzie model nie powinien podejmować decyzji przy każdym mikro-kroku.^[1]

Agent może nauczyć się procedury, a potem wyjść z pętli

Model generatywny nie musi sterować urządzeniem w każdej milisekundzie.

W jednym z przykładów Claude:

1. zmieniał ustawienia lasera,
2. obserwował wynik przez kamerę,
3. powtarzał eksperyment,
4. rozpoznawał zależności,
5. zapisał wyuczoną procedurę jako deterministyczny skrypt.^[1]

Po tym etapie skrypt mógł wykonywać procedurę bez ciągłego reasoning modelu.

To ważny wzorzec produkcyjny:

AI eksploruje
        ↓
AI tworzy procedurę
        ↓
człowiek / testy weryfikują
        ↓
deterministyczny kod wykonuje zadanie

QuEra zastosowała taki model przy kontrolerze ponownego blokowania lasera: agent pomógł stworzyć i przetestować kod, ale finalny kontroler jest zwykłym, inspekcyjnym programem i nie wymaga modelu w runtime.^[7]

MHS vs MCP: najważniejsza różnica

Element	MCP	MHS
Główny cel	Łączenie aplikacji AI z narzędziami, danymi i systemami	Standaryzacja opisu i kontroli fizycznego sprzętu
Typ zasobu	Software, API, dane, narzędzia	Programowalne urządzenia fizyczne
Model komunikacji	Host, client, server, JSON-RPC	Driver + opis sprzętu + mechanizmy sterowania
Tools	Tak	Może być udostępniany przez MCP
CLI	Nie jest głównym modelem protokołu	Jeden z oficjalnie opisanych sposobów kontroli
API/code files	Mogą istnieć za MCP	Jeden z oficjalnie opisanych sposobów kontroli
Fizyczne limity urządzenia	Nie są głównym zakresem MCP	Są elementem opisu MHS
Open source dzisiaj	Tak	Jeszcze nie
Status	Otwarty protokół	Ograniczony research preview

MCP został przez Anthropic wydany w 2024 roku jako otwarty standard umożliwiający dwukierunkowe połączenia między systemami AI a źródłami danych i narzędziami.^[4] Dokumentacja MCP opisuje architekturę host-client-server, capability negotiation oraz tools, resources i prompts.^[5][6]

MHS nie zastępuje tej warstwy.

Koncepcyjnie można przedstawić stos tak:

MODEL / AGENT
      │
      ├── MCP
      ├── CLI
      └── CODE / API
             │
          MHS DRIVER
             │
    INTERFEJS URZĄDZENIA
             │
        FIZYCZNY SPRZĘT

To diagram koncepcyjny POLPROG, nie oficjalny diagram specyfikacji.

Czy MHS jest „MCP dla świata fizycznego”?

To chwytliwe hasło, ale technicznie zbyt uproszczone.

Podobieństwo jest realne: oba projekty ograniczają liczbę indywidualnych integracji i tworzą wspólny interfejs dla agentów.

Różnica jest fundamentalna. MCP jest protokołem komunikacyjnym dla systemów AI i narzędzi. MHS dodaje semantykę fizycznego urządzenia, jego stanu, możliwości i ograniczeń.

Co więcej, MHS może korzystać z MCP.

Dlatego lepiej pisać:

MHS uzupełnia MCP o warstwę przeznaczoną dla fizycznego sprzętu.

niż:

MHS zastępuje MCP w robotyce.

MHS jest model-agnostic

Anthropic deklaruje, że MHS jest model-agnostic i że dowolny agent harness może uzyskać do niego dostęp przez standardowe protokoły, takie jak MCP.^[1]

Koncepcja nie jest więc formalnie ograniczona do Claude czy Claude Code.

W praktyce publiczne case studies skupiają się głównie na Claude, bo są to pilotaże Anthropic i partnerów. Nie ma jeszcze szerokiego, niezależnego benchmarku porównującego różne modele na tym samym sprzęcie, tym samym MHS driverze i tym samym zestawie zadań.

Bezpieczeństwo musi działać poniżej warstwy modelu

W świecie software błędny tool call może usunąć plik. W świecie fizycznym może uderzyć ramieniem robota, rozlać próbkę, przegrzać urządzenie albo zniszczyć eksperyment.

Natural-language prompt nie może być jedynym zabezpieczeniem.

MHS ma przekazywać informacje o egzekwowanych safety limits.^[1] W pilotażu QuEra firma podkreśla, że limity, interlocki i emergency stops były egzekwowane na interfejsie sprzętowym niezależnie od modelu.^[7]

Właściwy kierunek wygląda tak:

MODEL
proponuje działanie

POLICY / APPROVAL
może zaakceptować lub odrzucić

DRIVER / CONTROLLER
egzekwuje limity

HARDWARE INTERLOCK
chroni system nawet po błędzie software

Genentech: BCA protein assay i fizyczny błąd, którego agent nie rozumiał

Genentech testował MHS przy automatyzacji BCA protein assay, koordynując liquid handler, robotic arm i microplate reader.^[1]

Najciekawszy fragment dotyczył błędu.

Podczas mieszania powstawały pęcherzyki powodujące runtime errors. Claude początkowo traktował problem jak błąd software: próbował ponawiać operację w tym samym well z innymi parametrami. To pogarszało sytuację, bo dalsze mieszanie tworzyło więcej pęcherzyków.^[1]

Dopiero człowiek wyjaśnił fizyczną przyczynę oraz potrzebę użycia czystego well i łagodniejszego mieszania. Następnie zespół zakodował tę wiedzę w reusable liquid-handling skills.^[1]

Wniosek jest ważny:

Model może poprawnie widzieć błąd programu, a jednocześnie błędnie rozumieć fizykę procesu.

University of Washington: sześć urządzeń w mniej niż tydzień

W laboratoriach Baker i Pinglay MHS wykorzystano do zdalnego monitorowania instrumentów, nadzorowania qPCR i koordynacji ramienia robotycznego z liquid handlerem.^[1]

W demonstracji plate handoff liquid handler kończył dozowanie, agent odbierał sygnał, a około 10 sekund później uruchamiał ruch ramienia. Według opisu w powtarzanych testach urządzenia nie kolidowały.

Podłączenie sześciu urządzeń przez MHS miało zająć mniej niż tydzień, łącznie z napisaniem driverów.^[1]

To wynik konkretnego laboratorium, nie gwarancja dla dowolnego sprzętu.

Carnegie Mellon: sześć sztucznie wywołanych warunków bezpieczeństwa

Zespół Carnegie Mellon University zastosował MHS do serial dilution dose-response.^[1]

System obejmował liquid handler, plate reader, robotic arm, monitoring cameras i trzy komputery z niekompatybilnymi interfejsami.

Badacze sztucznie wywołali sześć warunków:

1. brak płytki,
2. obrócona płytka,
3. zajęty reader,
4. odłączona kamera,
5. nieosiągalne urządzenie,
6. aktywny emergency stop.^[1]

Według raportu wszystkie sześć zostało zablokowane przed ruchem urządzenia.

To dobry proof-of-concept, ale nie certyfikacja bezpieczeństwa standardu.

Autonomiczna korekta eksperymentu

W pierwszym runie agent odrzucił krzywą:

R² < 0,9

i zmniejszył maksymalne stężenie:

200 µg/mL
→
100 µg/mL

Kolejny run uzyskał:

R² > 0,98

bez interwencji człowieka.^[1]

Badacze podają, że cały proces od gotowego, lecz niezautomatyzowanego sprzętu do ukończonej krzywej wraz z autonomicznym rerunem trwał około 8 godzin. Porównują to z wieloma tygodniami typowej integracji vendorskiej.^[1]

HHMI Janelia: wspólny stan dla siedmiu programów

W jednym z projektów Janelia badaczka musiała wcześniej uruchamiać siedem programów w odpowiedniej kolejności.

MHS zastąpił punktowe połączenia wspólnym state dictionary w shared memory.^[1]

Według opisu:

• dodanie nowej kamery zajęło kilka minut zamiast wielu dni,
• start eksperymentu zmienił się z siedmiu etapów w pojedynczą operację,
• strumienie danych mogły być analizowane wspólnymi narzędziami niezależnie od programu źródłowego.^[1]

MHS ma też egzekwować urządzeniowe granice, np. maksymalną moc lasera, aby agent nie mógł przekroczyć zakresu bezpiecznego dla próbki.^[1]

QuEra: 695 na 700 relocków lasera

Najbardziej mierzalny publiczny wynik pochodzi z QuEra Computing.

Firma wykorzystała MHS, aby dać Claude dostęp do systemu laserowego komputera kwantowego.^[1][7][8]

Po fazie eksperymentalnej powstał deterministyczny kontroler.

QuEra przeprowadziła:

700 prób
7 klas zakłóceń
100 prób na klasę

Kontroler poprawnie odzyskał cel:

695 / 700
=
99,3%

^[7]

Prostsze błędy naprawiał w około:

0,9–5,4 s

najtrudniejsze:

10–14 s

QuEra porównuje to z ręczną procedurą eksperta trwającą:

5–10 minut

^[7]

To nie jest benchmark skuteczności Claude

W finalnym blind teście agent nie sterował sprzętem online.

Prawidłowe zdanie:

Agent wykorzystujący MHS pomógł opracować kontroler, który później osiągnął 99,3%.

Nie:

Claude ma 99,3% skuteczności w sterowaniu sprzętem.

Rozbieżność w źródłach

Anthropic opisuje wcześniejszy ręcznie napisany skrypt QuEra jako pracę trwającą „several months”.^[1]

Własny wpis QuEra mówi o około 2–3 tygodniach.^[7]

Ponieważ źródła różnią się w tej wartości, nie używamy czasu budowy poprzedniego skryptu jako twardej metryki porównawczej.

Ograniczenia ujawnione przez QuEra

Publiczne opisy wymieniają też problemy:

• Claude nie potrafił diagnozować części usterek czysto fizycznych,
• rozumiał rig przede wszystkim od strony programatycznej,
• wymagał dużo kontekstu,
• często zatrzymywał się i czekał na zgodę człowieka przy operacjach uznanych za ryzykowne.^[1]

W systemach fizycznych taki konserwatyzm może być pożądaną właściwością.

Tetsuwan: błąd wykryty przez jedno urządzenie, naprawiony przez inne

Tetsuwan połączył MHS z ResearchOS przy workflow qPCR dotyczącym zanieczyszczenia San Pedro Creek.^[1]

Kamera wykryła pęcherzyki w próbce. Robot trzymający próbkę nie mógł ich usunąć.

System:

1. wykrył problem,
2. przeszukał urządzenia połączone z MHS,
3. znalazł centrifuge,
4. Claude zaproponował użycie jej do usunięcia pęcherzyków,
5. po akceptacji wydał komendy do centrifuge.^[1]

To pokazuje potencjał orchestration across devices zamiast sztywno zakodowanego workflow.

Ekosystem partnerów

Anthropic wymienia między innymi:^[1]

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

AWS ma wspierać MHS przez Strands Robots. Hugging Face pracuje nad integracją w LeRobot, a Raspberry Pi nad integracją na wybranych produktach.^[1]

Nie oznacza to, że każdy z tych produktów ma dziś gotowe publiczne wsparcie produkcyjne. Część prac znajduje się w research preview lub fazie budowy.

MHS nie jest jeszcze open source

Oficjalna strona projektu mówi wprost, że MHS rozpoczyna się jako limited research preview.^[2]

Anthropic chce najpierw:

1. zebrać doświadczenia partnerów,
2. zbudować safety evaluations,
3. opracować best practices,
4. wzmocnić zabezpieczenia,
5. później otworzyć standard.^[1]

Na 30 sierpnia 2026 w sprawdzonych oficjalnych materiałach:

• nie ma publicznej daty wydania open-source,
• nie wskazano finalnej licencji,
• nie ma publicznej kompletnej specyfikacji o dojrzałości dokumentacji MCP.

Dlatego poprawne jest:

Anthropic planuje open-source MHS.

Nie:

MHS jest już open-source.

Czy wyniki są niezależnymi benchmarkami?

Nie.

Publiczne liczby pochodzą przede wszystkim z Anthropic i partnerów uczestniczących w preview.

Reuters niezależnie potwierdza fakt uruchomienia research preview, zakres projektu i plan późniejszego open source.^[3]

Nie istnieje jeszcze publiczny benchmark z:

• wspólnymi urządzeniami,
• identycznymi driverami,
• wieloma modelami,
• jednym agent harness,
• powtarzalnym zestawem błędów,
• niezależnym gradingiem.

Wyniki takie jak:

99,3%
3× szybciej
8 godzin
mniej niż tydzień

należy przypisywać konkretnym pilotażom.

Threat model: co może pójść źle?

Błędne reasoning

Model może źle zinterpretować sensor, error code, obraz albo fizyczną przyczynę błędu. Genentech pokazał realny przykład.^[1]

Błędny lub złośliwy driver

Błąd jednostek, nieprawidłowy stan lub brak walidacji może dać agentowi fałszywy obraz sprzętu.

Prompt injection

Dane z kamer, dokumentacji i systemów zewnętrznych mogą zawierać treści złośliwe lub manipulujące agentem.

Confused deputy

Agent z dostępem do wielu urządzeń może użyć prawidłowego narzędzia w niewłaściwym celu.

Race conditions

Dwa agenty mogą próbować modyfikować ten sam stan fizyczny równocześnie.

Utrata łączności

Bezpieczny stan musi być zdefiniowany na wypadek utraty modelu, MCP, sieci, drivera lub sensora.

Bezpieczna architektura

┌───────────────────────────────┐
│ MODEL / AGENT                 │
│ planuje i proponuje działania │
└──────────────┬────────────────┘
               │
┌──────────────▼────────────────┐
│ POLICY + APPROVAL             │
│ role, scopes, human approval  │
└──────────────┬────────────────┘
               │
┌──────────────▼────────────────┐
│ MCP / CLI / API               │
│ kanał sterowania              │
└──────────────┬────────────────┘
               │
┌──────────────▼────────────────┐
│ MHS DRIVER                    │
│ stan, procedury, limity       │
└──────────────┬────────────────┘
               │
┌──────────────▼────────────────┐
│ DETERMINISTIC CONTROLLER      │
│ walidacja, bounds, sequencing │
└──────────────┬────────────────┘
               │
┌──────────────▼────────────────┐
│ HARDWARE INTERLOCK / E-STOP   │
└──────────────┬────────────────┘
               │
          FIZYCZNY SPRZĘT

To rekomendowany model POLPROG, nie oficjalny diagram Anthropic.

Najważniejsza zasada:

LLM nie powinien być jedynym komponentem decydującym, czy fizyczna operacja jest bezpieczna.

Co powinna egzekwować warstwa deterministyczna?

Przykłady:

• zakres temperatury,
• maksymalna moc,
• prędkość ramienia,
• przestrzeń robocza,
• kolejność ruchów,
• collision zones,
• limity ciśnienia,
• stan osłon,
• emergency stop,
• maksymalny czas operacji.

Jeśli agent żąda wartości poza dopuszczonym zakresem, system powinien ją odrzucić niezależnie od reasoning modelu.

Human-in-the-loop nadal ma znaczenie

Dokumentacja MCP zaleca, aby przy tools użytkownik miał możliwość odmowy wywołania.^[5]

Przy sprzęcie fizycznym warto stosować poziomy:

READ
automatycznie

LOW-RISK WRITE
automatycznie w określonym zakresie

MEDIUM-RISK
policy + dodatkowa walidacja

HIGH-RISK
human approval

EMERGENCY / UNSAFE
zawsze zablokowane

Dlaczego deterministic fallback jest tak ważny?

QuEra pokazuje praktyczny wzorzec:

AI odkrywa rozwiązanie
→ kod jest generowany
→ testy i człowiek go weryfikują
→ produkcja uruchamia deterministyczny program

To ogranicza:

• koszt inferencji,
• latency,
• nondeterminism,
• zależność od API,
• ryzyko niespodziewanej decyzji modelu.

MHS a przemysłowe systemy sterowania

MHS nie powinien być traktowany jako zamiennik PLC, SCADA, OPC UA, safety PLC czy sterowników czasu rzeczywistego.

Może stanowić warstwę wyżej:

agent
↓
orchestration
↓
MHS
↓
istniejące kontrolery
↓
hardware

Anthropic sam pokazuje, że szybkie lub długotrwałe operacje mogą być pakowane do kodu, aby urządzenia wykonywały je bez reasoning LLM przy każdym kroku.^[1]

Kto powinien zainteresować się MHS już teraz?

Najbardziej:

• laboratoria z urządzeniami wielu vendorów,
• biotech i pharma,
• microscopy,
• robotics,
• quantum computing,
• advanced manufacturing,
• zespoły R&D tworzące dużo bespoke integrations.

Kto powinien zachować ostrożność?

Jeśli:

• system jest safety-critical,
• potrzebujesz stabilnej publicznej specyfikacji,
• potrzebujesz znanej licencji open-source,
• wymagane są certyfikowane standardy przemysłowe,
• urządzenie nie ma automatyzowalnego interfejsu,
• nie ma niezależnych interlocków,
• organizacja nie ma kompetencji do audytu driverów.

Research preview nie jest tym samym co dojrzały standard produkcyjny.

Jak przygotować firmę na MHS?

Krok 1: inwentaryzacja

Dla każdego urządzenia spisz:

vendor
model
SDK/API/GUI
jednostki
stany
komendy
limity
E-stop
zależności

Krok 2: oddziel read od write

Zdefiniuj, co można odczytać, co można zmienić, co jest low-risk i co wymaga approval.

Krok 3: usuń bezpieczeństwo z prompta

Nie polegaj na instrukcji:

"nigdy nie ustawiaj temperatury powyżej 80°C"

Prawdziwy limit musi być egzekwowany przez kod lub hardware.

Krok 4: loguj wszystko

Log powinien zawierać:

• agent/model,
• operację,
• parametry,
• stan przed i po,
• wynik,
• timestamp,
• decyzję policy,
• approval.

Krok 5: symulator przed sprzętem

Najpierw:

digital twin / mock driver

dopiero potem:

real hardware

Minimalny plan testów

Driver

• jednostki,
• ranges,
• timeouts,
• reconnect,
• błędne odpowiedzi,
• restart.

Agent

• błędny sensor reading,
• sprzeczne dane,
• nieznany error code,
• prompt injection,
• brak kontekstu.

Hardware

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

Wieloagentowość

• jednoczesne writes,
• stale state,
• resource locking,
• retry po timeout.

Checklista bezpieczeństwa MHS

Architektura

• Model nie steruje actuatorami bez walidacji.
• Każdy driver ma jawne limity.
• Wartości mają jednostki i zakresy.
• Krytyczne limity są deterministyczne.
• E-stop działa niezależnie od AI.
• System ma safe state po utracie łączności.
• Device state ma timestamp.
• Retry jest bezpieczne.

Uprawnienia

• Agent widzi tylko potrzebne urządzenia.
• READ i WRITE są rozdzielone.
• High-risk actions wymagają approval.
• Uprawnienia wygasają.
• Nie ma jednego admin tokenu dla całego środowiska.

Monitoring

• Każdy tool call jest logowany.
• Fizyczne zmiany mają telemetry.
• Alarmy nie zależą tylko od modelu.
• Operator widzi stan urządzeń.
• Jest event replay.
• Nieudane działania są klasyfikowane.

Testy

• Mock hardware.
• Physical sandbox.
• Fault injection.
• Prompt injection.
• Race conditions.
• Network partition.
• Restart agenta.
• Restart drivera.
• Błędne jednostki.
• Out-of-range values.

Produkcja

• Rollout zaczyna się od read-only.
• Następnie low-risk writes.
• Safety-critical actions pozostają poza agentem.
• Deterministyczny kod zastępuje AI tam, gdzie to możliwe.
• Drivery przechodzą code review.
• Jest rollback.
• Jest ręczne przejęcie kontroli.
• Zespół zna fizyczne konsekwencje każdej komendy.

Co musi się wydarzyć, aby MHS stał się rzeczywistym standardem?

Potrzebne będą m.in.:

1. publiczna specyfikacja,
2. stabilny versioning,
3. model kompatybilności,
4. publiczne SDK,
5. licencja open-source,
6. reference drivers,
7. conformance tests,
8. security evaluations,
9. niezależne implementacje,
10. wsparcie vendorów,
11. walidacja driverów,
12. jasny permission model.

MCP zyskał znaczenie dzięki interoperacyjnemu ekosystemowi. MHS będzie musiał przejść podobną drogę.

Czy MHS zmieni robotykę?

Może, ale na razie jest za wcześnie.

Najbardziej prawdopodobny wpływ dotyczy środowisk, gdzie sprzęt jest już programowalny, urządzeń jest dużo, integracja jest droga, a workflow często się zmienia:

laboratoria
R&D
biotech
microscopy
quantum
advanced manufacturing

MHS nie rozwiązuje automatycznie percepcji robota, motion planning, real-time control, safety certification czy fizyki manipulacji.

Może natomiast uprościć warstwę, przez którą agent korzysta z już istniejących rozwiązań.

Werdykt POLPROG

Model Hardware Standard jest jednym z ciekawszych rozwinięć trendu agentowego w 2026 roku, ponieważ przenosi problem interoperacyjności z systemów cyfrowych na sprzęt.

Co jest potwierdzone?

• MHS wystartował jako research preview 27 sierpnia 2026.^[1][3]
• projekt rozpoczął się we współpracy Anthropic i HHMI Janelia.^[1]
• jest model-agnostic.^[1]
• może być kontrolowany przez MCP, CLI i code/API files.^[1]
• MHS driver opisuje urządzenie i jego safety limits.^[1]
• Anthropic planuje później udostępnić standard jako open source.^[1][2]
• QuEra potwierdza 695 poprawnych relocków na 700 prób finalnego kontrolera.^[7]

Czego jeszcze nie wiemy?

• finalnego publicznego schematu,
• daty open-source,
• licencji,
• stabilności API,
• zgodności implementacji,
• wyniku niezależnego benchmarku,
• zachowania różnych modeli na wspólnym sprzęcie.

Najbardziej obiecujący wzorzec

Nie:

LLM steruje wszystkim cały czas

lecz:

agent rozumie cel
→ eksploruje bezpieczną przestrzeń
→ koordynuje urządzenia
→ tworzy lub dobiera procedurę
→ system waliduje wynik
→ powtarzalne operacje przechodzą do deterministycznego kodu

Jeśli Anthropic rzeczywiście otworzy specyfikację, producenci wdrożą wspólne drivery, a niezależne zespoły potwierdzą bezpieczeństwo i interoperacyjność, MHS może stać się ważną warstwą dla physical AI.

Jeszcze tam nie jesteśmy.