Agentes e Agentic AI¶

O que é um agente de IA¶

Um LLM sozinho é como um estagiário brilhante preso atrás de uma mesa de vidro: entende tudo o que se diz, raciocina bem e formula respostas inteligentes — mas só pode pensar, nunca agir. O RAG deu a ele uma "memória externa" (ver LLM); ferramentas dão a ele o equivalente a um telefone, um computador e uma caneta para assinar documentos. O estagiário deixa de apenas responder perguntas e passa a resolver problemas.

Definição: Agente de IA

Sistema que usa um LLM como "cérebro" para raciocinar, tomar decisões e usar ferramentas para atingir objetivos no mundo real. Pode interagir com APIs, bancos de dados, sistemas de arquivos e praticamente qualquer coisa que possa ser controlada por código. O conceito de agente autônomo existe na pesquisa desde os anos 1990; o que mudou foi a combinação de LLMs poderosos com o padrão ReAct (ver Engenharia de Prompt) — popularizada, em março de 2023, pelo projeto AutoGPT, que demonstrou um LLM capaz de se dar tarefas, executá-las com ferramentas e iterar sozinho até completar objetivos complexos.

O ciclo de vida de um agente¶

Um agente opera como uma pessoa resolvendo um problema complexo ("descubra quanto gastamos com fornecedores no último trimestre e mande um resumo para o diretor financeiro"): primeiro percebe a tarefa, depois raciocina sobre ela, então age (abre o sistema, faz as consultas, escreve o e-mail) e lembra das informações relevantes ao longo do processo.

flowchart TD
    AMB["Ambiente"] --> PER["Percepção"]
    PER --> AG{"Agente"}
    MEM[("Memória")] <--> AG
    AG --> RAC["Raciocínio"] --> ACA["Ação"] --> AMB

Percepção — chega como a mensagem do usuário ou um evento do sistema.
Raciocínio — acontece dentro do LLM: processa a informação e decide o próximo passo.
Ação — a execução de uma ferramenta (chamar uma API, consultar um banco, enviar uma mensagem).
Memória — armazena o contexto da conversa e informações importantes para uso futuro.

A grande diferença entre um chatbot simples e um agente é que o agente não para no primeiro raciocínio: executa esse ciclo várias vezes, usando o resultado de cada ação para informar a próxima decisão, até completar a tarefa.

Function Calling — o mecanismo que dá mãos ao LLM¶

Definição: Function Calling (Tool Calling)

Mecanismo (lançado pela OpenAI em junho de 2023) que formaliza o uso de ferramentas por um LLM. Antes dele, fazer o modelo usar ferramentas exigia engenharia de prompt criativa — pedir para "responder em formato JSON" e torcer para ele não errar a sintaxe. Agora o modelo é treinado para decidir quando usar uma ferramenta e gerar chamadas estruturadas de forma confiável. O segredo: o LLM não executa nada — apenas descreve o que quer fazer; o código do desenvolvedor cuida da execução.

Funciona como um "cardápio": cada ferramenta tem um nome, uma descrição (o que faz) e parâmetros (que informações precisa para funcionar), descritos num schema (esquema JSON). Quando o usuário faz um pedido, o LLM lê o cardápio, decide qual ferramenta usar e preenche o "pedido" com os parâmetros corretos — ex.: para "Preciso de guarda-chuva hoje em São Paulo?", retorna {"function": "get_weather", "arguments": {"city": "São Paulo"}}. O código chama a API real, devolve o resultado ao LLM, que formula a resposta final.

flowchart TD
    S["Schema da ferramenta<br/>(name, description, parameters)"] --> L["LLM"]
    L --> N{"Precisa de<br/>ferramenta?"}
    N -->|Sim| F["Chamar função<br/>com argumentos"] --> API["API externa"] --> RES["Resultado"] --> L
    N -->|Não| R["Responder diretamente"]

from openai import OpenAI
cliente = OpenAI()

ferramentas = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Obtém a previsão do tempo para uma cidade",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string", "description": "Nome da cidade"}},
            "required": ["city"],
        },
    },
}]

resposta = cliente.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Preciso de guarda-chuva hoje em SP?"}],
    tools=ferramentas,
)
chamada = resposta.choices[0].message.tool_calls[0]
print(chamada.function.name, chamada.function.arguments)

Definição: Por que separar \"decidir\" de \"executar\" importa

