Planejamento (Agentic)

Visão geral

Planejamento agêntico é o processo pelo qual um agente de IA transforma um objetivo de alto nível (“entregar uma correção de bug”, “reservar uma viagem”, “produzir um relatório”) em uma sequência de ações mediadas por ferramentas—e então executa essa sequência de forma confiável no mundo real, que é confuso. Diferentemente do “raciocínio” puro em uma janela de chat, agentes que usam ferramentas precisam lidar com:

Horizontes longos (muitas etapas, dependências, artefatos intermediários)
Estado externo (arquivos, APIs, bancos de dados, páginas web, calendários)
Incerteza e falhas (timeouts, permissões ausentes, dados parciais, ambientes que mudam)
Requisitos de verificação (testes, restrições, aprovações e políticas de segurança)

O planejamento agêntico moderno é, portanto, melhor compreendido como um sistema de controle em malha fechada (closed-loop control system):

Decompor o objetivo em subobjetivos e etapas acionáveis
Executar etapas usando ferramentas enquanto acompanha estado e custos
Verificar o progresso com base em critérios explícitos
Replanejar quando a realidade diverge das expectativas

Este artigo se concentra em planejamento para agentes que usam ferramentas: ciclos de decomposição, execução e verificação, e como essas ideias aparecem em arquiteturas práticas usadas por Agentes de LLM.

Por que o planejamento parece diferente para agentes que usam ferramentas

O “planejamento” clássico em IA muitas vezes pressupõe um mundo simbólico limpo, com ações bem definidas e efeitos determinísticos. Agentes que usam ferramentas, em vez disso, operam em ambientes onde:

Ações são chamadas de API com esquemas, limites de taxa, autenticação e efeitos colaterais.
Observações são não estruturadas (HTML, logs, linhas parciais de banco de dados, feedback humano).
O estado muda fora do controle do agente (atualizações de conteúdo na web, edições concorrentes).
A correção não é implícita; ela precisa ser verificada (testes passando, restrições satisfeitas, intenção do usuário atendida).

Como resultado, o planejamento agêntico se assemelha menos a gerar um plano perfeito uma única vez e mais a tomada de decisão contínua com monitoramento e reparo—especialmente para Tarefas de Longo Horizonte.

Fundamentos teóricos (e o que se transfere)

O planejamento agêntico toma emprestadas ideias de várias áreas clássicas de IA, mas as adapta ao uso de ferramentas e ao raciocínio baseado em LLM.

Planejamento clássico (modelos do tipo STRIPS)

No planejamento clássico, ações têm:

Pré-condições: o que deve ser verdadeiro para aplicar a ação
Efeitos: como o estado muda depois

Isso se mapeia bem para o uso de ferramentas quando é possível formalizar contratos de ferramentas:

Pré-condições: “usuário está autenticado”, “arquivo existe”
Efeitos: “um PR é criado”, “evento no calendário adicionado”

Na prática, muitas ferramentas não fornecem efeitos precisos; agentes aproximam com heurísticas e verificação.

Busca e orientação heurística

O planejamento pode ser formulado como uma busca por sequências de ações. Conceitos de Busca A* e busca heurística aparecem como:

Priorização de subobjetivos promissores (reduzir ramificação)
Escolha de ações de “coleta de informações” cedo (reduzir incerteza)
Busca consciente de orçamento (budget-aware) (limitar chamadas de ferramentas e tokens)

LLMs frequentemente atuam como uma heurística aprendida (learned heuristic): propõem próximos passos provavelmente bons em vez de explorar exaustivamente.

Processos de decisão e incerteza

Se você modela resultados de ferramentas probabilisticamente, você se aproxima de uma visão de Processos de Decisão de Markov (Markov Decision Processes) ou (com observabilidade parcial) de um POMDP. Esse enquadramento ajuda a explicar por que o replanejamento é essencial:

O agente não conhece o estado completo (contexto ausente, restrições ocultas).
Ações têm resultados estocásticos (erros de API, resultados ambíguos de busca).
Observações chegam depois das ações (respostas das ferramentas).

