Como criar seu próprio agente de IA no estilo OpenClaw

O que o OpenClaw realmente é

O OpenClaw é um agente pessoal de IA alojado pelo próprio utilizador. É executado no seu próprio servidor, ligado às aplicações de chat que já utiliza, e pode executar comandos de shell, controlar um browser, ler e escrever os seus ficheiros e agir com base nas mensagens que lhe envia. É licenciado ao abrigo da MIT, segue uma abordagem local-first e tinha mais de 380,000 estrelas no GitHub em meados de 2026, o que o torna num dos projetos com mais estrelas na plataforma. Por baixo do ruído, é um conjunto relativamente pequeno de componentes ligados de forma coerente. Este artigo explica esses componentes para que compreenda como uma ferramenta deste tipo é construída e onde estão os principais riscos.

Há um aviso importante, porque ele influencia todas as decisões de desenho abaixo. Em março de 2026, foram divulgados nove problemas de segurança no OpenClaw no espaço de quatro dias, incluindo uma falha crítica de escalada de privilégios classificada com 9.9 em 10 (CVE-2026-32922). O projeto foi concebido para ser protegido por si, enquanto operador. Um agente que pode executar qualquer comando é tão seguro quanto o sistema onde é executado e os limites que lhe impõe. Tenha isto em mente durante a leitura.

O daemon de gateway: um processo, mantido privado

No centro está um único processo de execução contínua, normalmente chamado gateway. Ele é o plano de controlo. Recebe mensagens, decide o que fazer, executa as ferramentas e envia as respostas. Tudo o resto se liga a ele.

O facto mais importante sobre o gateway é o endereço onde fica à escuta. Por predefinição, o OpenClaw liga-o ao endereço de loopback, 127.0.0.1, por isso não fica acessível a partir da Internet, a menos que o exponha deliberadamente. Mantenha-o assim. Este é o processo que executa comandos, portanto um gateway exposto dá a qualquer pessoa que o encontre um ponto de acesso remoto ao seu servidor. Quando precisar de aceder a ele a partir do portátil, faça-o através de uma VPN ou de um túnel SSH, em vez de abrir uma porta. Ninguém consegue atacar uma porta à qual não consegue aceder.

Conectores de canais: receber uma mensagem e enviar uma resposta

Um agente pessoal só é útil se puder falar com ele a partir das aplicações que já utiliza. É essa a função dos conectores de canais. Cada conector comunica com uma plataforma, como Telegram, WhatsApp, Slack ou Discord, através da API de bots ou de webhooks dessa plataforma.

A estrutura é igual em todos os conectores. O conector regista um bot na plataforma, recebe a mensagem recebida por si — através de polling da plataforma ou de um webhook enviado pela plataforma —, encaminha essa mensagem para o gateway e publica a resposta do gateway através da mesma API. O conector é uma camada fina de tradução. Converte «chegou uma mensagem do Telegram» em «aqui está texto para o agente» e faz a conversão inversa. Criar um conector próprio consiste principalmente em consultar a documentação de bots de uma plataforma e mapear o formato das mensagens para o formato do gateway.

O ciclo entre o modelo e as ferramentas

Dentro do gateway está a parte que o torna um agente, e não um chatbot. É um ciclo.

Uma mensagem chega. O gateway envia-a para um modelo de linguagem, juntamente com uma lista das ferramentas que o modelo pode utilizar. O modelo lê a mensagem e decide: responde diretamente ou chama uma ferramenta. Se chamar uma ferramenta, o gateway executa-a, recolhe o resultado e envia-o de volta ao modelo. O modelo analisa o resultado e decide novamente. Isto repete-se até o modelo não ter mais nada para fazer e produzir uma resposta final.

Esse ciclo é a ideia central de um agente. É o mesmo ciclo, quer o agente esteja numa aplicação de chat, quer esteja num terminal. Para saber como ligar ferramentas a esse ciclo de forma padronizada, ligar ferramentas através do Model Context Protocol é uma boa leitura seguinte. Para a parte do modelo, executar o próprio modelo no seu hardware completa a outra metade.

