Como criar seu próprio agente de IA em um VPS

O que é realmente um agente de IA

Um agente de IA é um ciclo à volta de um modelo de linguagem. O modelo lê a situação, decide uma ação, o seu código executa essa ação, o resultado volta ao modelo e o ciclo repete-se até a tarefa estar concluída. Essa é a ideia completa. Um chatbot simples responde uma vez e para. Um agente continua, executando ações reais entre as suas próprias interações, até atingir um objetivo que lhe foi dado. O ciclo é suficientemente pequeno para ser escrito por si numa tarde. É aí que começa um percurso faseado para aprender a criar agentes do zero, antes de adicionar ferramentas, memória e segurança.

A ação é a parte importante. Por si só, um modelo de linguagem apenas produz texto. Não consegue ler um ficheiro, chamar uma API ou executar um comando. Um agente fornece ao modelo um conjunto de ferramentas que ele pode utilizar e uma forma de as solicitar. Quando o modelo quer pesquisar na web ou escrever um ficheiro, não executa o trabalho diretamente. Emite um pedido estruturado, o seu código executa a ferramenta e a resposta volta como o próximo conteúdo que o modelo lê. O modelo fornece o discernimento; o seu servidor fornece os meios para agir.

Nem todas as tarefas precisam de um agente, e tentar usar um por defeito é um erro comum. Se os passos forem conhecidos antecipadamente, um script simples é mais fácil, rápido e fiável. "Obter esta página a cada hora e enviar-me o preço por email" é uma tarefa agendada, não um agente. Crie um agente quando o percurso não estiver definido antecipadamente, quando o modelo tiver de analisar o que encontrou e decidir o que fazer a seguir. O custo de um agente é a imprevisibilidade. Por isso, só o assuma quando a flexibilidade compensar esse custo.

Ferramentas: como um agente atua

Uma ferramenta é qualquer capacidade que se disponibiliza ao modelo e se descreve com detalhe suficiente para ele saber quando a deve utilizar. Ler um ficheiro, executar um comando shell, consultar uma base de dados ou enviar uma mensagem: cada ação é uma ferramenta com um nome, uma descrição curta e uma lista de entradas. Você define as ferramentas; o modelo decide quando as deve chamar. A pesquisa na Web costuma ser a primeira ferramenta que vale a pena adicionar. Se já executa a sua própria instância SearXNG, pode transformá-la no backend de pesquisa do agente em vez de pagar por uma API de pesquisa comercial.

O mecanismo é igual em qualquer contexto, independentemente do modelo utilizado. O modelo devolve um pedido estruturado que identifica uma ferramenta e preenche as respetivas entradas. O seu código recebe esse pedido, executa a função correspondente e envia o resultado na interação seguinte. O modelo lê o resultado e chama outra ferramenta ou escreve a resposta final. O function calling é a infraestrutura subjacente a todos os agentes. O loop que o executa tem apenas algumas linhas de código comum.

É também aqui que fica o seu controlo. O modelo pode pedir para executar um comando, mas nada é executado até o seu código decidir fazê-lo. É nesse intervalo que deve colocar pedidos de aprovação para ações perigosas, limites sobre aquilo que uma ferramenta pode modificar e um log de tudo o que o agente fez. A segurança de um agente depende apenas das ferramentas que lhe disponibiliza e das verificações que coloca à frente delas.

MCP: uma forma padrão de ligar ferramentas

Escrever manualmente uma integração nova para cada serviço torna-se rapidamente cansativo. O Model Context Protocol, ou MCP, é um padrão aberto que resolve este problema. Em vez de programar uma ferramenta nova para os seus ficheiros, a sua base de dados e o seu gestor de tarefas, aponte o agente para um servidor MCP que já disponibiliza esses recursos como ferramentas. O agente utiliza um único protocolo; o servidor trata da comunicação com o sistema real.