Conexões com Aprendizado por Reforço (Reinforcement Learning) e Aprendizado por Reforço Baseado em Modelo (Model-Based Reinforcement Learning) aparecem quando agentes aprendem políticas ou modelos de mundo com experiência, embora muitos agentes em produção usem controle baseado em regras mais raciocínio por LLM em vez de RL completo.

Planejamento hierárquico e decomposição

Tarefas longas frequentemente são tratadas via hierarquia: um objetivo de alto nível se divide em subobjetivos, que se dividem novamente até que as etapas sejam executáveis. Isso se assemelha ao planejamento HTN e a ideias de Aprendizado por Reforço Hierárquico (Hierarchical Reinforcement Learning).

Na prática, a hierarquia também é uma estratégia de engenharia: reduz carga cognitiva, melhora a depuração e permite verificação direcionada.

O ciclo central: Decompor → Executar → Verificar → Replanejar

Um modelo mental útil é um controlador que refina e valida repetidamente sua trajetória:

while not goal_satisfied:
    plan = decompose(goal, current_state, constraints, budget)
    for step in plan:
        result = execute(step, tools)
        current_state = update_state(current_state, result)
        if not verify(step, result, current_state):
            diagnose_failure()
            break  # replan

Esse ciclo é central para muitas Arquiteturas de Agentes, incluindo variantes de “planejar e executar” e agentes no estilo reflexão.

Princípio de design chave: tornar a verificação explícita

No planejamento agêntico, verificação não é opcional. Se você não definir o que significa “concluído” e como testar isso, o sistema vai derivar, superajustar a texto plausível ou parar cedo demais.

Decomposição: transformando objetivos em estrutura acionável

Decomposição é o processo de transformar um objetivo do usuário em:

Subobjetivos (marcos com critérios de conclusão mensuráveis)
Tarefas (unidades de trabalho atribuídas a ferramentas ou raciocínio interno)
Dependências (restrições de ordenação; frequentemente um DAG, não apenas uma lista)
Artefatos (arquivos, tickets, PRs, mensagens) que persistem entre etapas

Estratégias comuns de decomposição

1) Decomposição por marcos (entregáveis primeiro)

Comece pelos resultados desejados e trabalhe de trás para frente:

“Um relatório em PDF existe”
“Gráficos gerados a partir do conjunto de dados”
“Conjunto de dados limpo e validado”
“Dados obtidos da fonte”

Essa abordagem esclarece a verificação porque cada marco pode ter uma checagem concreta.

2) Decomposição orientada por restrições (guardrails primeiro)

Identifique restrições cedo:

Segurança: “sem chamadas externas à rede”
Conformidade: “PII não pode ser exportada”
Orçamento: “≤ 10 chamadas de ferramenta”, “≤ $X”
Latência: “finalizar em até 30 segundos”

Então decomponha tarefas que respeitem essas restrições (ver Segurança para Agentes).

3) Coleta de informações primeiro (reduzir incerteza)

Se o ambiente é incerto, planeje explicitamente coletar informações faltantes:

Inspecionar a estrutura do repositório antes de editar código
Consultar o esquema do banco de dados antes de escrever uma consulta
Fazer perguntas de esclarecimento ao usuário quando requisitos são ambíguos

Essa é uma resposta racional à observabilidade parcial (a “realidade POMDP”).

4) Árvores hierárquicas de tarefas (tipo HTN)

Represente o plano como uma árvore:

Objetivo: “Corrigir bug”
- Subobjetivo: “Reproduzir falha”
- Subobjetivo: “Identificar causa raiz”
- Subobjetivo: “Implementar correção”
- Subobjetivo: “Adicionar teste de regressão”
- Subobjetivo: “Abrir PR”

Cada subobjetivo pode ter seu próprio ciclo de executar/verificar.

Representando planos (esquemas práticos)

Um agente robusto geralmente representa planos em um formato estruturado para que possam ser inspecionados, registrados em logs e validados:

