Model Hardware Standard für die Laborautomatisierung: MHS, MCP und SiLA 2

Model Hardware Standard für die Laborautomatisierung: MHS, MCP und SiLA 2

Der Model Hardware Standard (MHS) ist Anthropics Ansatz im Stadium einer Research Preview, mit dem KI-Agenten programmierbare physische Geräte über standardisierte Treiber erkennen, bedienen und überwachen können. Für die Laborautomatisierung lässt sich MHS am besten als Hardware-Abstraktion verstehen, die über MCP arbeiten kann – nicht als Ersatz für MCP, SiLA 2, OPC UA LADS oder die deterministischen Sicherheitskontrollen zwischen einem KI-Plan und einem physischen Gerät.

Diese Unterscheidung ist wichtig, weil eine gemeinsame Schnittstelle Hardware zwar leichter erreichbar macht, aber nicht jede Aktion sicher ausführbar. Das öffentlich verfügbare Material zu MHS ist ein wichtiges Signal für Gerätehersteller, doch die Spezifikation ist noch nicht offen, und die veröffentlichten Demonstrationen sind frühe Belege, keine Zusicherung für den Produktivbetrieb oder in regulatorischer Hinsicht.

Die wichtigsten Erkenntnisse

• MHS zielt auf die Integrationsebene zwischen Agent und Hardware. Die öffentliche Beschreibung kombiniert standardisierte Treiber, Geräteerkennung, Zustand, Prozeduren, Sicherheitskontext und mehrere Zugriffsmechanismen.
• MCP und MHS lösen unterschiedliche Probleme. MCP bietet einer KI-Anwendung einen standardisierten Weg, Tools aufzurufen; MHS beschreibt, wie programmierbare physische Geräte hinter diesen Tools angebunden sein können.
• SiLA 2 und OPC UA LADS werden nicht obsolet. Sie bieten bereits laborspezifische Geräteverträge und Informationsmodelle, die ein MHS-Treiber möglicherweise nutzen oder bereitstellen kann.
• Sicherheit darf nicht allein in einer natürlichsprachlichen Beschreibung liegen. Vorbedingungen, Grenzwerte, Verriegelungen, Operationsidentität, Autorisierung und Wiederherstellungsverhalten müssen deterministisch bleiben.
• Gerätehersteller können sich jetzt vorbereiten, ohne auf eine unveröffentlichte Spezifikation zu setzen. Eine typisierte, beobachtbare und testbare Geräteschnittstelle ist nützlich, unabhängig davon, ob die spätere Integration MHS, MCP, SiLA 2, OPC UA LADS oder mehrere davon verwendet.

Was Anthropic tatsächlich angekündigt hat

Anthropic hat die MHS Research Preview am 27. August 2026 eröffnet. Das Projekt begann mit dem HHMI Janelia Research Campus und wird vor einer geplanten Open-Source-Veröffentlichung mit wissenschaftlichen Laboren und Hardwareherstellern getestet.

Die öffentliche Beschreibung weist MHS fünf wichtige Aufgaben zu:

1. Ein standardisierter Treiber übersetzt zwischen einem Gerät und der umgebenden Software.
2. Geräte werden in einem gemeinsamen Format erkennbar.
3. Der Treiber stellt Zustand und Operationen über einfache Primitive und ein Gerätemanifest bereit.
4. Gerätewissen kann Eigenschaften, Betriebskontext und Grenzwerte umfassen, die aus dem Code allein nicht ersichtlich sind.
5. Agenten können über MCP, eine Kommandozeilenschnittstelle oder Code auf die Hardware zugreifen.

Die Ankündigung beschreibt Proof-of-Concept-Workflows mit Liquid-Handling-Systemen, Roboterarmen, Plattenlesern, qPCR-Geräten, Mikroskopen, Kameras und weiteren programmierbaren Geräten. Sie berichtet zudem von Fällen, in denen Agenten Experimente überwachten, Parameter anpassten, Geräte koordinierten und sich von ausgewählten Fehlern erholten.

Diese Ergebnisse verdienen eine genaue Betrachtung, müssen aber korrekt eingeordnet werden: Es handelt sich um Berichte von Anthropic und seinen Preview-Partnern. Sie sind noch kein Beleg für breite Interoperabilität, Konformität über unabhängige Implementierungen hinweg, validierten Betrieb in regulierten Umgebungen oder sichere Autonomie für beliebige Hardware.

