Anthropic Model Hardware Standard: wie MHS KI-Agenten Hardware steuern lässt und worin es sich von MCP unterscheidet

Am 27. August 2026 eröffnete Anthropic einen Research Preview des Model Hardware Standard (MHS). Die gemeinsame Spezifikation soll KI-Agenten ermöglichen, programmierbare physische Geräte sicherer zu entdecken, zu beschreiben und zu bedienen.^[1]

MHS entstand zunächst in Zusammenarbeit von Anthropic mit dem HHMI Janelia Research Campus. In frühen Projekten wurde der Standard unter anderem mit Mikroskopen, Liquid Handlern, Roboterarmen, Plattenlesern und Komponenten des Lasersystems eines Quantencomputers eingesetzt.^[1]

Das ist relevant, weil die meisten verbreiteten KI-Agenten bisher vor allem in einer digitalen Umgebung handeln:

Dateien
Repositories
Terminal
APIs
Browser
Datenbanken
SaaS-Systeme

MHS versucht eine weitere Schicht zu standardisieren:

Sensoren
Kameras
Mikroskope
Laborroboter
Roboterarme
Laser
Messgeräte
Produktionsanlagen

Die Ankündigung sollte aber nicht als „Claude kann jetzt jede Maschine steuern“ beschrieben werden. MHS ist aktuell ein begrenzter Research Preview, der Zugang erfolgt per Bewerbung und der Standard wurde noch nicht öffentlich als Open Source veröffentlicht. Anthropic erklärt, MHS nach der Preview-Phase und zusätzlichen Sicherheitsarbeiten öffnen zu wollen. Zum 30. August gibt es jedoch weder ein öffentliches Release-Datum noch eine genannte Lizenz für die künftige offene Version.^[1][2]

MHS ist auch kein neues KI-Modell und ersetzt das Model Context Protocol (MCP) nicht. Anthropic bezeichnet MHS als model-agnostic. MCP ist einer von drei Mechanismen, über die ein Agent MHS-Hardware steuern kann; die anderen sind CLI sowie Code-Dateien/APIs.^[1]

Kernaussage: MHS ist weder „MCP 2.0“ noch ein Roboter. Es ist der Versuch, eine gemeinsame Treiber-, Gerätebeschreibungs- und physische Sicherheitsschicht zu schaffen, über die ein KI-Agent verschiedene Maschinen über ein konsistenteres Interface nutzen kann.

Informationsstand: 30. August 2026.

TL;DR

Frage	Verifizierte Antwort
Was hat Anthropic angekündigt?	Research Preview des Model Hardware Standard
Wann?	27. August 2026
Was ist MHS?	Gemeinsame Spezifikation und Treiberschicht für programmierbare Hardware
Ist MHS ein neues Claude-Modell?	Nein
Ist MHS heute Open Source?	Nein
Plant Anthropic Open Source?	Ja, nach Preview und Sicherheitsarbeit
Gibt es ein Release-Datum?	Nein
Gibt es eine öffentliche künftige Lizenz?	In den geprüften offiziellen Quellen nicht genannt
Ersetzt MHS MCP?	Nein
Wie nutzt MHS MCP?	MCP ist ein Steuerungsmechanismus für MHS-Hardware
Weitere Mechanismen	CLI und Code/API-Dateien
Funktioniert MHS nur mit Claude?	Nein, Anthropic nennt es model-agnostic
Welche Hardware?	Geräte mit programmierbarer Schnittstelle; Piloten umfassen Labor- und Robotiksysteme
Stärkster öffentlicher Pilotwert	QuEra: 695/700 erfolgreiche Laser-Relocks, 99,3 %
Unabhängiger Benchmark?	Nein, Ergebnis eines Partner-Piloten
Größtes Risiko	Agentenfehler können physische Folgen haben
Wichtigstes Sicherheitsprinzip	Limits und Interlocks müssen außerhalb des Modells erzwungen werden

Was ist der Model Hardware Standard genau?

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

Das zugrunde liegende Problem ist bekannt. Ein Labor oder eine Produktionslinie kann Geräte verschiedener Hersteller enthalten. Jedes bringt oft ein anderes SDK, API, Datenformat, Desktop-Programm, eigene Dokumentation und ein eigenes Fehlermodell mit.

Mehrere Maschinen zu einem Workflow zu verbinden erfordert daher häufig individuellen Glue Code.

