Automating Computational Chemistry Workflows via OpenClaw and Domain-Specific Skills

Die vorgestellte Arbeit demonstriert, wie OpenClaw durch eine entkoppelte Agenten-Fertigkeiten-Architektur komplexe computergestützte Chemie-Workflows automatisiert, indem sie Planung, Domänenwissen und die Ausführung auf heterogenen Hochleistungsrechnern entkoppelt und dabei robuste Fehlerbehandlung sowie skalierbare Prozesse ermöglicht.

Das Wesentliche

Stellen Sie sich vor, Sie wollen ein komplexes, mehrstufiges Kochrezept zubereiten – sagen wir, eine aufwendige Festtagsmahlzeit. Aber Sie haben ein Problem: Die Zutaten kommen aus verschiedenen Läden, die Kochutensilien sind unterschiedlich, und Sie müssen das Essen gleichzeitig in drei verschiedenen Küchen (vielleicht sogar in verschiedenen Städten) zubereiten.

Bisher war es so, dass man für jede solche Aufgabe einen eigenen, starren Koch einstellen musste, der genau wusste, wie man Schritt 1 bis 10 abarbeitet. Wenn man aber einen neuen Ofen hatte oder ein anderes Rezept wollte, musste man den Koch oft komplett neu ausbilden oder ersetzen. Das war mühsam und unflexibel.

Diese neue Forschung von Mingwei Ding und seinem Team stellt eine völlig andere Idee vor: Ein genialer Küchenchef-Assistent (der "Agent") und ein Team von spezialisierten Helfern (die "Skills").

Hier ist die Erklärung, wie das funktioniert, ohne Fachchinesisch:

1. Der Chef-Assistent (OpenClaw)

Stellen Sie sich OpenClaw als einen sehr klugen, aber allgemeinen Küchenchef-Assistenten vor. Er ist kein Experte für jedes einzelne Rezept, aber er ist brillant darin, den Überblick zu behalten.

• Seine Aufgabe: Er hört zu, was Sie wollen (z. B. "Ich möchte die chemische Reaktion von Methan und Sauerstoff simulieren").
• Sein Vorteil: Er muss nicht alles selbst wissen. Er koordiniert nur. Er sagt: "Okay, wir brauchen zuerst den Gemüseschneider, dann den Ofen, und am Ende den Teller." Er überwacht den Prozess, aber er kocht nicht selbst.

2. Die Spezialisten-Helfer (Skills)

Das ist das Geniale an der neuen Methode: Statt den Assistenten selbst zum Experten zu machen, holt er sich Helfer, die genau das können, was gerade nötig ist.

• Planungs-Helfer: Dieser Helfer nimmt Ihre vage Idee ("Ich will Methan oxidieren") und wandelt sie in eine klare, schriftliche Einkaufsliste und Kochanleitung um. Er sagt: "Zuerst schneiden wir das Gemüse, dann wiegen wir es, dann backen wir es."
• Fach-Helfer: Es gibt einen Helfer, der nur für das Schneiden zuständig ist (Quantenchemie), einen für das Backen (Molekulardynamik) und einen für das Servieren (Datenanalyse).
• Der Clou: Wenn Sie ein neues Rezept wollen, müssen Sie den Assistenten nicht neu lernen lassen. Sie holen sich einfach einen neuen Helfer, der das neue Rezept kann, und stecken ihn in das Team. Der Assistent bleibt derselbe.

3. Der Bote für die großen Küchen (DPDispatcher)

Oft müssen diese "Kochvorgänge" auf riesigen Supercomputern laufen, die wie riesige, fremde Industrieküchen sind (HPC-Umgebungen).

• Hier kommt DPDispatcher ins Spiel. Stellen Sie es sich wie einen Boten vor, der die Kochanweisungen vom Assistenten nimmt und sie in die Sprache der riesigen Industrieküchen übersetzt.
• Egal ob die Küche mit einem bestimmten Betriebssystem läuft oder eine andere Art von Ofen hat: Der Bote passt die Anweisung so an, dass sie dort funktioniert. Der Assistent muss sich nicht darum kümmern, wie die Ofen-Tür genau funktioniert; er gibt nur den Befehl "Backen" ab, und der Bote erledigt den Rest.

4. Was passiert, wenn etwas schiefgeht? (Fehlerbehebung)

In der alten Welt: Wenn beim Kochen etwas anbrennt, stürzt das ganze System oft ab oder der starre Koch weiß nicht weiter.

• In diesem neuen System: Wenn ein Schritt fehlschlägt (z. B. die Zutaten waren falsch gemischt), schaut der Assistent auf die Liste, prüft, was passiert ist, und versucht, es zu reparieren. Vielleicht probiert er es noch einmal mit anderen Parametern oder ruft den Planungs-Helfer hinzu, um die Anleitung zu korrigieren. Er gibt nicht sofort auf, sondern versucht, das Problem zu lösen, bevor er weitermacht.