Anthropic benennt diese Einschränkung ausdrücklich. Laut Ankündigung weisen aktuelle Modelle nach wie vor Schwächen beim räumlichen und physikalischen Denken auf, erfordern fachkundige Aufsicht und können physische Probleme fälschlich als Softwareprobleme diagnostizieren. Die Preview soll unter anderem dazu dienen, die fehlenden Sicherheitsevaluationen und Einsatzleitlinien zu entwickeln.

Wo MHS in einen Stack für die Laborautomatisierung passt

MHS lässt sich am einfachsten verstehen, wenn man die Ebenen trennt, die häufig unter dem Begriff «Integration» zusammengefasst werden.

Das Diagramm zeigt eine plausible Zusammensetzung auf Grundlage der öffentlichen MHS-Beschreibung. MCP ist das agentenseitige Interaktionsprotokoll. MHS ist die hardwareseitige Abstraktion und das Treibermodell. Ein Laborgerätevertrag wie SiLA 2, OPC UA LADS, ein Hersteller-SDK oder eine REST-API kann die zugrunde liegenden Fähigkeiten bereitstellen. Deterministische Verifikation, Autorisierung und Zustandsabgleich verbleiben im Ausführungspfad vor jeder physischen Aktuierung.

Diese Zusammensetzung ist eine ingenieurtechnische Interpretation, keine Aussage zur MHS-Konformität. Solange keine öffentliche Spezifikation die Verträge und Erweiterungspunkte definiert, kann niemand ausserhalb der Preview genau angeben, wie eine MHS-Implementierung auf einen bestehenden Laborstandard abgebildet werden muss.

Die MCP-Tool-Spezifikation definiert, wie Server aufrufbare Tools und deren Schemas bereitstellen. Sie beansprucht nicht, dass ein Schema bestimmen kann, ob ein Liquid-Handling-System über genügend Reagenz verfügt, ob eine Platte versiegelt ist oder ob ein Befehl mit Zeitüberschreitung eine Achse bereits bewegt hat. Das sind Fragen des physischen Zustands.

SiLA 2 adressiert einen tieferliegenden, laborspezifischen Vertrag. Features stellen typisierte Commands und Properties bereit, während der Kernstandard Erkennung, Fehler, Datentypen, Sicherheit und beobachtbare Ausführung abdeckt. OPC UA LADS geht weiter in Richtung eines Laborinformationsmodells, trennt Hardware- und Funktionssicht und definiert Programme, Funktionseinheiten, Zustand und Ergebnisverwaltung.

MHS könnte zu einer nützlichen gemeinsamen Ebene über diesen Schnittstellen werden. Es könnte auch beeinflussen, wie künftige Geräte diese bereitstellen. Der entscheidende architektonische Punkt ist, dass diese Technologien unterschiedliche Ebenen besetzen; «MHS vs. MCP» oder «MHS vs. SiLA 2» ist daher meist die falsche Beschaffungsfrage. Die bessere Frage lautet: Welcher Vertrag ist jeweils für Bedeutung, Zustand, Sicherheit und Ausführungsnachweise zuständig?

Der standardisierte Treiber ist notwendig, aber nicht die Sicherheitsgrenze

Ein KI-Agent kann einen syntaktisch gültigen Befehl erzeugen, der physisch falsch ist. transfer_liquid(source="A1", destination="B1", volume_ul=100) kann seinem Schema entsprechen, während die Quelle 40 uL enthält, das Ziel bereits voll ist oder die aufgesetzte Spitze mit einem inkompatiblen Reagenz in Kontakt gekommen ist.

Der Treiber sollte einen solchen Befehl vor der Aktuierung zurückweisen, doch dazu braucht es mehr als einen Operationsnamen und einen Parametertyp. Erforderlich sind der aktuelle Zustand, parameterübergreifende Regeln, Gerätegrenzwerte und Workflow-Kontext.

Fünf Kontrollen müssen daher unterhalb des Agenten deterministisch bleiben:

1. Vorbedingungen und zustandsabhängige Grenzwerte