Anthropic sagt, solche Integrationen könnten Wochen oder Monate dauern, und MHS könne einen Teil dieser Arbeit auf Stunden oder Minuten reduzieren.^[1] Diese allgemeine Aussage ist eine Herstellerangabe und kein unabhängiger Branchenbenchmark.

MHS ist weder Roboter noch Modell

MHS ist nicht:

• ein neues Claude-Modell,
• ein Robot Operating System,
• ein neuer Robotertyp,
• ein Firmware-Ersatz,
• ein eigenständiger Motion-Planning-Algorithmus,
• ein Industrienetzwerkprotokoll, das alle bestehenden Steuerstandards ersetzt.

Am treffendsten ist die Beschreibung als Interoperabilitätsschicht zwischen Agent und programmierbarer physischer Hardware.

Der Agent benötigt weiterhin Modell, Harness oder Anwendung, Berechtigungen, Gerätetreiber, reale Geräteschnittstelle und unabhängige physische Schutzmechanismen.

Wie funktioniert MHS?

3.1. Standardisierter Treiber

MHS führt einen standardisierten Driver ein, der Operationen zwischen Computer und Gerät übersetzt.^[1]

Anthropic nennt einfache Primitive wie:

read
write

zum Beispiel:

read temperature
write temperature

Das bedeutet nicht, dass jedes Gerät nur zwei Befehle hat. Komplexere Funktionen können auf einem kleinen konsistenten Satz von Grundoperationen aufbauen.

3.2. Standardisierte Gerätebeschreibung

MHS soll Geräte in einem einheitlichen Format discoverable machen, damit Agenten und andere Geräte sie im Netzwerk finden und ihre Fähigkeiten verstehen können.^[1]

Die Beschreibung kann enthalten:

• was ein Gerät misst,
• was verändert werden kann,
• physische Eigenschaften,
• relevante Einschränkungen,
• erzwungene Sicherheitsgrenzen.

Anthropic nennt das Gewicht eines Roboterarms als Beispiel für eine physische Eigenschaft, die für sichere Manipulation wichtig sein kann.^[1]

3.3. Natural-Language-Tags

MHS sieht Tags vor, mit denen Nutzer wichtige Hardwaremerkmale in natürlicher Sprache beschreiben. Das kann direkt oder über ein Interview mit einem Agenten erfolgen.^[1]

Der Driver erzeugt daraus eine Referenzdatei mit Gerätecharakteristika, Messwerten, veränderbaren Parametern und Sicherheitsgrenzen.

Die öffentliche Ankündigung ist jedoch keine vollständige Schema-Dokumentation. Da die Spezifikation noch in einer begrenzten Preview ist, sollte niemand erfundene Feldnamen oder Beispielkonfigurationen als offizielles MHS-Format ausgeben.

Drei Wege zur Steuerung von MHS-Hardware

Anthropic nennt drei Mechanismen:^[1]

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

MCP

Ein Agent kann Hardware über das Model Context Protocol verwenden. MCP-Server können Tools bereitstellen, also ausführbare Funktionen, die ein Modell entdecken und aufrufen kann.^[4][5]

CLI

Geräte können direkt über eine Kommandozeile bedient werden. Das ist für Operatoren, Skripte, Debugging und Integrationstests nützlich.

Code-Dateien und APIs

Ein Agent kann Befehle eines oder mehrerer Geräte in normalen Code verpacken. Anthropic hebt das für schnelle, wiederholbare oder lang laufende Abläufe hervor, bei denen ein LLM nicht über jeden Mikro-Schritt nachdenken sollte.^[1]

Der Agent kann eine Prozedur lernen und anschließend die Schleife verlassen

Ein generatives Modell muss Hardware nicht jede Millisekunde steuern.

In einem Beispiel:

1. veränderte Claude eine Lasereinstellung,
2. beobachtete das Resultat über eine Kamera,
3. wiederholte die Versuche,
4. lernte Zusammenhänge,
5. schrieb die gelernte Prozedur als deterministischen Code.^[1]

Danach konnte das Skript ohne kontinuierliches Modell-Reasoning laufen.

Ein wichtiger Produktionsmodus ist damit:

AI exploriert
      ↓
AI erzeugt Prozedur
      ↓
Mensch / Tests verifizieren
      ↓
deterministischer Code führt aus

