Tipos de agentes de IA: reflexo, objetivos e aprendizagem

Tipos de agentes de IA

Os tipos de agentes de IA vêm de uma taxonomia: agentes de reflexo simples, de reflexo baseados em modelo, baseados em objetivos, baseados em utilidade e de aprendizagem. Cada nome descreve uma característica: quanto o agente memoriza e até onde planeia antes de agir. Outros dois termos, multiagente e hierárquico, descrevem como vários agentes são ligados entre si, e não como cada agente toma decisões individualmente.

Essa lista é mais antiga do que qualquer modelo que tenha utilizado. Ela vem do manual padrão de IA e sobreviveu à chegada dos modelos de linguagem de grande escala porque coloca a questão que continua a determinar o seu design: o que é que este sistema precisa de saber antes de agir? Se ainda está a determinar onde termina um agente e começa um assistente de chat, leia primeiro a diferença entre um agente de IA e o LLM que executa. Esta página começa a partir desse ponto.

Agentes reflexos simples: uma condição, uma ação

Um agente reflexo simples mapeia a entrada atual para uma ação e não mantém memória do que aconteceu antes. Se a temperatura estiver acima de 25, liga a ventoinha. Esse é todo o mecanismo.

É quase certo que já executou um. Um webhook que inicia um workflow do n8n, lê o envio de um formulário e escreve uma linha numa base de dados é um agente reflexo simples. Continua a sê-lo mesmo quando um modelo de linguagem fica no meio e escolhe uma categoria para essa linha. Se lhe perguntar o que fez há uma hora, não consegue responder, porque nada guardou essa resposta.

Este tipo funciona corretamente mais vezes do que se espera. É barato de executar e a sua falha é fácil de interpretar: a condição foi correspondida ou não foi. Quando o trabalho é realmente "quando X chegar, fazer Y", a memória acrescenta formas de falhar e não traz qualquer benefício. Um agente n8n acionado por webhook é esta categoria da taxonomia com uma interface de utilizador por cima.

Falha no momento em que a ação correta depende do histórico. Um bot de respostas sem estado da thread irá contradizer-se na terceira mensagem, porque as duas primeiras mensagens nunca fizeram parte da sua entrada.

Agentes reflexos baseados em modelos: manter o estado entre eventos

Um agente reflexo baseado em modelos mantém uma representação interna do ambiente e atualiza essa representação à medida que recebe novos dados. Aqui, a palavra "modelo" significa um modelo do mundo, não uma rede neural. O termo é anterior ao significado atual em cerca de quarenta anos e confunde quase toda a gente na primeira leitura.

Uma regra de automação doméstica que desliga as luzes após vinte minutos sem movimento é baseada em modelos. Tem de ser. "Não há movimento neste momento" e "não houve movimento desde as 21:40" são o mesmo dado de entrada para um agente reflexo simples. Apenas o estado armazenado permite distingui-los.

A versão com LLM é qualquer agente que tenha um armazenamento de memória associado: um resumo contínuo da conversa ou um simples ficheiro Markdown que o agente lê no início de cada execução. Um serviço de memória local para um agente implementa essa ideia. O mecanismo não muda. A representação que o agente tem do mundo sobrevive ao evento que a criou.

O estado tem um custo. Um facto desatualizado é pior do que não ter qualquer facto, porque o agente age com base nele com confiança total e sem qualquer aviso. Tudo o que armazenar precisa de uma forma de expirar ou de ser verificado novamente. Caso contrário, o agente continuará a raciocinar sobre um servidor que desativou em março.

Agentes baseados em objetivos: planeamento até um estado verificável

Um agente baseado em objetivos recebe um estado-alvo e procura uma sequência de ações que o alcance. Trabalha a partir do resultado pretendido, por isso o caminho não é definido antecipadamente.

Um agente de programação é o exemplo mais claro que pode executar por si próprio. “Fazer o teste que falha passar” não indica ficheiros nem passos. O agente lê o teste, cria um plano, altera algo, executa o teste, lê o erro e tenta novamente. O ciclo termina numa verificação que consegue executar de facto. É por isso que essa instrução funciona e “melhorar este código” não funciona. Um objetivo que o agente consegue avaliar é um objetivo que consegue alcançar. Um objetivo que não consegue avaliar transforma-se num ciclo infinito com custos associados. Executar um agente de programação no seu próprio VPS coloca esse ciclo num local onde pode continuar a executar sem ocupar o seu portátil.

O custo está nesta linha. Cada passo de planeamento é outra chamada ao modelo que inclui todo o histórico até esse momento. Por isso, uma tarefa de dez passos não custa dez vezes mais do que uma tarefa de um passo. Custa mais. O trabalho de engenharia relevante está na estrutura do ciclo e na condição que o termina. Esse é o tema de engenharia de ciclos.

Agentes baseados em utilidade: escolher entre várias respostas boas

