Autor: Yanhua
Antonio Gullí é o diretor de engenharia do Google. Ele escreveu um livro de 453 páginas dividindo o desenvolvimento de AI Agent em 21 padrões de design.
Mas este não é um resenha de livro. Minha motivação para ler este livro era muito específica: escrevi Harness Engineering, escrevi sobre as armadilhas do Clawdbot, escrevi o artigo “Agentes de IA não são magia”, sobre os sete momentos de transição de gastar tokens para se tornar verdadeiramente útil; após cada um, permanecia uma questão que não havia sido totalmente esclarecida: por trás dessas coisas existe uma lógica subjacente reutilizável?
This book gave me the answers, and deeper than I thought.
O que você escreveu pode nem sequer ser um Agent
A avaliação mais impactante do livro está escondida no prólogo.
A maioria das pessoas usa o que chamam de "IA", mas é apenas Level 0: um LLM nu, sem ferramentas, sem memória, incapaz de agir. Você pergunta a ele qual será o melhor filme do Oscar em 2025, e ele chuta. O livro deixa bem claro: coisas de Level 0 não são Agentes.
Subir é o verdadeiro Agente:
Nível 1: Usuário de ferramentas
O agente começa a usar ferramentas: busca, API, banco de dados. Mas não se trata apenas de “conseguir chamar interfaces”, e sim de decidir sozinho quando chamar, o que chamar e como usar os resultados. O livro apresenta um exemplo muito específico: o usuário pergunta “quais são as novas séries recentes?”, e o agente percebe sozinho que essa informação não está nos dados de treinamento, ativa automaticamente a ferramenta de busca e sintetiza o resultado. O passo crucial está em “perceber sozinho”. Não é o ser humano que diz “vá pesquisar”, é o agente que julga por conta própria que precisa pesquisar. Essa capacidade de julgamento é o limite do Nível 1.
Nível 2: Pensador estratégico
Duas coisas a mais: planejamento e Context Engineering. O livro define Context Engineering como não acumular informações, mas sim selecionar, cortar e empacotar cuidadosamente o contexto. O exemplo é excelente: o usuário quer encontrar uma cafeteria entre dois locais. O agente primeiro chama a ferramenta de mapa para obter uma série de dados, depois decide sozinho que “o próximo passo precisa apenas dos nomes das ruas”, corta a saída do mapa em uma lista curta e fornece-a à ferramenta de busca local. Cada etapa realiza uma redução de ruído informativo.
Há uma frase no livro que li várias vezes: “Para que a IA atinja a maior precisão possível, é necessário fornecer a ela um contexto breve, focado e impactante.” O Context Engineering é exatamente isso.
Neste nível, o agente ainda pode se autoavaliar. Após concluir a tarefa, revisa sozinho e corrige os problemas identificados. Vou detalhar isso mais tarde.
Nível 3: Colaboração de Múltiplos Agentes
A posição do livro é clara: não fique obcecado em criar um super agente全能. A abordagem realmente confiável é construir uma equipe, como um agente gerente de projeto + agente pesquisador + agente designer + agente de redação. O exemplo citado no livro é o lançamento de um novo produto: um "agente gerente de projeto" coordena tudo e atribui tarefas ao "agente de pesquisa de mercado", ao "agente de design de produto" e ao "agente de marketing". A chave é a comunicação: como os agentes trocam dados, sincronizam estados e resolvem conflitos. Este capítulo apresenta seis estruturas de topologia de comunicação, desde o agente único mais simples até a mistura personalizada mais flexível, com explicações sobre qual cenário cada uma é adequada.
Depois de ver esses quatro níveis, de repente entendi por que muitas pessoas dizem “meu agente não funciona bem”. O modelo não tem problema; o problema é que você o está usando como um chatbot — ele nem chega ao Nível 1.
Engenharia de Contexto: O conceito mais subestimado do livro
Eu escrevi um artigo sobre Harness Engineering, que diz que o design da pista é mais importante que a potência do motor. Depois de ler este livro, percebi que Context Engineering é o mapeamento do Harness Engineering no nível do prompt.
A Engenharia de Prompt tradicional se concentra apenas em “como você pergunta”. A Engenharia de Contexto do livro trata do que o Agente tem diante de si antes de perguntar. Ela inclui quatro camadas de informações:
Primeiro nível, prompt do sistema. Define quem é o Agent, qual o tom e quais os limites. A maioria das pessoas só escreveu este nível.
Camada dois, dados externos. Documentos recuperados pelo RAG, valores retornados por chamadas de ferramentas, dados de API em tempo real. Este é o ponto onde a maioria das pessoas travam: sabem que precisam fornecer dados, mas não sabem como fazê-lo sem inundar o modelo.
Camada três: dados implícitos. Identidade do usuário, histórico de interações, estado do ambiente. Coisas que você não diz explicitamente, mas que o Agente deveria saber. Por exemplo, se você disser ao Agente: “Ajude-me a enviar um e-mail para John 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 John.
Quarto nível, loop de feedback. Após cada saída do agente, a qualidade é avaliada automaticamente e a estratégia de contexto para a próxima interação é ajustada. O livro chama isso de “otimização automática de contexto”; o Vertex AI Prompt Optimizer da Google é uma implementação engenhosa dessa ideia.
Quando li isso, lembrei-me do artigo que escrevi anteriormente, “Agentes de IA não são magia”, onde uma das lições era “Seu agente precisa de regras — e muitas regras”. Agora, olhando para trás, essas regras eram, na verdade, uma versão manual do Context Engineering, que o livro sistematizou.
Reflection: Dois Agentes realmente são melhores do que um
Este é o padrão mais prático para mim em todo o livro.
O núcleo do Reflection é simples: o Agent revisa seu próprio trabalho após concluí-lo e corrige os problemas sozinho. Mas a implementação exige cuidado. O livro deixa claro: Producer e Critic devem ser dois Agents diferentes, com prompts de sistema distintos. Um mesmo persona revisando seu próprio trabalho inevitavelmente terá cegueiras. Se você pedir ao mesmo LLM para escrever código e depois revisar o próprio código, ele provavelmente dirá “está bom”.
The book provides a complete code example.
O prompt do produtor é “Você é um desenvolvedor Python, escreva uma função para calcular o fatorial, lidando com condições limite e exceções”.
O prompt do Critic é “Você é um engenheiro sênior exigente, revisando linha por linha o código, verificando bugs, estilo, condições limite omitidas e áreas a serem melhoradas. Se estiver perfeito, saia com
CODE_IS_PERFECT, caso contrário, liste todos os problemas”.Em seguida, há um loop for: Producer escreve o código → Critic revisa → Producer ajusta com base no feedback → Critic revisa novamente → até que o Critic diga
CODE_IS_PERFECTou atinja o número máximo de iterações.
É tão simples assim. Mas o livro alerta para um custo facilmente ignorado: cada ciclo de reflexão é uma nova chamada ao LLM, e quanto mais iterações, mais caro fica. Além disso, à medida que o histórico da conversa cresce, a janela de contexto fica preenchida por versões anteriores e críticas, reduzindo o espaço real disponível para raciocínio. Portanto, a melhor prática para Reflection é: defina um número máximo razoável de iterações (o livro usa 3), pare assim que o Critic estiver satisfeito e não busque perfeição.
O uso vai muito além de escrever código. Escrever artigos, fazer planos, resumir documentos, resolver problemas lógicos — o modelo Producer-Critic pode ser aplicado a todos eles. O livro lista sete cenários de aplicação, todos com a mesma lógica central: primeiro produzir, depois revisar e, por fim, corrigir.
Multi-Agent não é quanto mais complexo, melhor
Neste capítulo, Multi-Agent Collaboration, meu favorito são os seis gráficos de topologia de comunicação. Muita gente começa com coisas complexas, mas na verdade, na maioria dos cenários, três são suficientes:
Agente único (execução independente): a tarefa pode ser dividida em subproblemas independentes, cada agente resolve o seu próprio. Simples e fácil de manter.
Rede ponto a ponto (Peer-to-Peer): Agentes se comunicam diretamente, sem nó de controle central. Descentralizado, com boa tolerância a falhas; a falha de um agente não afeta o sistema como um todo. Mas o custo de coordenação é alto e pode se tornar desorganizado.
Supervisor (agendamento central): Um agente Supervisor gerencia um grupo de agentes Worker. Atribui tarefas, coleta resultados e resolve conflitos. Hierarquia clara, fácil de gerenciar. Mas o Supervisor é um ponto único de falha e um gargalo de desempenho.
As outras três (Supervisor-as-Tool, hierárquica e híbrida personalizada) são variações e combinações das três primeiras. O livro é bem prático: a topologia que você precisa depende da complexidade da sua tarefa. Quanto mais você dividir a tarefa em partes menores, maior será o custo de comunicação; até certo ponto, o modelo Supervisor se torna mais eficiente do que o hierárquico.
Minha experiência é que muitas pessoas gastam 80% do tempo construindo protocolos de comunicação para Multi-Agent, esquecendo de fazer uma pergunta mais básica: este trabalho realmente precisa de vários Agentes? O livro deixa bem claro que um único Agente de Nível 2 + Reflection geralmente já é suficiente. O Nível 3 é destinado a cenários em que um único Agente realmente não consegue lidar.
Modelo de três camadas de Memory, eu já tinha sentido isso antes, mas não tinha nomeado
O capítulo Memory é o que mais me ressoa, pois, ao escrever os dois artigos sobre Obsidian + Claude, fiquei refletindo constantemente sobre uma pergunta: como dividir a memória de um Agente?
O livro dá a resposta:
Camada de Sessão: a janela de contexto da conversa atual, que é a memória mais curta e desaparece ao final da conversa. Modelos de contexto longo apenas ampliam essa janela, mas ainda são temporários por natureza, e cada inferência exige o processamento de toda a janela, o que é caro e lento.
Estado (camada de estado): Dados temporários durante a execução da tarefa atual. Por exemplo, “qual é a tarefa sendo realizada”, “em que etapa já se chegou”, “quais dados foram gerados no meio”. Mais duradouro que a Sessão, mas limpo ao final da tarefa. O livro apresenta um exemplo completo usando o mecanismo de Estado do Google ADK.
Memória (camada de persistência): memória de longo prazo entre sessões e entre tarefas. Preferências do usuário, experiências aprendidas e decisões históricas importantes são armazenadas em bancos de dados ou repositórios vetoriais, com busca semântica. O livro enfatiza um ponto muito importante: a memória não é apenas armazenar, mas também projetar uma estratégia completa sobre “o que armazenar, quando armazenar e como recuperar”. Armazenar demais gera ruído; armazenar muito pouco é insuficiente.
No artigo que escrevi anteriormente sobre o Clawdbot, mencionei "arquivos de estado" e "documentos de workspace", que, em essência, são implementações manuais das camadas State e Memory; o livro estruturou esse conceito.
Cinco suposições, a quinta é a mais absurda
No final do livro, são apresentadas cinco suposições sobre o futuro dos Agentes; as quatro primeiras ainda estão dentro do escopo de inferências razoáveis: Agentes gerais passando de escrever código a gerenciar projetos, descoberta ativa e profundamente personalizada das suas necessidades, inteligência embodiada saindo da tela e entrando no mundo físico, Agentes tornando-se entidades econômicas independentes.
O quinto que me deixou impressionado:变形 Multi-Agent.
Você apenas declara o objetivo, por exemplo: "criar um negócio de e-commerce de café premium". O sistema decide automaticamente: primeiro criar o "Agente de Pesquisa de Mercado" e o "Agente de Marca". Após rodar um ciclo de dados, o sistema julga automaticamente que o Agente de Marca não é mais necessário e o divide em três novos: "Agente de Design de Logo", "Agente de Criação de Site", "Agente de Cadeia de Suprimentos". Se o Agente de Criação de Site se tornar um gargalo, o sistema automaticamente replica três Agentes em paralelo para trabalharem em páginas diferentes. Durante todo o processo, o sistema continua ajustando automaticamente o prompt de cada Agente e reorganizando constantemente a estrutura da equipe.
O livro chama isso de "sistema multiagente orientado por objetivos e autossupervisionado". Ele não está executando o plano que você escreveu, mas gerando seu próprio plano, ajustando-o e reorganizando sua equipe de execução.
Isso me lembra o AutoResearch do Karpathy: escreva um program.md, definindo objetivos, métricas e limites, e inicie. O ser humano está fora do ciclo. Mas este livro vai mais longe: até como montar e reorganizar a equipe de Agentes é deixado para o sistema decidir por si só. O ser humano apenas declara “o que quer”.
Três coisas que você pode fazer imediatamente
Após ler este livro, tenho três ações imediatamente aplicáveis:
Primeiro, adicione um crítico ao seu agente atual. Seja qual for o método que você use — Claude Code, CrewAI ou um framework próprio —, adicione, no final do seu fluxo de trabalho atual, um passo: faça com que outro agente (com um prompt de sistema diferente) revise a saída do passo anterior. Geração de código + revisão de código, redação de artigos + verificação de fatos, elaboração de planos + avaliação de viabilidade. Uma chamada adicional ao LLM, mas a qualidade frequentemente dobra. O modelo Producer-Critic do livro é plug-and-play.
Em segundo lugar, comece a fazer Context Engineering, não apenas Prompt Engineering. Volte e revise o arquivo de instruções que você escreveu para o Agente. Se ele contiver apenas regras do tipo “você deve fazer”, mas faltar o contexto sobre “em que ambiente você está agora”, adicione-o. Informe ao Agente em qual projeto ele está, quais decisões tomou anteriormente e quais são as preferências do usuário. O capítulo sobre Context Engineering no livro e o seu
AGENTS.mdsão duas expressões da mesma coisa.Terceiro, não se apresse em usar Multi-Agent. Torne seu único Agent nível 2: com ferramentas, Reflection e Memory. O livro enfatiza repetidamente que um único Agent de nível 2, combinado com Producer-Critic e Context Engineering, cobre a maioria dos cenários práticos. O nível 3 é destinado a tarefas verdadeiramente interdisciplinares, com múltiplas etapas e que exigem divisão paralela de tarefas. O problema da maioria das pessoas não é ter agentes demais, mas sim não ter ajustado bem nem mesmo um único agente.
Este livro tem 453 páginas, publicado pela Springer em 2025. Os exemplos de código cobrem LangChain/LangGraph, Google ADK, CrewAI e OpenAI API. A introdução foi escrita pelo VP de IA do Google Cloud, e há uma recomendação do CIO da Goldman Sachs — surpreendentemente boa.
Mas a razão pela qual eu o recomendo não é “abrangente”. Ao ler, você perceberá uma coisa: todos os armadilhas que você enfrentou nos últimos seis meses com Agentes já foram organizadas em padrões. Você não precisa mais inventar Reflection, não precisa mais adivinhar como dividir a Memory e não precisa mais testar qual topologia de comunicação usar em Multi-Agent.
Alguém desenhou o mapa para você; o resto é apenas caminhar.
Você está desenvolvendo com um AI Agent? Em qual nível está seu Agent agora?