A principal vantagem é a reutilização. Um servidor MCP criado por outra pessoa para um serviço que utiliza fica disponível para o seu agente sem código de integração adicional, e um servidor que criar pode ser utilizado por qualquer agente compatível com o protocolo. Algumas aplicações self-hosted já incluem um servidor próprio: openGym, um registo de treinos disponibiliza um servidor MCP apenas de leitura, para que um agente possa responder a perguntas sobre o seu histórico de treinos sem o poder alterar. Num VPS, isto é importante porque pode executar os servidores MCP como pequenos serviços independentes junto do agente, atribuindo a cada um apenas o acesso de que necessita. Quando os sistemas por trás desses servidores estão numa rede que o VPS não consegue ver, como uma base de dados em casa ou num escritório, anunciar essa rede à sua tailnet com um router de sub-rede permite que o agente lhes aceda através de endereços privados sem expor nada à internet pública. Explico a configuração em executar servidores MCP num VPS.

Memória e recuperação

Um modelo de linguagem não tem memória própria entre chamadas. Tudo o que sabe sobre a tarefa atual tem de lhe ser fornecido em cada turno. Para uma tarefa curta, isso não é um problema, porque toda a conversa cabe num único pedido. A quantidade que cabe depende da janela de contexto, e um modelo self-hosted servido pelo Ollama recebe uma janela predefinida pequena que descarta silenciosamente os turnos mais antigos. Por isso, definir num_ctx para corresponder ao tráfego gerado pelo seu loop é uma medida útil antes de atribuir ao agente a falha de se esquecer. Para tarefas mais longas, tem de gerir a memória por sua conta. Há dois padrões que vale a pena conhecer.

O primeiro é um scratchpad. Dá ao agente um ficheiro que ele pode ler e escrever e instrui-o a registar o que aprende à medida que avança. No turno seguinte ou na sessão seguinte, ele lê novamente o ficheiro e retoma o trabalho a partir desse ponto. Isto é memória sob a forma de um documento simples. Funciona porque o agente trata o ficheiro como qualquer outra ferramenta.

O segundo é a recuperação. Quando o agente precisa de conhecimento proveniente de um conjunto grande de documentos que nunca caberia num único pedido, armazena esses documentos num formato pesquisável e introduz na visão do modelo apenas as partes relevantes quando são necessárias. Este padrão chama-se geração aumentada por recuperação, ou RAG. O agente faz uma pergunta, o seu código encontra as poucas passagens correspondentes e apenas essas passagens são enviadas para o modelo. O armazenamento fica no seu servidor, por isso os seus documentos privados nunca saem dele.

Muitos agentes, um coordenador

Um agente com muitas ferramentas resolve a maioria das tarefas. Quando um trabalho é grande ou se divide naturalmente em partes, outra estrutura pode ser mais adequada: um agente coordenador que delega tarefas a subagentes especializados. O coordenador divide o objetivo em partes, atribui cada uma a um subagente preparado para esse tipo de trabalho e combina os resultados. A delegação precisa de um canal entre as partes. A versão mais simples desse canal já está disponível no seu servidor: duas sessões do Claude Code no mesmo VPS podem enviar mensagens entre si. Esta é uma forma barata de perceber como as transferências de tarefas funcionam antes de criar uma infraestrutura de coordenação própria.

A vantagem é o foco. Um subagente com uma tarefa restrita e um conjunto pequeno de ferramentas toma decisões melhores do que um agente generalista a gerir tudo ao mesmo tempo. As partes independentes também podem ser executadas em simultâneo. O custo é a coordenação, que é real. Por isso, mantenha um único agente até que uma tarefa mostre claramente que precisa de mais. Comece de forma simples e adicione agentes apenas quando um deles estiver claramente sobrecarregado.

Modelo self-hosted ou alojado: qual modelo executa o seu agente

O modelo é a única parte de um agente que não precisa de executar por conta própria, e escolher onde ele fica é a maior decisão que terá de tomar. Um modelo alojado, acedido através de uma API, oferece o melhor raciocínio sem exigir operação da sua parte: envia texto e recebe texto. Um modelo self-hosted é executado no seu próprio servidor, mantém cada pedido privado, tem um custo fixo em vez de uma tarifa por token e nunca depende de terceiros permanecerem disponíveis. A contrapartida está na capacidade e no esforço. Os melhores modelos alojados estão à frente do que pode executar por conta própria, e executar o seu próprio modelo exige memória suficiente para o alojar.

Esse último ponto é a limitação prática. O modelo tem de caber na memória do servidor e, se utilizar uma GPU, na respetiva memória de vídeo. Um modelo demasiado grande para o hardware não será carregado. Antes de planear um agente self-hosted, confirme se o modelo pretendido cabe na máquina disponível:

