Capítulo 8 — Quando um modelo não basta: ferramentas e agentes

Oitavo post do passeio capítulo a capítulo pelo LLM Primer I: How Generative AI Works. Para muitas tarefas, um modelo sozinho não resolve. Aqui começa o terreno onde o modelo ganha braços.

O que um modelo sozinho não consegue

Os defeitos do capítulo 5 — alucinação, lacuna temporal, fraqueza de cálculo, oscilação — não se resolvem só com mais treinamento. A saída natural é estender o modelo para fora dele mesmo. Em vez de tentar consertar tudo dentro de uma única chamada, deixar o modelo recorrer a outras peças: busca, cálculo, banco de dados, código.

Em uma linha: se o modelo decide o próximo token a partir do contexto, então acrescentar ao contexto coisas que vêm de fora — resultado de busca, cálculo de calculadora, o horário atual, uma linha de banco de dados — expande, e muito, o que ele consegue fazer.

Chamada de função — simples e poderosa

A forma mais difundida de uso de ferramentas é a chamada de função. Você descreve, no contexto do modelo, "estas funções estão disponíveis"; o modelo responde com algo do tipo "quero chamar esta função com estes argumentos"; o sistema intercepta essa intenção, chama a função de verdade, e devolve o resultado para o contexto do modelo. O modelo, então, continua a partir dali.

Com essa peça, busca, cálculo, dados de usuário, qualquer coisa pode passar a alimentar o modelo. O modelo em si não muda; o leque do que ele consegue resolver dilata na medida das funções disponíveis.

O que distingue um "agente"

Se chamada de ferramenta é um movimento único, "agente" é o nome para a sequência. O modelo decide um passo, recebe o resultado, recoloca no contexto, decide o próximo passo, e assim por diante até a tarefa fechar.

Esse loop estende o que dá para ser feito a partir de pedidos curtos. "Faça uma análise destes dados" — o agente decide de onde puxar, como limpar, como apresentar, e vai resolvendo cada subproblema no caminho.

§8.6 — a seção nova de 2026 sobre padrões agentivos

Na edição de 2026, abri o §8.6 dedicado aos padrões agentivos. Não para repetir "o que é agente", mas para destrinchar os formatos que pegaram tração na prática.

ReAct. Alternar "reason (pensar)" e "act (agir)". O modelo escreve, no contexto, um raciocínio curto que justifica a próxima chamada, chama, recebe o resultado, e segue.

Planejador-executor. Um modelo (ou uma chamada) faz o plano completo de uma vez; outro modelo (ou outra chamada) executa cada passo. Divisão de trabalho entre o pensamento amplo e a execução fina — ajuda bastante em tarefas longas.

Reflexão. O modelo gera uma resposta inicial, e depois é levado a revisitar essa resposta — criticar, refinar, melhorar. Soa simples, e mesmo assim costuma fazer diferença significativa na qualidade final.

O que agentes ainda não resolvem

Na segunda metade do capítulo eu trato com franqueza dos limites. Quanto mais passos, mais chance de um deles falhar e contaminar os seguintes. Uma chamada que devolve uma resposta errada de uma ferramenta arrasta consigo todo o raciocínio que vem depois.

Operar agentes na prática exige tanta atenção às próprias ferramentas — qualidade do que elas devolvem, validação, contenção de erro — quanto ao modelo. É um trabalho diferente de operar um modelo isolado.

O fio do Capítulo 8

O que fica do capítulo: não tente resolver tudo dentro de um único modelo. O modelo cuida do que faz bem; outras ferramentas cuidam do que fazem bem. Essa divisão de trabalho é o que torna o sistema, como um todo, confiável.

Amanhã — Capítulo 9: RAG — costurando informação fresca no contexto. Vamos focar no uso de ferramentas mais comum hoje: recuperação semântica. Como apoiar a lacuna temporal e a exatidão factual com busca, e o que separa um RAG decente de um RAG que escala.