KI-Assistenten oder KI-Agenten für Laborgeräte: Was sollten Sie zuerst entwickeln?
Eine Bedienperson fragt: «Warum wurde dieser Lauf angehalten?» Eine Fachperson für Laborautomatisierung fragt: «Können Sie den nächsten Transfer vorbereiten?» Beide Aufgaben können von KI profitieren. Sie erfordern unterschiedliche Zugriffe, Berechtigungen und Nachweise.
Ein KI-Assistent für ein Laborgerät kann helfen, einen Fehler zu verstehen, ein Verfahren nachzuvollziehen oder eine Methode vorzubereiten. Ein KI-Agent für Laborgeräte kann weiter gehen: unterstützte Operationen auswählen, Werkzeuge nutzen und auf Beobachtungen reagieren. Ein fester Ablauf kann eine bekannte Sequenz automatisieren, ohne diese Entscheidungen einem Modell zu überlassen.
Beginnen Sie mit einem Assistenten, wenn Nutzer eine korrekte Erklärung oder einen prüfbaren Vorschlag benötigen. Nutzen Sie einen festen Ablauf, wenn die Sequenz bekannt ist. Erwägen Sie einen Agenten, wenn die Auswahl des nächsten Schritts anhand von Beobachtungen einen Mehrwert bietet und Sie seine Aktionen begrenzen können. Die sinnvolle erste Wahl hängt von der Aufgabe Ihrer Nutzer und den Nachweisen ab, die Ihre Gerätesoftware liefern kann.
Für Gerätehersteller kann das bedeuten, Applikationswissen leichter zugänglich zu machen. Für Fachleute der Laborautomatisierung kann es bedeuten, einen prüfbaren Ablauf für bestehende Geräte vorzubereiten. Beides sind sinnvolle Einstiegspunkte. Keiner erfordert ein autonomes Labor.
Wenn Sie sich mit selbststeuernden Laboren beschäftigen, hilft diese Entscheidung, die erste Fähigkeit rund um Ihre bestehenden Geräte festzulegen. Bestimmen Sie, was das System wissen kann, welche Operationen es nutzen darf und wie es das Ergebnis feststellen wird. Wählen Sie dann den Umfang der Unterstützung und Autonomie, den die Aufgabe benötigt.
Assistent und Agent beschreiben den Umgang mit einer Aufgabe
Produktbezeichnungen überschneiden sich. Ein Assistent kann Werkzeuge aufrufen, und ein Agent kann für jede Aktion eine menschliche Freigabe benötigen. Beschreiben Sie das Verhalten für eine Entwicklungsentscheidung ausdrücklich.
| Ansatz | Wer bestimmt den nächsten Schritt? | Beispiel einer Geräteaufgabe |
|---|---|---|
| KI-Assistent | Der Nutzer steuert die Aufgabe; das System antwortet oder bereitet ein Ergebnis vor, gegebenenfalls mit Werkzeugen | Einen Fehler anhand des richtigen Handbuchs und aktueller Protokolle erklären |
| Fester Ablauf | Definierte Steuerungslogik bestimmt die Sequenz und unterstützte Verzweigungen | Eine freigegebene Sequenz ausführen und ihren Abschluss melden |
| KI-Agent | Das Modell wählt begrenzte nächste Schritte anhand von Werkzeugen und Beobachtungen | Eine Anfrage interpretieren, einen Kandidaten vorbereiten, Rückmeldungen prüfen und innerhalb erlaubter Grenzen überarbeiten |
Werkzeugzugriff und Ausführungsberechtigung sind getrennte Entscheidungen. Ein Dokumentationsassistent könnte einen Verdünnungsrechner nutzen, ohne Flüssigkeit dispensieren zu dürfen. Ein Agent könnte einen vollständigen Ablauf vorbereiten und die Ausführung dennoch einer Bedienperson überlassen.
Diese Unterscheidung ist zentral für KI-Agenten für Laborgeräte: Mehr Autonomie verändert die Nachweise und Kontrollen, die das System benötigt.
Eine Anfrage macht den Unterschied sichtbar
Betrachten Sie eine Liquid-Handling-Anfrage:
Übertragen Sie zwei Proben auf die Ausgabeplatte mit 20 µL pro Probe.
Die Formulierung ist kurz. Die Entwicklungsfragen sind umfangreicher. Welche Proben? Welche Platte? Sind geeignete Spitzen verfügbar? Welche Operationen unterstützt das Gerät? Wie ist der aktuelle Zustand? Wer darf den Transfer freigeben?
Ein Assistent hilft, die Anfrage zu klären
Ein Assistent könnte die benötigte Labware erklären, das relevante Verfahren abrufen und einen Transfer vorschlagen. Er sollte seine Quellen nennen und nachfragen, wenn Proben- oder Zielidentitäten mehrdeutig sind.
Das kann auch ohne direkte Steuerungsverbindung eine nützliche Produktfähigkeit sein. Wenn Bedienpersonen Zeit damit verbringen, das richtige Verfahren zu finden oder einen Fehler zu verstehen, ist eine Verbesserung dieser Aufgabe ein konkretes Ergebnis.
Evaluieren Sie den Assistenten anhand fachlich geprüfter Fragen, einschliesslich fehlender Informationen und widersprüchlicher Dokumentversionen. Messen Sie, ob seine Antwort korrekt ist, ob die Quelle zur Geräteversion passt und wie viel Korrektur der Nutzer benötigt.
Ein fester Ablauf verarbeitet eine etablierte Sequenz
Wenn das Transferverfahren bereits definiert ist und seine Eingaben validiert werden können, kann ein fester Ablauf die Parameter erfassen, Voraussetzungen prüfen und die erlaubte Sequenz ausführen.
Die sinnvolle Frage ist, ob Interpretation oder adaptive Schrittauswahl einen Mehrwert bietet. Bei einer stabilen Sequenz kann herkömmliche Steuerungslogik die Aufgabe bereits gut lösen. Ein Assistent kann Nutzern weiterhin bei der Vorbereitung der Eingaben helfen.
Ein Agent bereitet innerhalb einer Grenze vor und überarbeitet
Ein Agent kann die Anfrage interpretieren, verfügbare Fähigkeiten prüfen und einen Ablaufkandidaten vorbereiten. Meldet eine Prüfung ein Problem, kann er es erklären oder den Kandidaten überarbeiten, sofern diese Änderung erlaubt ist.
Fehlende Ausstattung ist ein aufschlussreicher Fall. Wenn kein Spitzenrack vorhanden ist, würde eine stillschweigende Änderung des Decks die Aufgabe verändern. Die sinnvolle Antwort benennt die fehlende Voraussetzung und gibt die Kontrolle an den Nutzer zurück.
Die physische Ausführung bringt weitere Verantwortlichkeiten mit sich: Die Freigabe muss zum tatsächlichen Kandidaten gehören, der relevante Zustand muss weiterhin gelten und das System muss feststellen, was nach dem Absenden passiert ist. Ein vorbereiteter Plan und ein abgeschlossener Transfer sind unterschiedliche Ergebnisse.
Was ein Ablehnungstest nachweisen kann
In der QPillars-Referenzanwendung LiquidBridge haben wir die Entscheidungsprüfung des Planers mit einem geskripteten Modell sowie simulierten Antworten für Expansion und Validierung getestet. Das Modell lieferte wiederholt dieselbe Transferabsicht. Dadurch konnten die Tests isolieren, wie die Anwendung mit dem Ergebnis umging.
| Testbedingung | Beobachtetes Softwareverhalten |
|---|---|
| Die Expansion liefert ausführbare Schritte | Der Planer übergibt die expandierten Schritte an die Validierung und liefert einen Ablauf zurück |
| Die Expansion meldet ein fehlendes Spitzenrack | Nach dem konfigurierten Korrekturbudget liefert der Planer einen Fehler ohne Ablauf zurück; die nachgelagerte Validierung wird nicht aufgerufen |
| Die Expansion liefert ohne Fehler keine Schritte | Der Planer weist das leere Ergebnis zurück |
| Das geskriptete Modell liefert eine Ablehnung | Der Planer überspringt die Expansion |
Die Testsuite prüft auch die Struktur der Korrekturkonversation und den Umgang mit Expansionsergebnissen. Das ist ein Nachweis zur Entscheidungsprüfung des Planers. Er verwendet ein künstliches Modell, vorgegebene Expansionsergebnisse und einen Validator-Ersatz. Er misst weder, ob ein Sprachmodell die Anfrage versteht, noch ob ein Gerät seinen Zustand korrekt meldet oder Flüssigkeit korrekt übertragen wird.
Die Entwicklungslektion ist trotz dieses engen Umfangs nützlich: Eine Anwendung sollte einen unbrauchbaren Kandidaten zurückweisen, auch wenn das Modell ihn weiter vorschlägt. Die Evaluation benötigt gewöhnliche Anfragen und Ablehnungspfade.
Unser Leitfaden zu Probeläufen von Workflows erklärt, wie modellierte Prüfungen in einen grösseren Ausführungspfad passen. Ein Modell kann die Bedingungen prüfen, die es implementiert; physische Leistung benötigt separate Nachweise.
Ist Ihr Gerät für die gewünschte Fähigkeit bereit?
Nutzen Sie diese Fragen, um die erste Lieferung festzulegen.
| Frage | Wie eine nützliche Antwort aussieht |
|---|---|
| Welche wiederkehrende Aufgabe verbessern wir? | Ein benannter Nutzer, repräsentative Anfragen und ein beobachtbares nützliches Ergebnis |
| Welches Wissen ist massgeblich? | Identifizierte Handbücher, Verfahren und Versionen mit einem Umgang mit Widersprüchen |
| Worauf kann die Software zugreifen? | Unterstützte Dateien, APIs, SDK-Operationen oder SiLA 2-Fähigkeiten für die tatsächliche Geräteversion |
| Welchen Zustand können wir beobachten? | Relevanter Status mit Identität, Zeitstempeln und ausdrücklichem Umgang mit Unbekanntem |
| Welche Auswirkungen sind erlaubt? | Definierte Lese-, Vorbereitungs- und Ausführungsberechtigungen mit einem verantwortlichen Freigabepfad |
| Wer verantwortet die Ausführung? | Eine Steuerungsinstanz, die konkurrierende Anfragen verhindert und Befehle mit Ergebnissen verbindet |
| Was passiert nach einem Verbindungsabbruch? | Eine Möglichkeit, Ablehnung, laufende Arbeit, Abschluss und unklare Ergebnisse zu unterscheiden |
| Wie werden wir evaluieren? | Erwartete Ergebnisse und Fehler, ein Vergleich mit dem bestehenden Prozess und repräsentative Szenarien |
Sie benötigen nicht jede Antwort zur Ausführung, um einen nützlichen beratenden Assistenten zu entwickeln. Sie benötigen sie, sobald diese Verantwortlichkeiten Teil des Umfangs werden.
Beispielsweise können Handbücher und exportierte Protokolle eine Fehlererklärung ermöglichen. Eine API, die Befehle akzeptiert, deren Ergebnis aber nicht sichtbar macht, lässt eine erhebliche Lücke für automatisierte Ausführung. Ein Timeout sagt nicht aus, ob ein erneutes Dispensieren zweimal Material verbrauchen würde.
Die Bereitschaftsentscheidung sollte einen begrenzten Umfang ergeben: einen Fehler erklären, eine Sequenz vorbereiten oder eine bestimmte freigegebene Operation mit beobachtbarer Rückmeldung ausführen.
Wo MCP und Simulation passen
MCP-Werkzeuge ermöglichen kompatiblen Clients, beschriebene Softwarefähigkeiten zu entdecken und aufzurufen. Der Geräteadapter muss weiterhin das Verhalten des Geräts erhalten, einschliesslich Einheiten, Fehlern und Befehlslebenszyklus. Anwendungsberechtigungen und Freigaben benötigen eine Implementierung über die Werkzeugbeschreibung hinaus.
Eine bestehende Hersteller-API oder ein SDK kann unter dieser Schnittstelle bestehen bleiben. SiLA 2 ist eine weitere mögliche Kommunikationsschicht für Geräte. Die praktische Wahl hängt von Ihren vorhandenen Schnittstellen und benötigten Operationen ab. Unser MCP-Anbindungsleitfaden behandelt diese Integrationsgrenze.
Simulation kann helfen, einen Kandidaten vor der Ausführung zu prüfen. Die Dokumentation von OpentronsAI beschreibt die Erstellung und Änderung von Protokollen und die Nutzung von Simulation zur Vorbereitung. Das ist ein konkretes Beispiel des umfassenderen Musters: vor dem Ausführen erzeugen, prüfen und testen.
Wählen Sie Prüfungen anhand des Fehlers, den Sie erkennen möchten. Eine Schemaprüfung kann einen fehlerhaften Parameter erkennen. Ein Ressourcenmodell kann fehlende Labware erkennen. Keine dieser Prüfungen allein stellt fest, dass ein physischer Transfer erfolgreich war.
Wählen Sie die erste Entwicklung anhand ihrer Abnahmebedingung
Für einen Assistenten könnte eine sinnvolle erste Abnahmebedingung korrekte, quellenbasierte Fehlererklärungen für eine festgelegte Fallmenge sein, mit angemessenen Rückfragen bei unzureichenden Nachweisen.
Für eine Vorbereitungsfähigkeit könnten es Ablaufkandidaten sein, die gelieferte Probenidentitäten und Verfahrensregeln erhalten, fehlende Eingaben kennzeichnen und einer Fachperson die Prüfung ermöglichen.
Für die Ausführung muss die Abnahme zusätzlich Berechtigungen, Befehlsverantwortung, aktuellen Zustand und beobachtete Ergebnisse abdecken. Beziehen Sie Fehler wie Verbindungsabbrüche und mehrdeutigen Abschluss ein, bevor Sie den Umfang erweitern.
Die erste Fähigkeit rechtfertigt sich dadurch, dass sie einem Nutzer hilft, eine Aufgabe zu erledigen. Erweitern Sie sie, wenn die nächste Verantwortlichkeit ein reales Problem löst und evaluiert werden kann.
Entwickeln Sie Anbindung, Assistent und Agent selbst
Die QPillars Agentic Lab Academy bereitet zweitägige Präsenzworkshops in Zürich und Basel vor. Sie richten sich an Fachleute für Laborautomatisierung, Entwicklungs- und Applikationsfachleute für Laborgeräte sowie Wissenschaftlerinnen und Wissenschaftler, die einfaches Python anpassen können.
Der geplante Lernpfad folgt denselben Entscheidungen: unterstützte Gerätefähigkeiten an einen kompatiblen Copilot anbinden, einen Geräteassistenten entwickeln und anschliessend einen Agenten für eine definierte Aufgabe bauen. Angeleitete Übungen umfassen betreute Arbeit an echter Laborhardware, Rückmeldungen und Fehleruntersuchung sowie ein Startprojekt und eine Evaluationscheckliste für die Weiterarbeit.
Die ersten Gruppen sind in Vorbereitung. Melden Sie Interesse an einem Workshop an oder besprechen Sie ein Training für Ihr Team.
Wenn Ihr Ziel eine Produktfähigkeit ist, entwickelt QPillars massgeschneiderte KI-Assistenten und Agenten für Laborgeräte. Besprechen Sie einen Geräteablauf mit uns, einschliesslich Aufgabe, verfügbarer Schnittstelle und dem Ergebnis, das Ihre Nutzer benötigen.
Technischer Leiter und Mitgründer bei QPillars
Spezialisiert auf Laborautomatisierung – von der praktischen Gerätesteuerung und Flüssigkeitshandhabung bis zur KI-gestützten Orchestrierung von Protokollen.