Eu criei um sistema operacional colaborativo de IA com 5 funções usando OpenClaw: uma análise técnica completa

Passei muito tempo transformando o OpenClaw de um assistente único em um sistema operacional colaborativo de múltiplas funções. Não se trata apenas de "abrir alguns bots para conversar separadamente."

5 papéis de IA, compartilhando um único gateway, rodando em canais duplos do Discord e Telegram, com divisão clara de trabalho, roteamento, isolamento de memória e regras de colaboração, capazes de trabalhar em revezamento como uma equipe.

Neste artigo, detalho todo o processo de construção, as decisões de design em cada camada, as configurações específicas e os problemas que encontrei.

Se você também está usando o OpenClaw ou tem interesse em "como fazer múltiplas IAs colaborarem de verdade", este conteúdo deve ajudar você a evitar muitos desvios.

Conclusão Primeiro: Isso não é "multi-bot", é um sistema operacional multi-agente sob um único Gateway

Quando muitas pessoas ouvem "5 papéis de IA", a primeira reação é: você está rodando 5 bots independentes, certo?

Sim, mas também não.

Minha arquitetura é assim:

• 1 processo Gateway, unificando o acesso ao canal e o roteamento
• 5 Agentes independentes: Comandante, Estrategista, Engenheiro, Criador, Pensador
• Cada Agente tem seu próprio espaço de trabalho independente (personalidade, regras, memória e sessões são todos isolados)
• Rodando canais duplos Discord + Telegram simultaneamente (pode rodar muitas plataformas, mas eu só uso o Discord), usando bindings para distribuição precisa de mensagens
• Bate-papos privados e em grupo usam mecanismos completamente diferentes

Uma analogia: Isso não é contratar 5 pessoas e jogá-las em uma sala para agir livremente. É construir uma empresa — com estrutura organizacional, descrições de cargo, protocolos de comunicação, escritórios independentes e regras de reunião.

O próprio OpenClaw é um framework de assistente de IA pessoal de código aberto que suporta múltiplas plataformas (Discord, Telegram, WhatsApp, etc.) e múltiplos modelos (Claude, GPT, Gemini, etc.), com dados totalmente localizados.

Sua capacidade multi-agente é a razão central pela qual o escolhi — suporte nativo para espaços de trabalho independentes multi-agente + roteamento de bindings, o que me permitiu construir um verdadeiro sistema colaborativo em cima dele.

1. Arquitetura Geral: Gateway Único + Multi-Agente + Multi-Espaço de Trabalho + Multi-Canal

Primeiro, vamos falar sobre as decisões arquiteturais de nível mais baixo.

1) Hospedagem Unificada via Gateway Único

Atualmente, tenho um processo Gateway do OpenClaw carregando todas as capacidades — acesso a mensagens, roteamento, gerenciamento de sessão, chamadas de ferramentas, indexação de memória e gerenciamento de estado, tudo em um único gateway.

Por que não rodar um conjunto de serviços para cada função? Três razões:

• Manutenção centralizada: Apenas um Gateway para manter, sem necessidade de rodar serviços independentes para cada função.
• Configuração unificada: Um arquivo de configuração mestre gerencia as estratégias globais, e o monitoramento/solução de problemas também são centralizados.
• Base para colaboração: Para que as funções colaborem, elas precisam estar no mesmo runtime para uma comunicação eficiente.

2) 5 Agentes Paralelos, Não 5 Bots Soltos

Meus 5 papéis fixos:

• Comandante (zongzhihui): Consciência situacional global, decomposição de tarefas, atribuição, correção e encerramento.
• Estrategista (junshi): Análise estratégica, avaliação de propostas e previsão de riscos.
• Engenheiro (engineer): Execução técnica, implementação de código e manutenção do sistema.
• Criador (creator): Criação de conteúdo, otimização de expressão e saída externa.
• Pensador (zhiku): Auditoria de conhecimento, controle de qualidade e verificações de conformidade.

Cada agente tem seu próprio espaço de trabalho, como workspace-engineer, workspace-junshi, etc. Arquivos de personalidade, arquivos de regras, arquivos de memória e ativos de script são todos independentes e não se contaminam.

