openclaw worker
openclaw worker é o ponto de entrada de runtime restrito que um orquestrador
de workers em nuvem inicia dentro de um ambiente de worker preparado. Ele não é
um comando de uso geral para o registro manual de workers.
O Gateway instala o pacote correspondente do OpenClaw e abre o túnel SSH reverso
com chave do host fixada. O inicializador de workers inicia este comando com uma
atribuição preparada. O comando se conecta pelo soquete local encaminhado pelo
túnel e é admitido com a função dedicada worker.
Contrato de inicialização
O comando lê exatamente um envelope JSON de inicialização com tamanho limitado da entrada padrão. O envelope contém a localização do soquete local, a credencial de worker emitida, as identidades do pacote e do protocolo, a época do proprietário e a única sessão e turno atribuídos. A credencial nunca é aceita por argumentos de linha de comando, e esta página intencionalmente não fornece exemplos de credencial nem de envelope criado manualmente. A admissão falha de forma fechada se o envelope for inválido, a credencial for rejeitada, os recursos do pacote ou do protocolo não corresponderem ou a sessão e a época do proprietário não forem mais atuais. Os operadores devem iniciar os workers pelo orquestrador de workers em nuvem, em vez de invocar este ponto de entrada diretamente.Limite do runtime
O processo executa o loop normal do agente incorporado com um backend restrito:- As ferramentas de programação
read,write,edit,apply_patch,execeprocesssão executadas localmente no espaço de trabalho do worker. - As chamadas ao modelo usam o proxy de inferência do Gateway. Nenhum perfil local de autenticação do modelo é carregado.
- As gravações da transcrição usam a RPC de confirmação de transcrição do Gateway.
- As atualizações de streaming e do ciclo de vida das ferramentas usam a RPC de eventos em tempo real do Gateway.
- Somente a sessão e o turno atribuídos são aceitos.
stale-base-leaf interrompe de forma definitiva a
execução atual. O modo worker não tenta novamente a sequência rejeitada em uma
folha diferente, portanto nenhuma confirmação duplicada é produzida; qualquer
trecho final ainda não confirmado e mantido na memória dessa execução é perdido.
A reinicialização pertence ao proprietário do posicionamento do marco 3, que
deve criar uma nova atribuição a partir da transcrição autoritativa e do registro
de confirmações do Gateway. Da mesma forma, uma reinicialização do processo do
Gateway encerra um turno de inferência pendente com um erro do provedor; somente
uma reconexão do túnel ou do WebSocket do worker pode se reconectar a um fluxo de
inferência ativo no mesmo processo.
Consulte Protocolo do Gateway
para conhecer a superfície RPC fechada do worker e o Plano de workers em
nuvem para conhecer a arquitetura e o modelo de segurança.