Guia completo de roteamento multiagente no OpenClaw: separe trabalho, vida pessoal e testes

Numa segunda-feira, às nove da manhã, abri meu assistente de IA para escrever um trecho de integração de pagamento para um cliente. De repente, ele respondeu: “Com base na estratégia que você pesquisou ontem à noite para derrotar um chefe de Elden Ring, sugiro adotar aqui uma abordagem parecida de ‘atacar e esquivar’…”

Fiquei paralisado.

Para piorar, a conversa estava aberta durante uma reunião com compartilhamento de tela do cliente. Dava para sentir o silêncio constrangedor do outro lado da chamada.

Naquele momento, percebi que os assistentes de IA estavam cada vez mais inteligentes, mas misturavam meu trabalho, meu lazer e meus testes. Era como uma gaveta sem divisórias, com tudo jogado junto: você demora para encontrar qualquer coisa e ainda pega o item errado com frequência.

Se você também sente isso, este artigo pode ajudar. Passei um fim de semana estudando o roteamento multiagente do OpenClaw e descobri que ele permite dividir o assistente de IA em vários auxiliares especializados: trabalho fica com trabalho, vida pessoal fica separada e testes ficam confinados em uma sandbox.

A seguir, explico por que esse recurso é necessário, como configurá-lo e quais são os cinco cenários que uso na prática.

Guia econômico para criar seu próprio “camarão”: o ArkClaw torna os AI Agents acessíveis de verdade

O OpenClaw, o “lagostim” que está em alta, é útil, mas sua configuração pode afastar muita gente. O ArkClaw, da Volcengine, da ByteDance, derruba essa barreira. Sem precisar lidar com servidores nem configurar tokens, você obtém com um clique um “funcionário de IA” disponível 24 horas por dia, capaz de controlar o navegador, executar scripts e gerenciar o calendário.

E o preço realmente chama atenção: a mensalidade é de apenas 9,9 yuans. Com meu código de convite ZLKUK54M, cadastre-se aqui e pague somente 8,9 yuans. Se você é programador, pode assinar diretamente o Coding Plan Pro e usar o serviço de graça.

Por que um assistente de IA mistura os contextos?

Três situações constrangedoras causadas por um único assistente

Para ser sincero, eu usava um único assistente de IA para tudo, até passar por estas situações:

Cenário 1: contaminação de contexto
Você pede à IA para otimizar uma consulta ao banco de dados da empresa e ela comenta: “É parecido com aquele crawler em Python que você me perguntou na semana passada; dá para usar o mesmo tipo de processamento assíncrono…” O problema é que aquele crawler pertence a um projeto paralelo pessoal que você não quer revelar à empresa.

Cenário 2: vazamento de privacidade
Durante a demonstração de uma ferramenta nova para a equipe, você abre o histórico de conversas da IA para mostrar uma função, mas a lista está cheia de perguntas pessoais como “Como pedir aumento ao chefe?” e “Preciso declarar a renda do meu trabalho paralelo?”. Quem já passou por isso conhece o tamanho do constrangimento.

Cenário 3: um teste destrói o ambiente de produção
Certa vez, eu estava testando um script de automação e pedi à IA que renomeasse vários arquivos. Ela se lembrou do diretório de um projeto profissional anterior e alterou os nomes de todos os arquivos-fonte do projeto de um cliente. Ainda bem que eu tinha Git; sem ele, talvez eu precisasse desaparecer.

Por que isso acontece?

Na verdade, o assistente de IA não está errado. Ele apenas é “fiel” demais: lembra de tudo o que você diz e tenta conectar todo o contexto. O problema é que:

• O trabalho exige rigor e proteção de privacidade
• A vida pessoal pede leveza e recomendações personalizadas
• Os testes precisam de liberdade, mas não podem afetar o ambiente oficial

Essas três coisas nunca deveriam ficar misturadas.

Como o roteamento multiagente resolve o problema

Na prática, o roteamento multiagente do OpenClaw cria uma “sala” independente para cada cenário:

• Espaço de trabalho independente: o work-agent vê apenas o diretório /work, enquanto o personal-agent acessa apenas /personal, com isolamento físico no nível do sistema de arquivos
• Histórico de conversa independente: tudo o que você conversa no work-agent é completamente desconhecido pelo personal-agent, e vice-versa
• Permissões independentes: a sandbox de testes pode ficar sem internet e com o sistema de arquivos em modo somente leitura; o ambiente de trabalho pode acessar o Git da empresa; e o ambiente pessoal pode se conectar ao armazenamento pessoal em nuvem

No vocabulário do Docker, isso se chama “isolamento no nível de contêiner”. Em termos simples, é como instalar vários cérebros independentes no assistente de IA, sem interferência entre eles.

