Agentes de LLM

Visão geral

agentes de LLM (LLM agents) são sistemas que usam um modelo de linguagem grande (large language model, LLM) não apenas para gerar texto, mas para raciocinar sobre objetivos, decidir ações, chamar ferramentas e coordenar trabalho em múltiplas etapas em um ambiente. Em vez de responder a um único prompt, um agente repetidamente:

  1. Observa o estado atual (solicitação do usuário, arquivos, páginas da web, saídas de ferramentas)
  2. Pensa/Planeja o que fazer a seguir
  3. Age produzindo uma chamada de ferramenta ou uma ação externa
  4. Atualiza o estado com os resultados
  5. Repete até que a tarefa seja concluída (ou escalone para um humano)

Esse ciclo “sentir–pensar–agir” coloca os agentes de LLM dentro da família mais ampla de agentes de IA (AI agents) estudados em IA clássica, planejamento (planning) e aprendizado por reforço (reinforcement learning) — agora com LLMs fornecendo raciocínio flexível em linguagem natural e controle de interface.

Agentes de LLM são centrais para aplicações modernas como assistentes de programação, assistentes de pesquisa, automação de fluxos de trabalho e ferramentas de operações — especialmente para tarefas de longo horizonte (long-horizon tasks) que exigem muitas etapas dependentes, verificação e uso de ferramentas (veja Tarefas de Longo Horizonte).

O que faz de algo um “agente”?

Uma forma útil de distinguir um agente de LLM de um chatbot simples:

  • Um chatbot mapeia entrada → saída (conversa de um turno ou de múltiplos turnos), tipicamente sem realizar ações externas.
  • Um agente é projetado para alcançar um objetivo sob restrições ao escolher ações e usar ferramentas, frequentemente ao longo de muitas etapas, mantendo estado (state) e lidando com falhas.

Na prática, um agente de LLM geralmente inclui:

  • Política (policy): o mecanismo de tomada de decisão (frequentemente a LLM + elaboração de prompts (prompting))
  • Estado: memória da conversa, resultados intermediários, observações do ambiente (veja Memória & Estado)
  • Espaço de ações (action space): chamadas de ferramenta, requisições de API, edições de arquivos, ações no navegador (veja Uso de Ferramentas & Orquestração)
  • Objetivo (objective): meta explícita, além de restrições (tempo, custo, permissões)
  • Realimentação (feedback): saídas de ferramentas, logs de execução, correções do usuário, avaliadores

Fundamentos: de onde vêm os agentes de LLM

Modelo clássico de agente

Na IA clássica, um agente interage com um ambiente:

  • Percepções (observações) entram
  • O agente escolhe ações
  • As ações mudam o ambiente e as percepções futuras

Isso frequentemente é formalizado como um processo de decisão de Markov (Markov decision process, MDP) ou um MDP parcialmente observável (partially observed MDP, POMDP), embora agentes de LLM raramente sejam treinados de ponta a ponta como políticas ótimas. Em vez disso, eles tipicamente são sistemas engenheirados combinando:

  • inferência de LLM
  • ferramentas / APIs
  • heurísticas e lógica de controle
  • salvaguardas (guardrails) e aprovações

LLMs como “políticas gerais” (com elaboração de prompts)

LLMs modernas (baseadas na Arquitetura Transformer) conseguem seguir instruções, escrever código e produzir saídas estruturadas. Por meio de ajuste fino por instruções (instruction tuning) e treinamento por preferências (preference training) (por exemplo, RLHF), elas podem se comportar como uma política geral de decisão — especialmente quando o espaço de ações é expresso em linguagem natural ou em formatos estruturados de chamada de ferramenta.

No entanto, LLMs não são planejadores confiáveis por natureza. Projetos de agentes compensam isso usando:

  • etapas explícitas de planejamento
  • decomposição
  • ciclos de execução/verificação
  • ancoragem (grounding) guiada por ferramentas (recuperação, calculadoras, compiladores)

Uso de ferramentas como cognição ancorada