Se os valores não forem suficientes, tem três opções: escolher um modelo mais pequeno, utilizar uma quantização mais agressiva para o reduzir ou usar uma API alojada para o raciocínio e manter apenas as suas ferramentas e dados no servidor. Muitos agentes self-hosted começam com um modelo local através de Ollama numa VPS e recorrem a uma API alojada para as etapas mais exigentes.

O servidor é a parte perigosa

Um agente que pode executar comandos shell e escrever ficheiros é poderoso, e é exatamente por isso que é perigoso. O discernimento do modelo é bom, mas não é perfeito, e uma instrução incorreta, um erro de software ou uma entrada hostil podem transformar um agente útil num agente que elimina o item errado ou expõe um segredo. O trabalho de segurança não é opcional e, num servidor, é a parte mais importante.

Alguns hábitos têm o maior impacto. Execute o agente com um utilizador dedicado sem privilégios, nunca como root, para limitar as consequências de um erro; o mesmo princípio aplica-se a executar serviços com um utilizador sem privilégios. Mantenha os segredos, como chaves de API, fora do código e legíveis apenas por esse utilizador. Coloque em sandbox as ferramentas que interagem com o sistema, para que o agente só possa aceder ao que realmente precisa. Se preferir não escrever manualmente todas as verificações, os plugins do DeepSeek Harness que vale a pena instalar cobrem os mesmos requisitos com componentes prontos: regras de permissões das ferramentas, análise de prompt injection e um limite para o que o agente pode gastar antes de parar. Para um exemplo prático de proteção de um agente real autoalojado, consulte executar o OpenClaw com segurança numa VPS. Se preferir usar um modelo alojado para a componente de inteligência, o guia complementar sobre criar um agente com Claude numa VPS aplica as mesmas ideias e utiliza um modelo específico.

Para um exemplo prático, criar um agente pessoal ao estilo do OpenClaw aplica estes componentes. Se preferir executar um agente pronto, comece por autoalojar o Hermes Agent numa VPS ou executar o Agent Zero no seu próprio servidor. A comparação melhores agentes de IA autoalojados em 2026 apresenta, lado a lado, todas as opções prontas que abordamos.

FAQ

Qual é a diferença entre um agente de IA e um chatbot?

Um chatbot responde a uma mensagem e para. Um agente executa um ciclo: o modelo decide uma ação, o seu código executa-a, o resultado regressa ao modelo e o processo repete-se até a tarefa terminar. A diferença é que um agente executa ações reais entre as suas interações. Para isso, chama ferramentas que leem ficheiros, executam comandos ou consultam serviços, em vez de produzir apenas texto.

Preciso de uma GPU para executar um agente de IA numa VPS?

Apenas se alojar o modelo por conta própria. O ciclo do agente, as ferramentas e a memória são código normal que funciona numa VPS comum sem GPU. Uma GPU é relevante quando pretende executar o modelo de linguagem no seu próprio hardware, porque o modelo tem de caber na memória. Se utilizar um modelo alojado através de uma API, o processamento pesado ocorre noutro local e uma VPS modesta é suficiente.

O que é o MCP e preciso dele para criar um agente?

O MCP, Model Context Protocol, é um padrão aberto para ligar um agente a ferramentas e fontes de dados. Não precisa obrigatoriamente dele, porque pode escrever cada ferramenta manualmente. O MCP evita esse trabalho ao permitir reutilizar servidores existentes para serviços comuns e expor os seus próprios sistemas uma vez para que qualquer agente os utilize. É uma conveniência que se torna útil à medida que aumenta o número de integrações.

É seguro dar a um agente de IA acesso ao meu servidor?

Pode ser, se o isolar. A segurança de um agente que executa comandos depende da conta utilizada e das ferramentas que lhe permite utilizar. Execute-o como um utilizador sem privilégios, mantenha os segredos fora do seu alcance, coloque em sandbox as ferramentas que acedem ao sistema de ficheiros e exija aprovação para ações difíceis de reverter. Trate o agente como código não confiável que, por acaso, é inteligente, e dê-lhe apenas o que a tarefa exige.