Tarefas longas com GPT-6: mantenha os agentes avançando de verdade

GPT-6 Astra consegue trabalhar em projetos extensos, mas uma execução longa só é útil enquanto se aproxima de um resultado aprovado. Dê ao agente um marco concreto, uma forma de verificar progresso e estado salvo suficiente para retomar após interrupções. Amplie o escopo depois que ele concluir uma fase relevante.

Isso importa em sites, pacotes de pesquisa, migrações de repositório ou entregas com vários documentos. Todos podem gerar horas de atividade sem resolver o requisito central. A pergunta operacional é se o trabalho mais recente torna a entrega final mais utilizável.

Fontes: análise de Matt Shumer; issue #43193 do Codex; notas de lançamento da OpenAI. Consultadas em 7 de setembro de 2026. Resultados e experiências são atribuídos aos respectivos autores ao longo do texto.

O que revelam as primeiras experiências

A análise do Astra por Matt Shumer descreve projetos ambiciosos que desaceleraram quando o modelo se prendeu a detalhes. Ele encontrou uma configuração de coordenação que ajudou a manter a direção, mas reconheceu que a autonomia em execuções longas ainda não está resolvida.

Uma issue pública do Codex sobre orquestração e cumprimento de instruções relata alto consumo junto de falhas repetidas de processo. É um relato de usuário, não uma taxa de falha medida, mas ilustra por que mais atividade de agentes não deve ser confundida com progresso.

Essas experiências sugerem um hábito: avaliar o que mudou desde o último checkpoint. Se nenhum critério de aceitação ficou mais perto de ser atendido, examine o plano antes de acrescentar tempo ou agentes.

Diagnostique o tipo de interrupção

Uma tarefa longa pode parar porque falta uma decisão, uma ferramenta falhou, a aplicação encerrou a execução ou o trabalho perdeu a direção. Cada caso pede uma resposta diferente. Repetir "continue" dificilmente resolve um arquivo ausente ou uma instrução conflitante.

As orientações do GPT-6 da OpenAI descrevem maior tendência a pedir esclarecimentos e sensibilidade às instruções dos arquivos acessíveis. Também documentam direcionamento durante o turno e chamadas assíncronas. Essas capacidades ajudam a aplicação a coordenar o trabalho, mas não garantem que qualquer sessão continue executando indefinidamente.

Uma discussão inicial sobre revisão de documentos relata estagnação mesmo com checkpoints e um coordenador. É uma experiência individual, mas destaca um limite prático: o checkpoint preserva progresso; ele não fornece um agendador nem conserta um ambiente de execução parado.

Exemplo completo: revisar um grande conjunto de documentos

Imagine que sua equipe precise comparar requisitos entre vários documentos. Esse projeto ilustrativo se beneficia de lotes, pois permite verificar cobertura e achados durante o andamento. Comece por um inventário, em vez de pedir imediatamente o relatório final.

Fase 1: determine o que existe

Atribua identificador, versão, data e estado de revisão a cada documento. Registre arquivos ilegíveis e referências ausentes. Combine quais perguntas a revisão precisa responder para o modelo não gastar orçamento resumindo material que não influencia a decisão.

Fase 2: revise um lote representativo

Escolha alguns documentos com estruturas e complexidades diferentes. Peça achados vinculados a página, seção ou identificador de fonte. Revise esse primeiro lote antes de permitir o mesmo método no acervo inteiro. Um formato de extração defeituoso custa caro quando repetido centenas de vezes.

Fase 3: concilie os lotes

A síntese final deve comparar afirmações, definições e requisitos entre os documentos. Registre fontes contraditórias e explique qual versão prevalece. Não trate o primeiro resumo como autoridade apenas porque agentes posteriores o receberam no lugar do arquivo original.

Fase 4: confirme a conclusão