QuEra nutzte dieses Muster beim Laser-Relock-Controller. Der Agent half beim Entwickeln und Validieren, die finale Produktionslogik ist jedoch inspizierbare deterministische Software ohne Online-Modell im Runtime.^[7]

MHS vs MCP: der wichtigste Unterschied

Element	MCP	MHS
Hauptziel	AI-Anwendungen mit Tools, Daten und Systemen verbinden	Physische Hardware einheitlich beschreiben und steuern
Typisches Ziel	Software, APIs, Daten, Tools	Programmierbare physische Geräte
Kommunikationsmodell	Host, Client, Server, JSON-RPC	Driver + Hardwarebeschreibung + Steuermechanismen
Tools	Ja	Können über MCP exponiert werden
CLI	Nicht Kernmodell des Protokolls	Ein dokumentierter MHS-Steuerweg
API/code files	Können hinter MCP existieren	Ein dokumentierter MHS-Steuerweg
Physische Limits	Nicht Hauptfokus von MCP	Teil der MHS-Gerätesemantik
Open Source heute	Ja	Noch nicht
Status	Offenes Protokoll	Begrenzter Research Preview

Anthropic veröffentlichte MCP 2024 als offenen Standard für bidirektionale Verbindungen zwischen AI-Systemen und Datenquellen oder Tools.^[4] Die MCP-Dokumentation beschreibt Host-Client-Server, Capability Negotiation sowie Tools, Resources und Prompts.^[5][6]

MHS ersetzt diese Schicht nicht.

Ein konzeptioneller Stack:

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

Dies ist ein konzeptionelles POLPROG-Diagramm, kein offizielles Anthropic-Schema.

Ist MHS „MCP für die physische Welt“?

Als Kurzform ist das verständlich, technisch aber zu grob.

Beide Projekte reduzieren individuelle Integrationen und schaffen einen gemeinsamen Zugang für Agenten.

Der Kernunterschied lautet: MCP ist ein Kommunikationsprotokoll für AI-Systeme und Tools. MHS ergänzt Semantik für physische Geräte, ihren Zustand, ihre Fähigkeiten und Grenzen.

MHS kann MCP selbst verwenden.

Daher ist die bessere Formulierung:

MHS ergänzt MCP um eine Schicht für physische Hardware.

MHS ist model-agnostic

Anthropic erklärt ausdrücklich, MHS sei model-agnostic und jeder Agent-Harness könne über Standardprotokolle wie MCP darauf zugreifen.^[1]

Das Konzept ist also formal nicht auf Claude oder Claude Code beschränkt.

Die öffentlichen Launch-Piloten drehen sich dennoch überwiegend um Claude. Ein unabhängiger Benchmark verschiedener Modelle auf identischer Hardware, mit identischem Driver und gleichen Aufgaben existiert noch nicht.

Sicherheit muss unterhalb der Modellschicht funktionieren

Bei Software kann ein falscher Tool Call eine Datei löschen. In der physischen Welt kann eine falsche Entscheidung einen Roboter kollidieren lassen, Proben verschütten oder Geräte beschädigen.

Ein Prompt in natürlicher Sprache darf daher nicht die einzige Schutzschicht sein.

MHS kann erzwungene Safety Limits beschreiben.^[1] QuEra berichtet zusätzlich, dass Grenzen, Interlocks und Emergency Stops am Hardwareinterface unabhängig vom Modell durchgesetzt wurden.^[7]

Die Zielarchitektur sollte so aussehen:

MODEL
schlägt Aktion vor

POLICY / APPROVAL
akzeptiert oder verwirft

DRIVER / CONTROLLER
erzwingt Grenzen

HARDWARE INTERLOCK
schützt auch bei Softwarefehlern

Genentech: ein physischer Fehler, den der Agent zunächst falsch verstand

Genentech testete MHS bei einem BCA Protein Assay mit Liquid Handler, Roboterarm und Microplate Reader.^[1]

Blasen beim Mischen führten zu Runtime-Fehlern. Claude behandelte das Problem zunächst wie einen Softwarefehler und probierte im selben Well neue Parameter. Dadurch entstanden noch mehr Blasen.^[1]

Erst menschliche Experten erklärten die physische Ursache und wiesen auf ein sauberes Well und sanfteres Mischen hin. Das Team kodierte diese Erkenntnis anschließend in wiederverwendbare Liquid-Handling-Skills.^[1]