O uso de ferramentas dá aos agentes ancoragem — uma forma de checar fatos, calcular com precisão ou mudar o estado externo. Ferramentas podem incluir:

  • busca e recuperação (RAG; veja Geração Aumentada por Recuperação)
  • bancos de dados e APIs internas
  • execução de código (Python, SQL)
  • navegadores e automação de UI
  • compiladores, analisadores estáticos (linters), executores de testes
  • sistemas de tickets, e-mail, calendários

As saídas das ferramentas tornam-se novas observações, fechando o ciclo.

Componentes centrais de um agente de LLM

1) O “cérebro” LLM

A LLM fornece:

  • compreensão em linguagem natural de objetivos e restrições
  • decomposição em etapas
  • seleção de ferramentas
  • síntese de resultados em saídas voltadas ao usuário

Em produção, a LLM normalmente é envolvida por:

  • prompts de sistema/desenvolvedor (política, estilo, restrições)
  • restrições de saída estruturada (esquema JSON (JSON schema), chamada de função (function calling))
  • filtros de segurança e políticas de recusa
  • controles de amostragem (temperature, top_p) ajustados para confiabilidade

2) Ferramentas e ações

As ações variam por ambiente, mas categorias comuns incluem:

  • Ferramentas somente leitura: busca, recuperação, consultas analíticas
  • Ferramentas de transformação: sumarização, tradução, formatação de código
  • Ferramentas que alteram estado: criar/atualizar registros, enviar mensagens, fazer deploy de código

Uma decisão-chave de projeto é como as ferramentas são representadas:

  • Descrições de ferramentas em linguagem natural (flexíveis, mas com parsing menos confiável)
  • Chamada de função / esquema JSON (mais confiável, mais fácil de validar)
  • Linguagens específicas de domínio (domain-specific languages) (poderosas, mas com maior custo de engenharia)

Para mais profundidade sobre roteamento, tentativas e estratégias de seleção, veja Uso de Ferramentas & Orquestração.

3) Memória e estado

Agentes precisam de mais do que um histórico de chat. Eles podem acompanhar:

  • Memória de trabalho (curto prazo): plano atual, checklist de tarefas, notas intermediárias
  • Memória de longo prazo: preferências do usuário, projetos anteriores, fatos reutilizáveis
  • Estado externo: arquivos, bancos de dados, tickets, repositórios de código

Implementações comuns:

  • Janela de contexto (context window): a mais simples, mas limitada pelo orçamento de tokens
  • Memória resumida (summarized memory): comprime periodicamente o histórico
  • Recuperação por banco de dados vetorial (vector database retrieval): armazena vetores de embedding (embeddings) e recupera itens relevantes
  • Estado estruturado (structured state): objetos JSON explícitos representando objetivos, restrições e progresso

Veja Memória & Estado para padrões de projeto e estratégias de persistência.

4) Planejamento e loop de controle

O “loop do agente” geralmente é controlado por um orquestrador (orchestrator) que:

  • decide quando chamar a LLM
  • valida chamadas de ferramenta
  • executa ferramentas
  • lida com falhas e tentativas
  • impõe orçamentos e permissões

Planejamento em si é um tema grande; veja Planejamento (Agêntico) e Arquiteturas de Agentes.

5) Avaliação e realimentação

Agentes podem falhar silenciosamente de formas sutis (suposições erradas, etapas incompletas, ações inseguras). Sistemas robustos usam:

  • testes unitários/de integração para ferramentas
  • tarefas de avaliação roteirizadas
  • revisão humana e caminhos de escalonamento
  • críticos ou verificadores automatizados (com cautela)

Veja Avaliação de Agentes e Humano no Loop.

Arquiteturas comuns de agentes de LLM (padrões de projeto)

Agentes de LLM raramente são um único prompt monolítico. Vários padrões recorrentes são usados na prática:

ReAct (Raciocinar + Agir (Reason + Act))

Em ReAct, o modelo intercala raciocínio (“pensar”) e uso de ferramentas (“agir”), incorporando observações após cada chamada de ferramenta.

Loop típico:

  1. Pensar: o que fazer a seguir
  2. Agir: chamar uma ferramenta
  3. Observar: ler a saída da ferramenta
  4. Repetir

