Padrões de Design de Agentes: Um livro que me fez repensar "O que é exatamente um Agente?"

Autor: Yanhua

Antonio Gullí é diretor de engenharia na Google. Ele escreveu um livro de 453 páginas que divide o desenvolvimento de Agentes de IA em 21 padrões de design.

Mas isto não é uma crítica literária. A minha motivação para ler este livro é muito específica: escrevi sobre Engenharia de Harness, partilhei as minhas dificuldades com o Clawdbot e discuti os sete pontos de viragem de "Agentes de IA não são magia" que vão desde o consumo de tokens até à utilidade real. Após cada texto, ficava com uma questão que não tinha pensado totalmente: Existe uma lógica subjacente reutilizável por trás destas coisas?

Este livro deu-me a resposta, e foi mais profunda do que eu esperava.

Pode nem estar a escrever um Agente

O julgamento mais severo do livro está escondido no prólogo.

A maior parte da "IA" que as pessoas estão a usar é apenas Nível 0: LLM básico, sem ferramentas, sem memória e sem ações. Se lhe perguntar qual é o melhor filme nos Óscares de 2025, ele adivinha. O livro afirma claramente: Nível 0 não é um Agente.

Subir de nível é onde estão os verdadeiros Agentes:

• Nível 1: Utilizador de Ferramentas

  O Agente começa a usar ferramentas: pesquisa, APIs, bases de dados. Mas não se trata apenas de "ser capaz de chamar interfaces"; também precisa de julgar quando chamar, o que chamar e como usar os resultados. O livro fornece um exemplo muito específico: quando um utilizador pergunta "Que programas novos existem recentemente?", o Agente percebe que esta informação não está nos dados de treino e chama proativamente a ferramenta de pesquisa para a encontrar, sintetizando depois o resultado. O passo chave é "perceber por conta própria". Não é um humano a dizer-lhe "vai pesquisar", mas sim ele a julgar que precisa de pesquisar. Esta capacidade de julgamento é o limiar para o Nível 1.

• Nível 2: Pensador Estratégico

  São adicionados mais dois elementos: planeamento e Engenharia de Contexto. O livro define Engenharia de Contexto: não apenas acumular informação, mas selecionar, aparar e empacotar cuidadosamente o contexto. É dado um exemplo inteligente: um utilizador quer encontrar uma cafetaria entre dois locais. O Agente chama primeiro a ferramenta de mapas para recolher um conjunto de dados, depois julga que "apenas os nomes das ruas são necessários a seguir", reduz a saída do mapa a uma lista curta e fornece-a à ferramenta de pesquisa local. Cada passo serve para reduzir o ruído na informação.

  Há uma frase no livro que li várias vezes: "Para alcançar a maior precisão com IA, deve ser-lhe dado um contexto curto, focado e poderoso." A Engenharia de Contexto consiste em fazer isto.

  A este nível, o Agente também pode autorrefletir. Após completar uma tarefa, revê o seu trabalho, identifica problemas e faz correções por conta própria. Elaborarei sobre isto mais tarde.

• Nível 3: Colaboração Multi-Agente

  A posição do livro é clara: pare de pensar em criar um super agente todo-poderoso. A abordagem verdadeiramente fiável é construir uma equipa, como um Agente gestor de projeto + Agente investigador + Agente designer + Agente copywriter. O exemplo dado no livro é o lançamento de um novo produto: um "Agente gestor de projeto" coordena tudo, atribuindo tarefas ao "Agente de pesquisa de mercado", "Agente de design de produto" e "Agente de marketing". A chave é a comunicação: como os Agentes transmitem dados, sincronizam estados e lidam com conflitos. Este capítulo ilustra seis tipos de topologias de comunicação, desde o Agente único mais simples até à mistura personalizada mais flexível, com explicações sobre que cenários cada uma é adequada.

Depois de ler estes quatro níveis, percebi subitamente porque é que muitas pessoas dizem: "O meu Agente não é útil." O modelo não é o problema; a questão é que o está a tratar como um chatbot, e ele pode nem ter chegado ao Nível 1.

