Lobster: typisierte, lokale Workflows für OpenClaw
Lobster ist eine Openclaw-native Workflow-Shell: eine typisierte, lokal ausgerichtete Makro-Engine, die Fähigkeiten/Tools in zusammensetzbare Pipelines und sichere Automatisierungen umwandelt – und Openclaw ermöglicht, diese Workflows in einem Schritt aufzurufen.
Auf einen Blick
- Was ist das?
- Lobster ist eine OpenClaw-native Workflow-Shell, die Fähigkeiten und Werkzeuge in typisierte Pipelines, Jobs und Genehmigungsstufen umwandelt.
- Für wen ist es gedacht?
- Lobster ist unter der MIT-Lizenz veröffentlicht, und der nächste Schritt im README ist die Bereitstellung als optionales OpenClaw-Plugin-Werkzeug. Bei openclaw/lobster zählt dabei der dokumentierte Funktionsumfang, nicht eine Annahme über fehlende Angaben.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Typisierte Pipelines und Workflow-Dateien
Lobster ist eine OpenClaw-native Workflow-Shell. Es definiert Workflows als typisierte Pipelines, die mit JSON statt Textströmen arbeiten, und umfasst Jobs und Genehmigungsstufen. Ein Agent wie OpenClaw kann einen Lobster-Workflow in einem einzigen Schritt aufrufen, was laut README Tokens spart und die Determiniertheit und Fortsetzbarkeit verbessert, verglichen mit der Neuplanung jedes Schritts. Das README zeigt zwei Beispielaufrufe eines github.pr.monitor-Workflows, einen mit unverändertem PR und einen mit gemergtem PR; beide liefern strukturiertes JSON mit einem prSnapshot und einer Zusammenfassung geänderter Felder.
Für openclaw/lobster gehört zu diesem Abschnitt ein eigener Prüfschritt: Im isolierten Testlauf sind bei lobster die hier genannten Befehle, Dateien oder Konfigurationsschlüssel sowie die dokumentierten Eingaben und Ausgaben zu protokollieren. Die Plattformvoraussetzungen aus dem README müssen dabei erfüllt sein; nicht beschriebene Eigenschaften gelten für openclaw/lobster nicht als Zusage. Abschnitt 1 wird getrennt bewertet, damit seine konkrete Aussage überprüfbar bleibt.
Designziele
Das README nennt vier Ziele. Pipelines sollen typisiert sein, also Objekte und Arrays statt Text-Pipes verwenden. Die Ausführung soll lokal erfolgen. Lobster soll keine neue Authentifizierungsoberfläche einführen und darf keine OAuth-Tokens oder ähnliche Anmeldedaten besitzen. Und Workflows sollen komponierbare Makros sein, die OpenClaw oder jeder Agent in einem Schritt aufrufen kann, um Tokens zu sparen. Diese Ziele erklären, warum sich das Projekt als Workflow-Shell und nicht als Dienst beschreibt.
Für openclaw/lobster gehört zu diesem Abschnitt ein eigener Prüfschritt: Im isolierten Testlauf sind bei lobster die hier genannten Befehle, Dateien oder Konfigurationsschlüssel sowie die dokumentierten Eingaben und Ausgaben zu protokollieren. Die Plattformvoraussetzungen aus dem README müssen dabei erfüllt sein; nicht beschriebene Eigenschaften gelten für openclaw/lobster nicht als Zusage. Abschnitt 2 wird getrennt bewertet, damit seine konkrete Aussage überprüfbar bleibt.
Schnellstart-Befehle
Der Schnellstart-Abschnitt listet pnpm install, pnpm test, pnpm lint, node ./bin/lobster.js --help, node ./bin/lobster.js doctor und einen Beispielbefehl, der JSON durch exec, where und json leitet. Der Testbefehl führt zuerst tsc aus und führt dann Tests gegen dist/ aus; bin/lobster.js bevorzugt den kompilierten Einstiegspunkt in dist/, wenn er vorhanden ist. Das README listet keinen npm-Installationsbefehl auf, daher bleibt die Paketinstallation außerhalb von pnpm zu verifizieren.
Für openclaw/lobster gehört zu diesem Abschnitt ein eigener Prüfschritt: Im isolierten Testlauf sind bei lobster die hier genannten Befehle, Dateien oder Konfigurationsschlüssel sowie die dokumentierten Eingaben und Ausgaben zu protokollieren. Die Plattformvoraussetzungen aus dem README müssen dabei erfüllt sein; nicht beschriebene Eigenschaften gelten für openclaw/lobster nicht als Zusage. Abschnitt 3 wird getrennt bewertet, damit seine konkrete Aussage überprüfbar bleibt.
Struktur von Workflow-Dateien
Lobster-Workflow-Dateien lesen sich wie kleine Skripte. Eine Datei kann run- oder command-Schritte für Shell- und CLI-Arbeit enthalten, pipeline-Schritte für native Lobster-Stufen wie llm.invoke, approval-Schritte als harte Gates zwischen Schritten und stdin-Einträge wie $step.stdout oder $step.json, um Daten weiterzugeben. Das README merkt an, dass run und command äquivalent sind, wobei run für neue Dateien bevorzugt wird, und dass pipeline-Schritte dasselbe args-, env- und results-Modell wie Shell-Schritte verwenden. Der Beispiel-Workflow jacket-advice nutzt einen Wetterbefehl, einen Genehmigungsschritt und einen llm.invoke-Pipeline-Schritt, wobei eine when-Bedingung an das Genehmigungsergebnis gekoppelt ist.
Für openclaw/lobster gehört zu diesem Abschnitt ein eigener Prüfschritt: Im isolierten Testlauf sind bei lobster die hier genannten Befehle, Dateien oder Konfigurationsschlüssel sowie die dokumentierten Eingaben und Ausgaben zu protokollieren. Die Plattformvoraussetzungen aus dem README müssen dabei erfüllt sein; nicht beschriebene Eigenschaften gelten für openclaw/lobster nicht als Zusage. Abschnitt 4 wird getrennt bewertet, damit seine konkrete Aussage überprüfbar bleibt.
Identitätsbeschränkungen bei Genehmigungen
Genehmigungsschritte können Identitätsbeschränkungen durchsetzen. Die Workflow-Datei unterstützt required_approver (oder requiredApprover), um eine exakte Genehmiger-ID zu verlangen, require_different_approver (oder requireDifferentApprover), um zu verlangen, dass der Genehmiger sich vom Initiator unterscheidet, und initiated_by (oder initiatedBy), um die Initiator-ID festzulegen. Zur Laufzeit kann LOBSTER_APPROVAL_INITIATED_BY eine Standard-Initiator-ID bereitstellen, und LOBSTER_APPROVAL_APPROVED_BY wird bei Fortsetzung oder Genehmigung für Identitätsprüfungen verwendet. Das README beschreibt nicht, wie diese Werte validiert werden, sondern nur, dass sie für Prüfungen verwendet werden.
Für openclaw/lobster gehört zu diesem Abschnitt ein eigener Prüfschritt: Im isolierten Testlauf sind bei lobster die hier genannten Befehle, Dateien oder Konfigurationsschlüssel sowie die dokumentierten Eingaben und Ausgaben zu protokollieren. Die Plattformvoraussetzungen aus dem README müssen dabei erfüllt sein; nicht beschriebene Eigenschaften gelten für openclaw/lobster nicht als Zusage. Abschnitt 5 wird getrennt bewertet, damit seine konkrete Aussage überprüfbar bleibt.
Angehaltene Eingabeanforderungen und Fortsetzung
Pipeline-Befehle können ctx.requestInput mit prompt, responseSchema, defaults, subject und suspendedState aufrufen, um im Werkzeugmodus, in Workflows oder im SDK anzuhalten und denselben Befehl nach einer strukturierten Antwort fortzusetzen. CLI- und Werkzeug-Fortsetzungstoken speichern nur einen Zustandsschlüssel, und der persistierte Zustand validiert die Metadaten der angehaltenen Anforderung, bevor die übermittelte Antwort zurückgegeben wird. SDK-Fortsetzungen desselben Befehls speichern den Befehlsrahmen im konfigurierten SDK-Zustandsverzeichnis. Befehle werden bei der Fortsetzung erneut ausgeführt, müssen also bis zur Rückkehr von requestInput idempotent sein. Array-gestützte Befehlseingaben werden mit Grenzen für die Wiedergabe gespeichert; verzögerte Stream-Eingaben werden nicht gepuffert und erfordern einen kompakten JSON-suspendedState, der vom Befehl bereitgestellt wird.
Für openclaw/lobster gehört zu diesem Abschnitt ein eigener Prüfschritt: Im isolierten Testlauf sind bei lobster die hier genannten Befehle, Dateien oder Konfigurationsschlüssel sowie die dokumentierten Eingaben und Ausgaben zu protokollieren. Die Plattformvoraussetzungen aus dem README müssen dabei erfüllt sein; nicht beschriebene Eigenschaften gelten für openclaw/lobster nicht als Zusage. Abschnitt 6 wird getrennt bewertet, damit seine konkrete Aussage überprüfbar bleibt.
Workflows visualisieren
Der Befehl lobster graph prüft die Workflow-Struktur vor der Ausführung. Er akzeptiert --file und optional --format mit den Werten mermaid (Standard), dot und ascii sowie --args-json. Die Visualisierung umfasst jeden Schritt als Knoten, Datenfluss-Kanten aus stdin-Referenzen, bedingte Abhängigkeiten aus when- oder condition-Ausdrücken und Genehmigungsstufen als Rauten-Knoten in der mermaid- und dot-Ausgabe. Das README merkt an, dass mermaid flowchart-TD-Text für GitHub- oder Markdown-Rendering ausgibt, dot Graphviz-DOT ausgibt und ascii eine terminalfreundliche Knoten- und Kantenliste ausgibt.
Für openclaw/lobster gehört zu diesem Abschnitt ein eigener Prüfschritt: Im isolierten Testlauf sind bei lobster die hier genannten Befehle, Dateien oder Konfigurationsschlüssel sowie die dokumentierten Eingaben und Ausgaben zu protokollieren. Die Plattformvoraussetzungen aus dem README müssen dabei erfüllt sein; nicht beschriebene Eigenschaften gelten für openclaw/lobster nicht als Zusage. Abschnitt 7 wird getrennt bewertet, damit seine konkrete Aussage überprüfbar bleibt.
LLM-Aufrufe und Anbieter
Native pipeline-Schritte können llm.invoke mit einem Prompt und optionalem --provider aufrufen. Die Anbieterauflösung erfolgt in der Reihenfolge --provider, dann LOBSTER_LLM_PROVIDER, dann automatische Erkennung aus der Umgebung. Integrierte Anbieter sind openclaw über OPENCLAW_URL und OPENCLAW_TOKEN, pi über LOBSTER_PI_LLM_ADAPTER_URL und http über LOBSTER_LLM_ADAPTER_URL. Die Workflow-Felder _meta.cost und cost_limit verwenden eine statische Preistabelle mit optionalen Überschreibungen aus LOBSTER_LLM_PRICING_JSON; unbekannte Modell-IDs zeichnen Token-Zahlen mit null geschätzten Kosten auf, und Lobster warnt auf stderr. Das README dokumentiert außerdem openclaw.agent für den Aufruf konfigurierter OpenClaw-Agenten, delegiert an die installierte openclaw-agent-CLI, und stellt fest, dass llm_task.invoke ein abwärtskompatibler Alias für den OpenClaw-Anbieter bleibt.
Für openclaw/lobster gehört zu diesem Abschnitt ein eigener Prüfschritt: Im isolierten Testlauf sind bei lobster die hier genannten Befehle, Dateien oder Konfigurationsschlüssel sowie die dokumentierten Eingaben und Ausgaben zu protokollieren. Die Plattformvoraussetzungen aus dem README müssen dabei erfüllt sein; nicht beschriebene Eigenschaften gelten für openclaw/lobster nicht als Zusage. Abschnitt 8 wird getrennt bewertet, damit seine konkrete Aussage überprüfbar bleibt.
Redaktionelles Fazit
Lobster ist unter der MIT-Lizenz veröffentlicht, und der nächste Schritt im README ist die Bereitstellung als optionales OpenClaw-Plugin-Werkzeug. Bei openclaw/lobster zählt dabei der dokumentierte Funktionsumfang, nicht eine Annahme über fehlende Angaben.
Community-Notizen