Przejdź do głównej treści

​
openclaw worker

openclaw worker jest punktem wejścia ograniczonego środowiska uruchomieniowego, przeznaczonym do uruchamiania przez orkiestrator pracowników chmurowych w przygotowanym środowisku pracownika. Nie jest to polecenie ogólnego przeznaczenia do ręcznej rejestracji pracowników. Gateway instaluje pasujący pakiet OpenClaw i otwiera odwrotny tunel SSH z przypiętym kluczem hosta. Program uruchamiający pracownika uruchamia to polecenie z przygotowanym przydziałem. Polecenie łączy się przez lokalne gniazdo przekierowane w tunelu i uzyskuje dostęp w dedykowanej roli worker.

​
Kontrakt uruchomienia

Polecenie odczytuje ze standardowego wejścia dokładnie jedną ograniczoną kopertę uruchomieniową JSON. Koperta zawiera lokalizację lokalnego gniazda, wygenerowane poświadczenie pracownika, tożsamość pakietu i protokołu, epokę właściciela oraz pojedynczą przypisaną sesję i turę. Poświadczenie nigdy nie jest przyjmowane za pośrednictwem argumentów wiersza poleceń, a ta strona celowo nie zawiera przykładu poświadczenia ani ręcznie utworzonej koperty. Dopuszczenie kończy się bezpieczną odmową, jeśli koperta jest nieprawidłowa, poświadczenie zostanie odrzucone, funkcje pakietu lub protokołu nie są zgodne albo sesja i epoka właściciela nie są już aktualne. Operatorzy powinni uruchamiać pracowników za pośrednictwem orkiestratora pracowników chmurowych, zamiast bezpośrednio wywoływać ten punkt wejścia.

​
Granica środowiska uruchomieniowego

Proces uruchamia standardową osadzoną pętlę agenta z ograniczonym backendem:
  • Narzędzia programistyczne read, write, edit, apply_patch, exec i process działają lokalnie w przestrzeni roboczej pracownika.
  • Wywołania modelu korzystają z proxy wnioskowania Gateway. Lokalny profil uwierzytelniania modelu nie jest wczytywany.
  • Zapisy transkrypcji korzystają z RPC zatwierdzania transkrypcji Gateway.
  • Aktualizacje strumieniowania i cyklu życia narzędzi korzystają z RPC zdarzeń na żywo Gateway.
  • Akceptowane są tylko przypisana sesja i tura.
Tryb pracownika nie uruchamia kanałów, interfejsów HTTP Gateway ani automatycznego uruchamiania pluginów poza zestawem narzędzi przypisanej sesji. Korzysta z jednorazowego katalogu stanu i nie ma stałych poświadczeń dostawcy ani platformy forge. W tym trybie wysyłanie sesji między pracownikami nie jest udostępniane. Rozmieszczanie i wysyłanie pozostają zarządzane przez Gateway: operator może wysłać istniejącą lokalną sesję zarządzanego drzewa roboczego za pośrednictwem Gateway, natomiast proces pracownika nie może wysłać sam siebie ani innego pracownika. Przygotowany przydział zawiera kontekst transkrypcji, zaakceptowany liść bazowy, sekwencję zatwierdzeń i kursor zdarzeń na żywo. Po ponownym połączeniu tunelu proces ponownie uzyskuje dostęp przy użyciu tego samego poświadczenia i tej samej epoki właściciela, zachowuje zaakceptowaną bazę transkrypcji, odtwarza niepotwierdzoną końcówkę zdarzeń na żywo i ponownie dołącza trwającą turę wnioskowania z tą samą tożsamością. Końcowy komunikat wnioskowania jest miarodajny, jeśli pominięto strumieniowane delty. Nadrzędna epoka właściciela odcina proces i powoduje jego prawidłowe zakończenie. Odrzucenie transkrypcji stale-base-leaf natychmiast zatrzymuje bieżące uruchomienie. Tryb pracownika nie ponawia odrzuconej sekwencji względem innego liścia, więc nie powstaje zduplikowane zatwierdzenie; niezatwierdzona końcówka przechowywana w pamięci z tego uruchomienia zostaje utracona. Ponowne uruchomienie należy do właściciela rozmieszczania etapu 3, który musi utworzyć nowy przydział na podstawie miarodajnej transkrypcji Gateway i rejestru zatwierdzeń. Analogicznie ponowne uruchomienie procesu Gateway kończy oczekującą turę wnioskowania błędem dostawcy; tylko ponowne połączenie tunelu lub połączenia WebSocket pracownika może ponownie dołączyć do aktywnego strumienia wnioskowania tego samego procesu. Zobacz Protokół Gateway, aby poznać zamknięty interfejs RPC pracownika, oraz Plan pracowników chmurowych, aby poznać architekturę i model zabezpieczeń.