O conjunto de ferramentas é a finalidade e o perigo

As ferramentas são o que torna o OpenClaw poderoso. Uma ferramenta executa comandos de shell. Outra controla um browser. Outra lê e grava ficheiros. Dê acesso a essas ferramentas ao ciclo acima e ele poderá fazer quase tudo o que pode fazer num teclado. Esse alcance é o produto inteiro. Também é todo o risco.

Um agente que pode executar qualquer comando com base em instruções recebidas de uma aplicação de chat representa uma superfície de ataque ampla. Uma instrução maliciosa, um ataque de prompt injection oculto numa página Web visitada pela ferramenta de browser ou um erro como as falhas de março de 2026 pode transformar "ler o meu calendário" em "eliminar os meus ficheiros". Por isso, estas limitações não são extras opcionais. Execute o agente como um utilizador dedicado e sem privilégios, sem sudo, para impedir que um comprometimento aumente os privilégios. Coloque as ferramentas perigosas atrás de uma etapa de aprovação, para que o agente peça confirmação antes de executar uma operação destrutiva. Coloque a execução das ferramentas numa sandbox, para conter um comando descontrolado. Isole a chave de API do modelo, para que uma fuga não entregue a sua conta a um atacante. Considere também os outros segredos existentes no mesmo sistema, porque os verdadeiros pontos fracos do Vaultwarden são o token de administrador e o ficheiro de backup, não a encriptação, e um agente com acesso ao shell fica ao alcance de ambos.

Antes de expor qualquer componente que execute comandos de shell, reveja deliberadamente os aspetos básicos. Gere aqui uma checklist para o seu próprio sistema e siga-a de cima para baixo:

A execução como utilizador sem privilégios é abordada em detalhe em executar serviços como utilizador sem privilégios, e o guia completo para configurar o projeto real em segurança está em executar o OpenClaw em segurança numa VPS.

Memória como ficheiros de texto simples

A maioria das pessoas espera que a memória de um agente esteja numa base de dados. A memória do OpenClaw não está. É armazenada como ficheiros Markdown de texto simples no disco, e vale a pena copiar esta abordagem.

Os ficheiros são simples. Não existe um esquema para migrar, nenhum serviço para manter em execução e nenhuma linguagem de consulta para aprender. São fáceis de inspecionar: pode abrir a pasta e ler exatamente aquilo que o agente sabe sobre si, corrigir uma nota errada editando um ficheiro ou eliminar uma memória removendo esse ficheiro. Também são portáteis, porque mover o agente para um servidor novo consiste em copiar um diretório. Para um agente pessoal de um único utilizador, uma pasta com ficheiros de texto é suficiente e mantém todo o sistema fácil de compreender.

Competências: uma forma portátil de adicionar capacidades

Além das ferramentas integradas, o OpenClaw usa um formato portátil de competências para que a comunidade possa expandir as suas capacidades sem alterar o núcleo. Uma competência é um conjunto autónomo de instruções e, por vezes, código, que ensina o agente a executar uma nova tarefa. O agente carrega uma competência quando a tarefa o exige. A pesquisa na Web é normalmente a primeira competência que as pessoas adicionam, e configurar essa competência para usar a sua própria instância do SearXNG mantém as consultas fora de uma API de pesquisa comercial. Também deixa claro onde está o limite de confiança da competência, porque tudo o que ela devolve é texto escrito por terceiros.

O valor de um formato deste tipo é tornar as capacidades partilháveis. Alguém escreve uma competência para uma tarefa específica, publica-a e outras pessoas instalam-na. Essa conveniência tem riscos, porque uma competência é código de terceiros que o agente executará sem hesitação. Por isso, vale a pena submeter tudo o que não escreveu a um analisador de segurança alojado por si antes de o carregar. Se criar o seu próprio agente, definir cedo um formato de extensões pequeno e claro evita ter de codificar mais tarde todas as capacidades no núcleo.

Traga o seu próprio modelo