Engenharia de Contexto: O Conceito Mais Subestimado do Livro

Escrevi um artigo sobre Engenharia de Harness, discutindo como o design de pistas é mais importante do que a potência do motor. Depois de ler este livro, percebi que a Engenharia de Contexto é o mapeamento da Engenharia de Harness ao nível do prompt.

A Engenharia de Prompt tradicional preocupa-se apenas com "como pergunta". A Engenharia de Contexto do livro preocupa-se com "que contexto está à frente do Agente antes de perguntar". Inclui quatro camadas de informação:

1. Primeira camada, prompt de sistema. Define quem é o Agente, que tom usar e que limites definir. A maioria das pessoas apenas escreve esta camada.

2. Segunda camada, dados externos. Documentos recuperados por RAG, valores de retorno de chamadas de ferramentas, dados de API em tempo real. É aqui que a maioria das pessoas fica bloqueada: sabem que precisam de fornecer dados, mas não sabem como o fazer sem sobrecarregar o modelo.

3. Terceira camada, dados implícitos. Identidade do utilizador, histórico de interação, estado ambiental. Coisas que não são declaradas explicitamente, mas que o Agente deveria saber. Por exemplo, se disser ao Agente: "Ajuda-me a enviar um e-mail ao João para confirmar a reunião de amanhã", ele deveria saber qual é a reunião de amanhã no seu calendário e qual é a sua relação com o João.

4. Quarta camada, ciclo de feedback. Após cada saída, o Agente avalia automaticamente a qualidade e ajusta a estratégia de contexto para a próxima vez. O livro refere-se a isto como "otimização de contexto automatizada", e o Vertex AI Prompt Optimizer da Google é uma implementação de engenharia desta ideia.

Quando li isto, lembrei-me de uma experiência anterior que partilhei em "Agentes de IA não são magia", onde mencionei que "o seu agente precisa de regras, e muitas regras". Olhando para trás, essas regras são essencialmente a versão manual da Engenharia de Contexto, que o livro sistematizou.

Reflexão: Dois Agentes são Realmente Melhores que Um

Este é o padrão mais valioso na prática em todo o livro para mim.

O núcleo da Reflexão é simples: o Agente revê o seu trabalho após completar uma tarefa e faz correções por conta própria. Mas o método de implementação é crucial. O livro afirma claramente: O Produtor e o Crítico devem usar dois Agentes diferentes, com prompts de sistema diferentes. Uma única persona a rever o seu próprio trabalho terá sempre pontos cegos. Se tiver o mesmo LLM a escrever código e depois a rever o seu próprio código, é muito provável que diga: "Está muito bom."

O livro fornece um exemplo de código completo.

• O prompt do Produtor é "És um programador Python, escreve uma função para calcular o fatorial, lidando com casos extremos e exceções."

• O prompt do Crítico é "És um engenheiro sénior exigente, revê o código linha a linha, verificando erros, estilo, casos extremos perdidos e áreas de melhoria. Se estiver perfeito, devolve CODE_IS_PERFECT; caso contrário, lista todos os problemas."

• Depois há um ciclo for: Produtor escreve código → Crítico revê → Produtor faz alterações com base no feedback → Crítico revê novamente → até que o Crítico diga CODE_IS_PERFECT ou o número máximo de iterações seja atingido.

É simples assim. Mas o livro lembra-nos de uma questão de custo que é facilmente ignorada: cada ciclo de reflexão é uma nova chamada de LLM, e quanto mais iterações, mais caro se torna. Além disso, à medida que o histórico de conversação se expande, a janela de contexto fica preenchida com versões anteriores e críticas, reduzindo o espaço de raciocínio utilizável real. Portanto, a melhor prática para a Reflexão é: defina um número máximo de iterações razoável (o livro usa 3) e pare assim que o Crítico estiver satisfeito; não procure a perfeição.

Os usos estendem-se muito além de escrever código. Escrever artigos, fazer planos, resumir documentos, resolver problemas de lógica — tudo pode aplicar o modelo Produtor-Crítico. O livro lista sete cenários de aplicação, sendo a lógica central a mesma: produzir primeiro, depois rever e, finalmente, corrigir.

