Tarefas de Longo Horizonte

O que são tarefas de longo horizonte?

Uma tarefa de longo horizonte é um objetivo que não pode ser concluído de forma confiável em uma única invocação do modelo ou em um pequeno número fixo de etapas. Em vez disso, ela exige muitas ações dependentes ao longo do tempo—frequentemente envolvendo ferramentas, ambientes externos, artefatos intermediários (arquivos, código, tickets, e-mails) e restrições que mudam.

No contexto de agentes modernos de IA (especialmente Agentes de LLM (LLM Agents)), “longo horizonte” normalmente implica três requisitos centrais:

  1. Decomposição (decomposition): Dividir um objetivo de alto nível em subobjetivos gerenciáveis e etapas concretas.
  2. Verificação intermediária (intermediate verification): Verificar progresso e correção após cada etapa (ou checkpoint), não apenas ao final.
  3. Execução robusta (robust execution): Lidar com erros, incerteza e deriva ao longo de muitas etapas por meio de tentativas, backtracking, rastreamento de estado e uso seguro de ferramentas.

A competência em longo horizonte é um desafio definidor para sistemas agentes em Agentes & Planejamento, porque as falhas se acumulam: um pequeno erro no início pode invalidar tudo o que vem depois.

Por que tarefas de longo horizonte são difíceis

Tarefas de longo horizonte pressionam praticamente todas as fragilidades dos sistemas de IA atuais.

Erros cumulativos e deriva

Se cada etapa tem 95% de chance de estar correta, então após 50 etapas a probabilidade de uma trajetória totalmente correta é (0.95^{50} \approx 7.7%). Na prática, as taxas de erro não são independentes e podem ser piores devido a:

  • requisitos mal compreendidos logo no início
  • inconsistências acumuladas em artefatos intermediários
  • estado divergindo gradualmente (a crença do agente sobre o mundo difere da realidade)

Atribuição de crédito ao longo de muitas etapas

Na tomada de decisão sequencial, é difícil atribuir uma falha final à ação específica anterior que a causou. Este é um desafio clássico em aprendizado por reforço (reinforcement learning) e planejamento, especialmente com recompensas atrasadas.

Observabilidade parcial e estado oculto

Muitas tarefas reais são parcialmente observáveis (partially observable): você não consegue ver todas as variáveis relevantes (por exemplo, “o que o usuário realmente quis dizer”, “se um e-mail foi recebido”, “o que mudou em uma base de código desde a última execução”). Agentes precisam manter estado (state) e atualizá-lo conforme observam resultados.

Ambientes não estacionários

Ferramentas, APIs, páginas da web e repositórios mudam. Um plano que estava correto ontem pode quebrar hoje. Agentes robustos precisam revalidar suposições e se adaptar.

Falta de confiabilidade de ferramentas e efeitos colaterais

Chamadas de ferramentas podem falhar de forma transitória (timeouts, limites de taxa) ou permanente (erros de permissão). Pior: ferramentas frequentemente têm efeitos colaterais (side effects) (enviar e-mails, excluir dados, fazer deploy de código). Agentes de longo horizonte precisam ter cuidado com quando e como agir.

Contexto e memória limitados

Modelos de linguagem têm janelas de contexto limitadas. Tarefas longas podem exceder essa capacidade, exigindo sumarização, memória externa, recuperação (retrieval) e representação cuidadosa de estado.

Fundamentos teóricos (breve, mas útil)

Tarefas de longo horizonte conectam várias ideias fundamentais:

Planejamento sobre trajetórias

Um enquadramento clássico modela o problema como tomada de decisão sequencial: escolher ações para maximizar a satisfação do objetivo ao longo do tempo. Em cenários idealizados, isso se assemelha a otimizar uma política sobre um Processo de Decisão de Markov (Markov Decision Process, MDP), mas tarefas do mundo real frequentemente violam as suposições de MDP (observabilidade parcial, não estacionariedade, ferramentas externas).

Técnicas de planejamento agentivo frequentemente misturam:

  • ideias de planejamento simbólico (symbolic planning) (objetivos explícitos, restrições, pré-condições)
  • busca (search) (considerar múltiplos planos candidatos)
  • heurísticas baseadas em aprendizado (learning-based heuristics) (planos gerados por LLM, estimativas de valor)

