Agente de IA autônomo: como deixar o agente trabalhar horas sem produzir lixo

O que é um agente de IA autônomo e em que ele difere de um pedido comum

O trabalho comum com um agente é passo a passo: você escreve um prompt, o agente dá um passo, você olha o resultado e decide o próximo. Já um agente de IA autônomo trabalha em ciclo: você descreve uma vez como é o estado final e, a partir daí, o agente repete sozinho o ciclo «fazer — verificar — corrigir», até que o objetivo seja atingido ou o orçamento se esgote. Depois de iniciado, você pode se afastar.

Parece simples, mas a primeira experiência costuma ser esta: o agente recebe a tarefa de manhã e, à noite, você descobre que ele passou horas ajustando um bug que já estava corrigido, porque esqueceu o que fez uma hora antes. Ninguém disse a ele quando parar e quando chamar uma pessoa. A seguir, veja como projetar um ciclo que evita isso.

Uma ressalva importante: o ciclo não substitui o harness. O harness torna uma execução confiável, e o ciclo torna as execuções contínuas. Um ciclo sobre um harness ruim só produz lixo mais rápido.

Quais tarefas servem para um agente autônomo

A primeira pergunta é se o trabalho tem uma linha de chegada que a máquina consegue checar. «Todos os testes em tests/payments passam», «todas as funcionalidades da lista estão com status passing», «a métrica cresceu em relação à linha de base» — isso serve. «Deixe o código melhor» ou «continue melhorando os pagamentos» não serve: esse objetivo não tem fim, e o ciclo vai girar até consumir todo o orçamento.

Vale distinguir quatro tipos de ciclo:

• Passo a passo — você digita cada prompt; é o trabalho interativo comum.
• Por objetivo — você define a meta, e a parada vem de uma verificação independente ou do orçamento. É isso que caracteriza um agente autônomo de horas.
• Por tempo — execução agendada (por exemplo, a análise matinal de builds de CI que falharam), que você interrompe manualmente.
• Por evento — um gatilho externo (uma nova issue, um deploy que falhou) inicia o trabalho, e o processamento do evento ou o limite de repetições o encerra.

Um erro frequente é confundir o ciclo por tempo com o ciclo por objetivo: «a cada 10 minutos continue fazendo os pagamentos». Um ciclo agendado começa a instrução do zero a cada vez e não sabe o que já foi feito. Se a tarefa tem fim, é preciso um ciclo por objetivo com memória do progresso.

Passo 1. Sandbox: onde o agente pode quebrar coisas

Um agente que trabalha sem supervisão, cedo ou tarde, fará algo errado: apagará um arquivo, reescreverá uma migração, executará um comando pesado. Por isso a pergunta não é «como fazer para ele não errar», e sim «como fazer para que um erro não custe nada».

• Cópia de trabalho separada. O git worktree dá ao agente um diretório e uma branch próprios sobre o mesmo repositório. A branch principal não é tocada, vários agentes não interferem uns nos outros, e uma execução malsucedida é removida com um único comando.
• Contêiner ou máquina virtual. Se o agente precisa de acesso total aos comandos, rode-o em um contêiner sem acesso ao diretório pessoal, às chaves e aos bancos de produção.
• Dados de teste. Banco local, sandboxes de provedores de pagamento, chaves fictícias. Nenhum segredo de produção no ambiente do agente.

# branch e diretório próprios para a execução autônoma
git worktree add ../shop-agent -b agent/f03-refunds

# depois da execução: ver o resultado ou descartar
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

Passo 2. Permissões: o mínimo necessário para a tarefa

Quanto mais tempo o agente trabalha sozinho, mais restritas devem ser as permissões dele. No Claude Code, as permissões são configuradas no settings.json (listas allow e deny para ferramentas e comandos): permita explicitamente o que a tarefa exige — rodar testes, o linter, editar arquivos na cópia de trabalho — e proíba o perigoso: push para a branch principal, acesso a segredos, comandos de rede, quando não forem necessários.

O modo em que o agente executa tudo sem confirmações só é aceitável dentro de um sandbox isolado, onde o pior resultado é descartar um contêiner. Em uma máquina de trabalho com acesso às suas chaves e aos seus repositórios, isso não pode ser feito.

Proibições que não podem ser violadas devem ser reforçadas por mecanismos, não apenas por texto. A linha «não toque em migrations/» nas instruções é um pedido; um hook que bloqueia a edição desse diretório, ou as permissões do sistema de arquivos, é uma garantia.

Passo 3. Objetivo, verificação, parada — três linhas antes de iniciar

Um ciclo autônomo simples e funcional se apoia em três coisas, que convém registrar antes de começar, e não no meio da execução:

1. Objetivo — como é o estado final.
2. Verificação — uma forma verificável por máquina de saber que o objetivo foi atingido: um comando que retorna sucesso ou erro.
3. Condição de parada — um limite de tentativas, de tempo ou de custo, após o qual o ciclo para mesmo que o objetivo não tenha sido atingido.

É útil manter isso em um arquivo de metodologia que só a pessoa edita. Exemplo para um backend de pagamentos:

# program.md — metodologia da execução autônoma

## Objetivo
Todas as funcionalidades de .agent/feature_list.json estão com status passing.

## Métrica
Número de funcionalidades em passing. Cresce de forma monotônica. Regressão = reversão imediata.

## Restrições
- Uma funcionalidade em andamento por vez.
- Não alterar migrations/ e infra/.
- Não mexer em dependências sem registro no diário.

## Ordem de trabalho
1. Pegar a primeira funcionalidade que não está em passing.
2. Implementar, rodar pytest e o linter.
3. Verde — commit e registro em .agent/progress.md. Vermelho — corrigir.

