Agentes: ferramentas e planejamento

Muita gente considera os agentes o objetivo final da IA. Isso não é de hoje: o livro clássico de Stuart Russell e Peter Norvig, Artificial Intelligence: A Modern Approach (1995), já definia a pesquisa em inteligência artificial como "o estudo e o design de agentes racionais".

O que mudou foi a capacidade dos modelos de fundação. Agora dá para construir agentes que criam um site, coletam dados, planejam uma viagem, fazem pesquisa de mercado, cuidam da conta de um cliente ou ajudam você a se preparar para uma entrevista. A lista é enorme, e o valor econômico disso também.

Neste artigo eu vou falar sobre o que é um agente, quais ferramentas ele pode usar e como ele planeja o que vai fazer.

O que é um agente

O termo agente aparece em vários contextos: agente de software, agente de usuário, agente de conversação, agente de aprendizado por reforço. A definição que mais me ajuda é simples:

Um agente é qualquer coisa que consegue perceber o ambiente em que está e agir sobre ele.

Ou seja, um agente é definido por duas coisas: o ambiente onde ele opera e o conjunto de ações que ele consegue executar.

Ambiente

O ambiente vem do caso de uso:

• Um agente que joga Minecraft ou Go tem o jogo como ambiente.
• Um agente que extrai documentos da internet tem a internet como ambiente.
• Um robô de cozinha tem a cozinha.
• Um carro autônomo tem as ruas e tudo que está ao redor delas.

Conjunto de ações

As ações que um agente consegue executar dependem das ferramentas que ele tem. Muitos produtos de IA que você usa no dia a dia já são agentes, mesmo que simples. O ChatGPT, por exemplo, pesquisa na web, executa código Python e gera imagens. Um sistema RAG também é um agente: o recuperador de texto, o recuperador de imagens e o executor de SQL são as ferramentas dele.

Ambiente e ferramentas andam juntos. O ambiente define quais ferramentas fazem sentido (num jogo de xadrez, as únicas ações possíveis são movimentos válidos de xadrez). E as ferramentas limitam onde o agente pode atuar (um robô que só sabe nadar fica preso na água).

Um bom exemplo é o SWE-agent, um agente construído sobre o GPT-4. O ambiente dele é o computador, com terminal e sistema de arquivos. As ações são navegar no repositório, buscar arquivos, abrir arquivos e editar linhas.

Por que agentes exigem modelos mais fortes

Dentro de um agente, a IA é o cérebro. Ela recebe a tarefa e o feedback do ambiente, planeja uma sequência de ações e decide se a tarefa foi concluída. Isso costuma exigir modelos mais capazes do que um uso simples de chat, por dois motivos:

• Erros se acumulam. Um agente executa várias etapas, e a precisão total cai a cada uma delas. Com 95% de acerto por etapa, depois de 10 etapas você fica com uns 60%. Depois de 100 etapas, sobra 0,6%.
• O risco é maior. Com ferramentas, o agente consegue fazer coisas com mais impacto. Quando ele erra, o estrago também é maior.

No fim, o sucesso de um agente depende de duas coisas: as ferramentas que ele tem e a qualidade do planejamento.

Ferramentas

Um sistema não precisa de ferramentas externas para ser um agente, mas sem elas ele faz muito pouco. Um LLM sozinho gera texto. Um gerador de imagens sozinho gera imagens. As ferramentas são o que multiplicam o que o agente consegue fazer.

Só que tem um porém: quanto mais ferramentas, mais difícil fica para o modelo entender e usar todas bem. Achar o conjunto certo exige experimentação.

Eu gosto de separar as ferramentas em três categorias.

Aumento de conhecimento

São as ferramentas que ajudam a montar o contexto: recuperador de texto, recuperador de imagem, executor de SQL. Também entram aqui coisas como busca interna de pessoas, uma API de estoque que retorna o status dos produtos, busca no Slack ou um leitor de e-mail.