Multi-Agente não é melhor quando é mais complexo

O que mais gostei no capítulo de Colaboração Multi-Agente foram os seis diagramas de topologia de comunicação. Muitas pessoas saltam diretamente para a complexidade, mas na maioria dos cenários, três tipos são suficientes:

1. Agente Único (Execução Independente): As tarefas podem ser divididas em subproblemas independentes, cada Agente trata do seu. Simples e fácil de manter.

2. Rede Peer-to-Peer: Os Agentes comunicam diretamente entre si, sem um nó de controlo central. Descentralizado e tolerante a falhas; se um Agente falhar, não afeta todo o sistema. No entanto, os custos de coordenação são elevados e pode facilmente tornar-se caótico.

3. Supervisor (Coordenação Central): Um Agente Supervisor gere um grupo de Agentes Trabalhadores. Aloca tarefas, recolhe resultados e resolve conflitos. Hierarquia clara e gestão fácil. No entanto, o Supervisor é um ponto único de falha e um estrangulamento de desempenho.

Os outros três (Supervisor-como-Ferramenta, hierárquico, mistura personalizada) são variações e combinações dos primeiros três. O livro afirma de forma prática: A topologia de que precisa depende da complexidade da sua tarefa. Quanto mais fragmentada for a tarefa, maiores serão os custos de comunicação; a partir de certo ponto, o modelo de Supervisor pode ser mais eficiente do que o hierárquico.

A minha experiência é que muitas pessoas gastam 80% do seu tempo em protocolos de comunicação ao construir Multi-Agentes, esquecendo-se de fazer uma pergunta mais fundamental: esta tarefa precisa realmente de múltiplos Agentes? O livro afirma claramente que um Agente único de Nível 2 com Reflexão é muitas vezes suficiente. O Nível 3 destina-se a cenários que um único Agente não consegue realmente gerir.

Modelo de Três Camadas de Memória, eu tinha uma noção vaga, mas não lhe dei nome

O capítulo de Memória foi o que mais me ressoou, porque quando escrevi os artigos sobre Obsidian + Claude, estava constantemente a ponderar uma questão: como deve ser estratificada a memória do Agente?

O livro fornece a resposta:

1. Sessão (Camada de Conversação): A janela de contexto da conversação atual, que é a memória mais curta e desaparece assim que a conversação termina. Modelos de contexto longo simplesmente aumentam esta janela, mas essencialmente continua a ser temporária, e cada inferência tem de processar toda a janela, o que é dispendioso e lento.

2. Estado (Camada de Estado): Dados temporários durante a tarefa atual. Por exemplo, "Qual é a tarefa atual?", "Quanto progrediu?", "Que dados foram gerados entretanto?". Mais longa que a Sessão, mas limpa assim que a tarefa termina; o livro usa o mecanismo de Estado do ADK da Google como um exemplo completo.

3. Memória (Camada Persistente): Memória de longo prazo que abrange sessões e tarefas. Preferências do utilizador, experiências aprendidas, decisões históricas importantes armazenadas em bases de dados ou lojas de vetores, com recuperação semântica. O livro enfatiza um ponto importante: Memória não é apenas sobre armazenamento; também requer o design de uma estratégia completa para "o que armazenar, quando armazenar e como recuperar". Armazenar demasiado cria ruído, enquanto armazenar pouco é insuficiente.

No meu artigo anterior sobre o Clawdbot, mencionei "ficheiros de estado" e "documentos de espaço de trabalho", que eram essencialmente as minhas tentativas manuais de criar camadas de Estado e Memória, e o livro estruturou este processo.

Cinco Premissas, a quinta é a mais absurda

No final do livro, são mencionadas cinco premissas sobre o futuro dos Agentes, com as quatro primeiras ainda dentro de uma extrapolação razoável: Agentes de propósito geral a evoluir da codificação para a gestão de projetos, descoberta proativa profundamente personalizada das suas necessidades, inteligência incorporada a mover-se dos ecrãs para o mundo físico e Agentes a tornarem-se entidades económicas independentes.

