Como Executar um Agente Autônomo em Seu Próprio Servidor

A maioria das pessoas que tentam deixar um agente de IA operar em um VPS real acaba em alguns lugares.

Ou eles o bloqueiam de tal forma que o agente mal consegue fazer algo útil (somente leitura, sem gravações, pedindo a um humano para copiar e colar o comando de volta), ou entregam uma chave SSH permanente e apenas esperam que nada seja hackeado. Ou o pior cenário, uma bagunça de deletações e reescritas de dados sensíveis sem nenhum backup feito.

Nenhuma dessas opções conta como executar um agente autônomo. Um é um chatbot com uma janela de leitura em seu servidor. O outro é uma arma carregada com a segurança desligada, estilo cowboy.

Há uma outra maneira, e é a única que realmente se sustenta uma vez que você está fazendo trabalho real em um sistema real. Nós a executamos diariamente contra nossa própria infraestrutura de produção. Aqui está exatamente como funciona, com uma situação real do trabalho ao vivo que fizemos hoje, não uma hipótese.

As três coisas que precisam ser verdadeiras ao mesmo tempo

Um agente operando em sua infraestrutura precisa fazer três coisas ao mesmo tempo, ou toda a configuração desmorona.

Ele precisa agir, não apenas sugerir. Se cada comando é copiado e colado por um humano em um terminal separado, você construiu uma maneira mais lenta de fazer o trabalho você mesmo.

Ele precisa falhar de forma segura. Se um comando de gravação der errado, deve haver um caminho de volta que não envolva seus usuários dizendo que o site está fora do ar.

E ele precisa lembrar. Se o agente esquece cada correção e cada incidente no momento em que uma sessão termina, ele resolve os mesmos problemas do zero, repetidamente. Isso custa mais tempo do que fazê-lo manualmente.

A maioria das configurações gerencia uma dessas. Acertar as três ao mesmo tempo é a parte realmente difícil, e é por isso que "basta dar ao AI um terminal" ou permanece inútil ou eventualmente causa um incidente real.

Como nós realmente fazemos isso
Cada comando é classificado antes de ser executado.

Trabalhos de leitura, verificação de logs, listagem de arquivos, verificação de um processo, são executados imediatamente sem atrito.

Qualquer coisa que escreva no disco, reinicie um serviço ou instale um pacote volta como uma ação pendente com o comando exato mostrado, e nada é executado até que seja aprovado pelo humano desleixado.

Alguns podem dizer que isso é doloroso, pois querem que o agente loop para sempre; é 100% necessário para evitar um derretimento agente de Chernobyl em seu VPS.

Cada gravação recebe sua própria aprovação, não um sinal verde para toda a sessão. Essa é a verdadeira diferença entre "o agente tem acesso SSH" e "o agente propõe comandos que um humano confirma", e isso deixa de ser uma abstração na primeira vez que algo quase dá errado.

Nada é tocado sem um backup primeiro. Antes de qualquer alteração de arquivo, uma cópia é feita automaticamente. Esse único hábito é a razão pela qual você pode deixar um agente fazer uma mudança real com confiança real em vez de dedos cruzados. Se ele errar, o que eventualmente acontecerá devido a um contexto humano ruim, inchaço ou apenas erros de loop, você volta para o backup salvo anterior.

As chaves não vivem no servidor que está sendo administrado. As credenciais ficam em um cofre criptografado e são retiradas apenas no exato momento em que são necessárias, depois são destruídas imediatamente: escritas, usadas, trituradas, em um passo, para que nunca haja uma janela onde uma sessão interrompida deixe uma chave ao vivo sentada no disco. Se um servidor gerenciado for comprometido, não há chave permanente nele para um atacante encontrar e reutilizar em outro lugar.

E ele lembra. Não dentro de uma única sessão de chat, mas ao longo de dias e através de qualquer ferramenta de IA que você tenha aberto. Uma correção feita três meses atrás em uma ferramenta diferente ainda pode ser lembrada hoje, porque a memória não está ligada à janela de chat de um único aplicativo. O agente tem acesso em tempo real para recordar milhares de memórias salvas com ações passadas.