Isso é simples e eficaz para tarefas intensivas em ferramentas (busca, depuração), embora possa desviar sem restrições. Veja Arquiteturas de Agentes.

Planejar e executar (plan-and-execute)

Um planejador primeiro produz um plano de múltiplas etapas; um executor o realiza passo a passo, revisando quando necessário.

Benefícios:

  • estrutura mais clara para trabalho de longo horizonte
  • mais fácil mostrar progresso e permitir aprovações do usuário
  • melhor separação de responsabilidades (planejar vs fazer)

Desvantagem:

  • planos iniciais podem ser frágeis; replanejamento é essencial

Ciclos de reflexão / autocrítica (Reflexion / self-critique loops)

Agentes podem melhorar a confiabilidade adicionando:

  • uma etapa de crítico (critic) que verifica erros, etapas faltantes ou contradições
  • uma ferramenta de verificador (verifier) (testes, checagens de esquema, restrições)
  • reflexão retrospectiva salva na memória

Isso pode reduzir alguns modos de falha, mas também pode aumentar o custo e, às vezes, produzir críticas “confiantes, porém erradas” se não houver ancoragem.

Agentes aumentados por recuperação (retrieval-augmented agents)

Esses agentes chamam frequentemente ferramentas de recuperação (busca, banco vetorial) para ancorar decisões em informações atualizadas ou proprietárias. Isso é especialmente importante quando a tarefa depende de:

  • documentação interna
  • eventos recentes
  • fatos específicos de domínio fora dos dados de treinamento do modelo

Um loop mínimo de agente (conceitual)

Abaixo está um loop de agente simplificado mostrando como um orquestrador media entre a LLM e ferramentas. Sistemas reais adicionam checagens de segurança, validação de esquema, limitação de taxa e mais.

from typing import Any, Dict

TOOLS = {
    "search": lambda q: {"results": web_search(q)},
    "calc": lambda expr: {"value": safe_eval(expr)},
}

def llm_decide(messages: list[dict], tool_schemas: list[dict]) -> dict:
    """
    Returns either:
      {"type": "tool_call", "name": "...", "args": {...}}
    or {"type": "final", "content": "..."}
    """
    return call_llm(messages=messages, tools=tool_schemas)

def run_agent(user_request: str, max_steps: int = 8) -> str:
    messages = [{"role": "user", "content": user_request}]
    for step in range(max_steps):
        decision = llm_decide(messages, tool_schemas=[...])

        if decision["type"] == "final":
            return decision["content"]

        if decision["type"] == "tool_call":
            name = decision["name"]
            args = decision["args"]

            # Validate tool + args (types, permissions, budgets)
            if name not in TOOLS:
                messages.append({"role": "tool", "name": name, "content": "ERROR: unknown tool"})
                continue

            result: Dict[str, Any] = TOOLS[name](/ia-generativa/recuperacao-ferramentas/chamada-de-funcoes-uso-de-ferramentas/api-de-tool-calling-padrao-de-nome-e-args-kwargs)
            messages.append({"role": "tool", "name": name, "content": json.dumps(result)})

    return "Stopped: reached max steps without completing."

Ponto-chave: o orquestrador é dono da execução. A LLM propõe ações; o sistema as valida e as executa.

Exemplos práticos

Exemplo 1: Agente assistente de pesquisa (busca + síntese)

Objetivo: “Resuma as melhores práticas mais recentes para avaliar agentes de geração de código.”

Comportamento típico:

  1. O agente chama search("code agent evaluation benchmarks SWE-bench")
  2. Lê os resultados e então chama search("AgentBench benchmark details")
  3. Extrai propriedades-chave dos benchmarks (tipos de tarefa, métricas, armadilhas)
  4. Produz um resumo estruturado e cita fontes (se o sistema suportar linkagem de fontes)

Onde agentes ajudam:

  • ampliar/afunilar iterativamente a consulta
  • cruzar múltiplas fontes
  • transformar informações dispersas em um relatório coerente

Onde falham:

  • citar fontes pouco confiáveis
  • alucinar citações
  • deixar de fora contraexemplos cruciais

Mitigação:

  • exigir saídas de ferramentas para alegações factuais
  • impor formatos de citação
  • incluir um checklist de verificação (veja Avaliação de Agentes)