{
  "goal": "Fix failing CI test in repo",
  "constraints": ["no network beyond allowed domains", "must add regression test"],
  "steps": [
    {
      "id": "inspect-ci-logs",
      "tool": "ci.fetch_logs",
      "inputs": {"run_id": "latest"},
      "success_criteria": "identify failing test name and error trace"
    },
    {
      "id": "reproduce-locally",
      "tool": "sandbox.run_tests",
      "inputs": {"pattern": "failing_test"},
      "success_criteria": "failure reproduced with same stack trace"
    }
  ]
}

Planos estruturados permitem:

Execução determinística (menos “vaguear”)
Verificação e tentativas novamente (retries) em granularidade fina
Melhor avaliação e depuração (ver Avaliação de Agentes)

Execução: coordenando ferramentas sob restrições do mundo real

Execução é onde planos encontram a realidade. Agentes que usam ferramentas precisam gerenciar:

Esquemas de ferramentas e correção de argumentos
Retentativas, timeouts e limites de taxa
Resultados parciais (streaming, respostas paginadas)
Rastreamento de estado e gerenciamento de artefatos
Orçamentação (tempo, tokens, dinheiro e risco)

Dois estilos comuns de execução

Planejar e executar (plan-and-execute)

Produzir um plano explícito.
Executar etapas em ordem.
Replanejar apenas quando uma etapa falha ou novas informações chegam.

Prós:

Fácil de auditar
Comportamento estável
Bom para fluxos de trabalho de alto risco

Contras:

Planos podem ser frágeis se o ambiente mudar rapidamente

Raciocínio e ação intercalados (interleaved reasoning and acting) (tipo ReAct)

O agente alterna:

Pensar: decidir a próxima ação com base na observação atual
Agir: chamar uma ferramenta
Observar: incorporar o resultado

Prós:

Adaptativo a novas informações
Frequentemente com menos suposições iniciais

Contras:

Mais difícil de auditar e restringir sem estrutura adicional

Esses padrões são discutidos amplamente em Arquiteturas de Agentes.

Mecânicas de execução que importam em produção

Representação de estado e memória

A execução requer um estado de trabalho:

O que foi feito
Quais artefatos existem (nomes de arquivos, URLs, IDs de tickets)
Quais evidências sustentam o progresso
O que falta e por quê

Esse estado não deve depender apenas da janela de contexto do modelo. Abordagens comuns incluem:

Um log de execução persistente
Um armazenamento de tarefas (status da etapa: pending/running/done/failed)
Registros de artefatos (arquivos produzidos, saídas de ferramentas, hashes)

Idempotência e efeitos colaterais

Ações de ferramentas podem ter efeitos irreversíveis (enviar um e-mail, deletar um registro). Agentes robustos:

Preferem ações somente leitura ou reversíveis durante exploração
Usam modos de “dry run” quando disponíveis
Adicionam confirmações ou aprovações para etapas destrutivas (ver Humano no Loop (Human-in-the-Loop))

Execução consciente de orçamento

Tarefas de longo horizonte podem explodir em custo. Sistemas práticos impõem:

Máximo de chamadas de ferramenta
Máximo de tokens por etapa
Truncamento baseado em deadline (retornar progresso parcial + próximas ações)

Verificação: tornando o progresso mensurável e falhas recuperáveis

Verificação é o terceiro pilar: ela transforma um agente de um “gerador de texto com ferramentas” em um sistema que pode provar (dentro de limites) que está no caminho certo.

Níveis de verificação

Verificação no nível de etapa (local)

Após cada etapa:

A chamada da ferramenta foi bem-sucedida?
As saídas estão bem formadas?
Os resultados atendem aos critérios de sucesso da etapa?

Exemplos:

Validação de esquema JSON da saída da ferramenta
Verificar que um arquivo existe e não está vazio
Confirmar que uma API retornou status 2xx e campos esperados

Verificação no nível de subobjetivo (marco)

Após um agrupamento de etapas:

O artefato do marco está correto e completo?

Exemplos:

Uma suíte de testes unitários passa
Um gráfico corresponde a dimensões e rótulos esperados
Um relatório inclui seções e citações obrigatórias

Verificação no nível de objetivo (ponta a ponta)

