Arquiteturas de Agentes

O que significa “arquitetura de agente”

Uma arquitetura de agente é o loop de controle e o layout de componentes usados para transformar um modelo (frequentemente um LLM, isto é, modelo de linguagem grande (large language model)) em um sistema que consegue perseguir objetivos ao longo de múltiplas etapas, usar ferramentas, manter estado e se recuperar de erros. Enquanto uma única interação de prompt–resposta é “sem estado” (stateless), uma arquitetura de agente define:

Como decisões são tomadas (reativas vs planejadas vs reflexivas)
Quando ferramentas são invocadas (busca, execução de código, bancos de dados, APIs)
Como o estado intermediário é armazenado (scratchpads, memória de trabalho, memória de longo prazo)
Como o progresso é verificado (testes, validadores, críticos, revisão humana)
Como o sistema lida com incerteza e falhas (tentativas novamente, replanejamento, rollback)

A maioria dos “agentes de LLM” modernos é melhor compreendida como padrões de projeto (design patterns) que combinam um LLM com uma pequena quantidade de código de orquestração. Este artigo foca nos padrões mais comuns — ReAct, planejar e executar (plan-and-execute), reflexão (reflexion) — e em várias arquiteturas intimamente relacionadas.

Para um contexto mais amplo sobre agentes que coordenam ferramentas e contexto, veja Agentes de LLM. Para técnicas específicas de planejamento, veja Planejamento (Agêntico). Para desafios únicos de objetivos com muitas etapas, veja Tarefas de Longo Horizonte.

Fundamentos teóricos (em termos simples)

Arquiteturas de agente tomam emprestadas ideias de IA clássica e aprendizado por reforço (reinforcement learning):

Estado, ações, transições: a cada etapa, o agente observa um estado (mensagens, saídas de ferramentas, ambiente), escolhe uma ação (responder, chamar ferramenta, perguntar ao usuário) e o mundo transita para um novo estado. Isso espelha Processos de Decisão de Markov e, quando as observações são parciais, POMDPs.
Política vs planejamento: um agente reativo se comporta como uma política (“dada esta observação, faça aquilo”). Um agente de planejamento constrói explicitamente uma sequência de ações. Muitos sistemas práticos misturam ambos: planejam em alto nível, reagem em baixo nível.
Verificação e feedback: sistemas clássicos separam propor (gerar ações candidatas) de verificar (checar correção). Arquiteturas de agente modernas frequentemente implementam isso via críticos, testes, restrições e revisão humana.
Decomposição e hierarquia: tarefas longas ficam mais fáceis quando decompostas em subobjetivos (planejamento hierárquico). Arquiteturas como planejar e executar e supervisor–trabalhador tornam isso explícito.

LLMs adicionam um fator novo: eles podem gerar planos e comandos de ferramenta com fluência, mas não há garantia de correção. Arquiteturas existem em grande parte para reduzir o custo de erros e aumentar a confiabilidade.

Blocos fundamentais

A maioria das arquiteturas de agente é construída a partir das mesmas peças.

1) Loop do controlador

O orquestrador que decide o que acontece em seguida:

Ler o estado atual (conversa, resultados de ferramentas, memória)
Pedir ao modelo para propor o(s) próximo(s) passo(s)
Opcionalmente verificar (regras, testes, críticos)
Executar a ação (chamada de ferramenta / mensagem)
Atualizar o estado e repetir até concluir ou parar

2) Ferramentas e ambiente

Ferramentas são “ações” tipadas com esquemas de entrada/saída:

Recuperação/busca (web, docs, embeddings)
Execução de código (Python, SQL)
APIs externas (calendário, CRM, sistema de tickets)
Operações de arquivo (ler/escrever)
Modelos especializados (visão, fala, classificadores)

O uso de ferramentas introduz efeitos colaterais (enviar e-mails, modificar bancos de dados), o que torna fluxos de segurança e aprovação importantes; veja Segurança para Agentes e Humano no Loop.

3) Memória

Formas comuns:

Memória de trabalho: scratchpad de curta duração; objetivo atual, premissas, resultados parciais
Memória episódica: resumos de tentativas e resultados passados
Memória semântica: fatos, documentos ou embeddings (recuperação no estilo RAG, isto é, geração aumentada por recuperação (retrieval-augmented generation))

A memória pode ajudar a evitar repetir erros, mas também pode propagar erros se não for validada.

4) Verificação e guardrails