Muitas delas dão ao modelo acesso aos processos e dados privados da sua empresa. Mas também podem dar acesso a informação pública, principalmente da internet.

A navegação na web foi um dos primeiros recursos colocados nos chatbots, e por um bom motivo: ela evita que o modelo fique desatualizado. Se os dados de treinamento pararam na semana passada, o modelo não sabe nada desta semana. Sem acesso à web, ele não consegue falar de clima, notícias, preço de ações ou status de voo.

O lado ruim é que a web também abre a porta para todo tipo de conteúdo ruim. Escolha com cuidado as APIs que o seu agente vai consultar.

Extensão de capacidades

São ferramentas que cobrem limitações conhecidas dos modelos. É um ganho fácil de desempenho.

Modelos são conhecidos por errar contas. Se você perguntar quanto é 199.999 dividido por 292, é bem provável que ele erre. Com uma calculadora como ferramenta, a conta vira trivial.

Uma ferramenta mais poderosa é o interpretador de código. Em vez de esperar que o modelo "entenda" o código de cabeça, você deixa ele executar o trecho, ver o resultado e analisar os erros. Com isso o agente pode atuar como assistente de programação, analista de dados ou até assistente de pesquisa que escreve código para rodar experimentos.

Na mesma linha, um modelo que só entende texto pode usar uma ferramenta de legenda de imagens para "ver" imagens, uma de transcrição para processar áudio e uma de OCR para ler PDFs.

Ações no ambiente

Até aqui só falei de ações de leitura. Mas as ferramentas também podem escrever, ou seja, alterar dados:

• Um executor SQL pode ler uma tabela, mas também pode alterar ou apagar essa tabela.
• Uma API de e-mail pode ler e também responder.
• Uma API de banco pode consultar o saldo e também fazer uma transferência.

Com ações de escrita, dá para automatizar um fluxo inteiro, como o contato com clientes: pesquisar leads, achar os contatos, escrever e enviar o primeiro e-mail, ler as respostas, fazer o follow-up e registrar os pedidos no banco.

Ao mesmo tempo, isso assusta. Você não daria a um estagiário permissão para apagar o banco de produção, então também não deveria deixar uma IA em que você não confia fazer transferências bancárias. Confiança no sistema e boas camadas de segurança são obrigatórias, inclusive contra pessoas mal-intencionadas tentando manipular o agente para fazer algo prejudicial.

Valide as chamadas externas antes do agente

Uma premissa que eu adoto: qualquer chamada externa, seja uma API, um scraping de site ou outra fonte, deve ser feita de forma independente para validar se o conteúdo está disponível antes de passar para o agente.

Assim o agente não perde tempo (nem tokens) tentando trabalhar com uma fonte que está fora do ar ou retornando lixo.

Planejamento

No centro de um agente está o modelo responsável por resolver a tarefa. Uma tarefa tem um objetivo e restrições. Por exemplo: planejar uma viagem de duas semanas de São Francisco para a Índia com orçamento de US$ 5.000. A viagem é o objetivo, o orçamento é a restrição.

Tarefas complexas precisam de um plano, que é o roteiro com as etapas necessárias para chegar ao objetivo. Planejar bem exige entender a tarefa, considerar caminhos diferentes e escolher o mais promissor. Quem já participou de uma reunião de planejamento sabe que isso não é fácil.

Separe o planejamento da execução

Dá para planejar e executar no mesmo prompt: você pede para o modelo pensar passo a passo e já executar as etapas. O problema é quando o modelo inventa um plano de 1.000 etapas que nem chega no objetivo. Sem supervisão, o agente pode passar horas executando isso, gastando tempo e dinheiro em chamadas de API, até alguém perceber.

Por isso o ideal é desacoplar o planejamento da execução. Primeiro o agente gera um plano. Só depois que esse plano for validado ele é executado.

A validação pode ser feita com heurísticas simples:

• Descartar planos com ações inválidas. Se o plano pede uma busca no Google e o agente não tem acesso ao Google, o plano é inválido.
• Descartar planos com mais de X etapas.

