Agentes de IA: planejamento, ferramentas e memória

Quando você pede a um chatbot para "comparar o preço deste produto nas três maiores lojas online", ele ou dá informações antigas que lembra dos dados de treinamento, ou diz que não consegue fazer isso. Dê o mesmo pedido a um agente de IA e ele divide o trabalho em etapas: procura as lojas, abre cada página de produto, extrai o preço, tenta outro caminho onde não encontra e, no fim, monta uma tabela. Pode haver o mesmo tipo de modelo de linguagem por trás dos dois sistemas; a diferença vem do loop, das ferramentas e da memória construídos em volta do modelo.

Neste artigo, explicamos o que é um agente de IA e como ele se diferencia de um chatbot, o loop perceber-planejar-agir-avaliar que um agente repete a cada etapa e como funcionam o planejamento, o uso de ferramentas (function calling) e a memória. Depois, vemos como os agentes chegam à web, por que erram e como decidir se um trabalho precisa de um agente ou de um fluxo de trabalho predefinido.

O que é um agente de IA e como ele difere de um chatbot?#

Um chatbot produz uma resposta por mensagem. Ele pode lembrar o histórico da conversa, mas não inicia uma ação por conta própria nem confere o resultado de um trabalho para dar um novo passo. Você pergunta, ele responde.

Um agente de IA trabalha em direção a um objetivo e decide sozinho quais etapas seguir para chegar lá. O artigo Building effective agents da Anthropic traça a linha assim: sistemas que conectam um modelo de linguagem e ferramentas por caminhos de código definidos de antemão são fluxos de trabalho (workflows); sistemas em que o modelo conduz dinamicamente o próprio processo e o uso de ferramentas são agentes.

Como funciona o loop do agente?#

O modelo mais fiel do funcionamento de um agente é a repetição de um único loop. O loop continua até o objetivo ser atingido ou uma condição de parada ser cumprida.

1. Perceber. O agente reúne a situação atual: o objetivo do usuário, o histórico da conversa, os resultados das etapas anteriores e as informações recuperadas da memória. Tudo isso entra na janela de contexto do modelo.
2. Planejar. Olhando esse contexto, o modelo escolhe a próxima ação. Às vezes é uma única etapa, como "devo buscar primeiro"; às vezes, um plano de várias etapas.
3. Agir. O modelo produz uma chamada de ferramenta: escreve em formato estruturado qual ferramenta quer executar e com quais parâmetros. O aplicativo executa a chamada de fato.
4. Avaliar. O resultado da ferramenta volta ao modelo. O modelo confere se o resultado o aproxima do objetivo: os dados esperados chegaram, houve erro, o plano deve mudar?
5. Repetir ou terminar. Se o objetivo foi atingido, o modelo produz a resposta final. Se não, o loop volta à etapa um. Condições de parada como número máximo de etapas, limite de orçamento ou aprovação do usuário evitam que o loop rode para sempre.

Uma das expressões mais citadas desse loop é o artigo ReAct, publicado em 2022. O artigo mostra que fazer o modelo alternar entre "reasoning" (texto de raciocínio) e "acting" (chamadas de ferramentas) dá resultados melhores do que abordagens que se apoiam só em raciocinar ou só em agir. A maioria dos frameworks de agentes de hoje usa alguma variante dessa ideia.

O esqueleto abaixo mostra o loop independentemente do provedor. A função call_model é substituída pela API do modelo que você usa:

MAX_STEPS = 10

def run_agent(goal, tools, call_model):
    messages = [{"role": "user", "content": goal}]
    for step in range(MAX_STEPS):
        reply = call_model(messages, tools)          # planejar
        messages.append(reply.as_message())
        if not reply.tool_calls:                      # nenhuma ferramenta pedida: trabalho concluído
            return reply.text
        for call in reply.tool_calls:                 # agir
            try:
                result = tools[call.name](**call.arguments)
            except Exception as exc:                  # devolver o erro ao modelo
                result = f"Erro de ferramenta: {exc}"
            messages.append({"role": "tool", "tool_call_id": call.id, "content": str(result)})
        # a avaliação acontece na próxima chamada de call_model
    return "Limite de etapas atingido, o trabalho não pôde ser concluído."

Dois detalhes críticos do loop aparecem no código: os erros das ferramentas não derrubam o programa, e sim voltam ao modelo para ele tentar outro caminho; e sempre há uma condição de parada como MAX_STEPS.

Como o planejamento é feito?#

Planejar é o agente dividir um objetivo grande em etapas executáveis. Abordagens comuns:

