Um teste que falha deve mudar o próximo passo
Imagine um agente corrigindo o filtro de datas de uma aplicação web. O pedido diz que selecionar 12 de outubro deve incluir os registros daquele dia inteiro. A primeira alteração exclui os registros posteriores à meia-noite. Se o agente apenas reler a própria explicação, pode anunciar que terminou com toda a confiança, enquanto o problema continua lá.
Com uma ferramenta para executar testes, a próxima decisão pode partir de uma evidência concreta: falta um registro da tarde. O agente examina o cálculo do intervalo, propõe outra alteração e testa novamente. Esse é o ciclo de execução: realizar uma ação, observar o resultado e decidir como continuar. A orientação básica da Anthropic sobre agentes descreve esse uso do retorno do ambiente. [L1]
Nesse exemplo hipotético, vale definir o resultado esperado antes de editar: a data selecionada inclui os registros corretos, as datas vizinhas ficam de fora e os testes existentes continuam passando. Sem isso, o agente pode gastar várias tentativas resolvendo o problema errado.
O que torna uma nova tentativa útil é a evidência que muda o próximo passo.
Destaque editorial · Frase editorial original, sem atribuição a terceiros.
Deixe um registro útil para a próxima tentativa
O ciclo precisa de um estado: comportamento solicitado, versão atual do código, arquivos alterados, teste que falhou, tentativas restantes e dúvidas em aberto. Uma sessão posterior também precisa saber a qual versão cada resultado pertence. Um teste aprovado em código antigo pode dar uma falsa sensação de segurança sobre uma alteração mais recente.
A memória é a informação preservada para decisões futuras. Aqui, um registro breve pode guardar a suposição errada sobre a meia-noite e apontar para o resultado do teste. Salvar esse registro não atualiza os pesos do modelo. Muda a informação disponível na próxima execução.
Mantenha os requisitos do usuário separados das anotações de trabalho do agente. Um exemplo recente de automação da Anthropic separa preferências fixas de estado mutável e alerta que conteúdo não confiável pode contaminar a memória. [L4]
O grafo define os caminhos
Ao desenhar esse processo como um grafo, cada nó representa uma etapa: examinar, editar, testar ou pedir revisão. As conexões indicam os caminhos possíveis. Um teste que falha pode levar de volta à edição; um requisito confuso pode levar a uma pessoa; o fim das tentativas pode encerrar a execução.
O grafo deixa essas transições explícitas. Por si só, ele não ensina ao agente uma estratégia melhor de correção. Repetir o caminho pode repetir o erro. Para melhorar, é preciso receber informação útil, mudar a decisão e verificar se a mudança ajudou. Prompts e instruções das ferramentas continuam influenciando essas escolhas.
Separe a execução do veredito
No exemplo do filtro de datas, mantenha os testes de aceitação fora do alcance de escrita do agente que edita o código. Um executor separado verifica a versão proposta e registra o que aconteceu. Antes de editar, peça a uma pessoa que esclareça requisitos ambíguos, como o fuso horário que define o dia selecionado.
Um modelo pode ajudar nessa revisão, mas um segundo agente pode compartilhar os pontos cegos do primeiro. A pesquisa da Anthropic sobre estruturas de execução encontrou valor em separar geração e avaliação, mas reconhece que os avaliadores ainda podem dar notas generosas demais. [L2]
Defina um limite concreto: uma tentativa inicial e, no máximo, duas novas tentativas, dentro de um orçamento fixo de tempo e gasto. Pare antes se o requisito estiver confuso. Ao atingir o limite, devolva a alteração, as evidências e a falha pendente. Neste exemplo, uma pessoa aprova a integração ou a publicação do código, mesmo que os testes passem.
Meça a evolução além de uma execução
Um exemplo corrigido só demonstra aquele resultado. Para avaliar o sistema, compare-o com uma solução mais simples em tarefas representativas, incluindo casos que ficaram fora do processo de ajuste. A orientação da Anthropic sobre avaliações recomenda casos reservados e mudanças controladas para revelar ajustes excessivos ao teste e regressões. [L3]
Acompanhe a conclusão correta das tarefas, os anúncios falsos de sucesso, a intervenção humana e o custo por tarefa concluída, contando também as tentativas que falharam. Observe as execuções lentas, além do tempo médio. Mantenha condições comparáveis e guarde os registros das falhas. Mais autonomia deve depender dessas evidências; acumular tentativas, sozinho, não prova melhora.
Fontes e referências
- Building effective agents
- Harness design for long-running application development
- Automating eval design and hillclimbing with Claude
- Building effective agent automations
- Lamis Mukta — Learning while you sleep: Beyond memory to dreaming — AI Native DevCon June 2026
Tem outro ponto de vista? Quero ouvir. hello@maisfps.com
