Agentes e Planejamento

Visão geral: o que significa “agentes & planejamento”

Um agente de IA é um sistema que percebe informações sobre um ambiente, decide o que fazer e age — muitas vezes repetidamente — em direção a algum objetivo. Planejamento é o processo de selecionar (e às vezes revisar) uma sequência de ações ou uma política que provavelmente alcançará esse objetivo sob restrições como tempo limitado, informação incompleta e requisitos de segurança.

Sistemas “agênticos” modernos frequentemente combinam:

  • Um componente de raciocínio (frequentemente uma espinha dorsal baseada em Modelos de Linguagem Grandes (Large Language Models))
  • Uso de ferramentas (APIs, busca, bancos de dados, execução de código, atuação robótica)
  • Memória/estado e acompanhamento de tarefas ao longo de etapas
  • Execução de longo horizonte (dezenas a milhares de etapas)
  • Avaliação e guardrails para garantir confiabilidade, controle de custo e segurança

Este artigo apresenta os fundamentos teóricos de agentes e planejamento e, em seguida, os conecta a padrões práticos de design usados em sistemas baseados em LLM.

O que é um agente?

Um modelo mental útil é:

  • Ambiente: o mundo externo que o agente pode afetar (um site, base de código, espaço de trabalho de um robô, sistemas corporativos).
  • Observações: o que o agente pode “ver” (texto, leituras de sensores, respostas de API, saídas de ferramentas).
  • Ações: o que o agente pode fazer (clicar em um botão, chamar uma API, escrever código, mover um braço robótico).
  • Política: um mapeamento de observações (e estado interno) para ações.
  • Objetivo: uma meta ou utilidade a maximizar (sucesso da tarefa, satisfação do usuário, recompensa).

Esse enquadramento corresponde à IA clássica e ao Aprendizado por Reforço (Reinforcement Learning): o agente interage com um ambiente, executando ações para maximizar o retorno esperado.

Agentes vs. chatbots

Um chatbot produz texto. Um agente usa o texto como uma superfície de controle para decisões e chamadas de ferramentas. Diferenças típicas:

  • Com estado: mantém estado e progresso da tarefa (ver Memória & Estado).
  • Com uso de ferramentas: pode buscar informação, editar arquivos, executar código, navegar.
  • Orientado a objetivos: otimizado para concluir tarefas, não apenas responder.
  • Loops de autocorreção: pode checar o trabalho, voltar atrás e tentar novamente.

Fundamentos: planejamento na IA clássica

Antes dos LLMs, planejamento era um subcampo central da IA. Muitas ideias ainda se aplicam diretamente.

Busca em espaço de estados e planejamento clássico

No planejamento clássico, o mundo é modelado como:

  • Um estado (fatos sobre o mundo)
  • Ações com pré-condições e efeitos
  • Uma condição de objetivo a satisfazer

O planejador busca por uma sequência de ações que alcance o objetivo. Isso inclui:

  • Busca progressiva (do estado inicial até o objetivo)
  • Busca regressiva (das condições do objetivo de volta ao estado inicial)
  • Heurísticas para guiar a busca de forma eficiente (relacionadas a Algoritmos de Busca)

Representações clássicas incluem operadores no estilo STRIPS e PDDL (Planning Domain Definition Language). Esses métodos são poderosos quando o modelo do mundo é preciso e discreto, mas são frágeis quando o ambiente é parcialmente observado, desorganizado ou melhor descrito em linguagem natural (como “corrija este incidente em produção”).

Incerteza: MDPs e POMDPs

Quando os resultados são estocásticos e a informação é incompleta, o planejamento é formalizado como:

  • MDP: Processo de Decisão de Markov (Markov Decision Process) (totalmente observado)
  • POMDP: MDP Parcialmente Observável (Partially Observable MDP) (estado oculto; o agente mantém uma crença)

Esses conceitos formam a espinha dorsal teórica da tomada de decisão sob incerteza e estão intimamente ligados ao aprendizado por reforço. (Veja também Processos de Decisão de Markov.)

Planejamento hierárquico e abstração

Tarefas longas são mais gerenciáveis se planejarmos em múltiplos níveis:

  • Alto nível: “Entregar a funcionalidade”
  • Nível médio: “Implementar API”, “Escrever testes”, “Atualizar docs”
  • Baixo nível: “Editar arquivo X”, “Executar teste Y”

Essa ideia aparece como Redes Hierárquicas de Tarefas (Hierarchical Task Networks, HTNs) e, na prática moderna de agentes, como decomposição de tarefas, subobjetivos e checklists.

Sistemas agênticos modernos: LLMs + ferramentas + loops de controle

