OpenClaw ganha reimplementação em Go: um binário de 35 MB no lugar de 800 MB de dependências

O OpenClaw, que reúne cerca de 180 mil estrelas no GitHub, ganhou uma reimplementação independente em Go. O novo projeto, chamado GoClaw, promete eliminar os principais problemas da versão em Node.js: dependências pesadas, runtime extra e deploy complicado em servidores fracos.

Por que o GoClaw existe

A principal crítica ao OpenClaw não tem a ver com os recursos, mas com o empacotamento. Para subir o projeto original, é preciso ter Node.js, npm, o próprio repositório e a instalação de um grande conjunto de dependências, que pode chegar a 500–800 MB. Na prática, isso significa uma primeira execução demorada, conflitos de versão, problemas com módulos nativos e mais pontos de falha quando o serviço precisa ser implantado rapidamente em um VPS, um mini PC ou um Raspberry Pi.

O GoClaw resolve o problema da forma mais direta: em vez de um ecossistema de runtime e node_modules, o usuário recebe um único binário compilado estaticamente, de cerca de 35 MB. Basta baixá-lo, dar permissão de execução e usar. Para ferramentas que precisam ficar em segundo plano 24/7 aguardando mensagens do Telegram, do Discord ou de outros canais, esse formato reduz bastante a barreira de entrada e facilita a manutenção.

Como o projeto é estruturado

O GoClaw não é um fork nem um wrapper fino sobre o original, mas uma versão reescrita do zero do gateway de IA multiagente. O projeto se conecta a mensageiros, trabalha com vários provedores de LLM e aposta na concorrência nativa do Go. O artigo apresenta isso como uma base mais natural para cenários com agentes, em que há muitas requisições paralelas, esperas por respostas de API e coordenação entre papéis.

• Um único binário de cerca de 35 MB
• Suporte a mais de 11 provedores de LLM
• Operação por 5 canais de comunicação, incluindo Telegram e Discord
• Sistema multiagente com delegação e orquestração
• Quadro kanban para gerenciar as tarefas dos agentes

A arquitetura gira em torno de vários agentes especializados. Um projeta a solução, outro escreve o código, um terceiro verifica os testes e um quarto cuida da revisão. Uma tarefa de alto nível é decomposta automaticamente, e as etapas são distribuídas em um quadro kanban interno. Em Go, esse cenário parece orgânico: goroutines e canais permitem manter muitas cadeias paralelas sem complexidade extra, enquanto em Node.js isso costuma depender do event loop e de promises.

Ganhos e limitações

O GoClaw oferece não só compacidade, mas também economia na operação. O material fala em redução de 3 a 5 vezes no consumo de memória em relação à versão em Node.js, com funcionalidade comparável. Isso é especialmente importante em VPS baratos com 512 MB ou 1 GB de RAM, onde cada processo sempre ativo consome recursos rapidamente. A conteinerização também sai ganhando: uma imagem com um aplicativo em Go pode ser montada quase só com o binário, enquanto um serviço em Node.js costuma arrastar uma base mais pesada e todo o diretório de dependências.

Mas essa troca tem um custo. O OpenClaw é forte não só pelo código, mas por um ecossistema maduro: grande comunidade, mais de 180K estrelas, plugins consolidados, Skills e integrações. O GoClaw ainda é jovem, tem menos usuários e menos validação em produção. Quase não há compatibilidade entre os ecossistemas: os Skills existentes do OpenClaw não podem simplesmente ser levados para o novo projeto.

Por isso, a escolha depende da tarefa: se você precisa de um serviço minimalista para trabalho em segundo plano, a versão em Go parece fazer sentido; se plugins, personalização e comunidade importam, o original ainda é claramente mais forte.

O que isso significa

O caso do GoClaw mostra uma tendência mais ampla: as ferramentas de IA são avaliadas cada vez mais não só pela qualidade dos modelos, mas pelo custo de operação. Se um agente precisa funcionar de forma estável em segundo plano, ser implantado rapidamente e não exigir centenas de megabytes de dependências, o Go se torna uma escolha cada vez mais prática.

Mas a vitória da linguagem não é absoluta: o ecossistema e a maturidade do produto ainda podem pesar mais que a pura eficiência de engenharia.