Das Beispiel aus dem Papier: Methan-Oxidation

Um zu beweisen, dass das funktioniert, haben die Forscher eine komplexe chemische Reaktion simuliert (wie Methan verbrennt).

1. Sie gaben dem Assistenten einen einfachen Satz: "Simuliere die Oxidation von Methan."
2. Der Assistent rief den Planungs-Helfer, der daraus einen genauen Arbeitsplan machte.
3. Dann holte er sich die Fach-Helfer, um Moleküle zu bauen, sie zu optimieren und in eine Simulations-Software zu packen.
4. Der Bote (DPDispatcher) schickte die Aufgabe an einen Supercomputer.
5. Als die Simulation lief, überwachte der Assistent den Fortschritt.
6. Am Ende analysierte ein weiterer Helfer die Ergebnisse und zog die wichtigsten Schlussfolgerungen.

Warum ist das wichtig?

Früher musste man für jede neue wissenschaftliche Frage einen neuen, starren Roboter bauen. Jetzt haben wir ein flexibles System:

• Ein kluger Assistent, der den Überblick behält.
• Ein Werkzeugkasten aus spezialisierten Helfern, die man je nach Bedarf austauschen oder hinzufügen kann.
• Ein Bote, der die Verbindung zu den großen Computern herstellt.

Das macht die Wissenschaft schneller, weniger fehleranfällig und viel einfacher zu warten. Wenn ein neues Computerprogramm auf den Markt kommt, muss man nicht den ganzen Assistenten neu programmieren – man baut einfach einen neuen Helfer dafür. Das ist wie ein Lego-Set für wissenschaftliche Entdeckungen: Man kann die Bausteine immer wieder neu kombinieren, um neue Dinge zu erschaffen.

Technische Zusammenfassung

Problemstellung

Die Automatisierung von mehrstufigen Aufgaben in der computergestützten Chemie (Computational Chemistry) stellt nach wie vor eine große Herausforderung dar. Der Hauptengpass liegt nicht im Mangel an Rechenmethoden, sondern in der Schwierigkeit, heterogene Software-Tools, Datenrepräsentationen und Ausführungsumgebungen (insbesondere High-Performance Computing, HPC) zuverlässig zu koordinieren.
Bestehende Ansätze lassen sich in zwei getrennte Regime unterteilen:

1. Workflow-basierte Systeme (z. B. AiiDA, FireWorks): Diese bieten robuste Strukturen und Scheduler-Integration, sind jedoch stark auf vordefinierte Task-Graphen angewiesen. Sie stoßen an Grenzen, wenn Aufgaben kontextabhängige Entscheidungen erfordern, sich an neue Software anpassen müssen oder Laufzeitfehler auftreten, die eine dynamische Wiederherstellung erfordern.
2. Agenten-basierte Systeme (LLM-basiert): Diese bieten durch dynamisches Reasoning mehr Flexibilität, neigen jedoch dazu, Workflow-Strukturen, Wiederherstellungslogik und Domänenwissen direkt im Agenten-Stack zu verankern. Dies führt zu einer starken Kopplung („Engineering Entanglement"), die Wartung, Erweiterung und den Austausch von Modulen erschwert.

Das zentrale Problem ist also die enge Kopplung von Reasoning, Workflow-Spezifikation, Domänen-Execution und Infrastruktur, die eine unabhängige Weiterentwicklung verhindert.

Methodik und Architektur

Die Autoren schlagen einen entkoppelten Agenten-Skill-Ansatz vor, der auf dem Framework OpenClaw basiert. Das Designprinzip besteht darin, allgemeine Steuerungslogik von domänenspezifischen Ausführungsdetails zu trennen.

Die Architektur besteht aus vier Hauptkomponenten:

1. OpenClaw (General Agent): Dient als zentrale Steuerungs- und Überwachungseinheit. Es verwaltet den Kontext, führt Reasoning durch und orchestriert die Ausführung, ohne selbst tiefes chemisches Fachwissen zu kodieren.
2. Schema-definierte Planungsskills (Planning Skills): Diese Skills übersetzen wissenschaftliche Ziele (natürlichsprachliche Eingabe) in explizite, ausführbare Task-Spezifikationen (Workflows). Sie definieren Phasen, Abhängigkeiten, Eingaben, erwartete Ausgaben und Validierungsbedingungen. Dies ermöglicht ein „Lazy-Loading", bei dem nur der aktuelle Subtask in den Kontext geladen wird.
3. Domänen-Skills (Domain Skills): Diese kapseln spezifische computergestützte Chemie-Prozeduren (z. B. Quantenchemie, Molekulardynamik). Sie sind als wiederverwendbare Pakete mit Anweisungen, Templates und Validierungslogik aufgebaut.
   • Technische Umsetzung: Die Skills nutzen die uv-Toolchain, um isolierte, reproduzierbare Ausführungsumgebungen zu schaffen, die Abhängigkeitskonflikte minimieren und das Host-System sauber halten.
4. DPDispatcher Skill: Dieser Skill stellt die Schnittstelle zu heterogenen HPC-Umgebungen her. Er übersetzt die Absichten des Agenten in validierte Job-Skripte für verschiedene Scheduler (Slurm, PBS, LSF, lokale Shell) und verwaltet die gesamte Lebenszyklus-Steuerung (Einreichung, Monitoring, Fehlerbehandlung, Ergebnisabruf).

Der Ablauf:
Der Agent lädt Skills dynamisch basierend auf dem aktuellen Bedarf. Er analysiert den Zielzustand, den aktuellen Status und die verfügbaren Skills, trifft eine Entscheidung und führt die Aktion aus. Ergebnisse und Fehlermeldungen werden in den zentralen Kontrollschleife zurückgespeist, um den nächsten Schritt zu steuern. Ein autonomer Fehler-Wiederherstellungsmechanismus analysiert Logs bei Fehlern und versucht begrenzte Wiederherstellungsmaßnahmen (z. B. Parameterkorrektur, Neustart), bevor er bei Scheitern anhält.

Schlüsselbeiträge

• Entkoppeltes Design: Trennung von allgemeiner Koordination (OpenClaw) und domänenspezifischer Ausführung (Skills). Dies ermöglicht es, neue Fähigkeiten hinzuzufügen oder zu ersetzen, ohne den Agenten selbst neu zu designen.
• Open-Source Skill-Bibliothek: Veröffentlichung einer Bibliothek unter der LGPL-3.0-Lizenz (computational-chemistry-agent-skills), die Skills für Quantenchemie, Molekulardynamik, maschinelles Lernen (ML-Potenziale) und Datenverarbeitung bereitstellt.
• HPC-Integration: Nahtlose Integration von HPC-Schedulern durch den DPDispatcher-Skill, was die Komplexität der Job-Einreichung vom wissenschaftlichen Reasoning entkoppelt.
• Fehlertoleranz: Implementierung eines „bounded recovery"-Mechanismus, der Laufzeitfehler erkennt und begrenzte Wiederherstellungsversuche unternimmt, anstatt den gesamten Workflow abzubrechen.

Ergebnisse (Fallstudie: Methan-Oxidation)

Die Architektur wurde an einem komplexen Fallstudie zur reaktiven Molekulardynamik (MD) der Methan-Oxidation getestet.

• Aufgabe: Von einer natürlichen Spracheingabe ausgehend sollte das System eine vollständige Pipeline ausführen:
  1. Strukturvorbereitung (Open Babel).
  2. Geometrieoptimierung (B3LYP/6-31G(d,p)).
  3. Dateikonvertierung und Systemaufbau (Packmol, dpdata).
  4. Reaktive MD-Simulation (LAMMPS mit Deep Potential Modell, 1 ns bei 3000 K).
  5. Trajektorienanalyse und Extraktion von Reaktionswegen (ReacNetGenerator).
• Ergebnis: Das System führte den gesamten Workflow erfolgreich durch. Es konnte:
  • Mehrere Tools und Plattformen koordinieren.
  • Laufzeitfehler erkennen und durch automatische Wiederholungen oder Parameteranpassungen beheben.
  • Die Reaktionsnetzwerke aus den Simulationsergebnissen extrahieren.
  • Trotz der stochastischen Natur von LLMs (unterschiedliche Dialogverläufe) die Aufgaben konsistent abschließen.

Bedeutung und Ausblick

Dieses Papier zeigt einen vielversprechenden Weg zur praktischen Automatisierung in der computergestützten Chemie und Materialwissenschaft.

• Skalierbarkeit: Durch die Modularität können neue Softwarepakete einfach durch Hinzufügen von Skills integriert werden, ohne die Kernlogik zu berühren.
• Wartbarkeit: Die Trennung von Agent und Domänenwissen erleichtert die Wartung und die Anpassung an sich ändernde Softwareumgebungen.
• Zukunft: Die Autoren planen, das Skill-Ökosystem auf weitere Bereiche wie Hochdurchsatz-Screening und aktive Lernzyklen auszuweiten. Zudem wird die Integration mit Provenance-Tracking-Datenbanken und geschlossenen autonomen Schleifen als wichtiger nächster Schritt für die wissenschaftliche Entdeckung identifiziert.

Zusammenfassend bietet der vorgestellte Ansatz eine robuste, wiederverwendbare und überprüfbare Lösung für komplexe, mehrstufige wissenschaftliche Workflows, die über starre Skripte hinausgeht und die Flexibilität von KI-Agenten mit der Stabilität spezialisierter Domänen-Tools verbindet.