Veja também: Planejamento (Agentivo).

Estrutura hierárquica

Comportamentos de longo horizonte frequentemente são naturalmente hierárquicos:

  • objetivo de alto nível (por exemplo, “lançar uma funcionalidade”)
  • subobjetivos (“projetar API”, “implementar backend”, “escrever testes”, “fazer deploy”)
  • ações de baixo nível (editar arquivo, rodar testes, chamar API do CI)

Isso reflete intuições de planejamento hierárquico (hierarchical planning) e aprendizado por reforço hierárquico (hierarchical RL): ações abstratas (“opções”) podem simplificar a tomada de decisão.

Verificação como mecanismo de controle

Em termos de teoria de controle, a verificação intermediária atua como feedback: medir o estado do sistema, comparar com o estado desejado e corrigir. Sem feedback, você tem execução em malha aberta (open-loop), que é frágil em sequências longas.

Decomposição: transformando grandes objetivos em etapas executáveis

A decomposição converte uma solicitação ambígua em um plano estruturado. Uma decomposição eficaz tem duas propriedades:

  • Cobertura (coverage): inclui todo o trabalho principal necessário para concluir o objetivo.
  • Executabilidade (executability): cada etapa é concreta o suficiente para ser executada e verificada.

Estratégias comuns de decomposição

1) Divisão top-down de tarefas (estrutura analítica do trabalho)

Comece pelo objetivo e divida recursivamente em subobjetivos até que cada um seja “pequeno o suficiente”.

Exemplo: “Preparar uma apresentação de revisão trimestral de negócios (QBR)”

  • Coletar dados
    • extrair métricas de KPI dos dashboards
    • exportar receita por segmento
    • compilar motivos de churn
  • Analisar
    • identificar tendências e anomalias
    • produzir 3–5 principais insights
  • Rascunhar slides
    • estrutura narrativa
    • visuais e tabelas
  • Revisar e iterar
    • verificar números
    • alinhar com stakeholders

2) Decompor por artefatos

Defina o que deve existir ao final: documentos, módulos de código, relatórios de testes, aprovações. Depois, planeje etapas que produzam e validem cada artefato.

Exemplo: “Entregar uma correção de bug”

  • artefato: teste de reprodução
  • artefato: mudança de código
  • artefato: testes unitários/de integração passando
  • artefato: entrada de nota de release
  • artefato: PR aprovada e mergeada

3) Decompor por redução de incerteza

Priorize etapas que reduzam ambiguidade cedo:

  • esclarecer requisitos com o usuário
  • inspecionar o repositório / ambiente
  • executar uma reprodução mínima
  • checar restrições (prazos, permissões)

Isso frequentemente evita retrabalho caro mais adiante.

Armadilhas na decomposição

  • Etapas grandes demais: difíceis de verificar; escondem risco.
  • Etapas pequenas demais: o overhead explode; o progresso desacelera.
  • Dependências ausentes: a ordem das subtarefas importa (por exemplo, escrever testes antes de decidir interfaces).
  • Otimizar por texto plausível em vez de ações executáveis: um plano que “soa bem”, mas falha quando executado.

Padrões de design de agentes que integram decomposição explicitamente incluem plan-and-execute e refinamento iterativo; veja Arquiteturas de Agentes.

Verificação intermediária: tornando o progresso mensurável

A verificação intermediária é o que transforma um processo de longo horizonte de “torcer para funcionar” em um ciclo de engenharia.

O que verificar

A verificação deve checar tanto correção quanto alinhamento com a intenção:

  • Correção local: a etapa teve sucesso? (códigos de saída, saídas de ferramentas, validação de schema)
  • Consistência global: isso ainda satisfaz o objetivo original e as restrições?
  • Checagens de invariantes (invariant checks): políticas de segurança, limites de orçamento, regras não destrutivas
  • Checagens de regressão (regression checks): quebramos componentes que antes funcionavam?

Métodos de verificação (práticos)

1) Checagens de verdade de base com ferramentas