A quinta premissa chocou-me: Multi-Agente Transformador.

Apenas declara um objetivo, como "criar um negócio de comércio eletrónico a vender café premium". O sistema decide automaticamente: primeiro criar um "Agente de pesquisa de mercado" e um "Agente de branding". Após processar alguns dados, julga que o Agente de branding já não é necessário e divide-o em três novos Agentes: "Agente de Design de Logótipo", "Agente de Construção de Website" e "Agente de Cadeia de Abastecimento". Se o Agente de Construção de Website se tornar um estrangulamento, o sistema duplicará automaticamente três Agentes paralelos para trabalhar em páginas diferentes simultaneamente. Ao longo do processo, o sistema otimiza continuamente o prompt de cada Agente e reorganiza a estrutura da equipa.

O livro refere-se a isto como um "sistema multi-Agente autotransformador orientado por objetivos". Não está a executar um plano que escreveu; está a gerar os seus próprios planos, a ajustar os seus planos e a reorganizar a sua equipa de execução por conta própria.

Isto lembra-me o AutoResearch de Karpathy: escrever um program.md, definir objetivos, métricas e limites, e carregar em "iniciar". Os humanos estão fora do ciclo. Mas este livro leva-o mais longe: até a forma como a equipa de Agentes é formada e reorganizada é deixada ao critério do sistema. Os humanos apenas declaram "o que querem".

Três Ações que pode tomar imediatamente

Depois de terminar este livro, tenho três ações imediatas que posso implementar:

• Primeiro, adicione um Crítico ao seu Agente atual. Quer esteja a usar Claude Code, CrewAI ou uma estrutura que construiu, adicione um passo no final do seu fluxo de trabalho existente: peça a outro Agente (com um prompt de sistema diferente) para rever a saída do passo anterior. Geração de código mais revisão de código, escrita de artigos mais verificação de factos, planeamento mais avaliação de viabilidade. Adiciona mais uma chamada de LLM, mas a melhoria na qualidade é muitas vezes duplicada. O modelo Produtor-Crítico no livro é plug-and-play.

• Segundo, comece a fazer Engenharia de Contexto, não apenas Engenharia de Prompt. Olhe para os ficheiros de instruções que escreveu para o Agente. Se forem todas regras sobre "como deves fazer", sem contexto sobre "que ambiente estás a enfrentar agora", preencha isso. Diga ao Agente em que projeto está atualmente, que decisões foram tomadas anteriormente e quais são as preferências do utilizador. O capítulo de Engenharia de Contexto no livro e o seu AGENTS.md são duas expressões da mesma coisa.

• Terceiro, não se apresse para o Multi-Agente. Leve o seu Agente único ao Nível 2: com ferramentas, Reflexão e Memória. O livro enfatiza repetidamente que um Agente único de Nível 2 combinado com Produtor-Crítico e Engenharia de Contexto pode cobrir a grande maioria dos cenários práticos. O Nível 3 destina-se a tarefas que realmente requerem divisão de trabalho entre domínios, em várias fases e em paralelo. O problema da maioria das pessoas não é a falta de Agentes, mas sim não terem otimizado um único Agente.

Este livro tem 453 páginas e será publicado pela Springer em 2025. Os exemplos de código cobrem LangChain/LangGraph, Google ADK, CrewAI e OpenAI API. O prefácio é escrito pelo VP de IA da Google Cloud, e há uma recomendação do CIO da Goldman Sachs, que é inesperadamente bem escrita.

Mas a razão pela qual o recomendo não é pela sua "abrangência". É porque, depois de o ler, perceberá uma coisa: as dificuldades que encontrou com Agentes nos últimos seis meses já foram organizadas em padrões por outra pessoa. Não precisa de reinventar a Reflexão, não precisa de adivinhar como estratificar a Memória e não precisa de experimentar que topologia de comunicação usar para Multi-Agente.

Alguém desenhou o mapa para si; tudo o que resta é percorrê-lo.

Está a usar Agentes de IA para desenvolvimento? Em que nível está o seu Agente atual?