Statische Wertebereiche erfassen offensichtliche Fehler, etwa eine negative Temperatur oder eine nicht unterstützte Geschwindigkeit. Reale Workflows benötigen zusätzlich dynamische Prüfungen: verfügbares Volumen, montierte Werkzeuge, belegte Positionen, Kalibrierzustand, Türzustand, Identität von Verbrauchsmaterialien und ob eine andere Operation das Gerät belegt.

Der Agent kann die Aktion vorschlagen. Software mit Zugriff auf den massgeblichen Zustand entscheidet, ob die Vorbedingungen erfüllt sind.

2. Dauerhafte Operationsidentität

Eine Netzwerk-Zeitüberschreitung bedeutet nicht, dass das Gerät nichts getan hat. Der Befehl kann abgelehnt, angenommen, aber nicht gestartet, ohne Bestätigung abgeschlossen oder teilweise ausgeführt worden sein.

Jede folgenreiche Operation benötigt eine dauerhafte Kennung und einen Lebenszyklus. Die Wiederholung derselben Kennung sollte die bestehende Operation abrufen oder als Konflikt abgelehnt werden – und nicht stillschweigend ein zweites Mal aspirieren. Deshalb sind beobachtbare Gerätebefehle wichtiger als eine synchrone Erfolgsmeldung.

3. Ausführbare Verifikation vor der Übergabe zur Ausführung

Die Parametervalidierung prüft einen einzelnen Aufruf. Ein nützliches Protokoll enthält oft Dutzende voneinander abhängiger Operationen über mehrere Geräte hinweg. Der vollständige Workflow-Kandidat sollte vor der Ausführung gegen Ressourcen, Reihenfolgebedingungen und erwartete Zustandsübergänge geprüft werden.

Ein Probelauf mit digitalem Zwilling ist eine Möglichkeit, diese Grenze umzusetzen. Er erfordert kein fotorealistisches Rendering. Er benötigt genügend Zustand, um nachzuweisen, dass die vorgeschlagene Sequenz ausführbar ist, und um eine konkrete Ablehnung zurückzugeben, wenn sie es nicht ist.

4. Autorisierung im Verhältnis zur Tragweite

Das Ablesen einer Temperatur und das Starten eines Roboters sind keine gleichwertigen Operationen. Das System benötigt explizite Berechtigungsgrenzen für Beobachtung, Konfiguration, Wartung, Bewegung und probenrelevante Aktionen. Pläne mit hoher Tragweite können zudem eine menschliche oder richtlinienbasierte Genehmigung erfordern, die an genau den Plan gebunden ist, der ausgeführt wird.

Die MCP-Autorisierung kann den Zugriff auf einen Server regeln. Die Autorisierung auf Geräteebene muss zusätzlich beantworten, was dieser Akteur mit diesem Gerät in seinem aktuellen Zustand für diesen Workflow tun darf.

5. Telemetrie und Abgleich des physischen Zustands

Ein Agent kann den nächsten Schritt nicht allein anhand einer Tool-Antwort sicher wählen. Er benötigt den beobachteten Zustand des Geräts, das Endergebnis und jeden Nachweis dafür, dass die erwarteten physischen Effekte eingetreten sind.

Wenn die Telemetrie vom geplanten Zustand abweicht, sollte das System anhalten und den Zustand abgleichen. Es sollte nicht zulassen, dass das Sprachmodell eine Erklärung erfindet und weitermacht. Das ist der Unterschied zwischen einem Agenten, der Hardware aufrufen kann, und einem Agenten, der einen experimentellen Kreislauf zuverlässig schliessen kann.

Das wichtigste Ergebnis der MHS-Demonstrationen ist ein Fehlschlag

Der aufschlussreichste Teil von Anthropics Ankündigung ist weder die schnellste Integration noch der autonome Durchlauf. Es ist ein Fehlschlag beim Liquid Handling.

In einem berichteten Experiment reagierte der Agent auf durch Blasen verursachte Fehler, indem er es im selben Well mit geänderten Parametern erneut versuchte. Der erneute Versuch verschlimmerte das physische Problem. Ein menschlicher Experte musste erklären, dass der Softwarefehler ein Hinweis auf ein Problem im Fluidverhalten war und dass die Wiederherstellung den Wechsel in ein sauberes Well sowie eine Reduktion der Mischzyklen erforderte.