Muitas implementações atuais de agentes tratam um LLM como:

  • Um planejador (propor próximos passos)
  • Um controlador (escolher e parametrizar ferramentas)
  • Um sumarizador/verificador (interpretar saídas de ferramentas, checar restrições)

Mas o sistema como um todo é mais do que o modelo. Um agente prático frequentemente inclui:

  1. Interface de tarefa: pedido do usuário, restrições do sistema, permissões
  2. Estado: plano atual, resultados parciais, perguntas em aberto
  3. Roteador de ferramentas: escolhe quais ferramentas podem ser chamadas e como
  4. Executor: executa ferramentas, coleta saídas
  5. Verificador: valida resultados intermediários, detecta modos de falha
  6. Memória: armazena fatos e artefatos relevantes
  7. Camada de segurança: checagens de política, sandboxing, aprovações

Para padrões concretos de design como ReAct e plan-and-execute, veja Arquiteturas de Agentes. Para designs centrados em LLM, veja Agentes de LLM.

Uso de ferramentas: como agentes agem no mundo

O uso de ferramentas é o que transforma “raciocínio” em impacto. Uma ferramenta pode ser:

Chamada de função e ferramentas estruturadas

Um padrão comum é definir ferramentas com entradas e saídas estruturadas. Por exemplo:

{
  "name": "search_docs",
  "description": "Search internal documentation and return top results.",
  "parameters": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "top_k": { "type": "integer", "default": 5 }
    },
    "required": ["query"]
  }
}

O agente então decide se deve chamar search_docs, com quais argumentos, e como usar os resultados retornados.

Um loop mínimo de agente (conceitual)

Abaixo está um pseudocódigo simplificado mostrando o loop de controle que a maioria dos agentes implementa:

state = {
    "goal": user_goal,
    "plan": [],
    "history": [],
    "artifacts": {},
    "budget": {"max_steps": 30, "max_tool_calls": 20}
}

for step in range(state["budget"]["max_steps"]):
    observation = summarize_context(state)

    action = llm_decide_next_action(
        observation=observation,
        available_tools=tool_registry,
        constraints=policy_constraints
    )

    if action.type == "TOOL_CALL":
        tool_result = run_tool(action.tool_name, action.arguments)
        state["history"].append({"action": action, "result": tool_result})

        if verifier_detects_failure(tool_result):
            state = recovery_strategy(state, tool_result)  # retry, backtrack, ask user, etc.

    elif action.type == "FINAL_ANSWER":
        return action.content

return "Stopped: budget exhausted. Here is progress and next steps..."

Principal conclusão: agentes são sistemas de malha fechada. O planejamento acontece durante a execução, não apenas no início.

Questões práticas na orquestração de ferramentas

O uso real de ferramentas exige lidar com:

  • Confiabilidade da ferramenta: timeouts, limites de taxa, UIs instáveis
  • Correção de argumentos: schemas inválidos, identificadores errados
  • Seleção de ferramentas: evitar chamadas excessivas a ferramentas caras
  • Tentativas e fallback: ferramentas ou estratégias alternativas
  • Limites de segurança: garantir que ferramentas não possam exfiltrar segredos ou executar ações inseguras

Esses são temas centrais em Uso de Ferramentas & Orquestração.

Planejamento para tarefas de longo horizonte

Uma tarefa de longo horizonte exige muitas etapas dependentes nas quais erros iniciais se acumulam. Exemplos:

  • “Refatore este serviço e mantenha compatibilidade retroativa”
  • “Investigue um incidente em produção, mitigue e escreva um postmortem”
  • “Planeje e reserve uma viagem por várias cidades dentro de restrições”
  • “Faça uma revisão sistemática de literatura e produza um resumo”

Principais desafios:

  • Atribuição de crédito: qual decisão anterior causou a falha?
  • Erro cumulativo: pequenas imprecisões se amplificam
  • Não estacionariedade: o ambiente muda durante a execução (páginas web, atualizações na base de código)
  • Restrições de orçamento: chamadas de ferramentas limitadas, latência, custo
  • Observabilidade parcial: dados faltantes e requisitos ambíguos

Estratégias que funcionam na prática

Estratégias comuns de planejamento e execução incluem:

  • Decomposição: dividir em subobjetivos com critérios de aceitação claros
  • Intercalar planejar e agir: planejar alguns passos à frente, executar, replanejar
  • Verificação intermediária: testes unitários, checagens de sanidade, validação cruzada
  • Checkpointing: salvar o estado para retomar após falhas
  • Backtracking: reverter para pontos de decisão anteriores quando surgirem contradições
  • Loops de pergunta-esclarecimento: consultar o usuário quando restrições forem ambíguas

Isso é discutido com mais profundidade em Tarefas de Longo Horizonte e Planejamento (Agêntico).