O LLM nunca toca diretamente nos sistemas — apenas pede permissão para agir. Quem desenvolve mantém controle total sobre quais ferramentas existem, como funcionam e sob quais condições podem ser usadas. É a diferença entre dar a alguém a chave do cofre e dar a essa pessoa um formulário de requisição que precisa de aprovação.

A memória do agente¶

Para ser útil, o agente precisa lembrar de coisas — mas não existe um único tipo de memória. São três "gavetas", cada uma com um propósito:

flowchart TD
    M["Memória do agente"] --> C["Curta duração<br/>(janela de contexto)"]
    M --> L["Longa duração<br/>(vector store)"]
    M --> P["Procedural<br/>(habilidades/ferramentas)"]

Tipo	Analogia	O que guarda	Como é implementada
Curta duração	Lousa na sala de reunião	A conversa atual: o que o usuário perguntou, o que o agente respondeu, quais ferramentas foram usadas. Rápida, mas de espaço limitado (a janela de contexto) e apagada quando a conversa termina.	A lista de mensagens passada ao LLM a cada chamada; ao estourar a janela, descarta-se as mais antigas ou um resumo delas.
Longa duração	Arquivo permanente	Conversas passadas, preferências do usuário e fatos importantes (ex.: "prefere relatórios em bullet points"). Útil para agentes que atendem o mesmo usuário repetidamente.	Geralmente um vector store (ver RAG), consultado pelo agente.
Procedural	Manual de instruções	O conhecimento do agente sobre como usar suas ferramentas — os schemas: quais existem, quais parâmetros aceitam, quando usar cada uma. Não muda durante a execução (é definida por quem desenvolve); em sistemas avançados, o agente pode aprender novos procedimentos e guardá-los na memória de longa duração.	Os schemas das ferramentas fornecidos ao LLM.

Juntas, as três permitem que o agente responda "e o prazo daquele pedido?" sem pedir esclarecimento: a memória procedural diz o que o agente pode fazer; a de longa duração diz quem é o usuário; a de curta duração diz sobre o que estão falando agora.

Padrões de raciocínio de agentes¶

Dar ferramentas a um LLM não basta: é como dar um kit de ferramentas a alguém que nunca viu um martelo — falta uma estratégia para usá-las. Três padrões, cada um adequado a um nível de complexidade:

Definição: ReAct em agentes (Pensamento → Ação → Observação)

No ReAct (ver Engenharia de Prompt), as "ações" deixam de ser só passos de raciocínio e se tornam chamadas reais a ferramentas externas. Exemplo — "Qual a cotação do dólar hoje e quanto dariam 1000 reais?": Pensamento (preciso da cotação atual → ferramenta get_exchange_rate) → Ação → Observação (4,95) → Pensamento (agora divido 1000 / 4,95) → Ação (calculate) → Observação (202,02) → Resposta final. Importa porque é uma janela para a "mente" do agente: quando algo dá errado, lê-se os pensamentos e identifica-se exatamente onde o raciocínio falhou — a depuração vira um processo sistemático. Funciona bem em tarefas curtas, com poucos passos; em tarefas longas, o agente pode se perder no caminho.

Definição: Plan-Execute-Verify (planejar-executar-verificar)

Para tarefas mais longas, adiciona uma etapa de planejamento inicial: antes de agir, o agente cria um plano completo; depois executa passo a passo, marcando cada um; ao final, verifica o resultado. Ex.: "Prepare o relatório trimestral de vendas e envie para a diretoria" → Plano (buscar dados do trimestre; calcular totais por região; gerar gráficos; montar o relatório; enviar por e-mail; confirmar o envio) → Execução → Verificação ("o relatório cobre todos os dados do Q3?", "os totais batem com o sistema financeiro?", "todos os destinatários receberam?"). Se algo falhar na verificação, o agente volta ao passo específico e tenta de novo, sem refazer o plano inteiro. Use quando a tarefa tem mais de 3 ou 4 passos sequenciais, envolve múltiplas ferramentas ou quando o custo de um erro é alto; para tarefas simples, o ReAct é mais eficiente (o planejamento seria overhead desnecessário).

Definição: Reflexion (aprendizado com os próprios erros)