Um objetivo é binário. A utilidade é uma pontuação. Um agente baseado em utilidade encontra vários resultados aceitáveis e escolhe aquele que obtém a pontuação mais alta segundo uma função que você definiu.

Um job de backup que precisa de terminar antes do início do dia de trabalho sem saturar o uplink é um problema de utilidade. Não existe uma única resposta correta, apenas um compromisso. Um router que decide qual modelo trata cada pedido, ponderando o preço e a qualidade da resposta, tem a mesma estrutura.

O algoritmo não é a parte difícil. O difícil é escrever uma função de utilidade honesta. Se pontuar apenas o custo, obterá o modelo mais barato em todos os pedidos, incluindo o pedido que precisava do modelo mais caro. O sistema otimiza exatamente aquilo que você mediu. Isso é um problema quando o que mediu foi escolhido por ser fácil de medir.

Agentes de aprendizagem: o tipo que a maioria das pessoas presume já ter

Um agente de aprendizagem altera o seu próprio comportamento com base no feedback sobre resultados anteriores. Precisa de algo que avalie o resultado e de algo que altere a política em resposta.

Muito poucos sistemas self-hosted se qualificam. Um agente que lê notas que escreveu na semana passada é um agente baseado em modelo com um ficheiro de memória. Os pesos são idênticos. A política é idêntica. A recuperação de informação não é aprendizagem, e a distinção é prática: um sistema baseado em memória repete um erro indefinidamente, a menos que algo edite a memória, enquanto um sistema de aprendizagem deve deixar de o cometer.

Se quiser a componente de aprendizagem, comece por criar a avaliação. Um conjunto de testes pontuado, uma execução da sua alteração nesse conjunto e uma decisão de manter ou descartar a alteração formam um ciclo fechado em que você é o componente de aprendizagem. Isto é mais lento do que parece e é a única versão que funciona atualmente com componentes self-hosted. Alojamento próprio de um sistema de avaliação é aí que tudo começa.

Sistemas multiagente e hierárquicos: arranjos, não tipos

Estes não são um sexto e um sétimo tipo. Descrevem como os agentes estão organizados.

Um sistema multiagente executa vários agentes ao mesmo tempo num ambiente partilhado, como uma fila ou um repositório git. Como o ambiente é partilhado, os agentes entram em conflito nele. Dois agentes a editar o mesmo ficheiro é a falha mais comum, e a correção é usar um bloqueio ou uma fila de trabalho. Nenhum prompt resolve este problema.

Um sistema hierárquico coloca um supervisor acima dos agentes de trabalho. O supervisor divide uma tarefa, distribui as partes e junta os resultados recebidos. É popular porque corresponde à forma como as pessoas dividem o trabalho, e é dispendioso porque o contexto do supervisor cresce com cada relatório que lê. Um harness multiagente mostra como fazer esta integração na prática.

Um agente que funciona é melhor do que quatro que funcionam apenas na maioria das vezes.

Cada transferência de trabalho é um ponto onde podem perder-se informações. Comece com um único ciclo. Divida-o apenas quando conseguir identificar a etapa que é o gargalo.

Por que quase todo sistema real é híbrido

Considere um agente de implantação que você pode executar por conta própria. Um webhook o inicia, o que é reflexo. Ele lê o estado atual da release, o que é baseado em modelo. Ele planeja as etapas entre a versão em execução e a versão de destino, o que é baseado em objetivos. Ele escolhe uma janela de rollout com base na carga atual, o que é baseado em utilidade. Ele nunca edita a própria política, portanto não aprende.

Um sistema, quatro linhas da taxonomia ao mesmo tempo. A taxonomia é útil como lista de verificação de projeto, não como rótulo do produto concluído. Quando o sistema se comporta mal, a pergunta útil é qual camada está errada. Um gatilho que foi acionado pelo evento errado, um estado que ficou desatualizado, uma verificação de objetivo que nunca pode passar e uma pontuação que recompensa o resultado errado são quatro bugs diferentes, com quatro correções diferentes.

Qual tipo é adequado para cada tarefa

• Gatilho fixo, resposta fixa e sem necessidade de histórico: reflexo simples.
• A resposta correta depende do que aconteceu anteriormente: reflexo baseado em modelo.
• O estado final pode ser verificado, mas o caminho não é conhecido antecipadamente: baseado em objetivos.
• Existem vários resultados aceitáveis, com um compromisso real entre eles: baseado em utilidade.
• É necessário melhorar os resultados ao longo do tempo: crie um ciclo de avaliação e aceite que o componente de aprendizagem é você.

É possível alojar estes agentes por conta própria e quanto custa?

Sim, e o custo divide-se em duas partes. A orquestração é barata. Uma instância do n8n ou um ciclo de agente em Python passa a maior parte do tempo à espera de chamadas de rede, por isso 2 vCPU e 4 GB de RAM são suficientes. O modelo é onde está a maior parte do custo.