Sempre que possível, verifique usando sinais externos em vez do próprio julgamento do modelo:

  • rodar testes unitários / testes de integração
  • executar o código gerado
  • validar JSON contra um schema
  • checar uma restrição de banco de dados
  • comparar contra respostas conhecidas (golden files)

2) Validadores estruturados

Um padrão poderoso é representar saídas intermediárias em uma forma restrita e validá-las de maneira determinística.

Exemplo: validando um payload de chamada de ferramenta com JSON Schema (conceitual):

from jsonschema import validate

payload = {
  "recipient": "alice@example.com",
  "subject": "QBR Draft",
  "body": "Attached is the draft deck...",
}

schema = {
  "type": "object",
  "properties": {
    "recipient": {"type": "string", "pattern": ".+@.+"},
    "subject": {"type": "string", "minLength": 1},
    "body": {"type": "string", "minLength": 1}
  },
  "required": ["recipient", "subject", "body"],
  "additionalProperties": False
}

validate(instance=payload, schema=schema)

Esse tipo de verificação é barato, confiável e previne muitas falhas a jusante.

3) Verificação cruzada e crítica

Quando checagens baseadas em ferramentas não estão disponíveis, você pode usar checagens baseadas no modelo com mais cuidado:

  • gerar múltiplas soluções candidatas e comparar (autoconsistência)
  • usar uma passada separada de “crítico” que procura erros e restrições ausentes
  • exigir citações ou referências para afirmações factuais (e verificá-las)

Verificação baseada no modelo deve ser tratada como heurística, não como verdade de base.

4) Checkpointing e critérios de aceitação

Defina condições explícitas de “pronto” para cada subtarefa. Por exemplo:

  • “Endpoint de API retorna 200 com entrada válida; 400 com entrada inválida; documentado no README”
  • “Dataset tem N linhas, sem nulos em colunas-chave, e passa checagens de sanidade de distribuição”

Critérios de aceitação reduzem ambiguidade e tornam a verificação acionável.

Execução robusta: mantendo-se no rumo ao longo de muitas etapas

Sistemas de longo horizonte precisam antecipar modos de falha e se recuperar com elegância.

Padrão de loop de execução: planejar → agir → observar → verificar → atualizar

Um loop robusto comum de agente se parece com:

state = {
  "goal": user_goal,
  "constraints": constraints,
  "plan": None,
  "progress": [],
  "artifacts": {},
}

state["plan"] = propose_plan(state)

for step in state["plan"]:
  action = compile_action(step, state)

  result = run_tool_or_action(action)

  observation = summarize_observation(result)
  state["progress"].append({"step": step, "observation": observation})

  ok, issues = verify_step(step, result, state)
  if not ok:
    recovery = propose_recovery(step, issues, state)
    state = apply_recovery(recovery, state)
    continue

  state = update_state_from_result(result, state)

final_ok, final_issues = verify_goal_completion(state)

Ideia-chave: o agente não está apenas gerando texto—ele está gerenciando um processo com estado (stateful process).

Técnicas de robustez

Tentativas com backoff (para falhas transitórias)

  • timeouts de rede
  • limites de taxa
  • automação de UI instável (flaky)

Mas as tentativas precisam ser limitadas e registradas para evitar loops infinitos.

Backtracking e replanejamento

Se uma etapa falha de um modo que invalida o plano, gere o plano novamente a partir do novo estado. Agentes de longo horizonte frequentemente precisam “voltar no tempo”:

  • desfazer uma mudança (git revert)
  • restaurar a partir de um checkpoint
  • escolher uma abordagem alternativa

Isso é central para planejamento agentivo; veja Planejamento (Agentivo).

Idempotência e design seguro de ferramentas

Prefira ações que possam ser repetidas com segurança sem causar dano. Por exemplo:

  • “criar ou atualizar rascunho” em vez de “enviar e-mail”
  • “abrir PR” em vez de “fazer merge na main”
  • “deploy em dry-run” antes do deploy real

Mecanismos de segurança são cobertos com mais profundidade em Segurança para Agentes.

Orçamentação e timeouts