Também dá para usar um juiz de IA, pedindo para outro modelo avaliar se o plano faz sentido ou como melhorá-lo.

Se o plano for ruim, o planejador gera outro. Se for bom, ele é executado, e as ferramentas externas são chamadas via chamada de função. O resultado da execução também precisa ser avaliado. E o plano não precisa cobrir a tarefa inteira: pode ser um plano pequeno para uma subtarefa.

Repare que agora o sistema tem três componentes: um que gera planos, um que valida e um que executa. Se você pensar em cada um como um agente, já tem um sistema multiagente.

Para ganhar velocidade, você pode gerar vários planos em paralelo e pedir para o avaliador escolher o melhor. É a troca de sempre entre latência e custo: mais planos ao mesmo tempo significam mais chamadas pagas.

Entender a intenção

Para planejar, o agente precisa entender o que o usuário quer de verdade. É aqui que entra o classificador de intenção.

A classificação da intenção pode ser feita com outro prompt ou com um modelo de classificação treinado para isso. Esse classificador pode ser visto como mais um agente dentro do sistema multiagente.

Saber a intenção ajuda a escolher as ferramentas certas. Num suporte ao cliente, se a pergunta é sobre cobrança, o agente precisa de uma ferramenta que busca os pagamentos recentes do usuário. Se a pergunta é sobre como redefinir a senha, ele precisa da documentação.

Algumas perguntas simplesmente estão fora do escopo do agente. O classificador de intenção deve conseguir marcar essas requisições como IRRELEVANTES, para que o agente recuse com educação em vez de gastar FLOPs tentando resolver algo impossível.

Humanos no processo

Até agora parece que o agente faz tudo sozinho: gera, valida e executa o plano. Na prática, pessoas podem entrar em qualquer uma dessas etapas para reduzir riscos:

• Um especialista pode escrever um plano de alto nível que o agente expande.
• Uma pessoa pode validar o plano antes da execução.
• Operações arriscadas, como atualizar um banco de dados ou fazer merge de um código, podem exigir aprovação explícita ou ser executadas por uma pessoa.

Para isso funcionar, você precisa definir com clareza o nível de autonomia que o agente tem em cada ação.

O ciclo completo

Resumindo, resolver uma tarefa costuma passar por estas etapas:

1. Geração do plano: quebrar a tarefa em uma sequência de ações gerenciáveis. Por isso essa etapa também é chamada de decomposição de tarefas.
2. Reflexão sobre o plano: avaliar o plano gerado e, se for ruim, gerar outro.
3. Execução: executar as ações, geralmente chamando funções específicas.
4. Reflexão sobre o resultado: avaliar o que voltou, ver se o objetivo foi atingido, corrigir erros e, se precisar, gerar um novo plano.

A reflexão não é obrigatória, mas melhora muito o desempenho do agente.

Se parte da execução depende de APIs ou serviços externos, crie um ciclo que verifica a saúde desses serviços antes de o agente executar a tarefa. Isso evita chamadas desnecessárias.

Modelos de fundação conseguem planejar?

Essa é uma discussão aberta. Yann LeCun, cientista-chefe de IA da Meta, afirmou que LLMs autorregressivos não conseguem planejar. Subbarao Kambhampati vai na mesma linha: para ele, LLMs são ótimos em extrair conhecimento sobre planejamento, mas isso é diferente de gerar planos executáveis. Os planos podem parecer razoáveis para quem lê e mesmo assim quebrar na execução.

Planejar é buscar

No fundo, planejar é um problema de busca. Você olha caminhos diferentes até o objetivo, prevê o resultado de cada um e escolhe o mais promissor. Às vezes descobre que nenhum caminho chega lá.

Busca normalmente exige voltar atrás. Imagine que você tem duas ações possíveis, A e B. Executa A, cai num estado ruim e precisa voltar para tentar B.