Exemplo: agente de longo horizonte para “correção de bug e release”

Um fluxo de trabalho realista poderia ser:

  1. Reproduzir o bug localmente (ferramenta: run_tests, run_app)
  2. Identificar a provável causa raiz (raciocínio do LLM + ferramenta de busca no código)
  3. Implementar a correção (ferramenta: edit_file)
  4. Adicionar teste de regressão (ferramenta: edit_file, run_tests)
  5. Executar a suíte completa de testes (ferramenta: gatilho de CI)
  6. Escrever notas de release (LLM)
  7. Abrir PR e solicitar revisão (ferramenta: create_pull_request)

O “planejamento” não é apenas a lista inicial. O agente deve se adaptar quando os testes falham, novos logs aparecem ou revisores pedem alterações.

Sistemas multiagentes: quando um agente não é suficiente

Algumas tarefas se beneficiam de múltiplos agentes especializados, por exemplo:

  • Um agente “planejador” que decompõe tarefas
  • Um agente “executor” que realiza chamadas de ferramentas
  • Um agente “crítico/verificador” que checa correção e segurança
  • Um agente “especialista de domínio” para um subsistema específico (cobrança, infra, jurídico)

Isso pode melhorar o throughput e reduzir falhas por ponto único, mas introduz desafios de coordenação:

  • Falha de comunicação: suposições inconsistentes entre agentes
  • Trabalho redundante: agentes duplicam esforço
  • Transferência de culpa: nenhum agente “é dono” do sucesso da tarefa
  • Falha emergente: loops de interação, espirais de escalonamento

Veja Sistemas Multiagentes para padrões e modos de falha.

Avaliação: medindo se agentes realmente funcionam

Avaliar sistemas agênticos é mais difícil do que avaliar geração de texto em uma única tentativa porque:

  • Resultados dependem de interações com ferramentas e do estado do ambiente
  • Existem muitas sequências de ações “aceitáveis”
  • Falhas podem ser raras, porém severas (riscos de segurança e conformidade)
  • O desempenho varia com aleatoriedade e sensibilidade a prompts

Para uma cobertura mais profunda, veja Avaliação de Agentes.

O que medir

Dimensões comuns de avaliação incluem:

  • Taxa de sucesso da tarefa: o agente atingiu o objetivo?
  • Eficiência: etapas executadas, chamadas de ferramentas, uso de tokens, latência, custo
  • Robustez: desempenho sob perturbações (informação ausente, erros de ferramenta)
  • Calibração: o agente sabe quando não sabe?
  • Segurança/conformidade: aderência a permissões, políticas e restrições
  • Confiabilidade ao longo do tempo: regressões após atualizações de modelo ou prompt

Avaliação por etapa e baseada em rastros

Como tarefas de longo horizonte podem falhar tarde, ajuda avaliar rastros:

  • Qualidade do plano: a decomposição faz sentido?
  • Correção no uso de ferramentas: as ferramentas certas foram chamadas com argumentos válidos?
  • Comportamento de recuperação: detectou e corrigiu erros?
  • Comportamento de verificação: testou antes de alegar sucesso?

Uma abordagem prática é registrar toda chamada de ferramenta e todo artefato intermediário e, então, computar métricas como:

  • Acurácia de chamadas de ferramenta
  • Número de tentativas (retries)
  • Frequência de “loops travados” (repetição de ações similares)
  • Fração de etapas gastas coletando informação vs. executando mudanças

Benchmarks e ambientes

A avaliação de agentes frequentemente usa benchmarks interativos ou semi-interativos, como:

  • Tarefas de navegação web e preenchimento de formulários
  • Ambientes incorporados (embodied) baseados em texto (ex.: tarefas domésticas)
  • Tarefas de engenharia de software (resolução de issues em repositórios reais)
  • Suítes de uso de ferramentas (composição de APIs, consultas a banco de dados)

Nenhum benchmark é definitivo; a avaliação em produção geralmente requer harnesses de teste específicos do domínio e conjuntos de tarefas curados.

Testes de regressão para agentes

Trate o comportamento do agente como um produto:

  • Mantenha um conjunto fixo de tarefas representativas
  • Reexecute-as a cada mudança (versão do modelo, prompt, implementação de ferramentas)
  • Acompanhe métricas e inspecione falhas
  • Armazene rastros para diff de “por que o comportamento mudou?”

Isso é especialmente importante porque agentes podem piorar quando pequenas mudanças alteram o roteamento de ferramentas ou o raciocínio intermediário.

Humano no loop e segurança para agentes

Quando agentes podem realizar ações reais (enviar e-mails, fazer deploy de código, movimentar dinheiro), guardrails não são opcionais.