Tarefas longas podem crescer silenciosamente. Sistemas práticos impõem:

  • máximo de chamadas de ferramenta
  • tempo máximo de relógio (wall-clock)
  • custo máximo
  • máximo de iterações por subtarefa

Rastreamento de estado e registro (journaling)

Agentes robustos mantêm:

  • um razão de tarefas (task ledger) (o que foi tentado, o que aconteceu)
  • um estado atual do mundo (current world state) (quais arquivos existem, quais endpoints estão ativos, o que foi aprovado)
  • um registro de decisões (decision record) (por que uma escolha foi feita)

Isso reduz trabalho repetido e ajuda no debugging.

Exemplos práticos de tarefas de longo horizonte

Exemplo 1: Mudança em base de código com testes e CI

Objetivo: “Adicionar login via OAuth ao app web.”

Decomposição + verificação típicas:

  1. Inspecionar a estrutura do repositório e o fluxo de autenticação
    • verificar: consegue rodar o app localmente; testes baseline passam
  2. Projetar mudanças de API e configuração
    • verificar: especificação revisada; variáveis de ambiente documentadas
  3. Implementar endpoints de backend
    • verificar: testes unitários para troca de token; lint passa
  4. Implementar fluxo de login no frontend
    • verificar: UI compila; caminho básico de e2e funciona
  5. Adicionar testes de integração
    • verificar: CI verde
  6. Criar PR e solicitar revisão
    • verificar: template de PR preenchido; notas de segurança incluídas

Detalhes de execução robusta:

  • criar checkpoints com commits git após cada marco funcional
  • rerodar testes após merges/rebases
  • evitar armazenar segredos em logs

Exemplo 2: Pipeline de análise de dados com reprodutibilidade

Objetivo: “Analisar drivers de churn e produzir um relatório com gráficos.”

Etapas e checagens:

  • extrair dados do warehouse
    • verificar: contagem de linhas corresponde ao esperado; checagens de sanidade por amostragem
  • limpar e juntar tabelas
    • verificar: sem picos inesperados de nulos; unicidade de chaves se mantém
  • construir modelos (por exemplo, regressão logística + baseline baseado em árvores)
    • verificar: split de treino/validação; sem vazamento (leakage); métricas dentro de faixas plausíveis
  • gerar relatório e figuras
    • verificar: gráficos rotulados; números consistentes entre tabelas
  • entregar resultados
    • verificar: suposições e limitações declaradas; código executável de ponta a ponta

Isso é de longo horizonte porque a saída depende de muitas pequenas restrições de correção (joins, filtros, checagens de leakage).

Exemplo 3: Agente de suporte ao cliente com restrições de política

Objetivo: “Resolver uma disputa de cobrança.”

O agente pode precisar:

  • recuperar histórico da conta
  • interpretar regras de política
  • calcular ajustes
  • redigir uma resposta
  • escalar se for alto risco

A verificação intermediária inclui:

  • checagens de conformidade com a política (sem promessas fora da política)
  • cálculos validados
  • gatilhos de escalonamento para casos ambíguos

Isso se conecta naturalmente a Humano no Loop (Human-in-the-Loop) para aprovações em fluxos sensíveis.

Abordagens de treinamento e modelagem

Capacidades de longo horizonte vêm de uma mistura de avanços de modelagem e design de sistemas.

Abordagens no nível do modelo (aprendizado)

  • Ajuste por instruções e otimização por preferências (instruction tuning and preference optimization) podem incentivar planejamento, uso cuidadoso de ferramentas e autocorreção, mas não garantem correção.
  • Aprendizado por reforço (reinforcement learning) (incluindo RL baseado em ambiente) pode melhorar desempenho multi-etapas, especialmente em ambientes sintéticos de uso de ferramentas.
  • Aprendizado por imitação a partir de trajetórias (imitation learning from trajectories) (rastros bem-sucedidos multi-etapas) ensina padrões de decomposição e recuperação.

Na prática, muitos avanços vêm de como os modelos são apoiados por scaffolding (loops de agente, ferramentas, memória, verificação), e não apenas do modelo base.

Scaffolding no nível do sistema

Mesmo modelos muito fortes se beneficiam de:

  • espaços de ação restritos (permitir apenas certas ferramentas)
  • interfaces de ferramenta tipadas e validação por schema
  • recuperação e memória durável para contextos longos
  • verificadores determinísticos e suítes de testes