No fim:

O resultado satisfaz a intenção do usuário?

Isso pode exigir:

Revisão humana
Validadores específicos do domínio
Verificação cruzada com fontes externas

Técnicas de verificação

Validadores determinísticos (preferidos)

Use checagens baseadas em código sempre que possível:

Testes unitários/de integração
Análise estática / linters
Verificação de tipos
Validação de consultas SQL e checagens de sanidade de contagem de linhas
Motores de regras de negócio

Checagens determinísticas reduzem a dependência da autoavaliação do modelo.

Críticos baseados em LLM (úteis, mas limitados)

LLMs podem atuar como revisores:

Comparar saídas com requisitos
Detectar inconsistências
Propor casos de borda ausentes

Mas podem ser excessivamente confiantes. A melhor prática é tratar a crítica por LLM como sinal, não como verdade fundamental, e combiná-la com checagens determinísticas.

Redundância e verificações cruzadas

Para tarefas de alto risco:

Executar múltiplas tentativas de solução independentes e comparar (autoconsistência)
Validar com um segundo modelo ou um prompt “verificador”
Verificar via ferramentas alternativas (por exemplo, calcular uma estatística de duas maneiras diferentes)

Juntando tudo: exemplos práticos

Exemplo 1: Agente de análise de dados produzindo um relatório de KPI

Objetivo: “Gerar um relatório semanal de KPIs a partir de um CSV e produzir um resumo em PDF.”

Decomposição

Carregar conjunto de dados; validar esquema e valores ausentes
Calcular KPIs e tabelas de resumo
Gerar gráficos
Redigir resumo narrativo
Exportar para PDF
Verificar: totais de KPI correspondem ao esperado; PDF renderiza corretamente

Ciclo de execução + verificação (esboço)

def verify_kpis(df, kpis):
    assert df.shape[0] > 0
    assert "revenue" in df.columns
    assert kpis["total_revenue"] >= 0
    return True

state = {}
df = tool.python("load_csv('weekly.csv')")
tool.python("validate_schema(df, required_cols=[...])")

kpis = tool.python("compute_kpis(df)")
verify_kpis(df, kpis)

plots = tool.python("make_plots(df)")
tool.files("save_pdf(kpis, plots, narrative)")
tool.files("assert_pdf_readable('report.pdf')")

Se a verificação falhar (por exemplo, coluna ausente), o agente replana: “solicitar arquivo correto” ou “ajustar definição de KPI”.

Exemplo 2: Agente de codificação corrigindo um teste que falha

Objetivo: “Corrigir teste de CI que está falhando e abrir um PR.”

Decomposição

Identificar falha a partir de logs de CI
Reproduzir localmente
Isolar causa raiz
Implementar correção mínima
Adicionar teste de regressão
Executar suíte completa de testes
Criar PR com resumo

Verificação

Reprodução deve corresponder ao stack trace de CI
Novo teste falha antes da correção e passa depois da correção
Suíte completa de testes passa
Checagens de lint/tipos passam

Este é um fluxo de trabalho canônico de “planejamento com uso de ferramentas”: ele é naturalmente estruturado em torno de verificadores determinísticos fortes (testes).

Exemplo 3: Agente de suporte ao cliente com ferramentas de banco de dados + e-mail

Objetivo: “Reembolsar o último pedido e notificar o cliente.”

Restrições

Deve confirmar identidade
Valor do reembolso deve seguir a política
Não deve enviar por e-mail notas internas sensíveis
Requer aprovação acima de $500

Plano

Buscar registro do cliente (somente leitura)
Buscar detalhes do último pedido
Calcular reembolso elegível
Se reembolso > $500: solicitar aprovação humana
Executar reembolso
Enviar e-mail de confirmação
Verificar que o ID da transação de reembolso existe e corresponde ao pedido

Este exemplo destaca por que o planejamento agêntico deve integrar Segurança para Agentes e Humano no Loop: a verificação inclui checagens de política e “portões” (gates) de aprovação.

Padrões de implementação para planejamento agêntico

Separação Planejador–Executor–Verificador