3) Acesso Dual-Stack Multi-Canal: Discord + Telegram

O mesmo Gateway está conectado tanto ao Discord quanto ao Telegram. Cada função tem bindings no nível de accountId em ambos os canais. Claro, você pode usar este mesmo arquivo de configuração para integrar mais plataformas como Lark, WeChat, etc.

Isso não é "implantação duplicada entre plataformas", mas "o mesmo cluster cerebral, diferentes camadas de acesso". Configurei o Discord como o principal campo de batalha de colaboração.

Se você quer que múltiplos agentes cooperem e colaborem dentro de um grupo, basta escolher o Discord; uma plataforma é suficiente. Outras não são perfeitas, já testei!!!

2. Camada de Roteamento: Bindings Mapeando "Contas" para "Papéis"

Esta é a lógica de entrada de todo o sistema.

Configurei uma estratégia de binding explícita para canais duplos: channel + accountId -> agentId.

Especificamente:

• discord + zongzhihui -> zongzhihui
• discord + engineer -> engineer
• telegram + creator -> creator
• ... um total de 10 mapeamentos (5 papéis × 2 canais)

Por que fazer isso?

Porque o sistema decide "quem deve lidar com esta mensagem" na camada de entrada, em vez de deixar todos os agentes ouvirem e depois disputarem para responder. Se esta etapa não for bem feita, toda a colaboração subsequente será caótica.

Você pode pensar nos bindings como a "triagem da recepção" deste sistema. Quando uma mensagem chega, primeiro verifica qual canal e conta a receberam, então a roteia diretamente para a função correspondente — limpo e eficiente.

3. Isolamento de Sessão: Por que os Bate-Papos Privados Não se Cruzam e os de Grupo Não Ficam Bagunçados

Este é um dos pontos de engenharia mais críticos no meu sistema.

Configuração central: session.dmScope = per-account-channel-peer

Este parâmetro significa: O contexto do bate-papo privado é isolado por três dimensões: "conta + canal + usuário par."

Por que escolher isso?

• Se a mesma pessoa contatar a mesma função via Discord e Telegram, os contextos não se cruzarão.
• Se usuários diferentes contatarem a mesma função, os contextos estarão completamente isolados.
• Em cenários multi-agente + multi-conta, o risco de "interferência cruzada" é minimizado.

Em outras palavras, não criei apenas "múltiplos papéis"; também fiz "engenharia de estratégia de isolamento de contexto."

Muitas pessoas constroem sistemas multi-agente onde os papéis são claramente divididos, mas o gerenciamento de contexto é uma bagunça — o conteúdo do bate-papo privado do Usuário A acaba na resposta do Usuário B, ou a memória da conversa do Discord contamina o contexto do Telegram.

per-account-channel-peer é a estratégia de isolamento recomendada pelo OpenClaw para cenários de múltiplas contas, e meus testes mostram que é de fato a escolha mais estável.

4. Orquestração de Bate-Papo em Grupo: Colaboração Orientada por Regras, Não Conversa Livre

Esta parte é a mais interessante e tem mais armadilhas.

Estratégia Central: Comandante em Escuta Global + Outros Papéis Acionados por @

Minha estratégia de bate-papo em grupo no lado do Discord é a seguinte:

Comandante: requireMention = false (Escuta global)

• Pode ver todas as mensagens no grupo por padrão.
• Responsável por entender a situação global, julgar se a colaboração é necessária, realizar a decomposição de tarefas e atribuir trabalho.

Outros 4 Papéis: `requireMention = true` (Acionados por @)

• Só agem quando explicitamente mencionados com @.
• Reduz ruído e evita que falem uns por cima dos outros.

Cada papel é configurado com `mentionPatterns`