É por isso que “engenharia de agentes (agent engineering)” frequentemente é tão importante quanto “engenharia de modelos (model engineering)” para tarefas de longo horizonte.

Avaliação: como medir competência em longo horizonte?

Avaliar tarefas de longo horizonte é difícil porque os resultados dependem de:

  • correção ao longo de muitas etapas
  • uso seguro de ferramentas
  • robustez a perturbações
  • eficiência amostral (quantas tentativas/chamadas de ferramenta)
  • capacidade de se recuperar de falhas injetadas

Abordagens comuns de avaliação:

  • Taxa de sucesso ponta a ponta (end-to-end success rate) em tarefas realistas (mas pode ser caro e ruidoso)
  • Métricas por etapa (stepwise metrics): fração de etapas corretas, número de backtracks, eficiência de chamadas de ferramenta
  • Testes de perturbação (perturbation tests): mudar uma resposta de API, adicionar uma falha, modificar restrições no meio da execução
  • Suítes de regressão (regression suites): garantir que atualizações não degradem tarefas previamente resolvidas

Para mais, veja Avaliação de Agentes.

Princípios de design e boas práticas

Prefira “verificar, então prosseguir” em vez de “gerar tudo”

Para tarefas longas, geralmente é melhor:

  • produzir um pequeno incremento
  • validá-lo
  • commitá-lo (ou criar um checkpoint)
  • continuar

Isso reduz falhas catastróficas e facilita o debugging.

Tornar saídas intermediárias inspecionáveis

Use artefatos estruturados:

  • logs de ações em JSON
  • arquivos versionados
  • status explícitos de subtarefas
  • critérios de aceitação claros

Restringir ferramentas e permissões

Agentes de longo horizonte são mais perigosos do que assistentes one-shot porque podem causar efeitos colaterais cumulativos. Aplique:

  • acesso a ferramentas com privilégio mínimo
  • ambientes de execução em sandbox
  • gates de aprovação para ações irreversíveis

Veja Segurança para Agentes.

Use humanos estrategicamente

Humanos podem ser “verificadores de alta largura de banda” para checkpoints ambíguos ou de alto risco:

  • confirmar requisitos após o plano inicial
  • aprovar comunicações externas
  • validar (sign off) deploys ou pagamentos

Veja Humano no Loop.

Problemas em aberto e direções de pesquisa

Apesar do rápido progresso, tarefas de longo horizonte permanecem uma área ativa de pesquisa.

  • Autoverificação confiável (reliable self-verification): modelos frequentemente soam confiantes mesmo quando estão errados; verificação baseada em ferramentas ajuda, mas nem sempre está disponível.
  • Memória e representação de estado (memory and state representation): como armazenar e recuperar contexto de longo prazo sem perder detalhes críticos.
  • Planejamento robusto sob incerteza (robust planning under uncertainty): agentes precisam raciocinar sobre o que não sabem e tomar ações de coleta de informação.
  • Ambientes adversariais (adversarial environments): saídas de ferramentas ou páginas da web podem ser maliciosas ou enganosas (injeção de prompt, conteúdo falsificado).
  • Realismo de benchmarks (benchmark realism): muitos benchmarks são ou simplistas demais ou caros demais para rodar em escala; construir avaliações de longo horizonte representativas e reprodutíveis é difícil.

Resumo

Tarefas de longo horizonte são objetivos multi-etapas que exigem decomposição, verificação intermediária e execução robusta. Elas são difíceis porque erros se acumulam, ambientes são parcialmente observáveis e não estacionários, e o uso de ferramentas introduz falhas e efeitos colaterais. Agentes eficazes de longo horizonte combinam planejamento e estrutura hierárquica com loops de feedback estreitos: eles planejam, agem, observam, verificam, atualizam o estado e replanejam quando necessário. Na prática, os sistemas mais confiáveis dependem fortemente de checagens determinísticas (testes, schemas, validadores), rastreamento cuidadoso de estado, interfaces de ferramenta restritas e supervisão humana direcionada em etapas de alto risco.