Dieses Beispiel bringt die zentrale Herausforderung agentischer Laborautomatisierung auf den Punkt. Das Gerät gab einen Fehler zurück, doch die richtige Wiederherstellung hing von physischem und fachlichem Kontext ausserhalb des Fehlercodes ab. Die erste Reaktion des Modells war aus Softwaresicht plausibel und aus Laborsicht falsch.

Die Abhilfe bestand nicht in uneingeschränktem Schlussfolgern. Das Team überführte die gewonnene Wiederherstellungserkenntnis in wiederverwendbares Betriebswissen. Ein produktionsreifes Design sollte einen Schritt weiter gehen und sicherheitsrelevante Teile als maschinell prüfbare Regeln kodieren: wann ein erneuter Versuch untersagt ist, wann frisches Labormaterial erforderlich ist, welche Parameter geändert werden dürfen und wann ein Bediener eingreifen muss.

Ein separater Preprint vom August 2026 zum agentischen Betrieb eines Rasterkraftmikroskops berichtet von einer ähnlichen architektonischen Lehre. Dessen Agent nutzte über MCP angebundene Gerätefunktionen, während eine Mehrdeutigkeitsprüfung die Befehlsausführung absicherte und die Bildnachbearbeitung auf einen vorab genehmigten Tool-Satz beschränkt war. Die Autoren führen null Ausführungen falscher Befehle in ihrem Benchmark auf die abgesicherte Ausführungsschicht zurück, nicht allein auf die Fähigkeiten des Modells. Dieses Ergebnis ist spezifisch für ihre Aufgaben und ihren Aufbau, doch die Grenze ist allgemein nützlich.

Was Gerätehersteller jetzt entwickeln können

Das Warten auf die finale MHS-Spezifikation muss nicht bedeuten, mit der Agentenfähigkeit zu warten. Die folgenden Grundlagen verbessern jeden Integrationspfad:

1. Einen typisierten Fähigkeitsvertrag veröffentlichen. Benennen Sie Operationen, Parameter, Einheiten, Ergebnisse und deklarierte Fehler. Wenn das Gerät bereits OpenAPI, ein Hersteller-SDK, SiLA 2 oder OPC UA bereitstellt, sollte dieser Vertrag massgeblich bleiben.
2. Beobachtbare Operationslebenszyklen bereitstellen. Lang laufende Befehle benötigen stabile Kennungen, Fortschrittsangaben, wo sinnvoll, Endzustände, Ergebnisse und eine Abbruchsemantik.
3. Grenzwerte ausführbar machen. Verankern Sie statische und zustandsabhängige Einschränkungen im Code nahe am Gerät. Natürlichsprachliche Hinweise können eine Regel erläutern; sie sollten nicht die einzige Durchsetzung sein.
4. Absicht von Mechanik trennen. Lassen Sie einen Agenten eine wissenschaftlich sinnvolle Aktion anfordern, während deterministische Software sie in Low-Level-Gerätebefehle umsetzt. Unser Leitfaden für zuverlässige Geräte-Agenten erläutert, warum diese Wahl der Tool-Oberfläche wichtig ist.
5. Wiederherstellung bei unklarem Ergebnis definieren. Dokumentieren Sie, was nach einer Zeitüberschreitung, einem Verbindungsabbruch, einem Neustart, einem Teilergebnis oder einer verspäteten Bestätigung geschieht. Machen Sie blinde Wiederholungen niemals zum Standard für probenrelevante Aktionen.
6. Eine Simulationsschnittstelle bereitstellen. Derselbe High-Level-Vertrag sollte ohne physische Hardware testbar sein, mit ausdrücklich benannten Einschränkungen. Simulation unterstützt Integrationstests, Fehlerinjektion und Verifikation vor der Ausführung.
7. Protokolltreue wahren. Eine Übersetzung muss offenlegen, was sie nicht abbilden kann. Unser Open-Source-Generator von OpenAPI zu SiLA 2 erkennt explizit Konstrukte wie Callbacks, Streaming-Antworten, binäre Bodies und Fehlerschemas, die eine besondere Behandlung erfordern, statt vorzugeben, jede Konvertierung sei verlustfrei.
8. Nachweise für jeden folgenreichen Übergang sammeln. Verknüpfen Sie den angeforderten Plan, die Genehmigung, die Operationskennung, die Telemetrie, das Endergebnis und den abgeglichenen Zustand.

