Como criar um agente de IA em um VPS

O que um agente de IA realmente é

Um agente de IA é um loop em torno de um modelo de linguagem. O modelo analisa a situação, decide por uma ação, seu código executa essa ação, o resultado volta para o modelo, e o loop recomeça até que a tarefa seja concluída. Essa é a ideia central. Um chatbot comum responde uma vez e para. Um agente continua operando, realizando ações reais entre seus próprios turnos, até atingir o objetivo definido.

A ação é a parte crucial. Por conta própria, um modelo de linguagem produz apenas texto. Ele não consegue ler um arquivo, chamar uma API ou executar um comando. Um agente fornece ao modelo um conjunto de ferramentas que ele tem permissão para usar, e uma forma de solicitá-las. Quando o modelo deseja pesquisar na web ou escrever um arquivo, ele não realiza o trabalho diretamente. Ele emite uma requisição estruturada, seu código executa a ferramenta, e a resposta retorna como a próxima leitura do modelo. O modelo fornece o julgamento; seu servidor fornece as mãos.

Nem toda tarefa exige um agente, e recorrer a um por padrão é um erro comum. Se os passos são conhecidos antecipadamente, um script simples é mais simples, rápido e confiável. "Busque esta página a cada hora e envie o preço por e-mail" é um job agendado, não um agente. Construa um agente quando o caminho não estiver definido previamente, ou quando o modelo precisar analisar o que encontrou para decidir o próximo passo. O custo de um agente é a imprevisibilidade, portanto, utilize-o apenas quando a flexibilidade justificar o uso.

Ferramentas: como um agente age

Uma ferramenta é qualquer capacidade que você entrega ao modelo, descrita de forma clara o suficiente para que ele saiba quando utilizá-la. Ler um arquivo, executar um comando shell, consultar um banco de dados, enviar uma mensagem: cada um é uma ferramenta com um nome, uma descrição curta e uma lista de inputs. Você define as ferramentas; o modelo decide quando chamá-las.

O mecanismo é o mesmo em qualquer lugar, independentemente do modelo utilizado. O modelo retorna uma requisição estruturada que nomeia uma ferramenta e preenche seus inputs. Seu código identifica essa requisição, executa a função correspondente e envia o resultado de volta no próximo turno. O modelo lê o resultado e chama outra ferramenta ou escreve sua resposta final. O function calling é a infraestrutura de todo agente, e o loop que o impulsiona consiste em apenas algumas linhas de código comum.

É aqui também que reside o seu controle. O modelo pode solicitar a execução de um comando, mas nada é executado até que seu código decida executá-lo. Nesse intervalo, você insere prompts de aprovação para ações perigosas, limites para o que uma ferramenta pode tocar e um log de tudo o que o agente fez. Um agente é tão seguro quanto as ferramentas que você fornece e as verificações que implementa antes delas.

MCP: um padrão para conectar ferramentas

Escrever uma integração nova para cada serviço manualmente torna-se cansativo rapidamente. O Model Context Protocol, ou MCP, é um padrão aberto que resolve isso. Em vez de codificar uma nova ferramenta para seus arquivos, seu banco de dados e seu rastreador de problemas, você aponta o agente para um servidor MCP que já expõe esses itens como ferramentas. O agente fala um único protocolo; o servidor realiza o trabalho de comunicação com o sistema real.

O benefício é o reuso. Um servidor MCP escrito por terceiros para um serviço que você utiliza torna-se disponível para seu agente sem necessidade de novo código de integração, e um servidor que você escrever será utilizável por qualquer agente que fale o protocolo. Em um VPS, isso é importante, pois você pode rodar servidores MCP como serviços pequenos e independentes ao lado do agente, cada um com apenas o acesso necessário. Eu detalho a configuração em rodando servidores MCP em um VPS.

Memória e recuperação

Um modelo de linguagem não possui memória própria entre as chamadas. Tudo o que ele sabe sobre a tarefa atual deve ser entregue a ele em cada turno. Para tarefas curtas isso funciona, pois toda a conversa cabe em uma única requisição. Para qualquer coisa mais longa, você deve gerenciar a memória manualmente, e existem dois padrões que valem a pena conhecer.

O primeiro é o scratchpad (rascunho). Você fornece ao agente um arquivo que ele pode ler e escrever, e instrui-o a registrar o que aprende enquanto avança. No próximo turno, ou na próxima sessão, ele lê o arquivo e retoma de onde parou. Esta é a memória como um documento simples, e funciona porque o agente trata o arquivo como apenas mais uma ferramenta.

O segundo é a recuperação (retrieval). Quando o agente precisa de conhecimento de um grande volume de documentos que não caberiam em uma única requisição, você armazena esses documentos de forma pesquisável e extrai apenas as partes relevantes para a visão do modelo quando necessário. Este padrão é chamado de retrieval-augmented generation, ou RAG. O agente faz uma pergunta, seu código encontra os trechos correspondentes e apenas eles são enviados ao modelo. O armazenamento reside no seu servidor, garantindo que seus documentos privados nunca saiam dele.

Muitos agentes, um coordenador

