Najlepsza zalecana konfiguracja
Dla większości użytkowników najprostsza konfiguracja bota ratunkowego to:- pozostawienie głównego bota na profilu domyślnym
- uruchomienie bota ratunkowego na
--profile rescue - użycie całkowicie osobnego bota Telegram dla konta ratunkowego
- utrzymywanie bota ratunkowego na innym porcie bazowym, takim jak
19789
Szybki start bota ratunkowego
Użyj tego jako domyślnej ścieżki, chyba że masz ważny powód, aby zrobić coś innego:openclaw --profile rescue onboard:
- użyj osobnego tokenu bota Telegram
- zachowaj profil
rescue - użyj portu bazowego co najmniej o 20 wyższego niż główny bot
- zaakceptuj domyślny roboczy obszar ratunkowy, chyba że już zarządzasz własnym
gateway install nie jest potrzebne.
Dlaczego to działa
Bot ratunkowy pozostaje niezależny, ponieważ ma własne:- profil/konfigurację
- katalog stanu
- obszar roboczy
- port bazowy (plus porty pochodne)
- token bota Telegram
- łatwo utrzymać go wyłącznie dla operatorów
- osobny token i tożsamość bota
- niezależność od instalacji kanału/aplikacji głównego bota
- prosta ścieżka odzyskiwania oparta na wiadomościach DM, gdy główny bot jest uszkodzony
Co zmienia --profile rescue onboard
openclaw --profile rescue onboard używa normalnego przepływu onboardingu, ale
zapisuje wszystko w osobnym profilu.
W praktyce oznacza to, że bot ratunkowy otrzymuje własne:
- plik konfiguracyjny
- katalog stanu
- obszar roboczy (domyślnie
~/.openclaw/workspace-rescue) - nazwę zarządzanej usługi
Ogólna konfiguracja wielu Gateway
Powyższy układ bota ratunkowego jest najłatwiejszą opcją domyślną, ale ten sam wzorzec izolacji działa dla dowolnej pary lub grupy Gateway na jednym hoście. W bardziej ogólnej konfiguracji nadaj każdemu dodatkowemu Gateway własny nazwany profil oraz własny port bazowy:Lista kontrolna izolacji
Zachowaj unikalność tych elementów dla każdej instancji Gateway:OPENCLAW_CONFIG_PATH— plik konfiguracyjny danej instancjiOPENCLAW_STATE_DIR— sesje, poświadczenia, pamięci podręczne danej instancjiagents.defaults.workspace— katalog główny obszaru roboczego danej instancjigateway.port(lub--port) — unikalny dla każdej instancji- pochodne porty przeglądarki/canvas/CDP
Mapowanie portów (pochodne)
Port bazowy =gateway.port (lub OPENCLAW_GATEWAY_PORT / --port).
- port usługi sterowania przeglądarką = bazowy + 2 (tylko local loopback)
- host canvas jest serwowany na serwerze HTTP Gateway (ten sam port co
gateway.port) - porty CDP profilu przeglądarki są automatycznie przydzielane z zakresu
browser.controlPort + 9 .. + 108
Uwagi o przeglądarce/CDP (częsta pułapka)
- Nie ustawiaj
browser.cdpUrlna te same wartości w wielu instancjach. - Każda instancja potrzebuje własnego portu sterowania przeglądarką i zakresu CDP (pochodnego od jej portu gateway).
- Jeśli potrzebujesz jawnych portów CDP, ustaw
browser.profiles.<name>.cdpPortdla każdej instancji. - Zdalny Chrome: użyj
browser.profiles.<name>.cdpUrl(dla profilu, dla instancji).
Ręczny przykład zmiennych środowiskowych
Szybkie kontrole
gateway status --deeppomaga wykryć przestarzałe usługi launchd/systemd/schtasks ze starszych instalacji.- Tekst ostrzeżenia
gateway probe, taki jakmultiple reachable gateway identities detected, jest oczekiwany tylko wtedy, gdy celowo uruchamiasz więcej niż jeden odizolowany gateway, albo gdy OpenClaw nie może udowodnić, że osiągalne cele sondowania są tym samym gateway. Tunel SSH, adres URL proxy lub skonfigurowany zdalny adres URL do tego samego gateway to jeden gateway z wieloma transportami, nawet jeśli porty transportu się różnią.