Os padrões de segurança de IA de 2026 já exigem que sistemas empresariais adotem isolamento rigoroso de dados no nível do tenant. A solução de sandbox com Docker usada pelo OpenClaw oferece muito mais segurança do que ferramentas que apenas separam as conversas em grupos.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

A arquitetura de isolamento em três camadas do OpenClaw

Quando li a documentação do OpenClaw pela primeira vez, fiquei confuso com termos como Gateway, Brain e Skills. Depois de configurar tudo sozinho, percebi que o conceito é bastante simples.

As três camadas funcionam como um sistema de entregas

• Camada Gateway (ponto de recebimento e envio): recebe mensagens de plataformas como Telegram, Discord e Slack e, de acordo com a configuração, decide para qual agent encaminhar cada mensagem
• Camada Brain (central de coordenação): interpreta a mensagem para identificar sua intenção — escrever código, pesquisar informações ou executar um comando — e então organiza o fluxo da tarefa
• Camada Skills (centro de execução): é onde o trabalho acontece de verdade; cada agent tem seu próprio contêiner Docker para executar código e operar arquivos

Você pode escolher entre três níveis de isolamento

O projeto é flexível e permite escolher de acordo com sua necessidade:

Isolamento no nível de Session (tarefas temporárias)
Cada conversa abre um novo contêiner, que é destruído ao final. É adequado para tarefas pontuais, como “analise este arquivo CSV”. A vantagem é começar sempre com um ambiente limpo; a desvantagem é ter que recriá-lo na próxima conversa.

Isolamento no nível de Agent (cenários contínuos)
Cada agent mantém um contêiner ativo por longo prazo. Meus work-agent e personal-agent funcionam assim: depois de configurar o ambiente, eles ficam disponíveis a qualquer momento. É o modo que mais uso.

Isolamento no nível de usuário do sistema operacional (segurança máxima)
Agents diferentes são executados por usuários diferentes do sistema, portanto a separação já acontece no nível do sistema operacional. Sinceramente, nunca precisei chegar a esse nível, mas ele é uma escolha mais segura para dados altamente sensíveis, como informações financeiras ou médicas.

Fiz um teste: com o isolamento no nível de Agent, o agent-B não consegue acessar de nenhuma forma um arquivo criado no agent-A, a menos que você configure deliberadamente um diretório compartilhado. Essa segurança traz bastante tranquilidade.

Cinco cenários práticos que uso

Esta é a parte mais prática. Vou compartilhar as configurações que uso para que você possa adotá-las como referência.

Cenário 1: ambientes separados para trabalho e vida pessoal

Meu problema: o código dos projetos da empresa vivia se misturando com o do meu blog pessoal. Certa vez, ao fazer um commit, quase enviei código da empresa para meu GitHub pessoal.

Solução:

• work-agent: o diretório de trabalho aponta para D:\work, usa a chave SSH do GitLab da empresa e acessa apenas as chaves de API relacionadas ao trabalho
• personal-agent: o diretório de trabalho aponta para D:\personal, usa minha conta pessoal do GitHub e me deixa experimentar à vontade

Pontos principais da configuração:
Os dois agents usam arquivos .env diferentes, e o parâmetro WORKSPACE_PATH aponta para diretórios distintos. Outra dica: criei dois bots no Telegram, @my_work_bot e @my_personal_bot, para saber imediatamente com qual assistente estou falando.

Cenário 2: isolamento entre projetos de vários clientes

Meu problema: como freelancer, eu atendia três clientes ao mesmo tempo. Certa vez, uma sugestão de código da IA para o cliente A usou o padrão de nomes de variáveis do projeto do cliente B. Nada aconteceu, mas fiquei bastante preocupado.

Solução:
Três agents: client-nike-agent, client-adidas-agent e client-puma-agent — nomes fictícios, claro.

Pontos principais da configuração:

• Cada agent se conecta a um diretório de projeto e a um repositório Git independentes
• O .env de cada um define um PROJECT_NAME diferente para facilitar o rastreamento nos logs
• Importante: chaves de API e configurações de banco de dados de cada cliente ficam totalmente isoladas, sem qualquer cruzamento

Cenário 3: sandbox segura para testes

Meu problema: eu queria testar um script de processamento de arquivos em lote, mas tinha medo de que um erro de lógica excluísse arquivos importantes.

Solução:
Criei um sandbox-agent e ativei um modo de sandbox rigoroso.

Pontos principais da configuração:

ENABLE_NETWORK=false  # Sem acesso à internet
HOST_FILESYSTEM_MODE=readonly  # Sistema de arquivos do host somente leitura
TEMP_STORAGE=true  # Todas as alterações ficam em um diretório temporário, apagado ao reiniciar o contêiner

