KI Glossar
Model Hardware Standard (MHS)
Kurz erklärt
Der Model Hardware Standard (MHS) ist eine frühe Spezifikation, die KI-Agenten einen einheitlichen und sicherheitsorientierten Zugriff auf programmierbare physische Geräte ermöglichen soll.
Model Hardware Standard (MHS)
Definition
Der Model Hardware Standard (MHS) ist eine Spezifikation für die Verbindung von KI-Agenten mit programmierbaren physischen Geräten. Er soll Agenten ermöglichen, wissenschaftliche Instrumente, Sensoren, Roboter und Fertigungsanlagen über ein einheitliches Beschreibungs- und Steuerungsmodell zu entdecken, zu verstehen und sicher zu bedienen.
MHS wurde als gemeinsames Projekt von Anthropic und dem HHMI Janelia Research Campus begonnen. Am 27. August 2026 startete eine begrenzte Forschungsvorschau für ausgewählte Partner aus Wissenschaft und Industrie. Zum Start war der Standard noch nicht allgemein verfügbar und noch nicht als vollständiges Open-Source-Projekt veröffentlicht.
Welches Problem MHS lösen soll
Physische Geräte besitzen häufig herstellerspezifische Software Development Kits, Protokolle und Benutzeroberflächen. Ein Labor oder eine Produktionsanlage muss daher für jedes Gerät eine eigene Integration entwickeln. Wenn ein KI-Agent mehrere Instrumente koordinieren soll, vervielfacht sich dieser Aufwand.
MHS verfolgt die Idee, ein Gerät einmal über einen standardisierten Treiber zu beschreiben. Unterschiedliche Modelle und Agentensysteme sollen anschließend dieselbe Schnittstelle verwenden können, ohne für jede Kombination aus Modell und Maschine einen neuen Übersetzer zu bauen.
Standardisierte Treiber
Der MHS-Treiber bildet die herstellerspezifische Geräteschnittstelle auf einfache Operationen ab. Dazu gehören beispielsweise Leseoperationen für Messwerte oder Schreiboperationen für veränderbare Einstellungen. Ein Temperatursensor kann einen aktuellen Wert liefern, während ein steuerbares Gerät einen zulässigen Sollwert empfangen kann.
Die Vereinheitlichung bedeutet nicht, dass alle Geräte identisch funktionieren. Der Treiber übersetzt die individuellen Fähigkeiten eines Geräts in eine gemeinsame Struktur. Das bestehende Betriebssystem, die Firmware und die native Steuerungssoftware bleiben weiterhin relevant.
Gerätebeschreibung und Kontext
Ein Agent benötigt mehr als eine Liste technischer Befehle. Er muss wissen, welche Einheiten verwendet werden, welche Werte sicher sind, welche Zustände miteinander zusammenhängen und welche physischen Eigenschaften bei einer Aktion berücksichtigt werden müssen.
MHS soll deshalb maschinenlesbare Fähigkeiten mit natürlicher Sprache und Referenzinformationen verbinden. Ein Gerät kann beschreiben, was es messen oder verändern kann, welche Grenzen gelten und welcher Kontext für eine sichere Bedienung erforderlich ist. Bei einem Roboterarm kann beispielsweise Gewicht oder Reichweite entscheidend sein; bei einem Laborgerät können Temperaturgrenzen und empfindliche Proben relevant sein.
Verhältnis zum Model Context Protocol
MHS und das Model Context Protocol lösen unterschiedliche Ebenen desselben Integrationsproblems. MCP standardisiert, wie Agenten auf Softwarewerkzeuge und Datenquellen zugreifen können. MHS konzentriert sich auf die Beschreibung und Steuerung physischer Geräte.
MHS-Geräte können über MCP für einen Agenten zugänglich gemacht werden. MCP ersetzt dabei nicht den gerätespezifischen Treiber und MHS ersetzt nicht das allgemeine Werkzeugprotokoll. Vereinfacht formuliert beschreibt MHS die Hardwarefähigkeiten und Grenzen, während MCP eine mögliche Verbindungsschicht zum Agenten bereitstellt.
Steuerungsmöglichkeiten
Neben einem protokollbasierten Zugriff können Geräte über Kommandozeilenwerkzeuge oder Code-Dateien gesteuert werden. Direkte Agentenentscheidungen eignen sich für interaktive Planung und Fehlerdiagnose. Wiederholbare oder zeitkritische Abläufe sollten dagegen häufig in deterministische Programme übersetzt werden.
Ein Agent kann beispielsweise einen Versuchsablauf planen, passende Geräte auswählen und ein Skript erzeugen. Das Skript führt anschließend die zeitkritischen Schritte aus, während Messwerte und Sicherheitsgrenzen überwacht werden. Dadurch bleibt probabilistische Modellsteuerung von schneller, reproduzierbarer Maschinensteuerung getrennt.
Sicherheit
Bei physischer Hardware können Fehler reale Schäden verursachen. Falsche Parameter können Geräte beschädigen, Proben zerstören oder Menschen gefährden. Sicherheit muss deshalb auf mehreren Ebenen umgesetzt werden und darf nicht nur von der Entscheidung eines Sprachmodells abhängen.
Wichtige Maßnahmen sind hardwareseitige Grenzwerte, Not-Aus-Funktionen, Berechtigungen, isolierte Testumgebungen, Simulationen, Audit-Logs und menschliche Freigaben. Der Treiber sollte nur sichere und klar definierte Operationen verfügbar machen. Kritische Grenzen müssen deterministisch erzwungen werden, auch wenn ein Agent eine unzulässige Aktion anfordert.
Wie bei Computer Use kann ein Agent unerwartete Zustände falsch interpretieren oder schädlichen Anweisungen folgen. Bei Hardware kommen zusätzlich Sensorfehler, mechanische Blockaden und unvollständige Informationen über die Umgebung hinzu. Verifikation und kontrolliertes Loop-Engineering sind daher zentrale Bestandteile eines sicheren Systems.
Einsatzgebiete
Mögliche Einsatzfelder sind automatisierte Labore, Mikroskopie, Flüssigkeitshandhabung, Robotik, Elektroniktests und fortgeschrittene Fertigung. Ein gemeinsamer Standard könnte Experimente und Automatisierungsabläufe leichter zwischen Geräten und Standorten übertragbar machen.
Der praktische Nutzen hängt jedoch von verfügbaren Treibern, stabilen Spezifikationen und belastbaren Sicherheitsprüfungen ab. In der Forschungsvorschau dient MHS vor allem dazu, Anwendungsfälle zu erproben, Sicherheitsevaluationen zu entwickeln und Best Practices für agentengesteuerte physische Systeme zu sammeln.
Abgrenzung
MHS ist kein KI-Modell, kein Roboterbetriebssystem und kein Ersatz für industrielle Sicherheitsstandards. Es ist eine Integrationsschicht, die Gerätefähigkeiten und Bedienmöglichkeiten in einer agentenfreundlichen Form verfügbar machen soll.
Da sich MHS in einer frühen Vorschau befindet, können technische Details, Verfügbarkeit und Umfang noch verändert werden. Aussagen zur Implementierung sollten deshalb immer anhand der jeweils aktuellen offiziellen Spezifikation geprüft werden.