Mecanismos típicos:

Validadores de saída (esquemas, regex, checagens de tipo)
Testes unitários / checagens baseadas em execução (para código ou matemática)
Checagens de consistência (conferir com fontes)
Modelos “críticos” ou prompts de crítica
Permissões + aprovações para ferramentas sensíveis

Métodos de avaliação são discutidos em Avaliação de Agentes.

ReAct: intercalando raciocínio e ação

ReAct (Reason + Act) é um padrão em que o agente alterna entre:

pensar sobre o que fazer em seguida e
tomar uma ação (frequentemente uma chamada de ferramenta) para coletar informações ou avançar.

A ideia central: em vez de produzir um plano completo de antemão, o agente usa o feedback das ferramentas para orientar o próximo passo.

Quando ReAct funciona bem

Tarefas abertas com incógnitas (pesquisa, depuração, investigação)
Ambientes em que as saídas das ferramentas reduzem significativamente a incerteza
Problemas em que planejar cedo demais leva a planos frágeis ou incorretos

Modos comuns de falha

“Tool thrashing” (buscas demais ou chamadas repetidas)
Loops superficiais (nunca sintetiza; só coleta)
“Observações” alucinadas se os limites das ferramentas não forem aplicados
Riscos de raciocínio oculto (se o sistema depender de chain-of-thought privada)

Uma mitigação prática é separar raciocínio interno de rastros auditáveis, registrando apenas chamadas de ferramenta, saídas de ferramenta e justificativas concisas, em vez de pensamentos completos em formato livre.

Loop mínimo no estilo ReAct (pseudocódigo)

state = {
  "goal": user_goal,
  "messages": [],
  "scratch": "",
}

while not done(state):
    prompt = render_prompt(state)  # includes goal + recent tool outputs
    decision = llm(prompt)         # returns either TOOL_CALL or FINAL_ANSWER

    if decision.type == "TOOL_CALL":
        result = tools[decision.tool_name](/ia-generativa/recuperacao-ferramentas/chamada-de-funcoes-uso-de-ferramentas)
        state["messages"].append({"tool": decision.tool_name, "result": result})
    else:
        return decision.final_text

Exemplo prático: “Encontre a política mais recente e depois resuma”

Um agente ReAct poderia:

Buscar em docs internos → ler a página relevante → extrair cláusulas-chave → produzir resumo
Se os resultados forem inconsistentes, buscar novamente com uma consulta refinada

Essa costuma ser a arquitetura efetiva mais simples para fluxos de trabalho de “pesquisa + síntese”.

Planejar e executar: comprometer-se com a estrutura e depois rodá-la

Planejar e executar divide o trabalho em duas fases:

Planejamento: produzir um plano de múltiplas etapas (frequentemente um checklist com etapas de ferramenta)
Execução: realizar cada etapa, chamando ferramentas conforme necessário

Esse padrão é popular porque torna o comportamento mais previsível e auditável. Ele também dá suporte a controle de custo (limitar etapas) e governança (revisar o plano antes da execução).

Variantes

Plano estático: planejar uma vez e executar do começo ao fim (rápido, mas frágil)
Plano com checkpoints: verificar após cada etapa; replanejar se necessário
Planejamento hierárquico: plano de alto nível → expandir em subplanos (como HTNs)
Plano + orçamento: parar se o orçamento de etapas/tempo/ferramentas for excedido

Pontos fortes

Melhor para tarefas de longo horizonte onde a decomposição importa (planos de migração, fluxos de projeto)
Mais fácil de integrar com aprovação humana (“aprovar este plano?”)
Mais fácil de impor restrições (“deve usar a ferramenta X antes de escrever a saída”)

Pontos fracos

Planos podem estar errados porque o agente não tem informação suficiente no momento do planejamento
Decomposição excessivamente confiante pode pular descoberta necessária
A execução pode desviar se as etapas forem ambíguas

Exemplo: planejar e executar com replanejamento

plan = llm_make_plan(goal, constraints, tools)

for step in plan.steps:
    result = execute_step(step, tools)

    if not verify_step(step, result):
        plan = llm_replan(goal, plan, step, result)
        continue

return llm_summarize_outcome(goal, plan, execution_log)

Exemplo prático: “Relatório trimestral de KPIs”

Um plano pode incluir:

Consultar o BD de vendas para receita do Q4 por região (ferramenta SQL)
Consultar o CRM para mudanças no pipeline (ferramenta de API)
Calcular variações YoY (ferramenta Python)
Redigir narrativa + gráficos (ferramenta de template)
Validar totais contra o dashboard financeiro (etapa de verificação)

Esse estilo se alinha bem com fluxos corporativos porque dá suporte naturalmente a logging, revisão e conformidade.

Reflexão: aprender com erros por meio de crítica e memória

Arquiteturas de reflexão introduzem uma etapa explícita de autoavaliação. Após uma tentativa, o agente critica o próprio desempenho e armazena uma lição (uma “reflexão”) para melhorar o comportamento futuro.

Um loop típico:

Tentar a tarefa
Avaliar o resultado (testes, rubrica, modelo crítico, feedback do usuário)
Gerar reflexão (“O que deu errado? O que deve mudar da próxima vez?”)
Armazenar a reflexão na memória e tentar novamente ou aplicar em tarefas futuras

O que reflexção é (e o que não é)

Não é autoaperfeiçoamento mágico; é feedback estruturado + memória.
Funciona melhor quando há um sinal objetivo: testes passando, saídas de ferramentas, uma rubrica de avaliação ou critérios de aceitação do usuário.

Pontos fortes

Ajuda com erros recorrentes (formatação, restrições ausentes, uso incorreto de ferramentas)
Incentiva comportamento de “pós-mortem” que melhora a confiabilidade ao longo de execuções repetidas
Combina bem com tarefas de longo horizonte onde erros iniciais se acumulam

Riscos

“Reflexões ruins” podem consolidar crenças incorretas se a avaliação for fraca
A memória pode acumular contradições; precisa de curadoria e pontuação
Se as reflexões forem genéricas demais (“seja mais cuidadoso”), não ajudam

Exemplo prático: geração de código com testes

Um agente de reflexão pode:

Escrever código → rodar testes unitários → se falhar, criticar → atualizar a estratégia (“Eu interpretei a API errado; use datetime.timezone.utc”) → corrigir o código → rerodar os testes.

Essa abordagem é comum em agentes de programação porque testes fornecem um sinal de avaliação limpo.

Padrões de projeto de agentes relacionados (comumente usados na prática)

Arquitetura supervisor–trabalhador (gerente–especialista)

Um modelo supervisor decompõe a tarefa e delega a agentes trabalhadores especializados por conjunto de ferramentas ou domínio (pesquisador, programador, analista, redator). O supervisor integra resultados e aplica restrições.

Útil quando:

A tarefa mistura habilidades distintas (recuperação + matemática + escrita)
Paralelização importa (múltiplas subtarefas independentes)
Você precisa de separação de papéis por segurança (apenas um trabalhador pode chamar ferramentas sensíveis)

Esse padrão também é um degrau rumo a sistemas “multiagente”, embora muitos sistemas em produção mantenham trabalhadores leves para reduzir complexidade.

Loop crítico / verificador (gerar–verificar)

O agente gera uma saída candidata, então um verificador checa:

Verificação baseada em regras: validação de esquema, restrições, checagens determinísticas
Crítica baseada em modelo: um segundo LLM critica ou pontua a saída
Verificação baseada em execução: rodar código, avaliar queries, checar citações

Isso se assemelha a ideias de Autoconsistência e a fluxos clássicos de “propor–testar–revisar”.

Uma dica prática: sempre que possível, prefira checagens baseadas em execução em vez de “crítica por LLM”, porque críticos podem compartilhar os mesmos pontos cegos.

Agente com recuperação aumentada (RAG agêntico)

Em vez de uma única etapa de recuperação antes de responder, um agente usa recuperação ao longo do loop:

Buscar → ler → decidir a próxima consulta → reconciliar fontes → redigir → citar
A recuperação vira uma ação que pode ser repetida e refinada

Isso é especialmente efetivo em tarefas com muito conhecimento e combina naturalmente com ReAct.

Veja também Geração Aumentada por Recuperação (RAG).

Arquitetura de quadro-negro (workspace compartilhado)

Múltiplos componentes leem/escrevem em um estado compartilhado de “quadro-negro”:

Fatos, premissas, perguntas em aberto, soluções parciais, resultados de ferramentas
Um controlador seleciona qual componente roda em seguida

Essa é uma arquitetura clássica de IA que se mapeia bem para orquestradores modernos e torna o estado explícito e depurável.

Agentes orientados a eventos / agentes de workflow