Um argumento comum é que um modelo autorregressivo só gera ações para frente e não consegue voltar, então não poderia planejar. Mas isso não é bem verdade. Se depois de seguir o caminho A o modelo percebe que não faz sentido, ele pode revisar o plano e seguir por B. Na prática, isso é voltar atrás.

Saber o resultado de cada ação

Outra possibilidade é que os LLMs planejem mal porque não recebem as ferramentas certas para isso. Planejar exige saber não só quais ações existem, mas o que acontece depois de cada uma.

Pense em subir uma montanha. Você pode virar à direita, à esquerda, dar a volta ou seguir em frente. Se virar à direita te joga de um penhasco, você nem quer considerar essa opção. Tecnicamente, cada ação leva você de um estado para outro, e você precisa conhecer o estado resultante para decidir.

Por isso não basta pedir para o modelo gerar uma sequência de ações, como faz a técnica de cadeia de pensamento. O artigo "Reasoning with Language Model is Planning with World Model" defende que um LLM, por conter tanta informação sobre o mundo, consegue prever o resultado de cada ação e usar essa previsão para montar planos coerentes.

E mesmo que a IA não planeje bem sozinha, ela pode fazer parte de um planejador maior, com uma ferramenta de busca e um sistema que acompanha o estado.

Gerando um plano com prompt

O jeito mais simples de transformar um modelo em gerador de planos é com engenharia de prompt.

Imagine um agente que ajuda clientes a conhecer os produtos de uma loja chamada Kitty Vogue. Ele tem acesso a algumas ferramentas: buscar a data de hoje, buscar os produtos mais vendidos, buscar informações de um produto, gerar uma consulta e gerar a resposta final. O prompt de sistema pode ser algo assim:

SYSTEM PROMPT
Propose a plan to solve the task. You have access to 5 actions:
get_today_date()
fetch_top_products(start_date, end_date, num_products)
fetch_product_info(product_name)
generate_query(task_history, tool_output)
generate_response(query)

The plan must be a sequence of valid actions.

Examples
Task: "Tell me about Fruity Fedora"
Plan: [fetch_product_info, generate_query, generate_response]

Task: "What was the best selling product last week?"
Plan: [fetch_top_products, generate_query, generate_response]

Task: {USER INPUT}
Plan:

Dois detalhes desse exemplo:

• O formato do plano, uma lista de funções em que o agente infere os parâmetros, é só uma das várias formas de estruturar o fluxo do agente.
• A função generate_query usa o histórico da tarefa e a última saída de ferramenta para montar a consulta que vai para o gerador de respostas. A saída de cada ferramenta é adicionada ao histórico.

Quando faltam informações

Muitas vezes não dá para saber o valor exato dos parâmetros. Se o usuário pergunta "Qual é o preço médio dos produtos mais vendidos?", ficam dúvidas:

• Quantos produtos ele quer considerar?
• Mais vendidos da última semana, do último mês ou de sempre?

O modelo vai ter que chutar, e o chute pode estar errado.

Como tanto a sequência de ações quanto os parâmetros são gerados pelo modelo, os dois podem ser alucinados. O modelo pode chamar uma função que não existe ou chamar uma função válida com parâmetros errados.

Como melhorar o planejamento

As mesmas técnicas que melhoram um modelo em geral ajudam aqui:

• Escrever um prompt de sistema melhor, com mais exemplos.
• Descrever melhor as ferramentas e os parâmetros delas.
• Simplificar as funções, por exemplo quebrando uma função complexa em duas mais simples.
• Usar um modelo mais forte, que costuma planejar melhor.
• Fazer ajuste fino de um modelo para gerar planos.

No próximo artigo eu continuo nos agentes: como funciona a chamada de função na prática, os tipos de plano, a reflexão, as falhas mais comuns e a memória.

Referência

Este artigo faz parte dos meus estudos sobre engenharia de IA, baseados no livro AI Engineering: Building Applications with Foundation Models, de Chip Huyen (O'Reilly, 2025). As imagens usadas aqui também vêm do livro.