Skip to main content

​
openclaw worker

openclaw worker ist der eingeschränkte Laufzeit-Einstiegspunkt, den ein Cloud-Worker- Orchestrator innerhalb einer vorbereiteten Worker-Umgebung startet. Er ist kein Allzweckbefehl für die manuelle Worker-Registrierung. Das Gateway installiert das passende OpenClaw-Bundle und öffnet den per Hostschlüssel fixierten Reverse-SSH-Tunnel. Der Worker-Launcher startet diesen Befehl mit einer vorbereiteten Zuweisung. Der Befehl stellt die Verbindung über den durch den Tunnel weitergeleiteten lokalen Socket her und wird mit der dedizierten Rolle worker zugelassen.

​
Startvertrag

Der Befehl liest genau einen größenbeschränkten JSON-Start-Umschlag von der Standardeingabe. Der Umschlag enthält den Speicherort des lokalen Sockets, die ausgestellte Worker- Zugangsinformation, die Bundle- und Protokollidentität, die Owner-Epoche, die einzelne zugewiesene Sitzung und Ausführung sowie die exakten Namen der Worker-lokalen Tools, die für diese Ausführung autorisiert sind. Das Gateway ermittelt diesen endgültigen Toolsatz vor der Übergabe anhand der aktuellen Richtlinie; die Rohkonfiguration und die Identität des eingeplanten Owners gelangen niemals in den Worker-Umschlag. Die Zugangsinformation wird niemals über Befehlszeilenargumente akzeptiert, und diese Seite enthält absichtlich weder ein Beispiel für Zugangsinformationen noch für einen manuell erstellten Umschlag. Die Zulassung schlägt nach dem Fail-Closed-Prinzip fehl, wenn der Umschlag ungültig ist, die Zugangsinformation abgelehnt wird, die Bundle- oder Protokollfunktionen nicht übereinstimmen oder die Sitzung und die Owner-Epoche nicht mehr aktuell sind. Fehlende, doppelte oder unbekannte Toolnamen machen den Umschlag ebenfalls ungültig. Betreiber sollten Worker über den Cloud-Worker-Orchestrator starten, statt diesen Einstiegspunkt direkt aufzurufen.

​
Laufzeitgrenze

Der Prozess führt die normale eingebettete Agentenschleife mit einem eingeschränkten Backend aus:
  • Die Coding-Tools read, write, edit, apply_patch, exec und process werden lokal im Worker-Arbeitsbereich ausgeführt, wenn sie in der vom Gateway ausgestellten Ausführungsberechtigung enthalten sind. Bei einer leeren Berechtigung wird das Modell ohne Tools ausgeführt.
  • Modellaufrufe verwenden den Inferenz-Proxy des Gateways. Es wird kein lokales Modellauthentifizierungsprofil geladen.
  • Transkriptschreibvorgänge verwenden den RPC für Transkript-Commits des Gateways.
  • Streaming- und Tool-Lebenszyklusaktualisierungen verwenden den Live-Event-RPC des Gateways.
  • Nur die zugewiesene Sitzung und Ausführung werden akzeptiert.
Der Worker-Modus startet weder Kanäle noch Gateway-HTTP-Oberflächen oder den automatischen Plugin-Start über den zugewiesenen Sitzungstoolsatz hinaus. Er verwendet ein temporäres Zustandsverzeichnis und verfügt über keine dauerhaften Provider- oder Forge-Zugangsinformationen. Die Weiterleitung von Sitzungen zwischen Workern ist in diesem Modus nicht verfügbar. Platzierung und Weiterleitung bleiben Eigentum des Gateways: Ein Betreiber kann eine vorhandene lokale Sitzung mit verwaltetem Arbeitsbaum über das Gateway weiterleiten, während ein Worker-Prozess weder sich selbst noch einen anderen Worker weiterleiten kann. Die vorbereitete Zuweisung enthält den Transkriptkontext, das akzeptierte Basisblatt, die Commit-Sequenz und den Live-Event-Cursor. Bei einer erneuten Tunnelverbindung wird der Prozess mit derselben Zugangsinformation und Owner-Epoche erneut zugelassen, behält die akzeptierte Transkriptbasis bei, spielt das noch nicht bestätigte Ende seiner Live-Events erneut ab und bindet eine laufende Inferenzausführung mit derselben Identität wieder an. Die abschließende Inferenznachricht ist maßgeblich, falls gestreamte Deltas verpasst wurden. Eine ablösende Owner-Epoche grenzt den Prozess aus und bewirkt ein ordnungsgemäßes Beenden. Eine stale-base-leaf-Transkriptablehnung stoppt die aktuelle Ausführung endgültig. Der Worker-Modus versucht die abgelehnte Sequenz nicht erneut mit einem anderen Blatt, sodass kein doppelter Commit erzeugt wird; ein noch nicht committetes, im Arbeitsspeicher befindliches Ende dieser Ausführung geht verloren. Der Neustart liegt in der Verantwortung des Platzierungs-Owners von Meilenstein 3, der eine neue Zuweisung anhand des maßgeblichen Transkripts und Commit-Ledgers des Gateways erstellen muss. Ebenso beendet ein Neustart des Gateway-Prozesses eine ausstehende Inferenzausführung mit einem Providerfehler; nur die erneute Verbindung eines Tunnels oder Worker-WebSockets kann sich wieder an einen aktiven Inferenzstream desselben Prozesses anbinden. Weitere Informationen zur geschlossenen Worker-RPC-Oberfläche finden Sie unter Gateway-Protokoll und zum Architektur- und Sicherheitsmodell unter Plan für Cloud-Worker.