Alguns “agentes” estão mais próximos de workflows:

Máquinas de estado determinísticas para processos conhecidos
LLM usado apenas para etapas flexíveis (classificação, redação, extração)

Essa abordagem híbrida costuma ser a mais robusta em produção: use LLMs onde agregam valor e mantenha o resto determinístico.

Escolhendo uma arquitetura: trade-offs práticos

Reatividade vs estrutura

ReAct: adaptável, bom sob incerteza; mais difícil de auditar; risco de “tool thrash”
Planejar e executar: estruturado e auditável; pode ser frágil sem replanejamento
Reflexão: melhora ao longo de tentativas/execuções; depende da qualidade do sinal de avaliação

Muitos sistemas reais combinam:

Planejar e executar com uso de ferramentas no estilo ReAct durante cada etapa
ReAct com planejamento periódico (“a cada N etapas, reavaliar e atualizar o plano”)
Reflexão após execuções falhas para atualizar memória e restrições

Custo, latência e orçamentos

Loops de agente multiplicam custos de tokens e de ferramentas. Controles comuns:

Limite de etapas (máximo de chamadas de ferramenta)
Timeouts por ferramenta
“Confidence gating” (só chamar ferramentas caras se necessário)
Parada antecipada quando os critérios de aceitação forem atendidos

Observabilidade e depuração

Arquiteturas devem produzir um rastro de execução:

chamadas de ferramenta + argumentos
saídas de ferramenta (ou hashes/links se sensíveis)
resultados de etapas (passou/falhou)
artefatos finais

Esse rastro é essencial para testes de regressão e é central em Avaliação de Agentes.

Considerações de segurança e confiabilidade (em nível de arquitetura)

As escolhas de arquitetura de agente afetam fortemente a segurança:

Ferramentas com permissão: restringir efeitos colaterais; exigir aprovações para ações sensíveis
Sandboxing: executar código/ferramentas em ambientes isolados
Separação de funções: um planejador pode propor ações, mas um executor ou filtro de política aplica restrições
Escalonamento humano: encaminhar etapas ambíguas ou de alto impacto para humanos

Esses tópicos são abordados em Segurança para Agentes e Humano no Loop. Na prática, um agente “seguro” costuma ser uma arquitetura que torna ações arriscadas raras, revisáveis e reversíveis.

Aplicações práticas (onde esses padrões aparecem)

Automação de suporte ao cliente: ReAct para troubleshooting com bases de conhecimento; planejar e executar para fluxos de tickets
Assistentes de análise de dados: planejar e executar para pipelines reprodutíveis; reflexão com checagens de outliers e consultas de validação
Agentes de programação: reflexão com testes unitários; loops gerar–verificar; permissões de ferramentas limitadas
Assistentes de pesquisa: ReAct com recuperação iterativa; loops críticos para checagem de citações
Automação de Ops/IT: planejar e executar com aprovações e rollback; separação supervisor–trabalhador para ações privilegiadas

Dicas de implementação (o que importa em sistemas reais)

Torne o estado explícito. Armazene objetivos, restrições, saídas parciais e resultados de ferramentas em forma estruturada (JSON ou objetos tipados), não apenas como texto de chat.
Use esquemas para I/O de ferramentas. Aplique tipos e campos obrigatórios; rejeite chamadas malformadas.
Prefira etapas verificáveis. Adicione checkpoints com validadores determinísticos (testes, contagens de linhas em SQL, existência de arquivos).
Projete para replanejamento. Mesmo os melhores planos falham quando novas informações chegam.
Trate a memória como não confiável. Pontue, desduplique e expire reflexões; evite injetar cegamente memória grande em prompts.
Registre tudo o que for seguro registrar. Você não consegue melhorar o que não consegue observar.

Para onde o campo está indo

Tendências atuais em arquiteturas de agente incluem:

Mais verificação baseada em execução (testes, sandboxes, restrições formais)
Melhor confiabilidade de ferramentas e interfaces tipadas (menos prompts “stringly-typed”)
Workflows híbridos que combinam orquestração determinística com flexibilidade de LLM
Harneses de avaliação mais fortes e suítes de regressão para tarefas de longo horizonte

Para uma cobertura mais profunda de métodos de planejamento e estratégias de decomposição, veja Planejamento (Agêntico) e Tarefas de Longo Horizonte. Para saber como medir se uma arquitetura de fato melhora resultados, veja Avaliação de Agentes.