Compare o relatório final com o inventário. Cada documento obrigatório deve estar revisado, excluído por um motivo declarado ou ainda pendente. Um relatório bem apresentado, mas com cobertura incompleta, continua sendo uma entrega incompleta, mesmo que as seções prontas estejam corretas.

ID do documento | Versão | Revisão   | Arquivo de achados | Questões abertas
A-01            | 3      | Revisado  | findings-a01       | Nenhuma
A-02            | 2      | Bloqueado | findings-a02       | Apêndice ausente
A-03            | 1      | Pendente  | -                  | Ainda não revisado

Isso dá à sessão substituta um ponto de partida claro e permite ao revisor humano auditar a cobertura sem reproduzir toda a conversa.

Defina o que um checkpoint precisa preservar

Um checkpoint útil contém tanto o estado do trabalho quanto evidências de que esse estado está correto. "Fase dois concluída" não basta se ninguém encontra a saída. Inclua caminho do artefato, versão da entrada, verificações de aceitação concluídas e divergência restante.

Para código, registre a revisão usada e o teste relevante. Para pesquisa, guarde links e datas de consulta. Para planilhas, preserve a pasta de trabalho de entrada e as alterações aplicadas. Se outra pessoa editar o artefato, atualize o checkpoint antes de continuar, evitando que o agente use premissas antigas.

Crie checkpoints em limites naturais. Salvar depois de cada frase pode gerar burocracia; salvar apenas ao fim de várias horas torna a recuperação cara. Um lote concluído, uma mudança validada ou uma decisão de projeto resolvida costuma ser um bom limite.

Retome sem duplicar trabalho

Retome este marco a partir do registro salvo da tarefa.
Inspecione os artefatos atuais antes de alterá-los.
Identifique critérios já atendidos e não repita esse trabalho.
Confira o resultado de qualquer ação externa já tentada.
Continue pelo próximo critério ainda não atendido.
Se houver conflito entre registro e arquivos, explique e concilie antes.

A diferença entre tentado e concluído importa. Uma ferramenta pode criar um registro e depois apresentar timeout. Antes de repetir, leia o destino para descobrir o que aconteceu. Para artefatos locais, verifique se há um resultado parcial que pode ser concluído em vez de sobrescrito.

Planeje o orçamento com base em progresso útil

Use um piloto delimitado para aprender quanto trabalho a tarefa exige. Na revisão de documentos, acompanhe documentos verificados e achados corrigidos. Em programação, acompanhe comportamentos aprovados. Inclua revisão humana: uma saída grande que exige horas de reparo pode não aumentar a produtividade.

Defina uma resposta explícita quando o orçamento estiver quase esgotado: salvar o artefato, atualizar o registro e apresentar a próxima decisão. Um teto de tokens evita mais gastos, mas não garante uma passagem de trabalho útil. Essa passagem precisa fazer parte do contrato da tarefa.

Se o progresso deixar de melhorar entre checkpoints, pause a expansão e examine o gargalo. O próximo passo pode ser obter uma fonte, reduzir o marco, trocar de ferramenta ou pedir uma decisão humana. Aumentar o esforço de raciocínio é apenas uma das intervenções possíveis.

Defina a primeira linha de chegada

"Construa o produto inteiro" contém decisões implícitas demais. Comece por uma parte verificável: uma jornada funcionando, uma análise validada ou um componente migrado. Essa parte deve ser útil o suficiente para revelar se o modelo entendeu o projeto.

Defina o marco antes de começar. Mudar o objetivo depois de cada resultado intermediário dificulta distinguir uma correção de um aumento de escopo.

Painel de preparação da análise de Matt Shumer. As contagens registram progresso, mas não são uma verificação independente.

Mantenha um registro compacto da tarefa

O modelo precisa do objetivo atual, decisões, arquivos de trabalho, abordagens que falharam e verificações restantes. Uma transcrição longa nem sempre é o melhor lugar para recuperar isso. Mantenha um registro curto que possa ser inspecionado e corrigido.