Proposto em 2023 (Shinn et al.): e se um agente pudesse aprender com os próprios erros sem retreinamento? Em vez de recompensas numéricas (aprendizado por reforço, caro e lento em LLMs), o agente recebe críticas em linguagem natural (feedback verbal), que são armazenadas em memória e reutilizadas como orientação. Enquanto o ReAct e o Plan-Execute-Verify olham para a frente, o Reflexion olha para trás: após completar uma tarefa, um "crítico interno" avalia o resultado. Ciclo: execução (tentativa 1) → avaliação do crítico (ex.: "o resumo omitiu as cláusulas de penalidade e a vigência; nota 4/10") → reflexão (a "lição aprendida": "em resumos de contratos, sempre incluir partes, objeto, prazo, valores, penalidades e exclusividade") → memória (a lição vai para a memória de longa duração) → execução (tentativa 2, consultando as lições antes de agir; nota 9/10). Útil em tarefas repetitivas onde a qualidade importa mais que a velocidade; desvantagem: custo adicional (pelo menos duas chamadas ao LLM por tarefa), que pode não se justificar em tarefas simples ou de baixo impacto.

flowchart TD
    EX["Executar tarefa"] --> RI["Resultado inicial"] --> AR{"Agente de reflexão:<br/>resultado é bom?"}
    AR -->|Sim| OK["Concluído"]
    AR -->|Não| SG["Gerar sugestão<br/>de melhoria"] --> MR[("Memória de reflexão")] --> EX

Sistemas multiagente¶

Algumas tarefas são complexas demais para um único agente — por mais sofisticado que seja seu raciocínio. Ex.: "Analise este contrato, verifique se os valores estão de acordo com o mercado e redija uma contraproposta se necessário" exigiria um agente que fosse especialista em interpretação jurídica, análise de mercado e redação formal; o prompt ficaria enorme, o contexto se misturaria e a qualidade cairia. A solução é dividir o trabalho entre agentes especializados, cada um fazendo o que sabe melhor, com o resultado combinado. Três padrões de orquestração:

Padrão	Como funciona	Use quando	Não use quando
Manager-Worker (gerente-trabalhador) — coordenação centralizada	Um agente "gerente" recebe a tarefa principal, a analisa e distribui subtarefas para agentes especializados ("workers"); consolida os resultados. Ex.: triagem de currículos, com workers de habilidades, de experiência e de fit cultural, e o gerente consolidando uma nota final. Cada worker é um prompt especializado — análise mais rica e prompts mais simples de manter.	A tarefa pode ser decomposta em subtarefas independentes, e cada uma exige conhecimento especializado diferente.	As subtarefas são fortemente interdependentes — o gerente vira um gargalo de comunicação.
Debate — diversidade de perspectivas	Múltiplos agentes argumentam a partir de perspectivas opostas: um defende uma posição, outro critica, um terceiro (o "juiz") pondera os argumentos e sintetiza uma recomendação. Reduz vieses e produz análises mais equilibradas. Ex.: avaliar migração para um novo fornecedor de nuvem (Defensor, Crítico e Juiz).	Decisões importantes que envolvem trade-offs (compromissos entre vantagens e desvantagens) e não têm uma resposta objetivamente correta única.	Tarefas operacionais simples — o custo de três agentes não se justifica em decisões triviais.
Swarm (enxame) — distribuição descentralizada	Muitos agentes simples trabalham em paralelo, cada um resolvendo uma pequena parte do problema; não há coordenador central — cada agente opera de forma autônoma com regras simples. Ex.: analisar 5.000 documentos de suporte; cada agente pega um lote, classifica as reclamações e registra os resultados num banco compartilhado, e um processo final consolida os padrões.	Tarefas altamente paralelas, onde cada unidade de trabalho é independente e simples.	As subtarefas precisam de coordenação — sem um gerente, a comunicação entre agentes é limitada.

Um exemplo real de Manager-Worker: um sistema de busca de veículos ("Quero um SUV 2020, vermelho, com câmera de ré, até R$ 80 mil") com três agentes — o Analisador (extrai critérios estruturados da pergunta), o Buscador (consulta a API com os filtros) e o Refinador (renegocia critérios quando nenhum resultado é encontrado, ex.: "12 opções em laranja e 3 em bordô, próximas ao vermelho") — e um manager coordenando o fluxo e garantindo que a resposta final seja fiel ao pedido original, com cada decisão de relaxamento de critério registrada para auditoria.

Segurança de agentes — o poder exige responsabilidade¶

Um chatbot que alucina uma informação errada é inconveniente. Um agente que alucina um comando delete pode ser desastroso. A segurança em agentes não é um nice-to-have — é uma necessidade absoluta antes de qualquer deploy em produção: o risco dos prompts atacados (ver Engenharia de Prompt) é amplificado, porque o agente não apenas responde — ele age. Três riscos principais:

Definição: Ações perigosas

O LLM raciocina sobre linguagem natural, que é inerentemente ambígua: "Remove os duplicados" pode significar "apague registros duplicados da tabela" — uma operação irreversível. (Num caso relatado, um agente quase deletou um arquivo de produção ao interpretar "Limpa os dados antigos" como DELETE FROM dados.) Mitigações: confirmação humana (o agente prepara a ação mas só a executa após aprovação explícita — obrigatória para ações críticas como deletar dados, enviar e-mails ou transferir dinheiro) e sandboxing (isolamento: executar ferramentas em ambientes controlados, como um banco de dados de teste em vez do de produção).

Definição: Loops infinitos

Agentes podem ficar presos em ciclos sem fim — por exemplo, tentando corrigir um erro que o próprio agente introduziu, repetindo a mesma sequência indefinidamente. Mitigação: definir limites rígidos para o número de passos e para o custo que o agente pode gerar (ex.: se ultrapassar 20 iterações ou gerar mais de R$ 50 em chamadas de API, para automaticamente e escala para um humano), e monitorar padrões de repetição (se chamou a mesma ferramenta 5 vezes seguidas com os mesmos parâmetros, algo está errado).

Definição: Escopo excessivo e princípio do menor privilégio

O risco mais sutil: conceder ao agente mais permissões do que o necessário. Se o agente só precisa ler dados de vendas, não deveria ter acesso ao banco de dados de RH. O princípio do menor privilégio diz que cada agente deve ter acesso apenas às ferramentas e aos dados estritamente necessários para sua tarefa — na prática, criar conjuntos de ferramentas específicos para cada caso de uso, em vez de conceder acesso irrestrito. Ex. de perfis: o agente de atendimento só lê dados do cliente; o de análise apenas consulta relatórios; o administrativo tem acesso mais amplo, mas exige confirmação para qualquer ação de escrita. Um agente mal configurado pode deletar arquivos críticos, enviar dados sensíveis para destinatários errados, ou entrar em loops que consomem recursos e geram custos astronômicos — segurança é requisito, não funcionalidade.

Agentes representam a fronteira da IA generativa: transformam sistemas que processam informação em sistemas que atuam sobre ela. Construí-los exige domínio de prompts, RAG, padrões de raciocínio e, especialmente, uma mentalidade de segurança.

Model Context Protocol (MCP)¶

Hoje, cada aplicação de IA é um silo: o front-end, o back-end, os agentes e os modelos são fortemente acoplados, e alterar um componente frequentemente exige reescrever os outros — trocar um modelo, mudar o banco vetorial ou migrar para outro provedor costuma exigir reescrever partes do sistema. Um padrão emergente promete resolver isso.

Definição: Model Context Protocol (MCP)

Padrão aberto que visa criar um "barramento universal" para IA. Assim como o HTTP padronizou a comunicação na web, o MCP pretende padronizar como clientes (aplicações), hosts (back-ends) e servidores de modelo trocam contexto, ferramentas e prompts. Na prática, define um schema para a troca de mensagens: definição de ferramentas, recursos (como arquivos), templates de *prompts e metadados de segurança. Embora ainda seja um padrão em evolução, aponta para um futuro em que sistemas de IA serão mais modulares, interoperáveis* e mais fáceis de manter.

Um servidor MCP expõe ferramentas por meio de um schema JSON padronizado — a mesma ideia do schema de function calling (ver acima), mas agora independente de aplicação e de provedor. Uma ferramenta de consulta de estoque seria definida assim:

{
  "name": "consultar_estoque",
  "description": "Verifica disponibilidade de um produto no estoque",
  "inputSchema": {
    "type": "object",
    "properties": {
      "produto_id": {"type": "string", "description": "Código SKU do produto"},
      "filial": {"type": "string", "enum": ["SP", "RJ", "MG"], "description": "Filial para consulta"}
    },
    "required": ["produto_id"]
  }
}

Qualquer cliente compatível com MCP — seja o Claude Desktop, uma IDE (Integrated Development Environment, ambiente integrado de desenvolvimento) ou a sua própria aplicação — pode descobrir e usar essa ferramenta sem código de integração específico: o protocolo cuida da comunicação. A consequência prática é o desacoplamento: trocar o back-end de RAG (de ChromaDB para Pinecone, por exemplo) sem mudar uma linha do front-end, pois o protocolo garante que a interface seja a mesma — a migração leva horas, não semanas.