Exemplo 2: Agente de análise de dados (ferramenta Python)

Objetivo: “Dado este CSV, encontre anomalias e plote tendências.”

Ferramentas:

  • python_exec(code) que roda em um sandbox
  • ferramentas de leitura/escrita de arquivos
  • renderização opcional de visualizações

O agente pode:

  1. Carregar dados no pandas
  2. Calcular estatísticas descritivas
  3. Detectar outliers (z-score, IQR, decomposição sazonal)
  4. Gerar gráficos
  5. Fornecer uma explicação dos achados

Crucialmente, a execução de ferramentas ancora a saída: o agente pode calcular valores exatos em vez de aproximar.

Exemplo 3: Agente de engenharia de software (ferramentas de repo + testes)

Objetivo: “Corrija testes que estão falhando em um repositório.”

Ferramentas:

  • read_file, search_repo, edit_file
  • run_tests
  • run_linter

Um fluxo confiável:

  1. Rodar testes → observar o trace de falha
  2. Localizar o problema → ler o código relevante
  3. Propor correção mínima → aplicar o patch
  4. Re-rodar testes → confirmar que passou
  5. Resumir a mudança e o raciocínio

Este é um cenário canônico de agente de longo horizonte: o sucesso exige sequenciamento correto, verificação e rastreamento cuidadoso de estado.

Principais desafios e modos de falha

Alucinação e ações sem ancoragem

LLMs podem inventar:

  • saídas de ferramentas
  • conteúdos de arquivos
  • ações “bem-sucedidas” que nunca ocorreram

Mitigações:

  • nunca permitir que o modelo escreva diretamente “resultados de ferramentas”
  • separar estritamente observações (das ferramentas) vs texto do modelo
  • usar saídas de ferramentas estruturadas e assinaturas

Fragilidade em tarefas de longo horizonte

Ao longo de muitas etapas, pequenos erros se acumulam:

  • esquecer restrições
  • perder o rastro do progresso parcial
  • desvio do plano

Mitigações:

  • estado explícito da tarefa (checklists, rastreadores de etapas)
  • resumos periódicos
  • gatilhos de replanejamento quando observações diferem do esperado
  • decomposição e verificação intermediária (veja Tarefas de Longo Horizonte)

Erros de seleção de ferramentas

Modelos podem escolher a ferramenta errada ou usar argumentos incorretamente.

Mitigações:

  • descrições de ferramentas mais restritas e com exemplos
  • validação de esquema e checagem de tipos
  • roteadores de ferramentas (tool routers) (heurísticos ou aprendidos) antes da LLM (veja Uso de Ferramentas & Orquestração)

Riscos de segurança e safety

Agentes são alvos atraentes porque podem realizar ações. Riscos incluem:

  • injeção de prompt (prompt injection) via páginas da web ou documentos
  • exfiltração de dados (data exfiltration) via saídas de ferramentas
  • ações inseguras (enviar por e-mail informações sensíveis, deletar dados)

Mitigações (tópicos centrais em Safety para Agentes):

  • permissões de ferramentas com privilégio mínimo (least privilege)
  • execução em sandbox para código e navegação
  • listas de permissões (allowlists) para destinos (URLs, domínios de e-mail)
  • aprovações humanas para ações de alto impacto
  • tratamento robusto de entradas e defesas contra injeção de prompt

Otimização desalinhada (“reward hacking”)

Se um agente é avaliado por métricas superficiais (por exemplo, “produziu uma resposta”), ele pode otimizar para parecer correto em vez de ser correto.

Mitigações:

  • critérios de sucesso vinculados a resultados no ambiente (testes passam, registro atualizado)
  • tarefas de avaliação adversariais
  • revisão com humano no loop para fluxos críticos (veja Humano no Loop)

Blocos de construção em sistemas reais

Frameworks de orquestração (orchestration frameworks)

Muitas equipes usam frameworks para gerenciar:

  • registro de ferramentas
  • memória
  • roteamento multiagente (multi-agent)
  • rastreamento e avaliação

