🧠 Pensar: a fase de raciocínio
Antes de qualquer ação, o agente pensa. Esta fase é onde o LLM analisa o objetivo, examina o contexto disponível e decide qual será a próxima ação. É aqui que a qualidade do modelo e do prompt fazem a maior diferença.
🧠 O que acontece durante o raciocínio
O LLM recebe o contexto completo — objetivo, histórico de ações anteriores, resultados das tools já executadas — e gera um raciocínio antes de decidir a próxima ação. Esse raciocínio interno é o coração do loop.
Chain-of-Thought (CoT)
- • O modelo "pensa em voz alta" antes de responder
- • Raciocínio passo a passo melhora precisão em até 40%
- • Visível no scratchpad / thinking tokens
- • Custo extra em tokens, mas vale para tasks complexas
ReAct (Reason + Act)
- • Padrão: Thought → Action → Observation
- • Raciocínio e ação intercalados no mesmo loop
- • Cada observação alimenta o próximo pensamento
- • Base da maioria dos frameworks modernos
📋 O que está no contexto durante o Pensar
💡 Dica Prática
Use modelos com extended thinking (Claude claude-sonnet-4-6 thinking, o1) para tasks que exigem múltiplos passos lógicos. Para tasks simples, evite o custo extra. A regra: se um humano precisaria de mais de 30 segundos para pensar, use thinking habilitado.
⚡ Agir: execução com ferramentas
Após raciocinar, o agente age. Isso significa emitir uma chamada de ferramenta — uma instrução estruturada para executar uma ação no mundo real. É aqui que IA deixa de ser texto e vira consequência.
📊 Anatomia de uma Tool Call
Uma tool call é uma estrutura JSON que o modelo retorna no lugar de texto. O seu código intercepta isso e executa a ação correspondente.
// O modelo retorna isso:
{
"type": "tool_use",
"name": "search_web",
"input": {
"query": "preço Bitcoin hoje",
"max_results": 5
}
}
✓ Boas práticas em Ação
- ✓ Validar inputs da tool antes de executar
- ✓ Definir timeout por tool call
- ✓ Logar cada ação com timestamp e custo
- ✓ Usar sandboxing para ações destrutivas
- ✓ Requerer confirmação humana para ações irreversíveis
✗ Erros comuns na fase de Ação
- ✗ Dar permissões de escrita sem precisar
- ✗ Executar SQL sem validação de query
- ✗ Tools sem retry logic para falhas transientes
- ✗ Ignorar erros de permissão de sistemas externos
- ✗ Chamar APIs com rate limit sem backoff
⚠️ Ações têm consequências reais
Diferente de um chatbot que apenas gera texto, um agente em ação pode: deletar arquivos, enviar emails, gastar dinheiro via API, modificar bancos de dados em produção. Trate cada tool como se fosse um junior developer com acesso de admin — defina permissões mínimas e auditoria total.
👁️ Observar: lendo o resultado
Após agir, o agente observa o resultado da ação. O output da tool é injetado de volta no contexto como uma mensagem especial do tipo tool_result, e o próximo ciclo de raciocínio começa com essa informação.
👁️ O que entra no contexto após a observação
Resultado de sucesso
O output da tool é serializado e adicionado como tool_result. O agente sabe o que aconteceu e pode continuar.
Resultado de erro
O erro também é injetado no contexto. Agentes bem projetados conseguem ler o erro e tentar uma abordagem alternativa em vez de travar.
Output muito grande
Um search retornou 50 páginas? Um arquivo tem 10.000 linhas? Você precisa de estratégia de truncagem — o contexto tem limite e overflow causa falhas silenciosas.
💡 Dica de Parsing de Observação
Nunca injete raw output de tools sem processamento. Antes de adicionar ao contexto:
- • Limite o tamanho máximo (ex: primeiros 2000 caracteres de um arquivo)
- • Serialize objetos complexos como JSON formatado, não Python repr
- • Adicione metadados úteis: timestamp, tool usada, status HTTP
⚖️ Avaliar: o que separa agente de script
A fase de avaliação é onde um agente verdadeiro se diferencia de uma automação linear. Após observar o resultado, o agente decide: o objetivo foi atingido? O resultado é suficiente? Precisa tentar de outra forma?
🔍 As 4 perguntas da fase de Avaliação
O objetivo foi atingido?
Critério de sucesso precisa ser definido no sistema de raciocínio. Sem critério claro, o agente nunca sabe quando parar.
O resultado foi um erro recuperável?
Erro de rede é diferente de erro de permissão. O agente deve classificar erros e decidir se pode tentar de novo ou precisa escalar.
O plano atual ainda é válido?
Se uma pesquisa revelou que a abordagem original estava errada, o agente pode (e deve) replanificar antes de continuar.
É hora de parar e pedir ajuda?
Human-in-the-loop não é fraqueza — é arquitetura. Definir quando escalar para humano é tão importante quanto definir quando agir sozinho.
📊 Replanning: quando o agente muda de estratégia
Replanning acontece quando a avaliação detecta que o plano atual não vai funcionar. Um bom agente não insiste em uma estratégia falha:
- •API externa retornou 429? Tentativa com dados em cache.
- •Formato de dados diferente do esperado? Parse adaptativo.
- •Sub-tarefa impossível? Remove do plano, reporta limitação.
- •Objetivo ambíguo? Para e pede clarificação ao humano.
🔄 O loop na prática: walkthrough completo
Vamos ver o loop completo em ação. Objetivo: "Pesquise o preço do Bitcoin nos últimos 7 dias e gere um resumo de tendência." — 4 iterações reais com custo por iteração.
Iteração 1 — Planejar e buscar dados
~800 tokens · ~$0.002Pensar: "Preciso de dados de preço. Vou usar a tool de busca web para encontrar o preço atual e histórico de 7 dias."
Agir: search_web("Bitcoin price last 7 days 2026")
Observar: Retornou 5 resultados com preços de sites financeiros
Iteração 2 — Extrair dados estruturados
~1200 tokens · ~$0.003Avaliar: "Os resultados da busca têm texto mesclado com preços. Preciso de dados estruturados. Vou extrair os preços de uma API direta."
Agir (replanning): call_api("coinbase.com/v2/prices/BTC-USD/historic")
Observar: JSON com preços dos últimos 7 dias retornado com sucesso
Iteração 3 — Calcular tendência
~900 tokens · ~$0.002Pensar: "Tenho os dados. Vou calcular variação percentual, preço máximo e mínimo do período."
Agir: run_python("calcular_tendencia(precos)")
Observar: +12.3% no período, máximo $98.400, mínimo $87.200
Iteração 4 — Gerar resumo (DONE)
~600 tokens · ~$0.001 · TOTAL: ~$0.008Avaliar: "Objetivo atingido. Tenho dados e análise. Posso gerar o resumo final."
Resultado: Resumo formatado com tendência alta de +12.3%, contexto de mercado e recomendação de monitoramento
⚠️ Quando o loop vira problema
O loop agentic é poderoso — e por isso mesmo é perigoso quando sai do controle. Sem os guardrails corretos, um agente pode entrar em espiral infinita, gerar alucinações em cascata e acumular custo de forma explosiva.
🔁 Loop Infinito
O agente avalia que o objetivo não foi atingido, tenta novamente, falha do mesmo jeito, tenta de novo... indefinidamente.
Solução: max_iterations com fallback explícito
🌀 Alucinação em Cascata
O agente alucina um resultado de tool, usa esse resultado falso para gerar outro resultado, e o erro se amplifica a cada iteração.
Solução: Validação de output de tools antes de injetar no contexto
💸 Custo Explosivo
Sem limite de iterações ou budget cap, um agente mal configurado pode gastar centenas de dólares em uma única execução perdida.
Solução: Budget cap por execução + alerta em percentual do limite
🛑 Contexto Saturado
Após muitas iterações, o contexto fica cheio de histórico. O modelo começa a perder track do objetivo original e gera respostas inconsistentes.
Solução: Sliding window + summarização automática do histórico
🛡️ Os 3 guardrails obrigatórios
max_iterations = 20
Nunca deixe um loop aberto. Defina um máximo realista para sua task e adicione um fallback explicativo quando atingido.
budget_cap = $5.00
Defina um teto de custo por execução. Monitore tokens gastos em tempo real e interrompa com relatório quando próximo do limite.
circuit_breaker para erros repetidos
Se o mesmo erro ocorre 3 vezes seguidas, pare e escale para o humano. Não deixe o agente insistir em uma estratégia que claramente falhou.
✅ Resumo do Módulo 1.2
Próximo Módulo:
1.3 — Componentes do Agente: As 5 Peças Essenciais. Você vai ver cada componente que compõe um agente — LLM, memória curta, memória longa, tools e planejamento — e como eles se encaixam.