• Passo a passo (estilo ReAct): o modelo escolhe só a próxima ação a cada volta do loop. É flexível, porque o resultado de cada etapa influencia a seguinte. Em trabalhos longos, corre o risco de se perder.
• Planejar primeiro, executar depois: o modelo produz um plano completo no início e depois executa as etapas em ordem. É eficiente quando o trabalho é previsível; quando surge um resultado inesperado, o plano precisa ser refeito.
• Decomposição de tarefas: um agente principal divide o trabalho em subtarefas e entrega cada uma a um subagente ou a uma chamada separada ao modelo. É usado em trabalhos de pesquisa em paralelo.
• Autoavaliação (reflection): o modelo critica, em uma etapa separada, o resultado que produziu e o corrige se necessário. A qualidade sobe, mas cada avaliação significa custo e latência a mais.

Qual abordagem escolher depende da estrutura do trabalho. Para um trabalho cujas etapas se conhecem em boa parte de antemão, planejar no início funciona melhor; para uma pesquisa em que o resultado de cada etapa define a próxima, o passo a passo.

Como funciona o uso de ferramentas (function calling)?#

Um modelo de linguagem não consegue sozinho abrir uma página web, consultar um banco de dados ou gravar um arquivo. Para que consiga, o aplicativo entrega ao modelo definições de ferramentas. Quando o modelo quer usar uma ferramenta, em vez de texto simples ele produz uma chamada estruturada que segue o esquema dessa ferramenta. A documentação de function calling da OpenAI e a documentação equivalente de outros provedores descrevem esse fluxo com a mesma lógica.

Uma definição de ferramenta tem três partes: um nome, uma descrição que permite ao modelo entender para que a ferramenta serve e uma definição dos parâmetros em JSON Schema. Por exemplo, uma ferramenta que pega o preço de uma página de produto poderia ser definida assim:

{
  "name": "get_product_price",
  "description": "Abre a URL da página de produto informada e retorna o preço e a moeda exibidos na página. Use apenas com URLs de domínios permitidos.",
  "input_schema": {
    "type": "object",
    "properties": {
      "url": {
        "type": "string",
        "description": "O endereço completo da página de produto, começando com https://"
      },
      "country": {
        "type": "string",
        "enum": ["TR", "DE", "US"],
        "description": "De qual país o preço deve ser visto"
      }
    },
    "required": ["url"]
  }
}

O nome do campo do esquema de parâmetros varia conforme o provedor; algumas APIs usam input_schema, outras parameters. A lógica é a mesma.

O fluxo de uma chamada de ferramenta:

1. O aplicativo envia ao modelo o pedido do usuário e as definições de ferramentas.
2. Se o modelo decidir que precisa da ferramenta, devolve uma chamada com o nome get_product_price e argumentos como {"url": "https://...", "country": "TR"}.
3. O aplicativo recebe a chamada, valida os argumentos e executa a ferramenta no próprio código.
4. O resultado da ferramenta ({"price": "...", "currency": "TRY"} ou uma mensagem de erro) volta ao modelo.
5. O modelo usa o resultado para chamar outra ferramenta ou responder ao usuário.

O ponto mais importante aqui é a etapa três: quem executa a ferramenta é sempre o aplicativo. O modelo só pede a execução. Por isso autorização, validação e verificações de segurança são responsabilidade do código que executa a ferramenta, não do modelo. E por isso as descrições das ferramentas precisam ser claras: o modelo só usa bem uma ferramenta na medida em que a entende pela descrição.

Explicamos o MCP, o protocolo para compartilhar ferramentas entre aplicativos diferentes de forma padronizada, em O que é MCP (Model Context Protocol)?.

Memória: de curto e de longo prazo#

Modelos de linguagem não lembram nada sozinhos de uma chamada para a outra. A "memória" de um agente é simplesmente o que o aplicativo entrega ao modelo a cada chamada.

A memória de curto prazo é a janela de contexto: o objetivo do usuário, o histórico da conversa, as chamadas de ferramentas e seus resultados. Conforme o loop se alonga, essa janela enche. Quando o limite da janela de contexto se aproxima, o aplicativo geralmente escolhe um destes caminhos:

• Resumir as etapas antigas e descartar os detalhes.
• Encurtar saídas grandes das ferramentas (como uma página HTML inteira) ou manter só a parte necessária.
• Manter só o resultado das subtarefas concluídas.

A memória de longo prazo fica fora da janela de contexto, em um banco de dados, um arquivo ou um armazenamento vetorial. O agente recupera informações desse armazenamento com uma ferramenta quando precisa. Preferências do usuário, informações aprendidas em tarefas anteriores e grandes coleções de documentos são guardadas assim.

Como um agente chega à web?#

A maioria dos agentes que precisam de informação atual chega à web de uma destas três formas:

• API de busca. O agente envia uma consulta e recebe uma lista de títulos, endereços e trechos curtos. É rápido e barato, mas só vê trechos.
• Cliente HTTP. O agente busca um endereço específico e recebe o HTML ou o texto da página. Funciona bem em páginas estáticas e volta vazio em páginas cujo conteúdo carrega com JavaScript.
• Navegador. O agente controla um navegador de verdade: abre páginas, clica, preenche formulários, tira capturas de tela. É o caminho mais capaz, mas também o mais lento e caro.

Por trás dessas ferramentas há, do lado da rede, requisições HTTP comuns, e todas as regras do web scraping valem aqui também: limites de taxa, robots.txt, termos do site, gerenciamento de sessão. Como um agente pode abrir dezenas de páginas em segundos, essas regras importam ainda mais para os agentes.

Nessa configuração, um proxy fica na camada de rede e é usado para três coisas:

• Localização: fazer o agente ver separadamente o preço de um produto em Türkiye e na Alemanha.
• Controle de saída: limitar e registrar a partir de um único ponto quais domínios o agente alcança e em que velocidade.
• Isolamento: manter o tráfego do agente separado dos endereços IP principais da empresa.

Como projetar essa camada, junto com medidas contra injeção de prompt, está em Acesso seguro à web para LLMs: limites e permissões. Como os sites lidam com tráfego de agentes e por que os agentes são bloqueados é tratado em Por que os sites bloqueiam agentes de compras com IA?. Para um exemplo de como um modelo de linguagem pode ser usado para extrair dados estruturados de páginas web, veja Web scraping com GPT-6 Astra.

Por que os agentes erram?#

As falhas dos sistemas de agentes são diferentes dos erros de uma única chamada ao modelo, porque os erros se acumulam ao longo das etapas.

• Acúmulo de erros. Mesmo que cada etapa tenha uma pequena chance de erro, essas chances se multiplicam em um trabalho de dez etapas. Abrir a página errada no começo faz todas as etapas seguintes se basearem em dados errados.
• Argumentos de ferramenta errados. O modelo pode produzir um parâmetro que não existe, um endereço malformado ou um identificador inventado. Sem validação do lado da ferramenta, o erro segue em frente em silêncio.
• Ficar preso em loops. Chamar repetidamente a mesma ferramenta que falha com os mesmos argumentos. Sem limite de etapas e detecção de repetição, o custo cresce sem controle.
• Contexto cheio. Saídas grandes das ferramentas enchem a janela de contexto e o modelo começa a deixar passar as instruções do início da tarefa.
• Objetivo ambíguo. Um objetivo com critérios indefinidos, como "encontre o produto mais adequado", deixa o agente sem saber quando parar.
• Conteúdo não confiável. Páginas web, documentos e e-mails podem conter texto que parece instrução para o modelo. Se o agente confunde esse texto com o pedido do usuário, pode executar ações inesperadas. Esse risco se chama injeção indireta de prompt.
• Mensagens de erro perdidas. Se o erro de uma ferramenta não volta com clareza ao modelo, o modelo pode supor que o trabalho terminou com sucesso.

A maioria dessas falhas vem do design do sistema, não do modelo, e diminui com design: validar os argumentos das ferramentas, definir limites de etapas e de orçamento, encurtar as saídas das ferramentas, pedir aprovação humana antes de ações críticas e tratar o conteúdo da web como dado, não como instrução.

Fluxo de trabalho ou agente?#

Os agentes impressionam, mas não são a ferramenta certa para todo trabalho. A recomendação do artigo da Anthropic é começar pela estrutura mais simples que resolve o trabalho e só adicionar complexidade quando ela trouxer um benefício mensurável. Na prática, isso significa:

• Para um trabalho cujas etapas se conhecem de antemão e são feitas sempre na mesma ordem (buscar todo dia os preços das mesmas 50 páginas e gravá-los em uma tabela), um fluxo de trabalho definido no código é mais barato, mais rápido e mais previsível. Um modelo de linguagem pode ser usado dentro desse fluxo só em uma etapa específica, por exemplo para extrair dados de um texto irregular.
• Para um trabalho cujas etapas mudam conforme a situação e em que não se sabe de antemão quais fontes consultar (reunir informações sobre um mercado novo a partir de fontes dispersas), um agente faz sentido.

A diferença de custo e confiabilidade entre um pipeline clássico de scraping e uma abordagem baseada em agentes também deve ser avaliada nesse enquadramento. A extração com seletores dá o mesmo resultado em toda página; um agente consegue se adaptar quando a estrutura da página muda, mas carrega o custo de uma chamada ao modelo por página.