Assim, posso experimentar à vontade. No pior caso, excluo o contêiner e o recrio, sem afetar o ambiente do host. Hoje, testo primeiro aqui qualquer operação que pareça apresentar algum risco.

Cenário 4: colaboração em equipe e espaço pessoal

Meu problema: quando a equipe compartilhava um único assistente de IA, minhas anotações pessoais e tarefas também ficavam misturadas ali. Eu sempre sentia que não tinha privacidade.

Solução:

• team-agent: compartilhado pela equipe, com acesso ao repositório de código e à documentação do time
• private-agent: exclusivo para mim, onde registro ideias, rascunhos e tarefas pessoais

Pontos principais da configuração:
O diretório de trabalho do team-agent aponta para o NAS compartilhado da equipe, enquanto o private-agent aponta para uma partição local criptografada. No Telegram, o team-agent fica vinculado ao grupo da equipe, e somente eu posso conversar em particular com o private-agent.

Cenário 5: comparação entre vários modelos

Meu problema: eu queria comparar Claude, GPT-4 e um Llama local, mas trocar de configuração o tempo todo era trabalhoso.

Solução:
Três agents em paralelo: claude-agent, gpt-agent e llama-agent.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Pontos principais da configuração:
O .env de cada agent define um LLM_PROVIDER e uma API_KEY diferentes. Envio a mesma pergunta aos três e comparo a qualidade, a velocidade e o custo das respostas.

Uma descoberta interessante: Claude é o mais estável para geração de código, GPT-4 conversa de forma mais natural e o Llama local, embora seja mais lento, oferece mais privacidade. Por isso, uso o último para processar informações sensíveis.

Outras dicas práticas:

• Padrão de nomes: uso o formato cenário-finalidade-data, como client-nike-backend-20260201; mesmo meses depois, consigo identificar a finalidade nos logs
• Troca rápida: instalo várias contas do Telegram no celular e vinculo cada uma a um agent; alternar entre elas com um gesto é muito rápido
• Otimização de recursos: executo docker stop em agents que uso pouco, como o llama-agent, e só os inicio quando necessário para economizar memória

Como configurar seu primeiro par de agents, passo a passo

Agora que a teoria terminou, vamos à prática. Vou considerar que você já instalou o Docker e configurou o ambiente básico do OpenClaw. Caso ainda não tenha feito isso, consulte primeiro o guia de início rápido oficial.

Objetivo: configurar dois agents, work e personal

Etapa 1: prepare os arquivos de configuração

cd openclaw
cp .env .env.work
cp .env .env.personal

Etapa 2: altere a configuração do work-agent
Abra .env.work e altere estes parâmetros essenciais:

AGENT_NAME=work-agent
WORKSPACE_PATH=/path/to/your/work/directory
TELEGRAM_BOT_TOKEN=token_do_seu_work_bot
ALLOWED_USERS=seu_ID_de_usuário_do_Telegram

Etapa 3: altere a configuração do personal-agent
Abra .env.personal e faça mudanças semelhantes:

AGENT_NAME=personal-agent
WORKSPACE_PATH=/path/to/your/personal/directory
TELEGRAM_BOT_TOKEN=token_do_seu_personal_bot
CONTAINER_PORT=8001  # Altere a porta para evitar conflitos

Etapa 4: inicie os dois agents

docker-compose --env-file .env.work up -d
docker-compose --env-file .env.personal up -d

Espere alguns segundos. Quando aparecer Status: Running, a configuração estará concluída.

Três testes para verificar o isolamento

Teste 1: isolamento de arquivos

• Envie ao work-agent: “Crie um arquivo test.txt e escreva ‘work data’ nele”
• Envie ao personal-agent: “Liste todos os arquivos do diretório atual”
• Resultado: o personal-agent não vê test.txt

Teste 2: isolamento de conversas

• Diga ao work-agent: “Lembre-se de que o codinome do meu projeto é ProjectX”
• Pergunte ao personal-agent: “Qual é o codinome do meu projeto?”
• Resultado: o personal-agent responde “Não sei”, porque não tem acesso ao histórico de conversa do work-agent

Teste 3: isolamento de recursos

• Configure ENABLE_CODE_EXECUTION=true em .env.work
• Configure ENABLE_CODE_EXECUTION=false em .env.personal
• Resultado: o work-agent pode executar código, enquanto o personal-agent se recusa a executá-lo

Se os três testes passarem, parabéns: o isolamento está funcionando.

Problemas comuns:

• “A porta já está em uso”: verifique CONTAINER_PORT e use uma porta diferente para cada agent
• “O bot do Telegram não responde”: confirme se o token está correto e se ALLOWED_USERS contém seu ID de usuário
• “Erro de permissão de arquivo”: verifique as permissões do diretório WORKSPACE_PATH e confirme que o Docker tem acesso de leitura e gravação

Técnicas avançadas e armadilhas a evitar

Depois de alguns meses de uso, reuni estas experiências para compartilhar com você.

Otimização de desempenho: não deixe os agents consumirem todos os recursos

Quando configurei cinco agents pela primeira vez, a ventoinha do computador disparou e o consumo de memória chegou a 8 GB. Depois, fiz estas otimizações:

Limite máximo de recursos
Adicione isto ao docker-compose.yml:

deploy:
  resources:
    limits:
      cpus: '0.5'
      memory: 512M

Cada agent pode usar no máximo meio núcleo de CPU e 512 MB de memória, o que é suficiente.

Início e parada sob demanda
Para agents que uso pouco, como minha sandbox de testes, criei um script simples para iniciar e parar o contêiner:

# start-sandbox.sh
docker start sandbox-agent-container
# Depois de usar
docker stop sandbox-agent-container

Imagem base compartilhada
Todos os agents usam a mesma imagem base do OpenClaw e diferem apenas na configuração. Assim, cinco agents ocupam apenas mais 1 ou 2 GB de disco, em vez de cada um copiar a imagem inteira.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Práticas recomendadas de segurança: não deixe a conveniência causar problemas

Princípio do menor privilégio
Conceda a cada agent apenas as permissões indispensáveis. Meu personal-agent, por exemplo, não precisa acessar o diretório /work; portanto, esse caminho nem sequer é montado na configuração do Docker.

Tratamento de dados sensíveis
Sempre armazene chaves de API e senhas de banco de dados em variáveis de ambiente, nunca diretamente no código. Também verifico regularmente se algum arquivo .env foi enviado por engano ao Git — o .gitignore é seu melhor amigo.

Auditoria regular
Uma vez por semana, consulto os logs de operação dos agents:

docker logs work-agent-container --since 7d | grep ERROR

Assim, verifico se houve alguma operação anormal ou algum erro.

Solução de problemas comuns

O agent não inicia

• Consulte primeiro os logs: docker logs <nome_do_contêiner>
• Na maioria dos casos, é um conflito de porta ou um problema de permissão do Docker
• Solução: altere a porta ou conceda as permissões necessárias ao usuário do Docker

Falha no roteamento de mensagens

• Verifique se o token do bot do Telegram está correto
• Confirme se ALLOWED_USERS, na configuração do Gateway, contém seu ID
• Use curl para testar se o bot está online

Erro de permissão de arquivo

• O ID do usuário dentro do contêiner Docker não corresponde ao ID do usuário do host
• Solução: defina user: "${UID}:${GID}" no docker-compose.yml

Para ser sincero, já encontrei todas essas armadilhas. Se isso acontecer com você, não se assuste: em 90% dos casos, os logs mostram a resposta.

Resumo e próximos passos

Depois de tudo isso, os pontos centrais são apenas três:

Por que usar: um único assistente de IA mistura os contextos de trabalho, vida pessoal e testes, causando vazamentos de privacidade e perda de eficiência. O roteamento multiagente resolve esse problema por meio do isolamento físico.

Como configurar: use arquivos .env diferentes para criar vários agents, cada um com seu próprio diretório de trabalho, canal de mensagens e conjunto de permissões. Você consegue configurar o primeiro par work/personal em cinco minutos.

Práticas recomendadas: menor privilégio, início e parada sob demanda e auditorias regulares. É possível conciliar segurança e conveniência, desde que você não deixe esses cuidados de lado.

Hoje, uso esse sistema multiagente todos os dias. Na prática, trabalho com mais foco porque a IA não menciona de repente meus projetos paralelos; faço testes com tranquilidade porque posso experimentar à vontade na sandbox; e preservo melhor minha privacidade porque não preciso temer constrangimentos durante uma demonstração.

Próximas ações:

1. Ainda hoje, siga o tutorial acima e configure seu primeiro par de agents work/personal. É mais fácil do que parece
2. Se surgir algum problema, procure ajuda nas GitHub Issues do OpenClaw ou na comunidade do Discord; as pessoas por lá são receptivas
3. Se este artigo foi útil, compartilhe-o com alguém que também sofre quando o assistente de IA mistura os contextos

Para terminar: ferramentas de IA deveriam simplificar a vida, e não torná-la mais confusa. O roteamento multiagente funciona como um sistema de organização para o seu assistente de IA. Cada auxiliar cuida da sua própria função, e seu fluxo de trabalho fica naturalmente mais limpo.

Experimente. No futuro, você vai agradecer por ter começado hoje.