Duas abordagens complementares:

  • Humano no loop (human-in-the-loop): exigir revisão/aprovação em pontos-chave
    Veja Humano no Loop.
  • Restrições técnicas de segurança: sandboxing, permissões com escopo, aplicação de políticas
    Veja Segurança para Agentes.

Controles comuns de segurança

  • Permissões de ferramentas com privilégio mínimo (somente leitura por padrão)
  • Bloqueio de ação: aprovações para operações irreversíveis (deleções, pagamentos, deploys)
  • Execução em sandbox para código e navegação
  • Listas de permissão (allowlists) para domínios, APIs e caminhos de arquivo
  • Defesas contra prompt injection para ferramentas web/de conteúdo (trate saídas de ferramentas como não confiáveis)
  • Auditoria: logs imutáveis de chamadas de ferramenta e decisões

Modos de falha comuns (e mitigações)

Sistemas agênticos falham de maneiras características:

  1. Ações ou resultados de ferramentas alucinados
    Mitigação: impor fatos apenas via ferramentas; exigir citações a partir das saídas das ferramentas; schemas estritos.

  2. Decomposição ruim / plano errado
    Mitigação: adicionar templates de planejamento, checklists e uma passagem de verificador/crítico.

  3. Loops infinitos e thrashing
    Mitigação: orçamentos de etapa, detectores de loop, heurísticas de “travamento”, escalonamento forçado.

  4. Excesso de confiança sem verificação
    Mitigação: exigir testes/consultas antes de declarar sucesso; “checagens de aceitação” estruturadas.

  5. Fragilidade de ferramentas (mudanças de UI, APIs instáveis)
    Mitigação: retries, fallbacks, contratos, monitoramento, testes sintéticos.

  6. Prompt injection / envenenamento de dados via ferramentas
    Mitigação: navegação em sandbox, tratar texto externo como adversarial, restringir capacidades das ferramentas.

  7. Otimização desalinhada (otimizar métricas em vez de metas reais)
    Mitigação: critérios de sucesso mais ricos, avaliação adversarial, revisão humana.

Aplicações práticas

Agentes e planejamento aparecem em vários domínios:

  • Engenharia de software: triagem de issues, implementar correções, abrir PRs, executar CI
  • Análise de dados: consultar data warehouses, gerar gráficos, redigir relatórios com etapas rastreáveis
  • Operações de atendimento ao cliente: resolver tickets lendo políticas + interagindo com ferramentas de CRM
  • Automação de TI: investigar alertas, coletar logs, aplicar passos de runbook
  • Robótica: planejamento de alto nível + controladores de baixo nível (frequentemente híbridos, não apenas LLM)
  • Assistência à pesquisa: busca de literatura, extração, síntese com proveniência

Um tema recorrente: agentes são mais eficazes quando as tarefas são bem instrumentadas (boas APIs, estado observável, resultados verificáveis).

Orientação de implementação: projetando um agente em que você pode confiar

Um agente de nível produção geralmente é construído como um sistema orquestrado, não como um único prompt.

Blocos de construção recomendados:

  • Modelo explícito de estado (status da tarefa, suposições, perguntas em aberto)
  • Contratos de ferramentas (schemas, timeouts, códigos de erro)
  • Ganchos de verificação (testes, validadores, invariantes)
  • Logging estruturado (rastros completos com E/S de ferramentas)
  • Fallbacks e escalonamento (perguntar ao usuário, transferir para humano, parada segura)
  • Harness de avaliação (suítes offline de tarefas + monitoramento online)

Se você estiver projetando um agente baseado em LLM, muitas vezes é útil separar responsabilidades:

  • Um planejador que propõe etapas e critérios de sucesso
  • Um executor que realiza chamadas de ferramentas
  • Um verificador que checa saídas e decide prosseguir ou revisar

Essas separações reduzem o acoplamento de erros e facilitam a avaliação.

Para onde o campo está indo

Tendências atuais em agentes & planejamento incluem:

  • Verificadores melhores: combinar LLMs com testes, análise estática e checagens formais
  • Abordagens baseadas em modelo: aprender modelos de ambiente para um planejamento mais confiável
  • Grounding mais forte em ferramentas: acoplamento mais estreito entre saídas de ferramentas e afirmações
  • Avaliação padronizada: benchmarks de longo horizonte mais realistas e reprodutíveis
  • Autonomia mais segura: segurança baseada em capacidades, políticas auditáveis e fluxos robustos de humano no loop

Sistemas agênticos são, no fim, uma disciplina de engenharia: combinando ideias de planejamento da IA clássica, frameworks de tomada de decisão do aprendizado por reforço e métodos práticos de confiabilidade de sistemas distribuídos — adaptados às forças e fraquezas dos LLMs modernos.