• Por exemplo, o engenheiro pode ser acionado por @Engineer ou [@engineer](https://x.com/@engineer).
• Torna a convocação no grupo mais estável e previsível.

Qual é a essência desta combinação?

• O Comandante "vê o panorama geral", como um Gerente de Produto em uma equipe.
• Papéis especializados são "acionados sob demanda", como especialistas em várias posições.
• A fala no grupo muda de "forma livre" para "revezamento controlado".

Efeito real: Você faz uma pergunta no grupo, o Comandante primeiro julga que tipo de tarefa é, então menciona @ a função correspondente para lidar com ela. Uma vez que a função termina, o Comandante fecha o ciclo. Todo o processo é como uma equipe real tendo uma reunião.

5. Discord vs Telegram: Por que o Discord é o Campo de Batalha Principal

A rigor, não é que "só o Discord pode colaborar." É só que, na minha configuração atual, o Discord é o mais adequado para a orquestração de colaboração pública com múltiplos papéis.

Razões específicas:

1. Configurei 5 contas paralelas no Discord + um mecanismo de @ colaboração claro.
2. Identidades de papéis, cadeias de conversa e o processo de revezamento são todos visíveis — parece uma discussão de equipe.
3. A estratégia de escuta global do Comandante + portão de menção para outros papéis é mais intuitiva em cenários de bate-papo em grupo.
4. Atualmente, defini o groupPolicy do Discord como open, o que oferece maior flexibilidade.

No lado do Telegram, minha estratégia tende para allowlist + portão de menção, que é mais restrita e segura, adequada para "canais de produção controlados."

Então, o resumo é: o Discord é o palco de colaboração.

6. Camada de Configuração + Camada de Prompt: Governança em Duas Vias

Esta é a maior diferença entre este sistema e "apenas brincar."

Não confio apenas na configuração, nem apenas nos Prompts. Uso duas vias sobrepostas.

A. Via de Configuração (Controle de Nível de Plataforma)

Estas são configurações rígidas no nível da plataforma OpenClaw:

• política de canal: groupPolicy, dmPolicy, controlando estratégias básicas para bate-papos em grupo e privados.
• requireMention: Quem deve ser mencionado com @ por padrão para responder.
• bindings: Mapeamento de roteamento de mensagens.
• dmScope: Granularidade de isolamento de sessão.
• limite de ping-pong agentToAgent: Defini isso como 0, suprimindo diretamente o vai-e-vem sem sentido entre agentes.

O último é crucial — se você não limitar o ping-pong agente-para-agente, verá duas IAs em um grupo sendo educadas, confirmando uma com a outra e entrando em loop infinito. Definir como 0 diz ao sistema: agentes não devem fazer ping-pong automaticamente uns com os outros.

B. Via de Regras (Controle de Nível de Comportamento)

Estes são os arquivos de regras que escrevi em cada espaço de trabalho:

• SOUL.md: O arquivo de alma do papel — personalidade, tom, responsabilidades e piso de qualidade de saída.
• AGENTS.md: Manual de operações — processos de verificação de colaboração, normas de leitura/gravação de memória e estratégias de carregamento preguiçoso.
• ROLE-COLLAB-RULES.md: Limites de colaboração específicos do papel e linhas vermelhas.
• TEAM-RULEBOOK.md: Regras rígidas unificadas para a equipe (compartilhadas por todos os papéis).
• TEAM-DIRECTORY.md: Tabela de mapeamento de papéis para IDs reais para evitar mencionar @ a pessoa errada.

O efeito de sobrepor estas duas vias é: a camada de plataforma limita o fluxo + a camada de comportamento adiciona restrições.

Não se trata de colocar tudo na "autoconsciência" do modelo. Modelos cometem erros, derivam e esquecem regras. Portanto, restrições rígidas devem ser definidas primeiro na camada de configuração, seguidas por orientação suave na camada de prompt. Dupla segurança.

7. Sistema de Arquivos do Espaço de Trabalho: "Escritório Independente" de Cada Papel

O esqueleto de arquivos para cada espaço de trabalho é basicamente consistente, o que é importante — mostra que estou padronizando, não apenas empilhando arquivos aleatoriamente para cada papel.

Estrutura de Arquivos Padrão

8. Sistema de Memória: Carregamento Preguiçoso + Camadas + Arquivamento

O gerenciamento de memória é a parte mais facilmente negligenciada, mas mais problemática em um sistema multi-agente.

Minha estratégia não é "lembrar o máximo possível", mas sim uma clara divisão em camadas:

1) Registros de Curto Prazo (memória diária)