Casos de uso#

• Pesquisa de mercado e de concorrência: o agente reúne informações de produtos, preços e campanhas de fontes diferentes e aponta as inconsistências. A configuração de pesquisa está na nossa página de solução de pesquisa de mercado.
• Tratamento de exceções em um pipeline de coleta de dados: um pipeline clássico de scraping cuida da maioria das páginas; as páginas em que os seletores falham são entregues a um agente. A configuração geral de coleta de dados está na nossa página de solução de extração de dados.
• Assistente de conhecimento interno: o agente pesquisa os documentos internos, recupera os trechos relevantes e responde citando as fontes.
• Desenvolvimento de software: o agente pesquisa o código, lê arquivos, propõe mudanças e roda testes.
• Triagem no atendimento ao cliente: o agente classifica a solicitação, consulta o status do pedido e só passa para uma pessoa quando necessário.

Erros comuns#

• Construir um agente para um trabalho que um fluxo simples resolveria. Custo, latência e imprevisibilidade sobem sem motivo.
• Não definir condição de parada. Um agente sem limite de etapas, limite de orçamento ou timeout pode gerar custo sem controle.
• Escrever descrições de ferramentas curtas e vagas. O modelo chama a ferramenta na situação errada ou com argumentos errados.
• Não validar os argumentos das ferramentas. Todo valor produzido pelo modelo deve ser tratado como entrada não confiável.
• Tratar o conteúdo da web como instrução. O texto de uma página não deve ter a mesma autoridade que o pedido do usuário.
• Deixar ações críticas sem aprovação. Ações irreversíveis como pagamentos, envio de e-mails ou exclusão de dados devem exigir aprovação humana.
• Suspender as regras do site para o agente. Toda página aberta por um agente está sujeita aos mesmos limites de taxa e termos que uma página aberta por um scraper. Para o enquadramento legal, veja Web scraping é legal?.

Guia de decisão#

Perguntas frequentes#

Qual é a diferença essencial entre um agente de IA e um chatbot?#

Um chatbot produz uma resposta por mensagem e não inicia ações por conta própria. Um agente de IA planeja várias etapas para atingir um objetivo, chama ferramentas, avalia os resultados e mantém o loop funcionando até o objetivo ser atingido.

O agente executa as ferramentas sozinho?#

Não. O modelo só escreve, em formato estruturado, qual ferramenta quer executar e com quais argumentos. Quem executa a ferramenta, devolve o resultado ao modelo e faz as verificações de segurança é sempre o aplicativo que roda o agente.

Onde fica a memória de um agente?#

As informações da tarefa atual ficam na janela de contexto do modelo, ou seja, no histórico de mensagens enviado ao modelo a cada chamada. As informações que precisam persistir entre tarefas ficam em um banco de dados ou arquivo gerenciado pelo aplicativo e são recuperadas com uma ferramenta quando necessário.

Quais regras um agente deve seguir ao coletar dados de sites?#

As mesmas de um scraper: robots.txt, termos do site, limites de taxa e leis de proteção de dados pessoais. Ser um sistema de IA não muda essas regras; como ele pode trabalhar rápido, é ainda mais importante aplicar os limites no nível do sistema.

Por que os agentes podem dar resultados diferentes para o mesmo trabalho?#

Modelos de linguagem podem não produzir exatamente a mesma saída a cada chamada, e o caminho que o agente escolhe em cada etapa influencia a seguinte. Além disso, como fontes externas como a web mudam, a mesma consulta pode chegar a dados diferentes. Para trabalhos em que a repetibilidade importa, a abordagem de fluxo de trabalho é mais adequada.

Como saber se um trabalho é adequado para um agente?#

Se você consegue desenhar de antemão as etapas do trabalho como um fluxograma, provavelmente um fluxo de trabalho basta. Se as etapas só podem ser decididas conforme os resultados intermediários chegam, e o benefício dessa flexibilidade compensa o custo extra, um agente faz sentido.

Em resumo#

Um agente de IA é um sistema em que um modelo de linguagem percorre um loop perceber-planejar-agir-avaliar até atingir um objetivo. O planejamento divide o trabalho em etapas, o uso de ferramentas permite ao modelo agir no mundo externo e a memória é gerenciada pela janela de contexto e por armazenamentos externos. Quem executa as ferramentas é sempre o aplicativo, então permissões, validação, limites de taxa e aprovação humana fazem parte do design do sistema. Escolha um fluxo de trabalho para trabalhos com etapas conhecidas de antemão e um agente para trabalhos abertos. Para gerenciar o acesso à web dos seus agentes com controle de localização e de saída, conheça os nossos serviços de proxy.