O OpenClaw é independente do modelo. Não inclui o seu próprio modelo de linguagem. Em vez disso, liga-se ao modelo que escolher, que pode ser uma API alojada ou um modelo executado por si.

Esta separação é importante para o custo, a privacidade e o controlo. Uma API alojada disponibiliza os modelos mais avançados sem exigir hardware para gerir, com um preço por token e com os seus prompts a saírem do servidor. Um modelo autoalojado, servido com ferramentas como o Ollama, mantém todas as mensagens no seu próprio servidor e tem como custos apenas o hardware e a eletricidade, em troca de executar um modelo mais pequeno ou mais lento. Muitas pessoas combinam as duas opções. Se quiser manter um agente totalmente privado, alojar o modelo no seu VPS é o componente que elimina essa última lacuna, e o Hermes Agent é outro agente autoalojado que vale a pena comparar.

Você deve criar um?

É possível criar tudo isto. Os componentes não são exóticos: um daemon, alguns conectores de chat, um ciclo de modelo e ferramentas, uma pasta com ficheiros Markdown e um formato de plugins. Compreender estes componentes é realmente útil, porque elimina o mistério de qualquer agente que venha a usar e mostra exatamente onde está o risco.

Mas, para a maioria das pessoas, a resposta honesta é executar a solução real e reforçá-la, em vez de reinventá-la. O OpenClaw já resolveu os conectores, o ciclo de execução e o formato das skills, além de ter sido submetido a uma análise de segurança real. É melhor concentrar o esforço na parte que cabe a si fazer corretamente: a configuração e o reforço da segurança no seu próprio servidor. Se preferir começar pelo percurso de aprendizagem, avançar pelos conceitos em etapas é melhor do que ler o código-fonte do agente sem contexto, porque cada etapa deixa uma coisa que realmente construiu. Crie uma versão pequena para aprender. Execute e proteja a versão real para a utilizar.

Os fundamentos gerais estão em criar o seu próprio agente de IA num VPS, e criar um agente com Claude apresenta as mesmas ideias usando um modelo específico como cérebro.

FAQ

É difícil criar um agente como o OpenClaw?

As partes individuais não são difíceis. Um processo de gateway, um conector de chat, um ciclo de modelo e ferramentas e uma pasta de ficheiros são componentes simples por si só. A parte difícil é fazê-lo com segurança. Um agente que executa comandos shell a partir de mensagens de chat cria uma superfície de segurança séria. Configurar corretamente o sandbox, as permissões e a execução com um utilizador sem privilégios exige mais trabalho do que ligar as funcionalidades.

Por que razão o OpenClaw armazena a memória em ficheiros Markdown em vez de usar uma base de dados?

Porque, para um agente pessoal de um único utilizador, os ficheiros são suficientes e muito mais simples. Não é necessário executar um serviço de base de dados. A memória é fácil de ler e corrigir manualmente. Mover o agente para outro servidor consiste apenas em copiar um diretório. Uma base de dados justifica-se a uma escala maior, não neste caso.

Qual é a parte mais perigosa de um agente de IA pessoal?

São as ferramentas que lhe permitem agir: executar comandos shell, controlar um browser e escrever ficheiros. Essas ferramentas são a razão para criar o agente e também a razão pela qual ele pode causar danos. O incidente de segurança do OpenClaw em March 2026, com nine issues em four days, incluindo uma vulnerabilidade crítica com classificação 9.9, é o argumento mais claro para tratar a camada de ferramentas com cuidado: execute o agente com um utilizador sem privilégios, exija autorização para ações destrutivas e coloque a execução num sandbox.

Preciso do meu próprio modelo de linguagem para criar um agente?

Não. Agentes como o OpenClaw são independentes do modelo, pelo que pode ligar o modelo que escolher. Pode usar uma API alojada para obter os modelos mais avançados ou um modelo executado por si para ter privacidade total. A execução local com Ollama mantém todas as mensagens no seu próprio servidor, mas implica usar um modelo mais pequeno.