Se o agente chamar uma API alojada, o servidor precisa de poucos recursos e a fatura varia com o número de tokens. Num agente baseado em objetivos, isso significa que o custo varia com o número de passos de planeamento permitidos. Por isso, limite o ciclo.

Se executar o modelo no seu próprio hardware, a RAM determina o que consegue executar. Os valores abaixo são tamanhos de ficheiro publicados normalmente para pesos quantizados a 4 bits em agosto de 2026, acompanhados por uma estimativa de RAM total. A janela de contexto e o runtime também precisam de espaço além dos pesos.

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

Um modelo 8B a 4 bits tem cerca de 4.9 GB de pesos, e uma máquina com 10 GB de RAM executa-o sem usar swap. Um modelo 70B com a mesma quantização tem 43 GB de pesos e precisa de cerca de 64 GB. Repare no que estes valores não incluem: a velocidade. Numa VPS sem GPU, um modelo 8B a 4 bits gera poucos tokens por segundo. Isso é suficiente para um agente processar uma fila durante a noite, mas é demasiado lento para qualquer tarefa que dependa da espera de uma pessoa. Use a inferência local para trabalhos em lote e uma GPU ou uma API para as partes interativas. A seleção de agentes de IA que podem ser alojados localmente indica quais os projetos que justificam o espaço em disco, e um percurso de estudo para agentes em 2026 indica o que aprender e por que ordem.

Onde a taxonomia deixa de ser útil

Ela não diz nada sobre ferramentas ou permissões. Os agentes do manual percebem e atuam. Ninguém que escreveu esse capítulo estava preocupado com um agente que tivesse um token de API de produção. Um agente orientado por objetivos com acesso ao shell e um agente orientado por objetivos com uma única ligação de leitura a uma base de dados aparecem na mesma linha da tabela, mas têm riscos completamente diferentes. Decida a que o agente pode aceder antes de decidir quão sofisticado ele deve ser e leia como manter segredos fora de um agente de IA antes de lhe fornecer uma credencial.

Também não diz nada sobre o que acontece quando um passo falha. Os agentes reais passam a maior parte do tempo de execução a tratar erros: um limite de taxa ou uma ferramenta que devolveu algo que o modelo não esperava. Esse código determina se o seu sistema é utilizável, e nenhuma linha da taxonomia o descreve.

FAQ

Quais são os cinco tipos de agentes de IA?

Agentes de reflexo simples, de reflexo baseado em modelo, baseados em objetivos, baseados em utilidade e agentes de aprendizagem. Estão ordenados pela quantidade de informação que o agente tem antes de agir. Um agente de reflexo simples vê apenas a entrada atual. Um agente baseado em modelo mantém o estado do seu ambiente. Um agente baseado em objetivos planeia em direção a um estado-alvo. Um agente baseado em utilidade atribui pontuações a vários resultados aceitáveis e escolhe o mais elevado. Um agente de aprendizagem altera a sua própria política com base no feedback, algo que quase nenhuma instalação self-hosted faz na prática.

Que tipo de agente de IA devo usar para uma automação simples?

Um agente de reflexo simples, que na prática significa um webhook ou uma tarefa agendada que desencadeia uma sequência fixa. Se a resposta correta depender apenas da entrada que acabou de chegar, a memória acrescenta modos de falha sem acrescentar capacidade. Passe para um desenho baseado em modelo quando conseguir indicar uma decisão que tenha de saber o que aconteceu anteriormente.

Posso executar os meus próprios agentes de IA num VPS?

Sim. A camada de orquestração é leve, por isso 2 vCPU e 4 GB de RAM executam confortavelmente um motor de workflows ou um loop de agente. A decisão principal é onde o modelo será executado. Uma API alojada mantém o servidor pequeno e transfere o custo para os tokens. Um modelo local precisa de RAM proporcional à quantidade de parâmetros e, sem uma GPU, gera apenas alguns tokens por segundo. Isto é adequado para tarefas batch em fila, não para uma janela de chat.

Um modelo de linguagem de grande dimensão é, por si só, um agente de IA?

Não. Um modelo transforma texto de entrada em texto de saída e depois para. Torna-se um agente quando algo o envolve num loop que pode agir sobre o mundo e enviar o resultado de volta ao modelo. Para isso, precisa de ferramentas que possa chamar e de uma condição que indique ao loop quando deve parar. O wrapper é o agente. O modelo é um dos componentes no seu interior.

Preciso de um sistema multiagente?

Normalmente, não. Um único loop com várias ferramentas trata da maioria das tarefas e é muito mais fácil de depurar. Vários agentes são úteis quando partes de uma tarefa são realmente independentes e podem ser executadas em simultâneo, ou quando uma parte precisa de um modelo diferente. O custo é a coordenação: estado partilhado e um supervisor cujo contexto cresce com cada relatório de worker que lê. Adicione o segundo agente quando conseguir apontar para o passo que está lento.