Die Lektion:

Ein Modell kann eine Fehlermeldung verstehen und gleichzeitig die Physik dahinter missverstehen.

University of Washington: sechs Geräte in weniger als einer Woche

In den Baker- und Pinglay-Labs wurde MHS für Remote Monitoring, agentenüberwachtes qPCR und die Koordination von Roboterarm und Liquid Handler eingesetzt.^[1]

Bei einer Plate-Handoff-Demo beendete der Liquid Handler das Dosieren, der Agent erhielt das Signal und löste etwa zehn Sekunden später die Bewegung des Arms aus. Laut Projektbeschreibung kam es in wiederholten Tests zu keiner Kollision.

Das Verbinden von sechs Instrumenten inklusive Treiberentwicklung soll weniger als eine Woche gedauert haben.^[1]

Dies ist ein Laborergebnis, keine garantierte Implementierungsdauer.

Carnegie Mellon: sechs absichtlich erzeugte Sicherheitszustände

Ein Team der Carnegie Mellon University verwendete MHS für Serial-Dilution-Dose-Response-Experimente.^[1]

Das Setup bestand aus Liquid Handler, Plate Reader, Roboterarm, Kameras und drei Computern mit inkompatiblen Steuerungswegen.

Die Forscher erzeugten sechs Zustände:

1. fehlende Platte,
2. gedrehte Platte,
3. Reader beschäftigt,
4. Kamera getrennt,
5. Gerät nicht erreichbar,
6. Emergency Stop aktiv.^[1]

Das System blockierte laut Bericht alle sechs bevor sich ein Gerät bewegte.

Das ist ein wertvoller Proof of Concept, aber keine formale Sicherheitszertifizierung von MHS.

Autonome Korrektur des Experiments

Der Agent verwarf zuerst eine Kurve mit:

R² < 0,9

und reduzierte die maximale Konzentration:

200 µg/mL
→
100 µg/mL

Der zweite Run erreichte:

R² > 0,98

ohne menschlichen Eingriff.^[1]

Das Team nennt rund acht Stunden vom nicht automatisierten, aber betriebsbereiten Setup bis zur fertigen Kurve inklusive autonomem Wiederholungslauf und stellt dem mehrwöchige Vendor-Integration gegenüber.^[1]

HHMI Janelia: eine gemeinsame Zustandsschicht für sieben Programme

In einem Janelia-Projekt musste eine Forscherin zuvor sieben Programme in einer festen Reihenfolge starten.

MHS ersetzte Punkt-zu-Punkt-Verbindungen durch ein gemeinsames State Dictionary im Shared Memory.^[1]

Laut Fallstudie:

• dauerte das Hinzufügen einer neuen Kamera Minuten statt Tage,
• wurde der Start von sieben Schritten auf eine Aktion reduziert,
• konnten Datenströme mit wiederverwendbaren Tools unabhängig vom Herstellerprogramm analysiert werden.^[1]

MHS stellte außerdem geräteseitige Grenzen wie maximale Laserleistung bereit, sodass der Agent den für die Probe sicheren Bereich nicht überschreiten konnte.^[1]

QuEra: 695 erfolgreiche Relocks von 700

Der quantitativ stärkste öffentliche Pilot stammt von QuEra Computing.

QuEra nutzte MHS, um Claude Zugriff auf Teile eines Lasersystems eines Quantencomputers zu geben.^[1][7][8]

Nach der Experimentierphase entstand ein deterministischer Controller.

QuEra testete:

700 Versuche
7 Störungsklassen
100 Versuche pro Klasse

Der Controller erreichte:

695 / 700
=
99,3 %

^[7]

Einfache Fehler dauerten ungefähr:

0,9–5,4 s

schwierige:

10–14 s

QuEra vergleicht dies mit:

5–10 Minuten

für einen menschlichen Experten.^[7]

Das ist kein 99,3-%-Claude-Benchmark

Im finalen Blind Test steuerte der Agent den Laser nicht online.

Korrekt ist:

Ein Agent mit MHS half, einen Controller zu entwickeln, der später 99,3 % erreichte.

Nicht:

Claude steuert Hardware mit 99,3 % Genauigkeit.

Widerspruch zwischen Quellen

Anthropic beschreibt die Entwicklung des älteren handgeschriebenen QuEra-Skripts als Arbeit über „several months“.^[1]