Diese Arbeit ist nicht MHS-spezifisch. Sie erleichtert die Integration eines Geräts mit MHS, sobald die Spezifikation offen ist, und verbessert gleichzeitig die heutigen APIs und Automatisierungssysteme.

Häufig gestellte Fragen

Was ist der Model Hardware Standard?

Der Model Hardware Standard ist eine von Anthropic geleitete Research Preview, mit der KI-Agenten über standardisierte Treiber mit programmierbaren physischen Geräten verbunden werden. Öffentliche Materialien beschreiben Geräteerkennung, gemeinsame Beschreibungen von Zustand und Operationen, kontextbezogenes Hardwarewissen, durchgesetzte Grenzwerte sowie den Zugriff über MCP, Kommandozeilen-Tools oder Code. Die Spezifikation ist noch nicht öffentlich verfügbar.

Ist MHS dasselbe wie MCP?

Nein. MCP ist ein Protokoll, über das KI-Anwendungen Tools erkennen und aufrufen. MHS wird als Hardware-Abstraktion und Treibermodell beschrieben, das MCP als einen Zugriffsmechanismus nutzen kann. Ein über MHS angebundenes Gerät kann als MCP-Tools erscheinen, doch MCP allein definiert weder den physischen Zustand noch das Sicherheitsverhalten des Geräts.

Ersetzt MHS SiLA 2 oder OPC UA LADS?

Die öffentlich verfügbaren Belege stützen diese Schlussfolgerung nicht. SiLA 2 und OPC UA LADS definieren laborspezifische Gerätefähigkeiten, Zustand, Programme, Ergebnisse und Interoperabilität auf Ebenen unterhalb des Agenten. MHS kann diese Verträge nutzen, kapseln oder ergänzen, doch die genaue Beziehung kann erst normativ festgelegt werden, wenn die Spezifikation öffentlich ist.

Kann MHS den autonomen Laborbetrieb sicher machen?

MHS kann einen gemeinsamen Ort für Gerätewissen und durchgesetzte Grenzwerte bieten, was wertvoll ist. Ein sicherer Betrieb hängt jedoch weiterhin von der Vollständigkeit jedes Treibers, deterministischen Verriegelungen, dem aktuellen physischen Zustand, der Autorisierung, verifizierten Workflows, dem Wiederherstellungsverhalten und einer der Tragweite angemessenen menschlichen Aufsicht ab. Die Research Preview wird ausdrücklich genutzt, um weitere Sicherheitsevaluationen zu entwickeln.

Sollte ein Gerätehersteller MHS jetzt implementieren?

Organisationen, die in die Preview aufgenommen wurden, können die tatsächliche Spezifikation evaluieren und an klar abgegrenzten Anwendungsfällen testen. Andere Geräteteams können sich vorbereiten, ohne zu raten: typisierte APIs, beobachtbare Befehle, Grenzwerte, Simulation, Fehlerbehandlung und Ausführungsnachweise stärken. Diese Investitionen bleiben nützlich, selbst wenn sich die MHS-Schnittstelle vor der offenen Veröffentlichung ändert.

Von der Schnittstelle zur vertrauenswürdigen Ausführung

MHS ist ein deutliches Signal dafür, dass die Integration von KI und Hardware zu einer Produktanforderung wird. Der nachhaltige Vorteil wird nicht daraus entstehen, möglichst schnell möglichst viele Tools bereitzustellen. Er wird daraus entstehen, einen wertvollen Geräte-Workflow durchgängig erkennbar, verifizierbar, beobachtbar und wiederherstellbar zu machen.

QPillars entwickelt Software an dieser Grenze – von Geräteverträgen und Protokolladaptern bis hin zu ausführbarer Verifikation und Zustandsabgleich. Wenn Sie prüfen, wie ein Gerät an einem agentischen Workflow teilnehmen sollte, bringen Sie uns das Gerät und den Workflow, und wir zeigen auf, was die aktuelle Schnittstelle bereits unterstützt, was fehlt und welcher Teil deterministisch bleiben sollte.