Agentische KI für Laborabläufe - von Skripten zu autonomen Systemen
Agentische KI für Laborabläufe - von Skripten zu autonomen Systemen
KI-Agenten für die Laborautomatisierung sind Systeme, die über Protokolle schlussfolgern, sich an den Zustand der Geräte anpassen und mehrstufige Abläufe ohne fest programmierte Skripte zusammenstellen. Anders als herkömmliche LIMS-Automatisierung, die eine feste Abfolge unabhängig vom tatsächlichen Geschehen abarbeitet, beobachtet ein KI-Agenten-Laborsystem die Ergebnisse, entscheidet über den nächsten Schritt und behandelt Ausnahmen - so wie es eine erfahrene Wissenschaftlerin oder ein erfahrener Wissenschaftler tut, jedoch mit Maschinengeschwindigkeit. Der weltweite Markt für Laborautomatisierung erreichte 2025 schätzungsweise 8,4 Milliarden US-Dollar und soll bis 2034 auf über 14 Milliarden US-Dollar wachsen (Precedence Research, 2025), dennoch stützen sich rund 61 % der Labore zumindest bei einigen Abläufen noch auf manuelle Prozesse (MLO, 2025). Agentische KI verändert diese Ausgangslage.
Dieser Beitrag behandelt die Entwicklung von Skripten zu Agenten, die Architekturmuster, die dies ermöglichen, sowie die Sicherheitsmechanismen, die nötig sind, um einer KI physische Laborvorgänge anzuvertrauen.
Das Wichtigste in Kürze
- Skriptbasierte Automatisierung bewältigt 80 % der Routineabläufe, scheitert jedoch an Ausnahmen - Grenzfällen, die Wissenschaftlerinnen und Wissenschaftler intuitiv lösen, die Skripte aber nicht vorhersehen können
- Agentische KI bringt Schlussfolgern, Werkzeugnutzung und adaptive Entscheidungsfindung in Laborabläufe - Agenten beobachten, planen, handeln und lernen aus Ergebnissen
- MCP (Model Context Protocol) stellt die standardisierte Werkzeugschnittstelle bereit, die Agenten geräteunabhängig macht
- Human-in-the-Loop ist nicht optional - sicherheitskritische Laborvorgänge erfordern Freigabeschranken, keine vollständige Autonomie
- Der realistische Weg ist hybrid: Agenten übernehmen Orchestrierung und Anpassung, Menschen geben irreversible Aktionen frei
Drei Generationen der Laborautomatisierung
Die Laborautomatisierung hat sich über drei klar unterscheidbare Generationen entwickelt, wobei jede eine zusätzliche Ebene an Intelligenz hinzugefügt hat. Wo Ihr Labor auf diesem Spektrum steht, bestimmt, was agentische KI heute für Sie leisten kann.
Das obige Diagramm zeigt die Entwicklung von Generation 1 (feste Skripte, die sequenziell ausgeführt werden) über Generation 2 (regelbasierte Orchestrierung mit bedingten Verzweigungen) bis zu Generation 3 (KI-Agenten, die über Ziele schlussfolgern und Aktionen dynamisch zusammenstellen). Jede Generation behält die Fähigkeiten der vorherigen bei und fügt eine neue Ebene der Anpassungsfähigkeit hinzu.
Generation 1 - Skriptbasierte Automatisierung
Das Arbeitspferd der meisten Labore heute. Ein Python-Skript oder ein Hersteller-Makro führt eine feste Abfolge aus: aus Platte A aspirieren, in Platte B dispensieren, 30 Minuten inkubieren, Absorption messen. Das Skript läuft jedes Mal identisch ab. Meldet der Plattenleser einen Fehler, stürzt das Skript entweder ab oder überspringt den Schritt. Ist ein Well leer, saugt es Luft an.
# Generation 1: rigid script - no awareness of instrument state
for well in plate.wells():
liquid_handler.aspirate(well, volume_ul=50)
liquid_handler.dispense(target_plate[well], volume_ul=50)
incubator.run(minutes=30)
results = plate_reader.read_absorbance(wavelength_nm=450)
save_to_lims(results)
Das funktioniert bei Routineassays mit vorhersehbaren Bedingungen. Es versagt in dem Moment, in dem etwas Unerwartetes geschieht - ein Reagenz geht zur Neige, ein Well enthält eine Luftblase, ein Gerät muss neu kalibriert werden. Manuelle und skriptbasierte Vorgänge weisen Fehlerquoten von 10-30 % auf, verglichen mit 1-5 % bei vollautomatisierten Systemen mit adaptiver Fehlerbehandlung (SNS Insider, 2026).
Generation 2 - Regelbasierte Orchestrierung
LIMS-Workflow-Engines und Scheduler wie Hamilton VENUS, Beckman SAMI oder individuell entwickelte Workflow-Engines ergänzen bedingte Logik. Meldet der Plattenleser einen Fehler, wird erneut versucht. Überschreitet die OD eines Wells einen Schwellenwert, wird es markiert. Regeln behandeln bekannte Ausnahmen.
# Generation 2: rule-based - handles known exceptions
for well in plate.wells():
volume = liquid_handler.detect_volume(well)
if volume < 50:
logger.warn(f"Insufficient volume in {well}, skipping")
continue
liquid_handler.aspirate(well, volume_ul=50)
liquid_handler.dispense(target_plate[well], volume_ul=50)
incubator.run(minutes=30)
results = plate_reader.read_absorbance(wavelength_nm=450)
for well, od in results.items():
if od > 3.0:
flag_for_review(well, reason="OD out of range")
Besser, aber immer noch fragil. Jede Ausnahme muss vorhergesehen und programmiert werden. Wenn eine Wissenschaftlerin oder ein Wissenschaftler auf eine neue Situation stösst - das OD-Muster deutet auf eine Kontamination hin, eine Reagenzcharge hat eine andere Viskosität, das Protokoll muss aufgrund vorgelagerter Ergebnisse angepasst werden -, deckt keine Regel diesen Fall ab. Die Wissenschaftlerin oder der Wissenschaftler greift manuell ein, was den Zweck der Automatisierung zunichtemacht.
Generation 3 - KI-Agenten mit Werkzeugnutzung
Ein KI-Agent erhält ein Ziel («führe den ELISA-Assay auf Platte 7 durch, optimiere auf Sensitivität»), ermittelt die verfügbaren Geräte über MCP, schlussfolgert über das Protokoll und stellt den Ablauf dynamisch zusammen. Wenn etwas Unerwartetes geschieht, überlegt der Agent, was zu tun ist - genau wie es eine Wissenschaftlerin oder ein Wissenschaftler tun würde.
# Generation 3: AI agent - reasons about goals, adapts to state
agent_prompt = """
Run an ELISA assay on plate 7.
Goal: maximize sensitivity for low-abundance analytes.
Available instruments: liquid_handler, incubator, plate_reader.
Constraints: use standard curve from plate 6 results.
Approval required for: any volume > 200uL, incubation > 60min.
"""
# The agent:
# 1. Discovers instrument capabilities via MCP tools/list
# 2. Checks plate 7 current state (volume, temperature)
# 3. Plans the workflow based on the goal
# 4. Executes step-by-step, observing results
# 5. Adapts if results deviate from expected ranges
# 6. Requests human approval for high-risk actions
Der entscheidende Unterschied: Der Agent folgt keinem festen Pfad. Er hat ein Ziel, Werkzeuge und Randbedingungen. Er plant, führt aus, beobachtet und passt sich an. Genau das bedeutet «agentisch» im Laborkontext.
Was einen Labor-KI-Agenten «agentisch» macht
Der Begriff «agentische KI» wird oft unscharf verwendet. Im Laborkontext ist ein KI-System dann agentisch, wenn es über vier bestimmte Fähigkeiten verfügt, die zusammenwirken.
1. Werkzeugnutzung - Interaktion mit physischen Geräten
Der Agent kann Werkzeuge, die Laborgeräte steuern, ermitteln und aufrufen. Mit MCP als Integrationsschicht verbindet sich der Agent mit jedem Gerät, das über einen MCP-Server verfügt - Liquid Handler, Plattenleser, Inkubatoren, Zentrifugen -, ohne gerätespezifischen Integrationscode.
2. Schlussfolgern - Planung mehrstufiger Protokolle
Auf Grundlage eines übergeordneten Ziels zerlegt der Agent dieses in Schritte, berücksichtigt Abhängigkeiten (eine Platte kann nicht gemessen werden, bevor Reagenzien dispensiert wurden) und bestimmt die optimale Reihenfolge. Dabei kommt das ReAct-Muster (Reasoning + Acting) zum Einsatz, das erstmals 2022 von Yao et al. beschrieben wurde und bei dem das Modell abwechselnd darüber nachdenkt, was zu tun ist, und Aktionen ausführt.
3. Beobachtung - Erfassen von Gerätezustand und Ergebnissen
Nach jeder Aktion beobachtet der Agent das Ergebnis. War die Aspiration erfolgreich? Welche OD-Werte wurden zurückgegeben? Hat der Inkubator die Zieltemperatur erreicht? Diese Beobachtungen fliessen in die Schlussfolgerungsschleife zurück, sodass der Agent nachfolgende Schritte anpassen kann.
4. Anpassung - Umgang mit dem Unerwarteten
Wenn Ergebnisse von den Erwartungen abweichen - ein OD-Wert, der auf eine Kontamination hindeutet, eine Volumenprüfung, die zeigt, dass ein Reagenz zur Neige geht, ein Gerät, das eine Kalibrierwarnung meldet -, überlegt der Agent, was zu tun ist. Erneut versuchen? Überspringen? Einen Menschen alarmieren? Parameter anpassen? Genau hier unterscheiden sich Agenten grundlegend von Skripten.
Architekturmuster für Laboragenten
Der Aufbau eines KI-Agenten für Laborabläufe erfordert die Wahl des richtigen Architekturmusters. Nachfolgend drei Ansätze, geordnet vom einfachsten bis zum komplexesten.
Muster 1 - Einzelner Agent mit MCP-Werkzeugen
Das einfachste Muster. Ein LLM-Agent verbindet sich mit mehreren MCP-Servern, von denen jeder ein Laborgerät kapselt. Der Agent plant und führt den gesamten Ablauf aus.
Das Einzelagenten-Muster eignet sich gut für Abläufe mit 2-5 Geräten, bei denen ein einzelnes LLM den gesamten Kontext erfassen kann. Der Agent ermittelt die verfügbaren Werkzeuge über MCP, plant das Protokoll und führt es Schritt für Schritt aus. Eine menschliche Freigabeschranke fängt sicherheitskritische Aktionen ab, bevor sie die Hardware erreichen.
import Anthropic from "@anthropic-ai/sdk";
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
const anthropic = new Anthropic();
// Connect to instrument MCP servers
const liquidHandler = new Client({ name: "liquid-handler-client" });
const plateReader = new Client({ name: "plate-reader-client" });
// Discover available tools from all instruments
const tools = [
...(await liquidHandler.listTools()).tools,
...(await plateReader.listTools()).tools,
];
// Agent loop: reason, act, observe, repeat
const messages = [
{ role: "user", content: "Run ELISA on plate 7, optimize for sensitivity" }
];
while (true) {
const response = await anthropic.messages.create({
model: "claude-sonnet-4-6",
max_tokens: 4096,
system: SYSTEM_PROMPT,
tools: tools.map(convertMcpToolToAnthropicTool),
messages,
});
if (response.stop_reason === "end_turn") break;
// Execute tool calls against the appropriate MCP server
for (const block of response.content) {
if (block.type === "tool_use") {
const result = await routeToolCall(block, { liquidHandler, plateReader });
messages.push({ role: "tool", content: result });
}
}
}
Am besten geeignet für: Abläufe mit einem einzelnen Protokoll, kleine Gerätegruppen, schnelles Prototyping.
Muster 2 - Multi-Agenten-Orchestrierung (CrewAI / LangGraph)
Bei komplexen Abläufen über viele Geräte hinweg wird das Kontextfenster eines einzelnen Agenten zum Engpass. Multi-Agenten-Systeme weisen spezialisierten Agenten unterschiedliche Rollen zu - einen Protokollplaner, einen Gerätesteuerer, einen Qualitätsprüfer -, die von einem Orchestrator koordiniert werden.
CrewAI (44k GitHub-Sterne, eingesetzt von über 60 % der Fortune-500-Unternehmen) bietet ein Framework zur Definition von Agententeams mit Rollen, Zielen und Werkzeugzugriff. Jeder Agent ist auf einen Teilbereich des Ablaufs spezialisiert:
from crewai import Agent, Task, Crew
protocol_planner = Agent(
role="Protocol Planner",
goal="Design optimal assay protocols based on experimental goals",
tools=[literature_search, protocol_database],
llm="claude-sonnet-4-6",
)
instrument_operator = Agent(
role="Instrument Operator",
goal="Execute protocol steps on lab instruments safely",
tools=[liquid_handler_mcp, plate_reader_mcp, incubator_mcp],
llm="claude-sonnet-4-6",
)
qc_analyst = Agent(
role="QC Analyst",
goal="Validate results against acceptance criteria and flag anomalies",
tools=[statistics_tools, lims_connector],
llm="claude-sonnet-4-6",
)
crew = Crew(
agents=[protocol_planner, instrument_operator, qc_analyst],
tasks=[plan_task, execute_task, validate_task],
process="sequential", # or "hierarchical" with a manager agent
)
LangGraph (Teil des LangChain-Ökosystems mit 126k Sternen) verfolgt einen anderen Ansatz - es modelliert den Ablauf als zustandsbehafteten gerichteten Graphen, in dem jeder Knoten ein Agent oder eine Funktion ist und Kanten Übergänge auf Basis des aktuellen Zustands darstellen. Dies ermöglicht eine feingranulare Kontrolle über den Ausführungsfluss, die rollenbasierte Frameworks wie CrewAI wegabstrahieren.
Am besten geeignet für: Abläufe mit mehreren Protokollen, komplexe QC-Anforderungen, Teams mit vielfältigen Geräteparks.
Muster 3 - Individuelle Agentenschleife mit MCP und Sicherheitsschranken
Für produktive Laborumgebungen, in denen Zuverlässigkeit und Nachvollziehbarkeit wichtiger sind als die Flexibilität eines Frameworks, bietet eine individuelle Agentenschleife volle Kontrolle über den Ausführungszyklus. Genau das entwickeln wir bei QPillars.
class LabAgent:
def __init__(self, instruments: list[McpClient], safety_config: SafetyConfig):
self.instruments = {i.name: i for i in instruments}
self.safety = safety_config
self.audit_log = AuditLog()
async def execute_protocol(self, goal: str) -> ProtocolResult:
plan = await self.plan(goal)
self.audit_log.record("plan_created", plan)
for step in plan.steps:
# Safety gate: check if action requires approval
if self.safety.requires_approval(step):
approval = await self.request_human_approval(step)
if not approval.granted:
self.audit_log.record("step_rejected", step)
return ProtocolResult(status="halted", reason=approval.reason)
# Execute via MCP
result = await self.instruments[step.instrument].call_tool(
step.tool_name, step.arguments
)
self.audit_log.record("step_executed", step, result)
# Observe and adapt
if self.is_anomalous(result, step.expected):
adapted_plan = await self.replan(goal, plan, step, result)
plan = adapted_plan
self.audit_log.record("plan_adapted", adapted_plan)
return ProtocolResult(status="completed", audit=self.audit_log)
Am besten geeignet für: GxP-regulierte Umgebungen, klinische Labore und jeden Ablauf, bei dem Nachvollziehbarkeit nicht verhandelbar ist.
Sicherheit - die nicht verhandelbare Ebene
Einem KI-Agenten die Kontrolle über physische Geräte zu geben, unterscheidet sich grundlegend davon, ihm Zugriff auf APIs oder Datenbanken zu gewähren. Ein falsch gesetztes Dezimalkomma bei einem Dispensiervolumen kann teure Reagenzien verschwenden. Ein falscher Temperatursollwert kann biologische Proben zerstören, in denen Monate an Arbeit stecken. Sicherheit ist keine Zusatzfunktion - sie ist das Fundament.
Die Freigabehierarchie
Nicht alle Laboraktionen bergen das gleiche Risiko. Ein gut konzipiertes Agentensystem klassifiziert Aktionen nach Risikostufe und wendet angemessene Kontrollen an:
| Risikostufe | Beispiele | Kontrolle |
|---|---|---|
| Niedrig | Temperatur ablesen, Status prüfen, LIMS abfragen | Vollständig autonom |
| Mittel | Aspirieren/Dispensieren innerhalb validierter Bereiche, Standardinkubation starten | Protokollieren und fortfahren |
| Hoch | Volumen > Protokollmaximum, nicht standardmässige Temperaturen, neue Reagenzchargen | Menschliche Freigabe erforderlich |
| Kritisch | Gerätekalibrierung, Protokollabweichung, Proben verwerfen | Menschliche Freigabe + Abzeichnung durch Vorgesetzte |
Diese Hierarchie lässt sich direkt auf MCP-Werkzeugdefinitionen abbilden. Das Schema jedes Werkzeugs kann Sicherheitsgrenzen kodieren - Volumengrenzen, Temperaturbereiche, Listen zugelassener Reagenzien -, und die Sicherheitsschicht des Agenten setzt diese durch, bevor ein Werkzeugaufruf die Hardware erreicht.
Validierung mit dem digitalen Zwilling
Bevor ein Agent ein Protokoll auf physischen Geräten ausführt, führen Sie es auf einem digitalen Zwilling aus. Der Zwilling stellt dieselbe MCP-Schnittstelle bereit wie das reale Gerät, läuft jedoch in einer Simulation. Der Agent kann den Unterschied nicht erkennen. Wird das Protokoll auf dem Zwilling erfolgreich abgeschlossen - die Volumen gehen auf, das Timing stimmt, es gibt keine Verletzungen von Randbedingungen -, wird es für die physische Ausführung freigegeben.
Das ist keine Theorie. Unsere Plattform LiquidBridge nutzt genau dieses Muster: Agenten entwickeln und testen Protokolle an einem digitalen Zwilling des Liquid Handlers und führen sie erst nach bestandener Validierung auf realer Hardware aus.
Audit Trail
Jede Aktion eines Agenten muss mit vollständigem Kontext protokolliert werden: Was war das Ziel, was hat der Agent geplant, welcher Werkzeugaufruf wurde getätigt, welche Argumente wurden übermittelt, welches Ergebnis kam zurück und lag das Ergebnis innerhalb der erwarteten Grenzen? In regulierten Umgebungen (GxP, 21 CFR Part 11) ist dieser Audit Trail nicht nur Best Practice - er ist eine gesetzliche Anforderung.
Der realistische Weg zu autonomen Laboren
Vollständige Laborautonomie - bei der KI-Agenten ganze Experimente ohne menschliche Beteiligung durchführen - wird nicht morgen Realität. Der Weg dorthin ist jedoch klar, und jeder Schritt schafft echten Mehrwert.
Phase 1 - Assistiert (hier sollten die meisten Labore beginnen) KI-Agenten schlagen auf Basis von Ergebnissen nächste Schritte vor. Wissenschaftlerinnen und Wissenschaftler geben diese frei und führen sie aus. Der Agent lernt aus der Feedbackschleife. Dies lässt sich bereits heute mit bestehenden LLMs und MCP-Infrastruktur umsetzen.
Phase 2 - Überwacht Agenten führen Routineprotokolle autonom aus. Menschen überwachen Dashboards und geben nicht routinemässige Entscheidungen frei. Die Ausnahmebehandlung ist für bekannte Muster automatisiert und wird bei neuen Situationen eskaliert.
Phase 3 - Autonom (nur für bestimmte Abläufe) Vollständig autonome Ausführung für validierte, gut charakterisierte Abläufe - routinemässige QC-Assays, Standard-Probenvorbereitung, repetitive Screening-Läufe. Neuartige Experimente und Methodenentwicklung bleiben menschengesteuert.
Selbstfahrende Labore haben bereits bewiesen, dass autonome Ausführung bei spezifischen, klar abgegrenzten Abläufen funktioniert. Das A-Lab des Berkeley Lab synthetisierte während 17 Tagen Dauerbetrieb autonom 41 von 58 vorhergesagten anorganischen Materialien - eine Erfolgsquote von 71 % bei minimalem menschlichem Eingreifen (Nature, 2023). Emerald Cloud Lab ermöglicht die vollständig ferngesteuerte Planung und Durchführung von Experimenten auf Hunderten von Geräten. Die Herausforderung besteht darin, über gut charakterisierte Abläufe hinaus zu verallgemeinern - und genau hier verändert agentische KI mit Werkzeugnutzung und Schlussfolgerungsfähigkeiten die Spielregeln.
Auf regulatorischer Seite veröffentlichte die FDA im Januar 2025 einen Leitlinienentwurf, der einen Total-Product-Life-Cycle-Ansatz auf KI-gestützte Gerätesoftware anwendet und Modelldokumentation, Leistungskennzahlen sowie Spezifikationen der Mensch-KI-Arbeitsabläufe verlangt. Das NIST lancierte im Februar 2026 eine eigene AI Agent Standards Initiative, die darauf ausgerichtet ist, dass autonome Agenten sicher, interoperabel und vertrauenswürdig sind. Die Regulierung holt gegenüber der Technologie auf - was bedeutet, dass der Aufbau sicherheitsorientierter Architekturen heute nicht nur gutes Engineering ist, sondern auch Zukunftssicherheit schafft.
Wie QPillars dies angeht
Wir entwickeln die Infrastruktur, die Laboragenten möglich macht:
- MCP-Server für Geräte - Jedes Gerät im Labor erhält eine MCP-Schnittstelle. Der Agent spricht ein Protokoll und steuert jedes Gerät.
- Validierung mit dem digitalen Zwilling - Agenten testen Protokolle auf LiquidBridge, bevor sie reale Hardware berühren. Dieselbe MCP-Schnittstelle, simulierte Ausführung.
- Sicherheitsorientierte Architektur - Freigabeschranken, Parametervalidierung und vollständige Audit Trails sind in die Agentenschleife integriert und nicht nachträglich angefügt.
- Rust für den kritischen Pfad - Code zur Gerätesteuerung, der unterhalb von MCP läuft, ist in Rust geschrieben, um Speichersicherheit und Echtzeitgarantien zu gewährleisten.
Die Zukunft der Laborautomatisierung sind nicht Skripte, die blind ablaufen. Es sind Agenten, die darüber schlussfolgern, was sie tun - und wissen, wann sie um Hilfe bitten müssen.
Häufig gestellte Fragen
Was ist ein KI-Agent im Laborkontext?
Ein KI-Agent für Laborabläufe ist ein System, das ein übergeordnetes experimentelles Ziel erhält, verfügbare Geräte über standardisierte Protokolle wie MCP ermittelt, mehrstufige Protokolle plant, diese durch Aufrufen von Gerätewerkzeugen ausführt, Ergebnisse beobachtet und sein Vorgehen anpasst, wenn die Bedingungen von den Erwartungen abweichen. Anders als Skripte schlussfolgern Agenten darüber, was zu tun ist, statt einer festen Abfolge zu folgen.
Ist es sicher, KI Laborgeräte steuern zu lassen?
Sicherheit erfordert einen mehrschichtigen Ansatz: Parametervalidierung in Werkzeugschemata (verhindert Befehle ausserhalb zulässiger Bereiche), menschliche Freigabeschranken für risikoreiche Aktionen, Validierung mit dem digitalen Zwilling vor der physischen Ausführung sowie umfassende Audit Trails. Keine verantwortungsvolle Implementierung gewährt einem Agenten uneingeschränkten Zugriff auf die Hardware. Die Sicherheitsarchitektur ist es, die autonomen Betrieb für Routineabläufe ermöglicht und gleichzeitig Menschen bei neuartigen oder risikoreichen Situationen einbindet.
Worin unterscheidet sich agentische KI von herkömmlicher LIMS-Automatisierung?
Herkömmliche LIMS-Automatisierung führt vordefinierte Abläufe aus - feste Schrittfolgen mit bedingten Verzweigungen für bekannte Ausnahmen. Agentische KI erhält Ziele und stellt Abläufe dynamisch zusammen, wobei sie sich an Gerätezustand, Zwischenergebnisse und unerwartete Bedingungen anpasst. LIMS-Automatisierung beantwortet «Führe diese Abfolge aus». Agentische KI beantwortet «Erreiche dieses Ziel und finde die Schritte selbst heraus».
Welche Frameworks gibt es für die Entwicklung von Labor-KI-Agenten?
CrewAI und LangGraph sind die ausgereiftesten Multi-Agenten-Frameworks. CrewAI bietet rollenbasierte Agententeams mit integrierter Koordination. LangGraph modelliert Abläufe als Zustandsautomaten mit Agentenknoten. Für produktive Laborumgebungen bieten individuelle Agentenschleifen mit direkter MCP-Integration oft eine bessere Kontrolle über Sicherheit, Nachvollziehbarkeit und Fehlerbehandlung als Allzweck-Frameworks.
Können KI-Agenten mit bestehenden Laborgeräten arbeiten?
Ja - über MCP (Model Context Protocol). Ein MCP-Server kapselt die Schnittstelle, über die das Gerät bereits verfügt (seriell, TCP, REST, Hersteller-SDK), und stellt sie als standardisierte Werkzeuge bereit, die jeder KI-Agent ermitteln und nutzen kann. Ein neues Gerät hinzuzufügen bedeutet, einen MCP-Server bereitzustellen. Auf Seiten des Agenten sind keine Änderungen erforderlich.
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.