Como isso se parecia hoje
Usamos exatamente essa configuração para fazer uma mudança real de produção: sincronizando novos links de navegação em 20 páginas HTML ao vivo em um site público. Aqui está o que realmente aconteceu.

Vinte e quatro backups automáticos foram feitos antes de qualquer coisa ser escrita, um por grupo de arquivos mais instantâneas individuais, sem necessidade de configuração manual. Cada comando de gravação mostrou uma prévia e precisava de aprovação explícita antes de tocar no site ao vivo, então nada foi executado silenciosamente. O site nunca ficou fora do ar. Verificado logo depois: HTTP 200, tempo de resposta de 14 milissegundos, zero reinicializações impulsionadas por falhas, zero tempo de inatividade.

Um teste de memória separado, executado fresco em uma nova sessão, perguntou simplesmente o que um determinado repositório faz. A resposta revelou um bug específico passado (uma função chamada getSlipstream() estava retornando exportações de módulo em vez de uma instância singleton adequada) que nenhuma quantidade de leitura do código atual teria revelado.

É para isso que a memória persistente realmente serve. Não lembrar o que um arquivo contém agora, mas lembrar o que já deu errado e como foi corrigido.

Essa é a ideia toda, demonstrada em vez de reivindicada: agir de verdade, falhar de forma segura, lembrar o que aconteceu. Perder qualquer uma das três e você não tem um agente autônomo. Você tem ou uma responsabilidade do tamanho de uma contaminação ou um brinquedo agente cron.

Por que não funciona sem isso
Ignore a etapa de aprovação e a primeira exclusão ou sobrescrita de configuração alucinado se torna um incidente real sem desfazer. Ignore o backup e "eu consertei" de um agente é uma afirmação que você ainda precisa verificar, o que apaga a maior parte do tempo que você achou que estava economizando.

Ignore o cofre e cada servidor que você apontou para um agente se torna um ponto de pivô no dia em que qualquer um deles for comprometido. Ignore a memória persistente e cada sessão começa de volta ao zero, então você não está economizando tempo algum, você está apenas pagando o imposto de "explicar tudo novamente" para sempre.

Nenhuma dessas coisas pode ser adicionada facilmente depois do fato. Cada uma é uma decisão real feita de antemão, e errar qualquer uma delas é a diferença entre uma ferramenta que você usa diariamente sem pensar e uma que você teme silenciosamente.

Como as peças realmente se conectam
Nada disso depende de qual cliente de IA você prefere. Claude Desktop, Claude Code, Cursor e Windsurf falam o mesmo protocolo por baixo, chamado MCP.

Esse protocolo é o que torna a configuração portátil em vez de construída sob medida para cada ferramenta. Você executa um pequeno servidor localmente (ou aponta para um que está rodando em outro lugar), e qualquer cliente compatível com MCP pode se conectar a ele da mesma forma, usando seu próprio arquivo de configuração, mas apontando para o mesmo processo subjacente.

Para memória, esse servidor é suportado por um banco de dados SQLite local com embeddings gerados em sua própria máquina, sem API de nuvem envolvida na recuperação em si. O único detalhe que confunde as pessoas, e que também nos confundiu na primeira vez, é que o caminho do banco de dados deve ser definido explicitamente na configuração de cada cliente.

Deixe-o de fora e o servidor volta para um local padrão, o que significa que Claude Code e Cursor podem acabar falando com dois bancos de dados diferentes, quase vazios, enquanto você assume que eles estão compartilhando um único cérebro. Registrá-lo para Claude Code se parece com isso:

claude mcp add vektor \
--env VEKTOR_LICENCE_KEY=your-key \
--env VEKTOR_DB_PATH=/home/you/.vektor/slipstream-memory.db \
-- node /path/to/vektor.mjs mcp
As mesmas duas variáveis de ambiente são definidas na configuração do Claude Desktop, em .cursor/mcp.json, e na configuração MCP do Windsurf. Quatro arquivos diferentes, quatro formatos diferentes, um banco de dados compartilhado.