Pular para o conteúdo principal

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Faixas especializadas paralelas permitem que um Gateway roteie diferentes chats ou salas para agentes diferentes, mantendo a experiência do usuário rápida. O ponto-chave é tratar o paralelismo como um problema de design com recursos escassos, não apenas como “mais agentes”.

​
Princípios fundamentais

Uma faixa especializada só melhora a vazão quando reduz a contenção pelos gargalos reais:
  • Bloqueios de sessão: apenas uma execução deve modificar uma determinada sessão por vez.
  • Capacidade global do modelo: todas as execuções de chat visíveis ainda compartilham os limites do provedor.
  • Capacidade de ferramentas: shell, navegador, rede e trabalho em repositório podem ser mais lentos do que a própria rodada do modelo.
  • Orçamento de contexto: transcrições longas tornam cada rodada futura mais lenta e menos focada.
  • Ambiguidade de propriedade: agentes duplicados fazendo o mesmo trabalho desperdiçam capacidade.
O OpenClaw já serializa execuções por sessão e limita o paralelismo global por meio da fila de comandos. Faixas especializadas adicionam uma política por cima: qual agente é dono de qual trabalho, o que permanece no chat e o que se torna trabalho em segundo plano.

​
Implantação recomendada

​
Fase 1: contratos de faixa + trabalho pesado em segundo plano

Dê a cada faixa um contrato escrito em seu workspace e prompt de sistema:
  • Propósito: o trabalho que esta faixa possui.
  • Não objetivos: trabalho que ela deve repassar em vez de tentar executar.
  • Orçamento de chat: respostas rápidas permanecem no chat; tarefas longas devem reconhecer brevemente, depois executar em um subagente ou tarefa em segundo plano.
  • Regra de repasse: quando outra faixa possui o trabalho, diga para onde ele deve ir e forneça um resumo compacto de repasse.
  • Regra de risco de ferramenta: prefira a menor superfície de ferramenta capaz de fazer o trabalho.
Esta é a fase mais barata e corrige a maior parte dos congestionamentos: um trabalho de programação não transforma mais a faixa de pesquisa em melaço, e cada chat mantém seu próprio contexto limpo.

​
Fase 2: controles de prioridade e concorrência

Ajuste a capacidade da fila e do modelo em torno do valor de negócio de cada faixa: 
{
  agents: {
    defaults: {
      maxConcurrent: 4,
      subagents: { maxConcurrent: 8 },
    },
  },
  messages: {
    queue: {
      mode: "collect",
      debounceMs: 1000,
      cap: 20,
      drop: "summarize",
    },
  },
}
Use chats diretos/pessoais e agentes de operações de produção para trabalho de alta prioridade. Deixe pesquisa, redação e programação em lote passarem para tarefas em segundo plano quando o sistema estiver ocupado.

​
Fase 3: coordenador / controlador de tráfego

Adicione um pequeno padrão de coordenador quando várias faixas estiverem ativas:
  • Rastreie tarefas e proprietários ativos por faixa.
  • Detecte solicitações duplicadas entre grupos.
  • Roteie resumos de repasse entre faixas.
  • Exponha apenas bloqueadores, resultados concluídos e decisões que o humano precisa tomar.
Não comece por aqui. Um coordenador sem contratos de faixa apenas coordena o caos.

​
Modelo mínimo de contrato de faixa

# Lane contract

## Owns

- <job this lane is responsible for>

## Does not own

- <work to hand off>

## Chat budget

- Answer quick questions directly.
- For multi-step, slow, or tool-heavy work: acknowledge briefly, spawn/background
  the work, then return the result when complete.

## Handoff

If another lane owns the request, reply with:

- target lane
- objective
- relevant context
- exact next action

## Tool posture

Use the smallest tool surface that can complete the task. Avoid broad shell or
network work unless this lane explicitly owns it.

​
Relacionado