Definição numa frase
Sistema que utiliza un modelo para decidir pasos, mantener estado y operar herramientas bajo objetivos, permisos y reglas definidos.
O que é um agente de IA
Um agente de IA é um sistema que recebe informações de um ambiente, seleciona ações em função de um objetivo e observa o que acontece depois para decidir se continua, muda de rumo ou para. A palavra importante é «sistema»: o agente não é necessariamente um modelo de inteligência artificial isolado. Pode incluir um modelo ou uma política de controlo, instruções, informações de contexto, ferramentas, um ambiente e regras que limitam as ações possíveis.
Esta definição descreve um ciclo de perceção, decisão e ação. Não exige que o sistema tenha personalidade, consciência, memória permanente ou liberdade para fazer qualquer coisa. Também não exige que utilize um modelo de linguagem de grande dimensão (LLM). O enquadramento clássico dos agentes é mais amplo do que os atuais assistentes generativos; estes são uma família de implementações possíveis, não a definição completa.
Neste artigo, «agente» é usado num sentido funcional: o que importa é saber se o sistema consegue escolher entre ações possíveis com base no estado que observa e na tarefa que tem de cumprir. Um sistema pode ter autonomia muito limitada — por exemplo, selecionar uma ferramenta entre duas opções autorizadas — e ainda assim apresentar um comportamento agêntico. Por isso, a autonomia não é um simples interruptor ligado ou desligado.
Componentes possíveis e ciclo de funcionamento
Um agente pode combinar vários elementos. O objetivo define o que se pretende alcançar; o modelo ou a política de controlo ajuda a escolher o passo seguinte; as instruções e o contexto delimitam a tarefa; o estado reúne as informações necessárias para continuar; as ferramentas ou os atuadores permitem agir; e o ambiente é aquilo que o agente observa ou modifica. Também podem existir permissões, verificações, limites de utilização e condições de paragem. São componentes possíveis, não uma lista de requisitos que todos os agentes tenham de cumprir.
Numa implementação com um modelo generativo, o ciclo pode consistir em enviar ao modelo a tarefa e o estado disponível, analisar a resposta, executar uma ferramenta se o sistema o permitir e voltar a consultar o modelo com o resultado. O processo termina quando se obtém uma resposta final, se cumpre um critério de paragem, se atinge um limite ou se torna necessária a intervenção humana. A documentação de um SDK específico descreve um ciclo de execução deste tipo; outros projetos podem organizá-lo de forma diferente.
Também é importante ser preciso ao falar de memória. O sistema pode conservar informações durante uma tarefa ou receber um estado guardado entre tarefas, mas não se deve pressupor que todas as implementações o fazem. Do mesmo modo, pode utilizar uma única ferramenta, várias ou nenhuma. A disponibilidade de ferramentas não significa que o agente as possa invocar sem restrições: são as permissões e as regras de controlo que determinam quais as ações realmente possíveis.
Um ciclo agêntico, passo a passo
- 01Receber uma tarefa e determinar o objetivo e os limites aplicáveis.
- 02Observar o estado relevante do ambiente e o contexto disponível.
- 03Escolher entre responder, pedir informações, utilizar uma ferramenta permitida ou parar.
- 04Executar a ação autorizada e recolher o resultado.
- 05Atualizar o estado com a nova observação e decidir se deve continuar, encaminhar a tarefa ou terminá-la.
- 06Verificar a condição de paragem e, quando for caso disso, confirmar o resultado antes de o apresentar.
Quatro exemplos em áreas diferentes
Os exemplos seguintes são esquemas ilustrativos, não afirmações de que todos os produtos destes setores funcionem desta maneira. Em cada caso, o que torna o projeto agêntico é o ciclo entre observação, seleção de ações e revisão dos resultados. Uma tarefa delimitada pode ter permissões restritas e controlos humanos sem deixar de ser um sistema que escolhe os passos em função do que encontra.
blocks
Agente, chatbot, ferramenta e automação: diferenças práticas
Um chatbot costuma ser descrito pela sua interface de conversação: recebe mensagens e produz respostas. Pode limitar-se a responder, mas também pode incorporar ações e um ciclo de decisão. Por isso, «chatbot» e «agente» nem sempre são categorias mutuamente exclusivas: o primeiro termo pode designar a forma de interação, enquanto o segundo descreve como o sistema seleciona ações para avançar numa tarefa.
Uma chamada a ferramentas é uma capacidade ou uma etapa de execução, não uma garantia de autonomia alargada. Um modelo pode decidir que ferramenta chamar, quando o fazer e com que argumentos, como estuda o Toolformer; ainda assim, o sistema completo inclui o mecanismo que autoriza e executa essa chamada. Também pode haver agentes que não recorrem a ferramentas externas. Uma interface de ferramentas, como o MCP, é um conceito relacionado, mas a simples ligação a uma ferramenta não basta para determinar quanto decide o sistema.
Uma automação ou um fluxo de trabalho especifica etapas antecipadamente: se uma condição se verificar, executa-se uma ação definida. Se for introduzido um LLM numa dessas etapas, o fluxo passa a incluir IA, mas não adquire necessariamente a capacidade de selecionar ações de forma dinâmica. Num sentido amplo, alguém pode chamar «agêntico» a um fluxo que incorpora decisões. Neste artigo, reservamos «agente dinâmico» para um projeto que pode escolher o passo seguinte em função da tarefa e das observações, em vez de percorrer apenas uma sequência fechada.
Um assistente é uma categoria de produto ou função que pode abranger desde responder a perguntas até executar tarefas com ferramentas; por si só, não determina a arquitetura. Um sistema multiagente coordena mais do que um agente, mas o número de componentes não demonstra que a solução seja melhor. A memória de agente, a engenharia de contexto, a geração aumentada por recuperação (RAG) e o humano no circuito são conceitos relacionados que podem surgir em alguns projetos; nenhum é um requisito universal para classificar um sistema como agente.
Tabela de decisão: o que descreve melhor o sistema?
| O que observa | Descrição mais precisa | O que ainda precisa de verificar |
|---|---|---|
| Recebe mensagens e responde, sem serem descritas ações posteriores. | Chatbot ou interface de conversação. | Se pode selecionar e executar ações para além da resposta. |
| Executa sempre as mesmas etapas perante a mesma condição. | Automação ou fluxo predefinido. | Se existe escolha dinâmica do passo seguinte com base em novos resultados. |
| O modelo solicita uma ferramenta e o sistema executa-a. | Utilização de ferramentas; pode fazer parte de um agente. | Quem decide, que permissões existem e como o resultado é utilizado. |
| Observa resultados e escolhe entre ações permitidas para avançar numa tarefa. | Comportamento agêntico, com o grau de autonomia permitido pelos controlos. | Âmbito, verificações, intervenção humana e condições de paragem. |
Erros frequentes e limites
O primeiro erro é tratar o agente como se fosse apenas o LLM. Um modelo pode produzir uma proposta de ação, mas o sistema que a recebe decide se a executa, com que permissões e como devolve o resultado à etapa seguinte. Esta diferença é importante para analisar segurança e responsabilidade: uma resposta em texto e uma ação que altera um recurso não têm as mesmas consequências.
O segundo erro é inferir uma autonomia alargada a partir da utilização de ferramentas. O sistema pode ter apenas uma ferramenta disponível, exigir aprovação para cada ação ou funcionar num ambiente de teste. No sentido inverso, uma automação sem LLM pode selecionar ações em função das observações. É preferível descrever o comportamento e os controlos em vez de confiar num rótulo comercial.
Também não se deve confundir autonomia com fiabilidade. Um agente pode interpretar mal uma tarefa, planear de forma inadequada, receber observações incompletas ou utilizar incorretamente o resultado de uma ferramenta. Pode repetir ações num ciclo, parar demasiado cedo ou produzir uma síntese que não reflita as evidências recuperadas. Uma resposta fluida, uma demonstração ou uma execução bem-sucedida não provam, por si só, um desempenho consistente.
Quando um sistema processa instruções ou conteúdo externo, esse material pode tentar influenciar as suas decisões, por exemplo, através de prompt injection. O risco depende dos dados que o sistema lê, das ações que pode executar e da forma como as instruções de confiança são separadas do conteúdo observado. O princípio do menor privilégio, a revisão humana em etapas sensíveis e a possibilidade de reverter alterações são medidas de projeto que podem reduzir consequências, mas não tornam infalível uma tarefa aberta.
Por último, ter memória persistente, planeamento explícito ou vários agentes não é um requisito universal nem uma garantia de melhores resultados. São opções de projeto. A sua utilidade depende da tarefa, da forma como são implementadas e da respetiva avaliação. As fontes disponíveis para este artigo não permitem estabelecer uma comparação geral do desempenho de todas essas opções nem sustentar uma classificação universal dos agentes.
Como avaliar um agente antes de o utilizar
Comece por definir uma tarefa observável. «Ajudar nas operações» é demasiado abrangente; «classificar pedidos de uma categoria e preparar uma proposta de resposta sem a enviar» permite identificar entradas, resultado esperado e limites. Em seguida, descreva o ambiente, as informações a que o sistema acede e as ações que pode executar. Assim, é possível distinguir uma resposta gerada de uma intervenção efetiva.
Especifique as permissões e os controlos: que ações são apenas de leitura, quais alteram dados, quais exigem aprovação e quais são proibidas. Defina também o que deve acontecer perante dados em falta, resultados contraditórios, falhas de ferramentas ou incerteza. As condições de paragem devem ser explícitas; por exemplo, parar perante uma ação não autorizada ou encaminhar um pedido que não se enquadre nos critérios acordados.
Avalie a tarefa e a segurança separadamente. Uma medida pode indicar se o resultado cumpre o objetivo, mas não basta para saber se o sistema respeitou as permissões, evitou alterações indesejadas ou pediu ajuda quando devia. Verifique também os custos, o tempo, a repetição de ações, a facilidade de revisão dos resultados e a possibilidade de reverter uma operação. O método de avaliação deve incluir casos normais e casos-limite do ambiente real.
A intervenção humana não tem de ocorrer da mesma forma em todas as etapas. Pode ser necessária antes de uma ação irreversível, depois de uma proposta ou quando o sistema deteta ambiguidade. O importante é deixar claro quem aprova, que informações recebe e se o sistema pode agir antes dessa aprovação. Se a verificação do resultado depender do mesmo agente que o produziu, considere se é necessária uma verificação independente.
Lista prática de avaliação
- 01Descreva a tarefa, as entradas aceites e o resultado que conta como sucesso.
- 02Enumere o ambiente, as fontes de informação e todas as ações disponíveis.
- 03Separe as permissões de leitura, escrita e envio das ações que exigem aprovação.
- 04Defina condições de paragem, encaminhamento, reversão e resposta a falhas ou incerteza.
- 05Teste casos habituais, ambíguos e adversos; registe tanto os erros como as intervenções necessárias.
- 06Analise a qualidade, a segurança, os custos e a possibilidade de auditar os resultados antes de alargar o âmbito.
Conceitos relacionados e critérios finais
A chamada a ferramentas ajuda a compreender como um modelo pode solicitar uma ação externa; a memória de agente e a engenharia de contexto estão relacionadas com as informações que o sistema conserva ou recebe; a RAG procura incorporar informação recuperada numa resposta ou tarefa. O humano no circuito e o princípio do menor privilégio ajudam a pensar na supervisão e nos limites de acesso. São temas que convém associar às respetivas fichas do glossário, sem os pressupor como componentes obrigatórios de todos os agentes. Também é útil consultar a comparação entre agentes e outras formas de automação para analisar casos-limite.
Em síntese, chame agente a um sistema quando conseguir descrever um objetivo, observações do ambiente e uma seleção de ações que se ajusta aos resultados obtidos. Para o avaliar, não se fique pelo rótulo: pergunte o que decide, o que pode executar, o que precisa de aprovação, como verifica o resultado e quando para. Uma descrição concreta desses limites é mais informativa do que afirmar simplesmente que um produto é autónomo.