Exemplos no ecossistema incluem LangChain, LlamaIndex, Semantic Kernel e bibliotecas multiagente (as escolhas evoluem rapidamente). Mesmo com frameworks, sistemas em produção tipicamente adicionam orquestração customizada substancial, camadas de observabilidade e segurança.

Observabilidade e rastreamento (observability and tracing)

Falhas de agentes frequentemente são “distribuídas” ao longo de etapas. Logs úteis incluem:

  • cada entrada/saída da LLM (com redação)
  • chamadas de ferramentas, argumentos e resultados
  • orçamentos por etapa e razões de parada
  • diffs de edições de arquivo
  • resultados de avaliação

Isso dá suporte a testes de regressão e melhoria contínua (veja Avaliação de Agentes).

Sistemas multiagentes (brevemente)

Algumas aplicações usam múltiplos agentes especializados em vez de um generalista:

  • um agente planejador
  • um agente executor que usa ferramentas
  • um agente crítico/verificador
  • especialistas de domínio (agente SQL, agente de navegador, agente de programação)

Benefícios:

  • especialização e responsabilidades mais claras
  • trabalho em paralelo (buscar enquanto codifica)
  • modularidade e avaliação mais fácil

Custos:

  • sobrecarga de coordenação
  • falhas de comunicação e estado inconsistente
  • comportamentos emergentes difíceis de prever

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

Boas práticas (orientação prática)

Projete para verificação, não apenas geração

Prefira loops de agentes em que etapas intermediárias sejam checadas:

  • rodar testes
  • validar esquemas
  • confirmar escritas em banco de dados
  • comparar saídas com restrições

Torne o estado explícito

Em vez de esperar que o modelo “se lembre”, armazene:

  • objetivos, restrições, critérios de aceitação
  • etapas concluídas
  • artefatos produzidos (arquivos, links, IDs)

Isso reduz desvio e torna o comportamento auditável (veja Memória & Estado).

Restrinja ferramentas agressivamente

  • separar ferramentas de leitura vs escrita
  • exigir confirmações para ações destrutivas
  • adicionar limites de taxa e cotas
  • registrar tudo

Trate prompting como política, mas imponha com código

Prompts ajudam, mas o orquestrador deve impor:

  • ferramentas permitidas
  • tipos de argumento
  • máximo de etapas/custo
  • limites do sandbox

Avalie em tarefas realistas

Use suítes de tarefas que reflitam trabalho real:

  • fluxos de trabalho de múltiplas etapas
  • entradas ruidosas
  • falhas parciais
  • conteúdo adversarial (injeção de prompt)

Veja Avaliação de Agentes.

Quando usar (e quando não usar) um agente de LLM

Bom encaixe

  • tarefas que exigem coordenação de ferramentas
  • fluxos com estrutura variável (não dá para hardcodear todos os caminhos)
  • ambientes em que verificação é possível (testes, consultas, restrições)
  • assistentes voltados ao usuário que se beneficiam de esclarecimento iterativo

Mau encaixe

  • ações autônomas de alto risco sem aprovações robustas
  • tarefas sem sinal confiável de realimentação (não dá para verificar correção)
  • contextos de latência ultrabaixa ou custo ultrabaixo
  • fluxos determinísticos melhor atendidos por software tradicional

Resumo

Agentes de LLM estendem LLMs de “respondedores de texto” para sistemas orientados a objetivos que conseguem planejar, agir, usar ferramentas, manter estado e iterar. Seu poder vem de combinar raciocínio flexível em linguagem com ferramentas externas ancoradas e orquestração explícita. Seus riscos vêm da mesma autonomia: erros se acumulam ao longo do tempo, uso incorreto de ferramentas pode causar dano, e ameaças de segurança como injeção de prompt tornam-se preocupações práticas.

Um agente de LLM forte, portanto, é menos sobre um único prompt esperto e mais sobre arquitetura — loops de planejamento, memória, orquestração de ferramentas, verificação, avaliação e controles de segurança — cobertos em artigos relacionados como Arquiteturas de Agentes, Planejamento (Agêntico), Uso de Ferramentas & Orquestração, Memória & Estado, Avaliação de Agentes, Humano no Loop e Safety para Agentes.