Marco atual:
Critérios de aceitação:
Localização dos artefatos e fontes:
Decisões já tomadas:
Abordagens descartadas e motivos:
Resultados verificados:
Problemas abertos:
Próxima ação:

Atualize o registro após um resultado relevante ou mudança importante de direção. Não o transforme em narrativa de cada chamada de ferramenta. O objetivo é facilitar a próxima decisão.

Reconheça três tipos de estagnação

Repetir uma abordagem que não funcionou

Pergunte qual nova evidência justifica outra tentativa. Repetir após uma falha transitória de ferramenta pode fazer sentido; refazer o mesmo raciocínio sem informação nova é menos promissor. Preserve as tentativas fracassadas para a próxima sessão não repeti-las.

Refinar detalhes antes de concluir o essencial

O agente pode melhorar texto ou aparência enquanto a jornada central continua quebrada. Volte aos critérios de aceitação e identifique o requisito pendente mais importante. Conclua-o antes de aumentar o refinamento.

Aumentar o escopo para lidar com ambiguidades

Quando a tarefa não está clara, o modelo pode construir mais infraestrutura em vez de resolver a escolha ausente. Peça que formule a menor incerteza capaz de mudar o projeto. Resolva essa decisão antes de permitir uma reescrita ampla.

Use checkpoints para recuperar interrupções

O anúncio do Astra da OpenAI observa que proteções podem interromper trabalho legítimo. Falhas de rede, encerramentos da aplicação e mudanças do usuário também podem parar uma execução. Salve artefatos úteis ao longo da tarefa e confirme seu estado antes de retomar.

Uma tarefa retomada deve ler os arquivos atuais e o registro, identificar o que já está pronto e continuar pelo próximo critério pendente. Se a execução anterior puder ter realizado uma ação externa, confira o resultado antes de repeti-la.

Modelo de prompt para tarefa longa

Conclua este marco: [resultado específico].
Critérios de aceitação: [verificações observáveis].
Use estes materiais e ferramentas: [escopo].
Mantenha um registro curto com decisões e progresso verificado.
Priorize requisitos centrais pendentes antes de refinamentos.
Se houver estagnação, explique o impedimento e a evidência necessária.
Ao atingir o orçamento, entregue artefatos utilizáveis e a próxima ação.

Nem todo projeto precisa de vários agentes. Acrescente um papel separado apenas quando houver uma saída distinta que possa ser revisada de forma independente. A coordenação pode virar trabalho por si só, principalmente quando vários agentes editam o mesmo artefato.

Meça progresso e custo juntos

Acompanhe critérios atendidos, correções do revisor, tempo decorrido e uso total. Um checkpoint útil pode informar que duas das três jornadas passam, a terceira tem uma falha reproduzível e o patch está pronto para revisão. "Ainda trabalhando" não fornece informação suficiente para decidir se vale mais uma hora.

Mantenha briefing, fontes, rascunhos e decisões de revisão juntos no Ottermind. Para começar com tarefas menores, use os modelos de como usar GPT-6; para orçamentos de integração, veja o guia da API.

Perguntas frequentes

GPT-6 consegue concluir um projeto com um prompt?

Alguns criadores descrevem projetos iniciados assim, mas ambiente, ferramentas, configuração prévia e revisão posterior continuam importantes. Comece por um marco concreto.

Por quanto tempo devo deixar um agente executar?

Defina um orçamento adequado e examine o progresso em checkpoints relevantes. Não existe uma duração útil universal.

E se o agente só melhorar detalhes pequenos?

Reafirme o critério pendente mais importante e adie refinamentos opcionais até atendê-lo.

Devo criar mais agentes quando o progresso cair?

Primeiro descubra a causa. Requisitos ausentes e abordagens equivocadas precisam de esclarecimento ou correção, não de mais paralelismo.

O que uma execução interrompida deve devolver?

Artefatos utilizáveis, resultados verificados, problemas pendentes e uma próxima ação concreta, para retomar sem repetir etapas concluídas.