Dominando a Configuração Multi-usuário do OpenClaw em Pouco Tempo

Quando meu colega de trabalho começou a usar minha instância do OpenClaw, descobri que o multiusuário não era apenas uma caixa de seleção de configuração. Era um redesign de como o agente pensa sobre contexto, permissões e privacidade.

No momento em que percebi isso: meu colega pediu ao agente para verificar sobre “o projeto”, e o agente puxou meu projeto pessoal — não o projeto da equipe que eles queriam dizer. O agente tinha um contexto, uma memória e nenhum conceito de que usuários diferentes poderiam ter projetos diferentes com o mesmo nome.

Configurar o multiusuário corretamente me levou três tentativas. Aqui está o que aprendi.

Tentativa 1: Compartilhar Tudo

Minha primeira abordagem: ambos usamos o mesmo agente com a mesma configuração. Configuração fácil. Terrível na prática.

Problemas:
– O agente confundiu nossos contextos (“Você mencionou querer pizza para o jantar” — isso foi meu colega, não eu)
– As permissões eram idênticas (meu colega podia ver minhas automações pessoais e vice-versa)
– A memória era compartilhada (qualquer coisa que uma pessoa dissesse ao agente, a outra pessoa podia acessar)
– Tarefas cron eram executadas para nós dois, independentemente da relevância

Isto funciona se você não tiver requisitos de privacidade e casos de uso idênticos. Na prática, ninguém tem requisitos de privacidade zero.

Tentativa 2: Instâncias Separadas

Minha segunda abordagem: cada usuário tem sua própria instância do OpenClaw rodando no mesmo servidor. Isolamento completo. Sem contexto compartilhado.

Problemas:
– Uso duplicado de recursos (dois processos, dois conjuntos de memória)
– Sem conhecimento compartilhado (tivemos que contar a ambos os agentes sobre os processos da equipe separadamente)
– Configuração duplicada (qualquer mudança tinha que ser feita duas vezes)
– Habilidades instaladas duas vezes, atualizadas duas vezes, mantidas duas vezes

Isto funciona se os usuários forem completamente independentes. Mas compartilhamos uma equipe, trabalhamos nos mesmos projetos e precisamos de algum nível de contexto compartilhado.

Tentativa 3: O Que Realmente Funciona

A solução: uma instância com sessões específicas do usuário e memória compartilhada, mas separada.

Sessões de usuário. Cada usuário tem sua própria sessão com seu próprio histórico de conversa e contexto. Quando eu envio uma mensagem ao agente, ele carrega meu contexto. Quando meu colega envia uma mensagem, ele carrega o contexto deles. Sem contaminação cruzada.

Memória escopo. Três escopos de memória:
– Escopo pessoal: visível apenas para o usuário proprietário (preferências, projetos pessoais, notas privadas)
– Escopo da equipe: visível para todos (processos da equipe, detalhes de projetos compartilhados, decisões em grupo)
– Escopo global: informações a nível de sistema (endereços de servidor, configurações de ferramentas)

Quando eu conto ao agente sobre meu projeto pessoal, ele vai para meu escopo pessoal. Quando eu falo sobre o processo de implantação da equipe, ele vai para o escopo da equipe.

Permissões baseadas em função. Eu sou o administrador — posso configurar o sistema, gerenciar habilidades e acessar todos os escopos. Meu colega é um usuário padrão — eles podem usar o agente e gerenciar seu próprio escopo pessoal, mas não podem mudar a configuração do sistema.

Configurando

Passo 1: Configurar autenticação do usuário. Cada plataforma de mensagens tem sua própria identificação de usuário. Discord usa IDs de usuário, Slack usa IDs de membros, Telegram usa IDs de usuário. O OpenClaw mapeia esses para identidades internas de usuário.

Passo 2: Configurar isolamento de sessões. Configurar o OpenClaw para manter sessões separadas por usuário. Cada sessão tem seu próprio histórico de conversa e janela de contexto.

Passo 3: Configurar escopos de memória. Definir quais escopos existem (pessoal, equipe, global) e o escopo padrão para novas memórias. Eu defino o escopo pessoal como padrão — tudo é privado, a menos que compartilhado explicitamente.

Passo 4: Definir permissões. Definir o que cada função de usuário pode fazer. Usuários padrão: interagir com o agente, gerenciar memória pessoal, usar habilidades aprovadas. Administradores: tudo, além de configuração do sistema e acesso a todos os escopos.

Os Problemas

Tarefas cron compartilhadas. Uma tarefa cron que publica um resumo matinal — deve ser executada por usuário ou uma vez para todos? A resposta depende do trabalho. Resumos matinais são pessoais (calendários diferentes, prioridades diferentes). Verificações de saúde do servidor são compartilhadas (mesmos servidores para todos). Configure cada tarefa com o escopo apropriado.

Permissões de habilidade. Algumas habilidades são apropriadas para todos (busca na web, sumarização). Algumas são apenas para administradores (gerenciamento de servidores, configuração do sistema). Revise as capacidades de cada habilidade e atribua-a ao nível de permissão apropriado.

Conflitos de memória. Dois usuários podem salvar informações contraditórias no escopo da equipe. “Usamos PostgreSQL” e “Estamos migrando para MySQL.” O agente não reconcilia isso automaticamente — ele armazena ambos e pode apresentar qualquer um deles. A revisão regular da memória detecta esses conflitos antes que eles causem confusão.

Atribuição de custos. Com vários usuários compartilhando uma chave de API, o rastreamento individual de custos se torna importante. Sem isso, o uso intenso de um usuário é subsidiado pelo orçamento de todos os outros. Adicionei rastreamento de custos por usuário ao meu painel de monitoramento.

Considerações sobre Escala

Essa configuração funciona bem para 2-5 usuários. Nesse nível, a gestão manual da memória é prática, a configuração de permissões é gerenciável e uma única instância do OpenClaw lida com a carga.

Para equipes maiores (10+ usuários), você vai querer: gestão automatizada do escopo da memória (em vez de manual), controle de acesso baseado em papéis mais granular, balanceamento de carga entre várias instâncias e um painel administrativo adequado para gerenciamento de usuários.

Não precisei escalar além de 5 usuários, então não posso falar sobre os detalhes de implantações maiores. Mas a arquitetura central (sessões isoladas, memória escopo, permissões baseadas em papéis) deve escalar se a infraestrutura escalar.

🕒 Published: April 5, 2026