Agente baseado em LLM: como um ciclo de modelo e ferramentas substituiu o chatbot

Três datas definem o agente de LLM moderno: 2022, ano em que saiu o artigo sobre a abordagem ReAct; junho de 2023, quando a OpenAI adicionou a chamada de funções à sua API; e novembro de 2024, quando a Anthropic apresentou o protocolo MCP para conectar ferramentas. O Habr publicou um material sobre como funciona um agente construído sobre uma LLM. O autor avisa logo de início que não vai discutir a arquitetura dos transformers e que olha o sistema pelo lado prático. O anúncio no RSS traz apenas a introdução, por isso o texto abaixo descreve o esquema geral em que a maioria dos agentes se apoia, sem recontar os detalhes do artigo em si.

Um ciclo em vez de uma única resposta

Um chat comum é simples: o usuário faz uma pergunta e o modelo responde. O agente funciona de outro jeito. O modelo recebe a tarefa e a lista de ferramentas disponíveis e então decide o que fazer: responder de imediato ou chamar uma função. O resultado da chamada volta para o contexto, e o modelo dá o passo seguinte. Isso se repete até que ele considere a tarefa concluída ou até que o código externo interrompa o ciclo.

O modelo, por si só, não executa nada. Ele gera uma requisição estruturada, por exemplo o nome da função e os argumentos em JSON. Quem executa é um programa comum, chamado de orquestrador ou runtime. É ali que ficam a lógica de novas tentativas, os timeouts e as restrições.

Do que é feito um agente

O conjunto de componentes é parecido na maioria das implementações, seja em código próprio, seja em um framework pronto:

• Modelo: recebe o contexto e devolve texto ou uma chamada de ferramenta.
• Ferramentas: funções com descrição em texto e esquema de argumentos. Busca, SQL, shell, navegador, APIs internas.
• Memória: o histórico de passos dentro da janela de contexto, mais um armazenamento externo, como um banco vetorial ou arquivos.
• Orquestrador: código comum que roda o ciclo, valida as chamadas e mantém os logs.
• Condição de parada: a resposta final do modelo, o limite de passos ou o orçamento de tokens.

Vale uma menção à parte ao MCP. O protocolo define uma forma única de descrever ferramentas e recursos, e o mesmo servidor pode ser conectado a clientes diferentes. Para o desenvolvedor, isso reduz o custo das integrações: a descrição da ferramenta é escrita uma só vez.

Onde os agentes quebram

Os problemas costumam surgir não no modelo em si, mas ao redor dele. O primeiro é o agente entrar em loop: ele chama a mesma ferramenta com os mesmos argumentos e espera um resultado diferente. O segundo é o crescimento do contexto a cada passo. As respostas das ferramentas, sobretudo os despejos longos de dados, empurram instruções importantes para fora, e o custo de cada passo seguinte aumenta. O terceiro é o acúmulo de erros. Se a probabilidade de acerto em cada passo é de 95%, cerca de 60% das execuções passam por dez passos seguidos sem erro. Por isso, cadeias longas sem verificações funcionam bem pior do que as curtas.

Há ainda um risco ligado às permissões. Um agente com acesso a shell ou a um banco de dados executa o que o modelo sugeriu, e o modelo pode ser induzido por uma entrada mal-intencionada ou por um texto de página web que tenha ido parar no contexto.

Como montar o seu

O ideal é começar por um ciclo mínimo, com um único modelo e duas ou três ferramentas. Um limite rígido de passos e um orçamento de tokens são necessários desde o primeiro dia, assim como um registro de cada chamada com argumentos e resposta: sem ele, depurar vira adivinhação. Ações perigosas, como gravação, exclusão e pagamentos, é melhor fazer passar pela confirmação de uma pessoa. Os resultados das ferramentas devem ser cortados e resumidos antes de entrar no contexto. Os frameworks ficam para depois, quando estiver claro quais partes do ciclo realmente precisam de mais complexidade. O autor publica no Habr a análise completa, com exemplos, e é de lá que vale tirar os detalhes concretos de implementação.