Uma arquitetura robusta comum separa responsabilidades:

Planejador: propõe etapas estruturadas e critérios de sucesso
Executor: realiza chamadas de ferramentas, lida com retentativas/timeouts
Verificador: avalia resultados contra critérios e invariantes

Essa separação:

Melhora auditabilidade
Permite trocar modelos (por exemplo, executor menor, planejador mais forte)
Permite avaliação direcionada (qualidade do planejamento vs confiabilidade da execução)

Ferramentas tipadas e saídas estruturadas

Agentes são mais confiáveis quando ferramentas têm:

Esquemas precisos (argumentos e tipos de retorno)
Modos de erro claros
Semântica idempotente quando possível

Saídas estruturadas (JSON com esquemas) reduzem falhas “stringly typed” e tornam a verificação direta.

Gatilhos de replanejamento (quando abandonar o plano)

Gatilhos típicos incluem:

Falha de ferramenta além da política de retentativas
Novas informações invalidam suposições
Falha de verificação (etapa ou marco)
Limite de orçamento atingido
Violação de restrição de segurança ou pico de incerteza

O replanejamento deve ser explícito, com um diagnóstico registrado (“por que mudamos de rumo”).

Modos de falha comuns (e mitigação)

Decomposição superficial: etapas grandes demais para verificar
Mitigação: marcos menores com critérios de sucesso mensuráveis.
Deriva de argumentos de ferramenta: parâmetros incorretos ou IDs incompatíveis
Mitigação: armazenar artefatos no estado; usar esquemas tipados; validar IDs.
Conclusão parcial silenciosa: agente assume sucesso sem checar
Mitigação: exigir pós-condições após cada ação com efeitos colaterais.
Dependência excessiva de autoavaliação: “parece bom” sem testes
Mitigação: validadores determinísticos; checagens independentes.
Loops infinitos de reparo: retentativas repetidas sem novas informações
Mitigação: retentativas limitadas, estratégias alternativas, escalonamento para humanos.

Esses problemas frequentemente são revelados sistematicamente por meio de Avaliação de Agentes, incluindo suítes de regressão sobre cenários de longo horizonte.

Planejamento sob restrições de segurança e governança

O planejamento é onde políticas de segurança se tornam operacionais:

Permissões: quais ferramentas podem ser chamadas em quais contextos
Sandboxing (isolamento): isolar execução de código e limitar exfiltração de dados
Aprovações: exigir sign-off para ações irreversíveis ou de alto impacto
Menor privilégio: conceder apenas as capacidades necessárias para o plano

Na prática, restrições de segurança devem ser entradas de primeira classe para o planejador e checagens de primeira classe no verificador (ver Segurança para Agentes).

Para onde o campo está indo

Tendências atuais em planejamento agêntico enfatizam:

Verificadores melhores: checagens automatizadas mais fortes, geração de testes, restrições formais
Modelos de estado mais ricos: modelos explícitos do mundo e grafos de artefatos em vez de contexto puramente textual
Planejamento híbrido: combinar planejamento/busca simbólicos com heurísticas de LLM (e às vezes Busca em Árvore de Monte Carlo (Monte Carlo Tree Search) em domínios restritos)
Iteração guiada por avaliação: tratar fluxos de trabalho de agentes como software, com benchmarks, testes de cenários e regressões

O tema unificador é uma mudança de “gerar um plano” para “executar um processo controlado” que consiga sobreviver a falhas reais de ferramentas e ainda assim convergir.

Resumo

O planejamento para agentes que usam ferramentas é melhor compreendido como um ciclo de controle iterativo:

Decomposição cria um caminho estruturado com marcos e critérios de sucesso.
Execução coordena ferramentas enquanto rastreia estado, artefatos e orçamentos.
Verificação torna o progresso mensurável e permite replanejamento seguro quando a realidade diverge.

O planejamento agêntico eficaz trata menos de produzir um plano inicial perfeito e mais de construir sistemas que sejam auditáveis, testáveis e resilientes—os requisitos centrais para Agentes de LLM confiáveis operando sobre Tarefas de Longo Horizonte.