QuEra selbst spricht von ungefähr zwei bis drei Wochen.^[7]

Da die Quellen hier voneinander abweichen, verwenden wir die Entwicklungszeit des Vorgängers nicht als harte Vergleichsmetrik.

Grenzen des QuEra-Piloten

Die Berichte nennen auch Schwächen.

Claude:

• konnte einige rein physische Hardwarefehler nicht diagnostizieren,
• verstand den Rig vor allem programmatisch,
• benötigte viel Kontext,
• stoppte häufig und fragte nach menschlicher Bestätigung bei Aktionen, die leicht riskant wirkten.^[1]

Bei physischer Hardware kann diese Vorsicht sinnvoller sein als Überkonfidenz.

Tetsuwan: ein Gerät erkennt den Fehler, ein anderes behebt ihn

Tetsuwan verband MHS mit ResearchOS für einen qPCR-Workflow zur Untersuchung der Verschmutzung im San Pedro Creek.^[1]

Eine Kamera erkannte Blasen in einer Probe. Der Roboter, der sie hielt, konnte das Problem nicht lösen.

Das System:

1. erkannte das Problem,
2. suchte MHS-Geräte,
3. fand eine Zentrifuge,
4. ließ Claude deren Einsatz vorschlagen,
5. führte nach Freigabe die Zentrifugenbefehle aus.^[1]

Das zeigt das Potenzial geräteübergreifender Orchestrierung statt vollständig fest kodierter Recovery-Pfade.

Partner-Ökosystem

Anthropic nennt unter anderem:^[1]

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

AWS plant Support über Strands Robots. Hugging Face arbeitet an LeRobot-Support und Raspberry Pi an Integrationen ausgewählter Produkte.^[1]

Das bedeutet nicht, dass jede Integration heute öffentlich produktionsbereit ist.

MHS ist noch nicht Open Source

Die offizielle Projektseite bezeichnet MHS als limited research preview.^[2]

Anthropic möchte zunächst Partnererfahrung sammeln, Safety Evaluations entwickeln, Best Practices aufbauen und Schutzmaßnahmen verstärken.^[1]

Zum 30. August 2026 gibt es in den geprüften offiziellen Quellen:

• kein öffentliches Open-Source-Release-Datum,
• keine finale Lizenz,
• keine vollständige öffentliche Spezifikation mit der Reife der MCP-Dokumentation.

Richtig ist:

Anthropic plant, MHS Open Source zu machen.

Nicht:

MHS ist bereits Open Source.

Sind die aktuellen Ergebnisse unabhängige Benchmarks?

Nein.

Die Zahlen stammen primär von Anthropic und Preview-Partnern.

Reuters bestätigt unabhängig den Start des Research Preview, den allgemeinen Anwendungsbereich und den Plan eines späteren Open-Source-Releases.^[3]

Es gibt jedoch keinen öffentlichen Benchmark mit identischer Hardware, gleichen Treibern, mehreren Modellen, einem gemeinsamen Agent-Harness und unabhängiger Bewertung.

Werte wie:

99,3 %
3× schneller
8 Stunden
unter einer Woche

müssen daher der jeweiligen Fallstudie zugeordnet bleiben.

Threat Model: Was kann schiefgehen?

Falsches Reasoning

Ein Modell kann Sensorwert, Error Code, Bild oder physische Ursache falsch interpretieren. Genentech liefert einen realen Fall.^[1]

Fehlerhafter oder bösartiger Driver

Falsche Einheiten, Zustände oder fehlende Validierung können dem Agenten eine falsche Realität zeigen.

Prompt Injection

Kameratexte, Dokumentation, Netzwerkdaten oder externe Systeme können manipulative Inhalte enthalten.

Confused Deputy

Ein Agent mit mehreren Geräten kann das richtige Tool für den falschen Zweck verwenden.

Race Conditions

Zwei Agenten oder Geräte können inkompatible Änderungen gleichzeitig durchführen.

Verbindungsverlust

Es muss einen sicheren Zustand geben, wenn Modell, MCP, Netzwerk, Driver oder Sensor ausfallen.

Eine sicherere Produktionsarchitektur

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

Das ist eine POLPROG-Empfehlung, kein offizielles Anthropic-Diagramm.