• Registra os processos de tarefas do dia, fragmentos de contexto e decisões no local.
• Arquivos são nomeados por data, criando naturalmente uma linha do tempo.

2) Memória de Longo Prazo (MEMORY.md)

• Destila preferências estáveis, decisões de longo prazo, experiência reutilizável e regras rígidas.
• Nem tudo entra; apenas informações verificadas e estáveis são escritas.

3) Memória de Longo Prazo do Grupo (GROUP_MEMORY.md)

• Retém apenas informações reutilizáveis e seguras do grupo.
• Não mistura conteúdo de bate-papo privado; esta é uma linha vermelha de privacidade.

4) Arquivamento a Frio (archive)

• Dados antigos são arquivados periodicamente para evitar que o contexto ativo se expanda descontroladamente.
• Não são excluídos, mas movidos para armazenamento de baixa prioridade.

5) Mecanismo de Recuperação (memory_search + memory_get)

• Recuperação semântica primeiro, depois leitura precisa.
• Evita o carregamento completo — a janela de contexto é um recurso limitado e não pode ser desperdiçada.

O valor central desta divisão em camadas:

• A qualidade do bate-papo privado não é contaminada pelo histórico do bate-papo em grupo.
• A colaboração em grupo não é interferida pelo contexto privado pessoal.
• A janela de contexto é "carregada sob demanda", não "despejada completamente".

Trato o orçamento de contexto como um problema de gerenciamento de recursos. Tokens são finitos; cada memória inserida ocupa espaço de inferência. Portanto, cada bit deve ser calculado cuidadosamente.

9. Modo Privado vs Modo de Grupo: Duas Estratégias para o Mesmo Papel

Isto é algo que muitas pessoas não pensam: o mesmo papel deve se comportar de forma diferente em bate-papos privados e em grupo.

Eu distingo explicitamente entre os dois modos no SOUL.md de cada papel:

Modo Privado:

• Cada papel atua como um especialista solo, lidando com os problemas do usuário do início ao fim.
• Nenhum processo de colaboração necessário; forneça respostas completas diretamente.
• O padrão de qualidade é "uma pessoa pode lidar com isso."

Modo de Grupo:

• Executa revezamento incremental de acordo com os protocolos de colaboração da equipe.
• Cada papel é responsável apenas pelo que é bom.
• O Comandante é responsável por conectar e fechar.

Específico para cada papel:

• Comandante: Fica em silêncio e observa por padrão em grupos, apenas intervindo fortemente quando necessário para evitar falar por cima dos outros.
• Engenheiro: As entregas devem ser executáveis, verificáveis e reversíveis — não apenas fornecer uma ideia.
• Estrategista: As conclusões devem vir com premissas e caminhos de verificação — não apenas de cabeça.
• Pensador: As auditorias devem fornecer classificação de problemas + planos de reparo — não apenas dizer "há um problema."
• Criador: A expressão não pode sacrificar autenticidade e executabilidade — não apenas buscar estética.

Esta é a fonte de "o mesmo papel ter desempenho diferente em cenários diferentes." Não depende do julgamento do modelo, mas é explicitamente instruído através de arquivos de regras.

Palavras Finais

Multi-Agente não é apenas abrir mais alguns bots. É um sistema de engenharia inteiro — desde design arquitetural, estratégias de roteamento, isolamento de sessão, orquestração de colaboração, gerenciamento de memória e governança de regras até verificações automatizadas; cada camada precisa de design cuidadoso.

O OpenClaw fornece uma ótima base, mas a quantidade de engenharia de "funcionável" para "funcionando bem" é muito maior do que a maioria das pessoas imagina.

Se você está fazendo algo semelhante, espero que este conteúdo lhe dê alguma referência. Claro, este conteúdo é apenas o começo; lançarei mais várias peças mais tarde para compartilhar mais questões "específicas e refinadas."