## Parada e escalonamento
- 3 tentativas malsucedidas em uma funcionalidade — marcar como blocked e seguir para a próxima.
- Todas as restantes em blocked — parar e escrever um relatório.
- Qualquer tarefa sobre dinheiro de clientes, permissões de acesso ou exclusão de dados — não executar, e sim escalonar.

Passo 4. Ciclo verificar-corrigir com memória em disco

A janela de contexto não sobrevive a um trabalho longo: ela transborda, é compactada, a sessão é reiniciada. Por isso o progresso precisa viver em arquivos, e não na «cabeça» do agente: uma lista de tarefas com status, um diário do que foi feito e do que não funcionou, o histórico do git.

Um bom modelo é a «catraca que avança só para a frente», do projeto autoresearch de Andrej Karpathy, em que o agente conduz centenas de experimentos de ML durante a noite. Cada iteração: ler a metodologia, formular uma hipótese, fazer uma alteração, rodar o experimento com um orçamento de tempo fixo, comparar com a linha de base. Melhorou — commit; não melhorou — reverter. O resultado vai para o diário, e então vem a próxima hipótese.

Dessa estrutura valem duas decisões:

• Orçamento fixo por tentativa. As tentativas ficam comparáveis, e uma hipótese fracassada não consome a noite inteira.
• Na branch principal, só melhorias. Tudo o que não funcionou é revertido, e não deixado ao lado. O git log vira um diário verificado do trabalho, fácil de ler pela manhã.

Nesse mesmo esquema, a divisão de papéis aparece nos arquivos: a infraestrutura e a avaliação não são editadas por ninguém; o código do experimento é editado só pelo agente; a metodologia, só pela pessoa. O agente não consegue «melhorar» o resultado alterando a forma como ele é medido.

Passo 5. Quem decide que está pronto: um avaliador separado

Quando não há pessoa no ciclo, a autoavaliação do agente é o único freio — e esse freio não funciona. O agente que acabou de escrever o código tende a considerá-lo correto: ele vê o próprio raciocínio e «sabe» o que queria fazer.

Regras para separar o gerador do avaliador:

• Quem avalia não é a sessão que fez o trabalho. No Claude Code, subagentes são úteis para isso, pois cada um tem seu próprio contexto.
• O avaliador recebe um contexto limpo: o requisito, o diff e os resultados das execuções — e nada do raciocínio do executor.
• Sempre que possível, o avaliador é outro modelo ou, no mínimo, outro prompt com outro papel.
• O veredito é dado por uma rubrica, e cada item aponta uma evidência: a linha de um teste, a saída de um comando, o trecho do diff.

As verificações por máquina continuam sendo as primárias. O avaliador serve para o que os testes não pegam: o requisito foi entendido de forma errada, o teste foi ajustado ao código, a alteração saiu do escopo da tarefa.

Critérios de parada: quando o agente deve desistir

Um ciclo sem condições de parada entra em loop — é só uma questão de tempo. O conjunto mínimo:

Verifique o progresso pelo conteúdo, e não pelo número de tentativas: «foram 40 iterações» não diz nada; «o número de funcionalidades verdes subiu de 5 para 9» diz. Se a tarefa travou, isso é motivo para passá-la a uma pessoa, e não para rodar o ciclo mais uma vez.

Riscos do agente autônomo que não aparecem de imediato

Os riscos óbvios — arquivos apagados e build quebrado — são controlados pelo sandbox e pelas permissões. Mais perigosos são os custos silenciosos que se acumulam por semanas:

• Dívida de verificação. «Parece normal» no lugar de «confirmado por máquina». O antídoto são apenas condições de parada verificáveis por máquina, sem exceções.
• Perda de entendimento. Você conhece cada vez menos o próprio código. O antídoto é ler os diffs de forma obrigatória: a velocidade do ciclo não deve superar a sua velocidade de leitura.
• Capitulação cognitiva. Você deixa de ter opinião sobre o resultado e aceita tudo. Vale contar com honestidade os casos em que disse «vejo depois» e não viu.
• Inchaço do contexto. Uma execução longa acumula histórico, e cada passo seguinte fica mais caro e pior. Compactação de contexto e memória externa são necessárias desde o primeiro ciclo, e não quando tudo já saiu do controle.

Como rodar o primeiro ciclo autônomo em uma noite

Não comece com «o agente sozinho encontra e faz as tarefas». A autonomia cresce por degraus: primeiro, uma tarefa com objetivo e condição de parada; depois, uma automação agendada; em seguida, executor e verificador separados em uma cópia de trabalho isolada; e só então ciclos que encontram o trabalho sozinhos e rodam em paralelo.

1. Escolha uma tarefa que você faz à mão pelo menos duas vezes por semana e que tenha um fim verificável.
2. Escreva o objetivo, a verificação e a condição de parada — três linhas.
3. Crie um worktree separado e configure as permissões: testes e edição de arquivos liberados; push e segredos, não.
4. Crie um arquivo de progresso e peça ao agente que o atualize a cada iteração.
5. Separe os papéis: o executor escreve, e o verificador, em outro contexto, avalia o diff.
6. Defina um limite total e confira o primeiro resultado depois de uma hora, e não de manhã.

Resumo

Um agente de IA autônomo é confiável na mesma medida em que são confiáveis os seus limites: um sandbox em que um erro não custa nada, permissões mínimas, um objetivo verificável por máquina, memória em disco, um avaliador separado e condições de parada rígidas com escalonamento para uma pessoa. Sem isso, uma execução longa não economiza tempo; ela apenas adia a limpeza da bagunça. Como montar um ciclo desses em um projeto de ponta a ponta — do program.md até o avaliador independente — é algo que o curso de harness engineering mostra na prática.