A maioria das equipas de IA que procura melhorar o desempenho dos agentes recorre às mesmas soluções: janelas de contexto maiores, mais documentos e prompts mais inteligentes. Este artigo defende que esse instinto está completamente errado. O elemento em falta não é mais informação. É controlo. Uma camada de controlo bem concebida é o que distingue um agente que funciona numa demonstração de outro que funciona em produção.
Dar a um agente de IA mais memória, mais documentos ou uma janela de contexto maior não o torna mais inteligente, apenas mais lento e dispendioso. Os verdadeiros ganhos surgem quando ensinamos o agente a escolher aquilo de que precisa e quando precisa, em vez de consumir tudo de uma só vez.
A fiabilidade vem do ciclo, não do modelo. A diferença entre um agente que impressiona numa demonstração e outro que se mantém fiável em produção não está na qualidade da IA, mas na capacidade do sistema para verificar o seu próprio trabalho. Os agentes que planeiam, agem, observam e verificam cada etapa detetam os próprios erros, em vez de cometerem erros com toda a confiança.
Atualmente, a maioria dos agentes de IA são essencialmente chatbots com etapas adicionais: não dispõem de mecanismos para saber se estão no caminho certo, quando devem parar ou quando devem tentar outra abordagem. É uma verdadeira camada de controlo — critérios de sucesso claros, estado estruturado e verificações de validação — que transforma algo com forma de agente num sistema realmente fiável.
O que almoçou ontem?
Provavelmente, não reproduziu todas as suas memórias até encontrar «ontem + almoço». Foi diretamente à parte da sua experiência onde residem esses conceitos. É um modelo mental útil para criar agentes:
Uma janela de contexto gigante não é memória.
Uma pilha de documentos obtidos não é compreensão.
Uma longa cadeia de pensamento não é fiabilidade.
Esses são apenas ingredientes. Mas aquilo que faz um agente parecer um verdadeiro agente é o mesmo que impede o cérebro de processar à força toda a nossa história de vida: controlo.
Um estudo recente — Agentic Reasoning for Large Language Models — resumiu (e deu nome) de forma exemplar à mudança que muitos temos sentido ao desenvolver sistemas: do raciocínio dentro do modelo para o raciocínio através da interação. Este artigo não é um resumo desse documento. É uma tentativa de traduzir essa mudança em princípios práticos de conceção de sistemas:
Se criar agentes como chatbots com ferramentas, continuará a ter os mesmos modos de falha dos chatbots, mas com erros mais caros.
Durante algum tempo, o nosso guia predefinido para «tornar o modelo mais inteligente» resumia-se a melhores prompts, cadeia de pensamento, autoconsistência ou melhorias baseadas em amostragem e, talvez, alguma pesquisa.
O ReAct marcou uma viragem, porque tornou natural a sequência «pensamento → ação → observação». Mas repare na restrição implícita: grande parte disto continua a resultar em «inferência one-shot, mas com mais tokens». O enquadramento do estudo é mais preciso: o raciocínio agêntico dá prioridade à expansão da interação em tempo de teste, transformando a inferência num processo iterativo em que o modelo, a memória e o ambiente permanecem no ciclo.
Se criou (ou utilizou) agentes que impressionam em demonstrações, mas são frágeis em fluxos de trabalho reais, este artigo é para si.
Deixe-me descrever um padrão que tenho visto muitas vezes (e cujas versões também já criei):
Escolher um bom modelo de conversação
Adicionar algumas ferramentas (pesquisa, consulta de bases de dados e, talvez, execução de código)
Adicionar RAG
Adicionar um prompt de sistema “you are an autonomous agent”
Colocar tudo num ciclo while até parar ou esgotar o tempo
Parabéns, tem um objeto com forma de agente. Mas tende a falhar de formas previsíveis:
Contexto excessivo: todas as observações são acrescentadas; os prompts tornam-se camadas arqueológicas.
Uso errático de ferramentas: «usar a ferramenta errada com toda a confiança» torna-se o modo de falha habitual.
Sem condições de paragem: continua porque pode, não porque deve.
Sem disciplina de fundamentação: não percebe que está errado, a menos que seja forçado a fazê-lo.
Memória = histórico da conversa: o que equivale, essencialmente, a criar registos e chamar-lhe aprendizagem.
É por isso que os «agentes» parecem muitas vezes mágicos nas demonstrações e caóticos em produção. A nossa experiência ao colocar sistemas agênticos em produção confirma-o: quando deixamos de avaliar um modelo e passamos a avaliar um sistema, os modos de falha incluem navegação, utilização responsável das ferramentas, redução do contexto e conceção da avaliação — não apenas «o modelo respondeu corretamente?».
A pergunta passa então a ser: o que é um agente deliberado?
Para tornar isto menos abstrato, eis um fluxo de trabalho simples que quase todos conseguem imaginar: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Uma implementação comum com «forma de agente» funciona assim:
Obtém imediatamente inúmeros documentos sobre companhias aéreas e políticas de viagem, mesmo que ainda não sejam necessários.
Chama uma ferramenta de pesquisa, cola uma longa lista de resultados no prompt e «escolhe um».
Faz a reserva prematuramente, sem verificar as restrições (hora de chegada, bagagem, lugar e política).
Se falhar, tenta novamente de forma ligeiramente diferente, mas sem saber ao certo o que mudou ou o que aprendeu.
A falha não está na incapacidade de raciocínio do modelo, mas no facto de o sistema não controlar o fluxo de trabalho.
Uma versão mais agêntica trata a tarefa como um processo interativo, com estado e verificações explícitos:
PLANEAR: reformular as restrições e indicar os dados em falta (por exemplo, «tem preferência por algum aeroporto?»/«aceita uma escala?»).
AGIR: chamar a pesquisa de voos com uma consulta estruturada (intervalo de datas, limite de chegada e orçamento).
OBSERVAR: guardar os resultados num objeto de estado compacto (os cinco melhores candidatos, com preço, chegada e escalas), em vez de colar um enorme bloco de dados.
ATUALIZAR: aperfeiçoar a consulta se as restrições não forem cumpridas (por exemplo, «chegar antes das 18:00 é demasiado restritivo — alargar o intervalo horário ou aumentar o orçamento?»).
VERIFICAR: executar validadores («chegada < 18:00», «preço ≤ £900», «em conformidade com a política», «seleção de lugar disponível»).
PARAR: apenas quando a API de reservas devolver uma confirmação e todos os validadores forem aprovados.
A mudança é subtil, mas decisiva. A obtenção de informação é condicional, não um reflexo; o contexto é gerido, com um estado estruturado em vez de acumulado; e a verificação faz parte do ciclo, em vez de ficar a cargo do utilizador. Troque «reservar um voo» por «criar uma ordem de compra», «emitir um reembolso», «alterar uma configuração de produção» ou «entregar um PR» e a história é a mesma: quando o agente pode agir, o ciclo torna-se mais importante do que o prompt.
O estudo acima referido organiza o raciocínio agêntico em três camadas: fundamental (planeamento, utilização de ferramentas e pesquisa), autoevolutiva (feedback e memória) e coletiva (coordenação entre vários agentes).
Mas a ideia mais profunda é esta: o raciocínio torna-se o princípio organizador do planeamento, da tomada de decisões e da verificação, em vez de servir apenas para gerar uma cadeia de pensamento plausível. Isto parece abstrato até o associarmos às mudanças na arquitetura. Há três pontos essenciais a reter:
Um bom agente não deve encarar a obtenção de informação como algo que faz sempre. Trata-se de uma decisão, não de um reflexo.
Eis uma heurística prática:
Se o seu sistema obtém informação em cada interação, não criou um mecanismo de obtenção: criou um imposto sobre o contexto.
Isto acontece constantemente no trabalho real. Ao depurar um incidente em produção, não se colocam todos os registos no contexto; decide-se que métricas ou registos obter a seguir com base na hipótese atual. Isto é «obtenção agêntica». Eis um padrão mais concreto:
Decidir se é necessário obter informação
Se for: preparar uma consulta, obter, examinar e extrair
Se as provas forem contraditórias: obter novamente
Só depois sintetizar
É também aqui que o «RAG agêntico» começa a distinguir-se do RAG tradicional: a obtenção torna-se uma etapa deliberada de raciocínio, não uma fase predefinida do processo.
Quando deixamos de avaliar «um modelo» e passamos a avaliar «um sistema», o acompanhamento e o rastreio do estado tornam-se importantes.
Entretanto, o setor tornou mais explícita a importância da observabilidade nos fluxos de trabalho dos agentes. Por exemplo, o Agents SDK da OpenAI inclui rastreio integrado e um painel Traces que regista as execuções dos agentes (gerações, chamadas de ferramentas, transferências, proteções e eventos personalizados), para que possa depurar e auditar passo a passo o que aconteceu.
Isto não é apenas algo «bom de ter». É a diferença entre um sistema que pode ser depurado e outro que só pode ser avaliado por intuição.
Na minha opinião, a parte do estudo com maior aplicação prática é a forma direta como aborda o feedback. Divide-o em três regimes: feedback reflexivo (gerar → criticar → rever), adaptação paramétrica (aprender através de ajuste fino/aprendizagem por reforço) e feedback orientado por validadores (repetir até passar num validador).
A maioria das equipas deve começar pelo feedback orientado por validadores, porque é uma solução pouco entusiasmante, mas eficaz. Se conseguir criar qualquer validador que execute testes unitários, verifique o schema, imponha regras ou restrições empresariais («nenhum reembolso acima de X sem escalamento») ou confirme a exatidão factual («citações obrigatórias»), pode transformar os resultados não determinísticos do modelo em algo verdadeiramente fiável.
Uma das mudanças que não sabíamos que desconhecíamos é simples: no mundo dos agentes, a fiabilidade vem muitas vezes mais do ciclo do que do modelo.
Esta é a disciplina de ciclo mais simples que encontrei para melhorar o comportamento de forma fiável e sem treino:
Trabalhar por etapas: Planear → Agir → Observar → Atualizar;
Depois de cada ação, resumir a observação em 1–3 pontos;
Parar quando os critérios de sucesso forem cumpridos ou o orçamento se esgotar; devolver o melhor resultado conhecido e as incertezas restantes.
O objetivo não é tornar o modelo prolixo. É tornar o sistema compreensível e obrigá-lo a «confrontar-se com a realidade» em cada etapa. Um exemplo muito próximo da realidade dos engenheiros é a fundamentação em ciclo fechado, ao estilo da integração contínua:
Planear: propor uma lista de alterações
Agir: executar testes/análise estática
Observar: analisar as falhas
Atualizar: corrigir e repetir
Algumas perguntas que costumam revelar projetos de agentes acidentais:
«O meu agente decide o que deve obter ou sou eu que obtenho sempre a informação?»
Se a obtenção for incondicional, pagará o preço em latência, custos, diluição do contexto e maior risco de lixo à entrada, lixo à saída.
«O meu agente consegue perceber que está errado?»
Se o único sinal de feedback do agente for «o utilizador fica irritado», está a fazer aprendizagem por reforço à custa do sofrimento humano. Um ciclo de repetição orientado por validadores é a forma mais simples de o confrontar com a realidade.
«É possível escrever na memória e esta melhora ao longo do tempo?»
Se a sua «memória» se limita a acrescentar o histórico da conversa, está essencialmente a criar registos. A forma como o estudo enquadra a memória é importante: esta torna-se um contexto que cresce dinamicamente e que os agentes aperfeiçoam ao longo do tempo, não apenas uma transcrição.
Os registos dizem o que aconteceu; a memória diz o que fazer da próxima vez. O histórico da conversa é uma transcrição. A memória é uma política em evolução sobre aquilo que vale a pena preservar.
Um ponto de partida prático é uma pequena tabela de «lições aprendidas», organizada por tipo de tarefa, ferramenta e modo de falha, com registos do que funcionou e do que deve ser evitado. O objetivo não é criar um grafo de conhecimento perfeito. O objetivo é criar um comportamento de melhoria cumulativa: a memória e o feedback transformam os agentes, que deixam de ser «assistentes sem estado» e passam a ser sistemas que melhoram ao longo do tempo.
É tentador lançar mais agentes sobre o problema, mas isso multiplica frequentemente os custos de coordenação. Um bom padrão de «equipa mínima viável»:
Coordenador: decompõe e atribui
Executor: chama ferramentas e efetua alterações
Crítico/avaliador: verifica a correção e o risco
Responsável pela memória: regista e organiza as lições
Se não consegue explicar a responsabilidade de cada agente, provavelmente ainda não precisa de vários agentes.
Se aceitarmos realmente a mudança de paradigma, provavelmente deixaremos de colocar tudo nos prompts, de tratar as falhas como resultados finais e de avaliar os agentes como chatbots. E começaremos a tratar os agentes como aquilo que são: sistemas de software em que a linguagem é o plano de controlo e a fiabilidade vem do ciclo.
Antes de adicionar outro modelo, adicione outro ciclo de avaliação. Antes de obter tudo, torne a obtenção condicional. Coloque um validador em produção antes de colocar dez. Trate a memória como decisões de política, não como uma base de dados. E, ao adotar vários agentes, comece com dois, não com vinte. Não são regras; são os padrões que sobreviveram à produção.