Capítulo 4 — Agentes de IA e Tool Calling

Quarto post do passeio capítulo a capítulo pelo LLM Primer V: Construindo Aplicações LLM Reais. O capítulo que trata o agente como um modelo de linguagem em loop contra ferramentas cujos schemas, camadas de memória e cabeamento multi-agente têm de ser engenheirados antes de o loop poder ser confiado a algo real.

Por que este capítulo existe

Um modelo sem estado que só aceita texto e devolve texto é uma calculadora. Trabalho de produção exige transformá-lo num ator que persegue metas em múltiplos passos — chama esta ferramenta, depois aquela, decide quais resultados resumir para o usuário e para quando a tarefa está feita. A ideia parece simples num diagrama e não é simples na realidade. Agentes vagueiam, entram em loop, chamam a ferramenta errada, inventam argumentos que a ferramenta não aceita, esquecem o que já buscaram, e agem fora da sua autoridade. O Capítulo 4 é sobre a engenharia que mantém o loop legível e limitado — os schemas, a disciplina de memória e a estrutura multi-agente que transformam uma demo plausível num ator de produção.

4.1 Arquiteturas de agente como composição, não seleção

O loop base é o ReAct: raciocine sobre a situação, aja chamando uma ferramenta, observe o resultado, e repita até a meta ser atingida ou o orçamento de passos se esgotar. Sistemas de produção então compõem três aumentos sobre a base em vez de escolher entre eles. Function calling nativo — o provedor restringe os argumentos de ferramenta contra um JSON Schema em tempo de decodificação — endurece o contrato de I/O de modo que o loop já não precisa se recuperar de chamadas malformadas. Planejamento explícito, no estilo Plan-and-Execute, front-loada um plano para tarefas de horizonte longo e só reexecuta o planejador quando o mundo muda. Orquestração de workflow codifica as transições conhecidas da tarefa como um grafo e deixa ao modelo apenas as decisões de dentro de fase, que é o formato para o qual a maior parte dos deployments corporativos converge porque separa o que é conhecível do que exige julgamento. Loops de reflexão, roteamento multi-modelo por uma frota escalonada por custo e sub-agentes especialistas ficam ao lado destes como aumentos adicionais.

4.2 Mecânica de tool calling — o schema é o contrato

Toda ferramenta tem um schema, e o schema é o contrato que o loop impõe ao modelo. Descrições em nível de propriedade são documentação para o modelo, não para o leitor humano; enums fecham o espaço de argumentos onde o domínio permite; chaves de idempotência deixam o loop retentar uma chamada sem dobrar o efeito; erros retriáveis estruturados permitem ao modelo se recuperar com limpeza em vez de chutar. Ferramentas devem ser mínimas — uma tarefa clara por ferramenta — porque uma ferramenta gorda com dez flags opcionais é uma ferramenta que o modelo vai errar. Uma ferramenta ask_user pertence ao catálogo explicitamente, para que o agente tenha um caminho legítimo de escalar ambiguidade em vez de inventar argumentos. Concorrência é segura só quando as ferramentas declaram independência; o loop trata as declaradas independentes como paralelizáveis e todo o resto como estritamente sequencial. Todo incidente real de produção rastreado até "o agente fez a coisa errada" resolve numa ferramenta cujo schema não dizia o que os argumentos dela significavam.

4.3 Três camadas de memória: curto prazo, longo prazo, semântica

Agentes precisam de memória porque uma tarefa raramente cabe num turno. Memória de curto prazo é uma janela deslizante sobre a conversa recente com mensagens fixadas que sobrevivem ao deslize — o prompt de sistema, a meta atual, o plano em curso — e sumarização periódica das rodadas que caem para fora da janela. Memória de longo prazo é um vector store de fatos curados escritos na confirmação, não em cada observação, e recuperados em múltiplos pontos do loop em vez de só no início. Memória semântica é um grafo de conhecimento de triplas para as consultas que precisam de composição estruturada em vez de similaridade — "quem se reporta a quem", "quais produtos pertencem a qual categoria", relações que o vector store achata. As três são armazenadas de forma diferente porque são usadas de forma diferente, e a disciplina é rotear escritas e leituras para a camada certa em vez de colapsar tudo num único índice de embeddings.

O que o Capítulo 4 prepara

Agentes e RAG ambos produzem traces estocásticos. O usuário reclama, o log mostra cem spans espalhados por três ferramentas e oito chamadas de modelo, e o time tem de decidir se a falha é uma regressão de recuperação, um drift de prompt, um problema de schema de ferramenta, ou o agente escolhendo corretamente contra um sistema downstream quebrado. Essa pergunta não pode ser respondida sem uma disciplina de transformar traces em sinais mensuráveis de pass/fail. O Capítulo 5 é essa disciplina — LLM-como-juiz, a Tríade RAG, testes de trajetória para agentes, e o loop contínuo em que traces de produção alimentam o conjunto de eval que segura o próximo release.

Próximo — Capítulo 5: Avaliando Aplicações LLM. A disciplina de avaliação que transforma traces estocásticos em sinais de pass/fail contra os quais o time pode fazer deploy.