Um único agente com muitas ferramentas atende à maioria das tarefas. Quando um trabalho é grande ou se divide naturalmente em partes, uma estrutura diferente ajuda: um agente coordenador que delega para subagentes especializados. O coordenador divide o objetivo em partes, entrega cada parte a um subagente construído para aquele tipo de trabalho e combina os resultados.

O ganho é o foco. Um subagente com uma função estreita e um conjunto limitado de ferramentas toma decisões melhores do que um generalista que lida com tudo, e partes independentes podem rodar simultaneamente. O custo é a coordenação, que é real, portanto, mantenha-se em um único agente até que uma tarefa claramente exija mais. Comece de forma simples e adicione agentes apenas quando um único agente estiver claramente sobrecarregado.

Self-hosted ou hospedado: qual modelo roda seu agente

O modelo é a única parte de um agente que você não precisa rodar por conta própria, e escolher onde ele reside é a decisão mais importante que você tomará. Um modelo hospedado, acessado via API, oferece o raciocínio mais forte sem necessidade de operação: você envia texto e recebe texto de volta. Um modelo self-hosted roda em seu próprio servidor, o que mantém cada requisição privada, possui um custo fixo em vez de uma taxa por token e não depende da disponibilidade de terceiros. A troca é entre capacidade e esforço. Os melhores modelos hospedados estão à frente do que você pode rodar sozinho, e rodar o seu próprio significa fornecer memória suficiente para acomodá-lo.

Este último ponto é o entrave prático. Um modelo deve caber na memória do seu servidor e, se você usar uma GPU, na sua memória de vídeo. Um modelo grande demais para o hardware não carregará. Antes de planejar um agente self-hosted, verifique se o modelo desejado cabe na máquina que você possui:

Se os números não coincidirem, você tem três opções: escolha um modelo menor, use uma quantização mais agressiva para reduzir o tamanho ou use uma API hospedada para o raciocínio e mantenha apenas suas ferramentas e dados no servidor. Muitos agentes self-hosted começam com um modelo local via Ollama em um VPS e recorrem a uma API hospedada para as etapas mais difíceis.

O servidor é a parte perigosa

Um agente capaz de executar comandos shell e escrever arquivos é poderoso, e é exatamente por isso que é perigoso. O julgamento do modelo é bom, mas não é perfeito; uma instrução errada, um bug ou um input malicioso podem transformar um agente útil em um que deleta o item errado ou vaza um segredo. O trabalho de segurança não é opcional e, em um servidor, é a parte mais importante.

Alguns hábitos carregam a maior parte da responsabilidade. Rode o agente como um usuário dedicado sem privilégios, nunca como root, para que um erro tenha um limite de impacto; o mesmo raciocínio está em rodando serviços como um usuário sem privilégios. Mantenha os segredos dele, como chaves de API, fora do código e legíveis apenas por esse usuário. E faça o sandbox das ferramentas que tocam o sistema, para que o agente só alcance o que realmente precisa. Para um exemplo prático de endurecimento (hardening) de um agente self-hosted real, veja rodando OpenClaw com segurança em um VPS. Se preferir usar um modelo hospedado para a inteligência, o guia complementar sobre construindo um agente com Claude em um VPS aplica os mesmos conceitos utilizando um modelo específico.

Para um exemplo prático, construindo um agente pessoal estilo OpenClaw aplica estas peças, e se preferir rodar um pronto, comece com self-hosting Hermes Agent em um VPS ou rodando Agent Zero em seu próprio servidor, e os melhores agentes de IA self-hosted em 2026 compara cada opção pronta que cobrimos, lado a lado.

FAQ

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

Um chatbot responde uma mensagem e para. Um agente executa um loop: o modelo decide uma ação, seu código a executa, o resultado volta para o modelo e ele repete o processo até a tarefa ser concluída. A diferença é que um agente realiza ações reais entre seus turnos, chamando ferramentas para ler arquivos, executar comandos ou consultar serviços, em vez de apenas produzir texto.

Eu preciso de uma GPU para rodar um agente de IA em um VPS?

Apenas se você hospedar o modelo (self-host). O loop do agente, as ferramentas e a memória são códigos comuns que rodam bem em um VPS normal sem GPU. A GPU é necessária quando você deseja rodar o modelo de linguagem em seu próprio hardware, pois o modelo precisa caber na memória. Se você usar um modelo hospedado via API, o processamento pesado ocorre em outro lugar e um VPS modesto é suficiente.

O que é MCP e eu preciso dele para construir um agente?

MCP, o Model Context Protocol, é um padrão aberto para conectar um agente a ferramentas e fontes de dados. Você não precisa estritamente dele, já que pode escrever cada ferramenta manualmente. O MCP economiza esse trabalho ao permitir o reuso de servidores existentes para serviços comuns e a exposição de seus próprios sistemas uma única vez para qualquer agente utilizar. É uma conveniência que se justifica conforme o número de integrações cresce.

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

Pode ser, se você o contiver. Um agente que executa comandos é tão seguro quanto a conta sob a qual ele opera e as ferramentas que você permite. Rode-o como um usuário sem privilégios, mantenha seus segredos fora de alcance, faça o sandbox das ferramentas que tocam o sistema de arquivos 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 forneça apenas o que a tarefa exige.