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 multi-função. 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 de trabalho clara, 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 as armadilhas que encontrei.

Se você também está usando o OpenClaw ou tem interesse em "como fazer múltiplas IAs realmente colaborarem", este texto deve ajudá-lo a evitar muitos desvios.

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

Quando muitos 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 e o roteamento dos canais
• 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 todas isoladas)
• Rodando canais duplos Discord + Telegram simultaneamente (pode rodar várias plataformas, mas eu só uso o Discord), usando bindings para distribuição precisa de mensagens
• Chats privados e em grupo usam mecanismos completamente diferentes

Uma analogia: Isso não é contratar 5 pessoas e colocá-las numa sala para agir livremente. Isso é 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 principal pela qual o escolhi—suporte nativo para espaços de trabalho independentes de múltiplos agentes + roteamento por bindings, o que me permitiu construir um sistema colaborativo verdadeiro sobre ele.

1. Arquitetura Geral: Gateway Único + Multi-Agente + Multi-Workspace + Multi-Canal

Primeiro, vamos falar sobre as decisões arquiteturais de base.

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 estratégias globais, e o monitoramento/depuração também são centralizados.
• Base para colaboração: Para que as funções colaborem, elas precisam estar no mesmo runtime para comunicação eficiente.

2) 5 Agentes em Paralelo, 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, regras, memória e ativos de script são todos independentes e não se contaminam.

3) Acesso Multi-Canal em Pilha Dupla: 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 para colaboração.

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

2. Camada de Roteamento: Bindings Mapeando "Contas" para "Funções"

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 funções × 2 canais)

Por que 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 este passo não for bem feito, 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 Chats Privados Não se Cruzam e Chats em Grupo Não São Bagunçados

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

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

Este parâmetro significa: O contexto de chat privado é isolado por três dimensões: "conta + canal + peer usuário."

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 são completamente isolados.
• Em cenários multi-agente + multi-conta, o risco de "interferência cruzada" é minimizado.

Em outras palavras, não criei apenas "multi-funções"; também fiz "engenharia de estratégia de isolamento de contexto."

Muitas pessoas constroem sistemas multi-agente onde as funções são claramente divididas, mas o gerenciamento de contexto é uma bagunça—o conteúdo do chat 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 multi-conta, e meus testes mostram que é de fato a escolha mais estável.

4. Orquestração de Chat 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 + Outras Funções Acionadas por @

Minha estratégia de chat 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 captar a situação global, julgar se a colaboração é necessária, realizar a decomposição de tarefas e atribuir o trabalho.

As outras 4 funções: `requireMention = true` (Acionadas por @)

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

Cada função é configurada 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 Projeto numa equipe.
• As funções especializadas são "acionadas 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 é, depois menciona a função correspondente para lidar com ela. Assim 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 "apenas o Discord pode colaborar." É que, na minha configuração atual, o Discord é o mais adequado para a orquestração de colaboração pública multi-função.

Razões específicas:

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

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

Então, o resumo é: Discord é o palco da 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 a Nível de Plataforma)

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

• channel policy: groupPolicy, dmPolicy, controlando estratégias básicas para chats em grupo e privados.
• requireMention: Quem deve ser mencionado com @ por padrão para responder.
• bindings: Mapeamento de roteamento de mensagens.
• dmScope: Granularidade do isolamento de sessão.
• agentToAgent ping-pong limit: Defino como 0, suprimindo diretamente o vaivém sem sentido entre agentes.

O último é crucial—se você não limitar o ping-pong agente-para-agente, verá duas IAs num 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.

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

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

• SOUL.md: O arquivo da alma da função—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/escrita de memória e estratégias de carregamento preguiçoso.
• ROLE-COLLAB-RULES.md: Limites de colaboração e linhas vermelhas específicas da função.
• TEAM-RULEBOOK.md: Regras rígidas unificadas para a equipe (compartilhadas por todas as funções).
• TEAM-DIRECTORY.md: Tabela de mapeamento de funções para IDs reais para evitar mencionar a pessoa errada com @.

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, divergem 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 Workspace: "Escritório Independente" de Cada Função

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

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 a mais problemática num sistema multi-agente.

Minha estratégia não é "lembrar o máximo possível", mas sim um camadas claras:

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)

• Apenas retém informações reutilizáveis e seguras do grupo.
• Não mistura conteúdo de chat 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 é excluído, mas movido para armazenamento de baixa prioridade.

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

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

O valor central destas camadas:

• A qualidade do chat privado não é contaminada pelo histórico do chat 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. Então, cada bit deve ser calculado cuidadosamente.

9. Modo Privado vs Modo de Grupo: Duas Estratégias para a Mesma Função

Isto é algo que muitos não pensam: a mesma função deve se comportar de forma diferente em chats privados e em grupo.

Eu distingo explicitamente os dois modos no SOUL.md de cada função:

Modo Privado:

• Cada função 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:

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

Especificamente para cada função:

• Comandante: Fica em silêncio e observa por padrão no grupo, só 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 suposições e caminhos de verificação—não apenas de cabeça.
• Pensador: As auditorias devem fornecer classificação do problema + 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 "a mesma função se comportando de forma diferente em cenários diferentes." Não depende do julgamento do modelo, mas é dito explicitamente 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 texto lhe dê alguma referência. Claro, este conteúdo é apenas o começo; lançarei mais alguns artigos depois para compartilhar questões mais "específicas e refinadas."