Auteur : Yanhua
Antonio Gullí est directeur technique chez Google. Il a écrit un livre de 453 pages qui décompose le développement d'agents IA en 21 modèles de conception.
Mais ce n’est pas une critique de livre. Mon motif pour lire ce livre est très spécifique : j’ai écrit Harness Engineering, j’ai partagé mes expériences avec Clawdbot, j’ai rédigé l’article « Les agents IA ne sont pas de la magie », qui décrit les sept étapes passées de la consommation de tokens à une utilisation réellement efficace. À chaque fois que j’ai terminé, une question n’a pas été entièrement élucidée : y a-t-il une logique sous-jacente réutilisable derrière tout cela ?
This book gave me the answers, and deeper than I thought.
Ce que tu as écrit n'est probablement pas du tout un Agent
Le jugement le plus sévère du livre est caché dans le prologue.
La plupart des gens utilisent ce qu’ils appellent « l’IA », mais c’est seulement le niveau 0 : un LLM nu, sans outils, sans mémoire, incapable d’agir. Vous lui demandez quel est le meilleur film aux Oscars 2025, il devine. Le livre le dit clairement : ce qui est au niveau 0 n’est pas un Agent.
Monter est le vrai Agent :
Niveau 1 : Utilisateur d'outils
L'agent commence à utiliser des outils : recherche, API, base de données. Mais il ne s'agit pas seulement de « pouvoir appeler des interfaces » ; il doit également juger lui-même quand appeler, quoi appeler, et comment utiliser les résultats. Le livre donne un exemple très concret : l'utilisateur demande « Quelles sont les nouvelles séries récentes ? » L'agent comprend automatiquement que cette information n'est pas présente dans ses données d'entraînement, et appelle activement l'outil de recherche pour la trouver, puis synthétise le résultat. L'étape cruciale réside dans la « compréhension autonome ». Ce n'est pas l'humain qui lui dit « Va chercher », c'est lui qui décide lui-même qu'une recherche est nécessaire. Cette capacité de jugement constitue la barrière d'entrée du niveau 1.
Niveau 2 : Penseur stratégique
Deux éléments supplémentaires : la planification et l’ingénierie du contexte. Le livre définit l’ingénierie du contexte : il ne s’agit pas d’accumuler des informations, mais de sélectionner, de trancher et d’emballer soigneusement le contexte. L’exemple est excellent : l’utilisateur cherche un café entre deux endroits. L’agent appelle d’abord un outil de carte pour obtenir une quantité de données, puis détermine lui-même que « la prochaine étape ne nécessite que les noms de rues », réduit la sortie de la carte à une courte liste, puis la fournit à un outil de recherche locale. Chaque étape effectue une réduction du bruit informationnel.
Dans le livre, il y a une phrase que j'ai lue plusieurs fois : « Pour que l'IA atteigne la précision maximale, il faut lui fournir un contexte court, ciblé et percutant. » L'ingénierie du contexte consiste précisément à faire cela.
À ce niveau, l'Agent peut encore se réfléchir. Après avoir terminé le travail, il revient dessus lui-même et corrige les problèmes qu'il identifie. J'expliquerai cela plus en détail plus tard.
Niveau 3 : Collaboration entre plusieurs agents
La position du livre est claire : ne cherchez pas à créer un super agent tout-en-un. La méthode la plus fiable consiste à constituer une équipe comme on le ferait avec des humains : un agent chef de projet, un agent chercheur, un agent designer, un agent rédacteur. L'exemple donné dans le livre concerne le lancement d'un nouveau produit : un « agent chef de projet » coordonne l'ensemble et attribue les tâches à l'« agent d'étude de marché », à l'« agent de conception produit » et à l'« agent marketing ». L'élément clé est la communication : comment les agents échangent des données, synchronisent leur état et résolvent les conflits. Ce chapitre présente six structures de communication, allant du simple agent unique à la combinaison personnalisée la plus flexible, avec une explication des scénarios adaptés à chacune.
Après avoir lu ces quatre niveaux, je comprends soudain pourquoi beaucoup disent « mon Agent ne fonctionne pas bien ». Le modèle n’est pas en cause, le problème est que vous l’utilisez comme un chatbot ; il ne atteint peut-être même pas le niveau 1.
Ingénierie du contexte : le concept le plus sous-estimé du livre
J'ai écrit un article sur l'ingénierie des gaines, qui explique que la conception de la piste est plus importante que la puissance du moteur. Après avoir lu ce livre, j'ai réalisé que l'ingénierie du contexte est la correspondance de l'ingénierie des gaines au niveau des invites.
L'ingénierie traditionnelle des invites ne gère que « comment vous posez la question ». L'ingénierie du contexte du livre gère « ce que l'agent a devant les yeux avant de poser la question ». Elle comprend quatre niveaux d'informations :
Première couche, prompt système. Définit qui est l'Agent, quel ton et quelles limites. La plupart des gens n'écrivent que cette couche.
Couche deux, données externes. Documents récupérés par RAG, résultats des appels d'outils, données API en temps réel. C'est ici que la plupart des gens butent : ils savent qu'ils doivent fournir des données, mais ignorent comment le faire sans submerger le modèle.
Couche trois : données implicites. Identité de l'utilisateur, historique des interactions, état de l'environnement. Ce que vous ne dites pas explicitement mais que l'Agent devrait connaître. Par exemple, si vous dites à l'Agent : « Aide-moi à envoyer un e-mail à John pour confirmer la réunion de demain », il devrait savoir quelle est la réunion prévue dans votre calendrier pour demain et quel est votre lien avec John.
Niveau quatre, boucle de rétroaction. Après chaque sortie de l'agent, la qualité est automatiquement évaluée et la stratégie contextuelle pour la prochaine itération est ajustée. Le livre appelle cela « l'optimisation automatique du contexte » ; l'outil Vertex AI Prompt Optimizer de Google en est une réalisation concrète.
En lisant cela, j'ai pensé à mon article précédent intitulé « Les agents IA ne sont pas de la magie », où l'une des leçons était : « Votre agent a besoin de règles, et beaucoup de règles ». En regardant en arrière, ces règles étaient essentiellement la version manuelle de l'ingénierie de contexte, que le livre systématise.
Reflection : Deux agents sont vraiment meilleurs qu'un seul
C'est le modèle le plus utile sur le plan pratique pour moi dans tout le livre.
Le cœur de Reflection est simple : l'Agent revient sur son travail après l'avoir accompli et corrige les problèmes lui-même. Mais la mise en œuvre requiert une attention particulière. Le livre le précise clairement : le Producer et le Critic doivent être deux Agents distincts, dotés de prompts système différents. Un même persona ne peut pas évaluer objectivement son propre travail ; il y aura toujours des aveugles. Si vous demandez au même LLM d'écrire du code, puis de l'examiner, il dira probablement : « C'est bien ».
The book provides a complete code example.
Le prompt du producteur est « Vous êtes un développeur Python, écrivez une fonction pour calculer la factorielle, en gérant les conditions limites et les exceptions ».
Le prompt de Critic est « Vous êtes un ingénieur senior exigeant qui examine ligne par ligne le code, vérifie les bugs, le style, les conditions limites manquantes et les améliorations possibles. Si le code est parfait, affichez
CODE_IS_PERFECT, sinon listez tous les problèmes ».Ensuite, une boucle for : le Producer écrit le code → le Critic l'audit → le Producer le modifie selon les commentaires → le Critic réaudit → jusqu'à ce que le Critic dise
CODE_IS_PERFECTou que le nombre maximal d'itérations soit atteint.
C’est aussi simple que cela. Mais le livre souligne un coût souvent négligé : chaque cycle de réflexion correspond à un nouvel appel à un LLM, et plus il y a d’itérations, plus cela coûte cher. De plus, à mesure que l’historique des échanges s’allonge, la fenêtre de contexte est saturée par les versions antérieures et les critiques, réduisant ainsi l’espace de raisonnement effectivement disponible. La meilleure pratique pour la réflexion est donc de fixer un nombre maximal d’itérations raisonnable (le livre utilise 3), et d’arrêter dès que le critique est satisfait, sans chercher la perfection.
L'utilisation va bien au-delà de l'écriture de code. Écrire des articles, établir des plans, résumer des documents, résoudre des problèmes logiques : le modèle Producer-Critic s'applique à tous. Le livre liste sept scénarios d'utilisation, dont la logique fondamentale est identique : produire d'abord, puis examiner, et enfin corriger.
Multi-Agent n'est pas aussi complexe que possible
Ce que j'aime le plus dans ce chapitre sur la collaboration multi-agent, ce sont les six schémas de topologie de communication. Beaucoup commencent par des solutions complexes, mais en réalité, la plupart des scénarios n'en nécessitent que trois :
Agent unique (exécution indépendante) : la tâche peut être décomposée en sous-problèmes indépendants, chaque Agent gère le sien. Simple et facile à maintenir.
Réseau pair à pair (Peer-to-Peer) : les agents communiquent directement entre eux sans nœud de contrôle centralisé. Décentralisé et résilient, la panne d’un agent n’affecte pas l’ensemble du système. Toutefois, le coût de coordination est élevé et le désordre peut facilement survenir.
Superviseur (ordonnancement central) : un agent superviseur gère un groupe d'agents travailleurs. Il attribue des tâches, collecte les résultats et résout les conflits. La hiérarchie est claire et facile à gérer. Toutefois, le superviseur constitue un point unique de défaillance et un goulot d'étranglement de performance.
Les trois autres (Supervisor-as-Tool, hiérarchique, hybride personnalisé) sont des variantes et combinaisons des trois premiers. Le livre le dit clairement : la topologie dont vous avez besoin dépend de la complexité de votre tâche. Plus vous décomposez la tâche en éléments petits, plus le coût de communication augmente ; à un certain point, le modèle Supervisor devient plus efficace que le modèle hiérarchique.
Mon expérience montre que beaucoup de personnes consacrent 80 % de leur temps à concevoir les protocoles de communication lorsqu’elles construisent un Multi-Agent, tout en oubliant de se poser la question plus fondamentale : ce travail nécessite-t-il vraiment plusieurs agents ? Le livre l’explique clairement : un seul agent de niveau 2 avec Reflection suffit souvent. Le niveau 3 est réservé aux cas où un seul agent ne peut effectivement pas accomplir la tâche.
Le modèle en trois couches de Memory, j'avais vaguement ressenti cela auparavant mais je ne l'avais pas nommé
Le chapitre Memory est celui avec lequel j'ai le plus d'affinité, car en écrivant mes deux articles sur Obsidian + Claude, je me posais constamment la question : comment hiérarchiser la mémoire d'un Agent ?
La réponse est donnée dans le livre :
Couche de session : fenêtre de contexte de la conversation actuelle, il s'agit de la mémoire la plus courte, qui disparaît à la fin de la conversation. Les modèles à long contexte n'agrandissent simplement cette fenêtre, mais restent fondamentalement temporaires, et chaque inférence doit traiter l'ensemble de la fenêtre, ce qui est coûteux et lent.
État (couche d'état) : Données temporaires pendant l'exécution de la tâche actuelle. Par exemple : « Quelle tâche est en cours ? », « À quel stade en est-on ? », « Quelles données intermédiaires ont été générées ? ». Plus durable qu'une session, mais nettoyé à la fin de la tâche. Le livre présente un exemple complet en utilisant le mécanisme d'état de Google ADK.
Mémoire (couche persistante) : mémoire à long terme persistante entre les sessions et les tâches. Les préférences utilisateur, les expériences acquises et les décisions historiques importantes sont stockées dans une base de données ou une bibliothèque vectorielle, avec une recherche sémantique. Le livre souligne un point crucial : la mémoire ne se limite pas à être stockée, elle doit également inclure une stratégie complète pour décider « quoi stocker, quand le stocker et comment le rechercher ». Trop de données introduisent du bruit, trop peu rendent le système inutilisable.
Dans l'article que j'ai écrit sur Clawdbot, j'ai mentionné les « fichiers d'état » et les « documents de travail » ; en réalité, je mettais en œuvre manuellement les couches State et Memory, et le livre structure ce processus.
Cinq hypothèses, la cinquième est la plus absurde
À la fin du livre, cinq hypothèses sur l'avenir des agents sont présentées ; les quatre premières restent dans les limites d'une déduction raisonnable : un agent généraliste passant de l'écriture de code à la gestion de projets, une découverte proactive et hautement personnalisée de vos besoins, une intelligence incarnée sortant de l'écran pour entrer dans le monde physique, un agent devenant une entité économique indépendante.
Le cinquième m’a stupéfié : Multi-Agent变形.
Vous définissez uniquement l'objectif, par exemple « créer une entreprise de commerce électronique de café de qualité ». Le système décide automatiquement de créer d'abord l'« Agent d'étude de marché » et l'« Agent de marque ». Après une boucle de données, il détermine automatiquement que l'« Agent de marque » n'est plus nécessaire et le décompose en trois nouveaux agents : « Agent de conception de logo », « Agent de création de site web », « Agent de chaîne d'approvisionnement ». Si l'« Agent de création de site web » devient un goulot d'étranglement, le système copie automatiquement trois agents parallèles pour travailler simultanément sur différentes pages. Tout au long du processus, le système optimise en continu les invites de chaque agent et restructure constamment l'architecture de l'équipe.
Le livre appelle cela un « système multi-agent ciblé et auto-transformant ». Il ne se contente pas d'exécuter le plan que vous avez écrit ; il génère lui-même son plan, l'ajuste et réorganise son équipe d'exécution.
Cela me rappelle AutoResearch de Karpathy : écrivez un program.md, définissez les objectifs, les indicateurs, les limites, puis lancez. L'humain est en dehors du cycle. Mais ce livre pousse plus loin : même la manière dont l'équipe d'agents est constituée ou restructurée est laissée à la discrétion du système. L'humain ne fait que déclarer « ce qu'il veut ».
Trois choses que vous pouvez faire immédiatement
Après avoir lu ce livre, j'ai trois actions immédiatement applicables :
Premièrement, ajoutez un critique à votre agent actuel. Que vous utilisiez Claude Code, CrewAI ou un cadre que vous avez développé vous-même, ajoutez une étape à la fin de votre workflow actuel : faites examiner la sortie de l'étape précédente par un autre agent (avec un prompt système différent). Génération de code + revue de code, rédaction d'article + vérification des faits, élaboration de plan + évaluation de faisabilité. Une appel LLM supplémentaire, mais la qualité augmente souvent de façon double. Le modèle Producer-Critic du livre est plug-and-play.
Deuxièmement, commencez à faire de l’ingénierie de contexte, et non seulement de l’ingénierie de prompts. Revenez sur le fichier d’instructions que vous avez écrit pour l’agent. Si celui-ci ne contient que des règles du type « Que devez-vous faire ? » sans contexte sur « Dans quel environnement vous trouvez-vous actuellement ? », complétez-le. Indiquez à l’agent dans quel projet il se trouve, quelles décisions il a prises précédemment et quels sont les préférences de l’utilisateur. Le chapitre sur l’ingénierie de contexte dans le livre et votre
AGENTS.mdexpriment la même chose de deux manières différentes.Troisièmement, ne passez pas tout de suite au Multi-Agent. Améliorez votre Agent unique jusqu’au niveau 2 : avec des outils, une réflexion et une mémoire. Le livre insiste à plusieurs reprises sur le fait qu’un Agent de niveau 2 combiné à Producer-Critic et à l’ingénierie du contexte couvre la majorité des scénarios réels. Le niveau 3 est réservé aux tâches véritablement interdisciplinaires, en plusieurs étapes et nécessitant une répartition parallèle des rôles. Le problème de la plupart des gens n’est pas qu’ils n’ont pas assez d’Agents, c’est qu’ils n’ont pas bien réglé un seul Agent.
Ce livre compte 453 pages, publié par Springer en 2025. Les exemples de code couvrent LangChain/LangGraph, Google ADK, CrewAI et OpenAI API. La préface est écrite par le VP d'IA de Google Cloud, et une préface de recommandation est fournie par le CIO de Goldman Sachs, étonnamment bien écrite.
Mais la raison pour laquelle je le recommande n’est pas « complet ». Après l’avoir lu, vous réaliserez une chose : toutes les erreurs que vous avez faites sur les Agents au cours des six derniers mois ont déjà été regroupées en modèles. Vous n’avez plus besoin d’inventer le Reflection, de deviner comment hiérarchiser la Memory, ou d’essayer quelles topologies de communication utiliser pour les Multi-Agent.
Quelqu'un a tracé la carte pour toi, il ne reste plus qu'à marcher.
Utilises-tu un AI Agent pour le développement ? À quel niveau est ton Agent actuellement ?