Ein LLM sollte nie die einzige Komponente sein, die entscheidet, ob eine physische Operation sicher ist.

Was sollte die deterministische Schicht erzwingen?

Zum Beispiel:

• Temperaturbereiche,
• Maximalleistung,
• Geschwindigkeit eines Arms,
• Arbeitsraumgrenzen,
• Bewegungsreihenfolge,
• Kollisionszonen,
• Drucklimits,
• Schutzhaubenstatus,
• Emergency Stop,
• maximale Betriebsdauer.

Eine außerhalb des erlaubten Bereichs liegende Anforderung muss unabhängig vom Reasoning des Modells abgelehnt werden.

Human-in-the-loop bleibt relevant

Die MCP-Tool-Spezifikation empfiehlt, dass Nutzer Tool-Aufrufe ablehnen können.^[5]

Für physische Hardware bieten sich Risikostufen an:

READ
automatisch

LOW-RISK WRITE
automatisch in engem Bereich

MEDIUM-RISK
Policy + zusätzliche Validierung

HIGH-RISK
Human Approval

EMERGENCY / UNSAFE
immer blockiert

Warum deterministischer Fallback wichtig ist

QuEra zeigt ein nützliches Muster:

AI entdeckt Lösung
→ Code wird erzeugt
→ Tests und Menschen verifizieren
→ Produktion führt deterministischen Code aus

Das reduziert Inferenzkosten, Latenz, Nichtdeterminismus, API-Abhängigkeit und das Risiko unerwarteter Modellentscheidungen.

MHS und industrielle Steuerungssysteme

MHS sollte nicht als Ersatz für PLC, SCADA, OPC UA, Safety PLC oder Echtzeitcontroller verstanden werden.

Realistischer ist eine höhere Schicht:

Agent
↓
Orchestration
↓
MHS
↓
bestehende Controller
↓
Hardware

Anthropic zeigt selbst, dass schnelle oder lange Operationen in Code verpackt werden können, damit die Hardware ohne LLM-Reasoning bei jedem Schritt arbeitet.^[1]

Wer sollte MHS jetzt beobachten?

Besonders:

• Labore mit Multi-Vendor-Hardware,
• Biotech und Pharma,
• Mikroskopie,
• Robotik,
• Quantum Computing,
• Advanced Manufacturing,
• R&D-Teams mit viel bespoke Integration Code.

Wer sollte vorsichtig sein?

Wenn:

• das System safety-critical ist,
• eine stabile öffentliche Spezifikation Pflicht ist,
• eine bekannte Open-Source-Lizenz erforderlich ist,
• zertifizierte Industriestandards nötig sind,
• Geräte keine automatisierbare Schnittstelle haben,
• unabhängige Interlocks fehlen,
• das Team Treiber nicht sicher auditieren kann.

Ein Research Preview ist kein ausgereifter Produktionsstandard.

Wie kann sich ein Unternehmen vorbereiten?

Schritt 1: Hardware inventarisieren

Vendor
Modell
SDK/API/GUI
Einheiten
Zustände
Befehle
Limits
E-stop
Abhängigkeiten

Schritt 2: Read und Write trennen

Definieren, was gelesen, verändert, automatisch ausgeführt oder freigegeben werden muss.

Schritt 3: Sicherheit aus dem Prompt entfernen

Nicht auf:

"Stelle die Temperatur nie über 80°C"

vertrauen. Ein echtes Limit muss durch Code oder Hardware erzwungen werden.

Schritt 4: alles protokollieren

Agent/Modell, Operation, Parameter, Zustand vorher/nachher, Ergebnis, Timestamp, Policy und Approval.

Schritt 5: simulieren

Zuerst:

digital twin / mock driver

danach:

real hardware

Minimaler Testplan

Driver

• Einheiten,
• Bereiche,
• Timeouts,
• Reconnect,
• ungültige Antworten,
• Restart.

Agent

• falscher Sensorwert,
• widersprüchliche Daten,
• unbekannter Error Code,
• Prompt Injection,
• fehlender Kontext.

Hardware

• Collision Prevention,
• E-stop,
• Stromausfall,
• Netzwerkausfall,
• mechanische Blockade,
• Out-of-range Request.

Multi-Agent

• gleichzeitige Writes,
• stale state,
• Resource Locking,
• Retry nach Timeout.

MHS-Sicherheitscheckliste

Architektur

