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, exec e process sã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.

O modo worker não inicia canais, superfícies HTTP do Gateway nem a inicialização automática de plugins além do conjunto de ferramentas da sessão atribuída. Ele usa um diretório de estado descartável e não possui credenciais permanentes de provedor nem de forge.

O despacho de sessões entre workers não é exposto neste modo. O posicionamento e o despacho permanecem sob responsabilidade do Gateway: um operador pode despachar pelo Gateway uma sessão local existente de árvore de trabalho gerenciada, enquanto um processo de worker não pode despachar a si próprio nem outro worker.

A atribuição preparada contém o contexto da transcrição, a folha-base aceita, a sequência de confirmação e o cursor de eventos em tempo real. Quando o túnel é reconectado, o processo é readmitido com a mesma credencial e época do proprietário, mantém a base aceita da transcrição, reproduz o trecho final de eventos em tempo real ainda não confirmado e se reconecta a um turno de inferência em andamento com a mesma identidade. A mensagem final da inferência é autoritativa caso deltas transmitidos não tenham sido recebidos. Uma época do proprietário substituta bloqueia o processo e causa uma saída limpa.

Uma rejeição de transcrição 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.