• Modell steuert Actuators nicht ohne Validierung.
• Jeder Driver hat explizite Limits.
• Werte haben Einheiten und Bereiche.
• Kritische Grenzen sind deterministisch.
• E-stop funktioniert unabhängig von AI.
• Safe State nach Verbindungsverlust.
• Device State ist timestamped.
• Retry-Verhalten ist sicher.

Berechtigungen

• Agent sieht nur notwendige Geräte.
• READ und WRITE sind getrennt.
• High-Risk-Aktionen benötigen Approval.
• Rechte laufen ab.
• Kein gemeinsamer Admin-Token für alles.

Monitoring

• Jeder Tool Call wird geloggt.
• Physische Änderungen erzeugen Telemetrie.
• Alarme hängen nicht nur vom Modell ab.
• Operator sieht den aktuellen Zustand.
• Event Replay existiert.
• Fehler werden klassifiziert.

Tests

• Mock Hardware.
• Physical Sandbox.
• Fault Injection.
• Prompt Injection.
• Race Conditions.
• Network Partition.
• Agent Restart.
• Driver Restart.
• Falsche Einheiten.
• Out-of-range Values.

Produktion

• Rollout beginnt read-only.
• Danach Low-Risk Writes.
• Safety-Critical Actions bleiben außerhalb des Agenten.
• Deterministischer Code ersetzt AI, wo sinnvoll.
• Driver erhalten Code Review.
• Rollback existiert.
• Manuelle Übernahme ist möglich.
• Team kennt physische Konsequenzen jeder Kommandoklasse.

Was muss passieren, damit MHS ein echter Standard wird?

Nötig sind unter anderem:

1. öffentliche Spezifikation,
2. stabiles Versioning,
3. Kompatibilitätsmodell,
4. öffentliche SDKs,
5. Open-Source-Lizenz,
6. Reference Drivers,
7. Conformance Tests,
8. Security Evaluations,
9. unabhängige Implementierungen,
10. Vendor-Support,
11. Driver-Validierung,
12. klares Permission Model.

MCP wurde durch ein interoperables Ökosystem relevant. MHS muss einen ähnlichen Weg gehen.

Wird MHS die Robotik verändern?

Möglicherweise, aber für eine sichere Aussage ist es zu früh.

Der größte kurzfristige Fit liegt in Umgebungen, in denen Hardware bereits programmierbar, Integration teuer und Workflows variabel sind:

Labore
R&D
Biotech
Mikroskopie
Quantum
Advanced Manufacturing

MHS löst nicht automatisch Robot Perception, Motion Planning, Real-Time Control, Safety Certification oder Manipulationsphysik.

Es kann aber die Schnittstelle vereinfachen, über die ein Agent bestehende Steuerungssysteme nutzt.

POLPROG-Fazit

Model Hardware Standard ist eine der interessanteren Agentenentwicklungen 2026, weil es Interoperabilität aus der digitalen in die physische Welt verschiebt.

Was ist bestätigt?

• Research Preview seit 27. August 2026.^[1][3]
• Ursprung in der Zusammenarbeit Anthropic und HHMI Janelia.^[1]
• model-agnostic.^[1]
• Steuerung über MCP, CLI und Code/API-Dateien.^[1]
• Driver beschreibt Gerät und Safety Limits.^[1]
• Anthropic plant ein späteres Open-Source-Release.^[1][2]
• QuEra bestätigt 695 erfolgreiche Relocks von 700 für den finalen Controller.^[7]

Was wissen wir noch nicht?

• finales öffentliches Schema,
• Open-Source-Datum,
• Lizenz,
• API-Stabilität,
• Kompatibilität verschiedener Implementierungen,
• unabhängige Benchmarks,
• Leistung verschiedener Modelle auf gleicher Hardware.

Das interessanteste Muster

Nicht:

LLM steuert alles dauerhaft

sondern:

Agent versteht Ziel
→ exploriert sicheren Raum
→ koordiniert Geräte
→ erstellt oder wählt Prozedur
→ System validiert
→ wiederholbare Arbeit wandert in deterministischen Code

Wenn Anthropic die Spezifikation öffnet, Hersteller wiederverwendbare Driver bereitstellen und unabhängige Teams Sicherheit und Interoperabilität bestätigen, könnte MHS eine wichtige Physical-AI-Schicht werden.

So weit ist es noch nicht.