Ce document vous aide à choisir un modèle de conception pour votre système d'IA agentive. Les modèles de conception d'agents sont des approches architecturales courantes pour créer des applications agentiques. Un modèle de conception d'agent offre un framework distinct pour organiser les composants d'un système, intégrer le modèle et orchestrer un ou plusieurs agents pour accomplir un workflow.
Les agents IA sont efficaces pour les applications qui résolvent des problèmes ouverts, qui peuvent nécessiter une prise de décision autonome et une gestion de workflows complexes en plusieurs étapes. Les agents sont particulièrement efficaces pour résoudre des problèmes en temps réel à l'aide de données externes et pour automatiser des tâches nécessitant de nombreuses connaissances. Les agents IA sont adaptés lorsque vous avez besoin de l'IA pour effectuer des tâches axées sur des objectifs avec un certain degré d'autonomie. Pour d'autres cas d'utilisation, vous pouvez utiliser des applications d'IA d'assistance et d'IA générative. Pour en savoir plus sur les différences entre les agents d'IA et les applications d'IA sans agent, consultez Quelle est la différence entre les agents d'IA, les assistants d'IA et les bots ?
Ce guide part du principe que vous possédez des connaissances de base sur les systèmes d'IA agentique et sur la différence entre leur architecture et celle des systèmes non agentiques, tels que ceux qui utilisent le raisonnement de modèle direct ou la génération augmentée par récupération (RAG).
Pour un résumé des conseils sur les modèles d'agent, consultez la section Comparer les modèles de conception plus loin dans ce document.
Présentation du processus de conception
Voici les principales étapes à suivre pour choisir un modèle de conception pour votre système d'IA agentive. Ces étapes sont décrites en détail plus loin dans ce document.
- Définissez vos exigences : évaluez les caractéristiques de votre charge de travail, y compris la complexité des tâches, les attentes en termes de latence et de performances, le budget et la nécessité d'une intervention humaine.
- Consultez les modèles de conception d'agent courants : découvrez les modèles de conception courants dans ce guide, qui incluent à la fois les systèmes à agent unique et les systèmes multi-agents.
- Sélectionnez un modèle : Sélectionnez le modèle de conception approprié en fonction des caractéristiques de votre charge de travail.
Ce processus n'est pas une décision ponctuelle. Vous devez régulièrement revoir ces étapes pour affiner votre architecture à mesure que les caractéristiques de votre charge de travail changent, que vos exigences évoluent ou que de nouvelles fonctionnalités Google Cloud deviennent disponibles.
Définir vos exigences
Les questions qui suivent ne sont pas des checklists exhaustives pour la planification. Utilisez ces questions comme point de départ pour identifier l'objectif principal de votre système agentif et sélectionner le meilleur modèle de conception.
- Caractéristiques de la tâche : votre tâche peut-elle être effectuée en suivant des étapes de workflow prédéfinies ou est-elle ouverte ? Votre tâche doit-elle utiliser un modèle d'IA pour orchestrer le workflow ?
- Latence et performances : devez-vous privilégier les réponses rapides ou interactives au détriment de l'exactitude ou de la qualité des réponses ? Votre application peut-elle tolérer un délai pour obtenir un résultat plus précis ou plus complet ?
- Coût : quel est votre budget pour les coûts d'inférence ? Pouvez-vous prendre en charge des modèles qui nécessitent plusieurs appels au modèle pour une seule requête ?
- Implication humaine : votre tâche implique-t-elle des décisions à enjeux élevés, des opérations critiques pour la sécurité ou des approbations subjectives qui nécessitent un jugement humain ?
Si votre charge de travail est prévisible ou hautement structurée, ou si elle peut être exécutée avec un seul appel à un modèle d'IA, il peut être plus rentable d'explorer des solutions non agentiques pour votre tâche. Par exemple, vous n'aurez peut-être pas besoin d'un workflow agentique pour des tâches telles que résumer un document, traduire du texte ou classer les commentaires des clients. Pour savoir comment choisir les composants d'architecture pour les applications d'IA générative qui ne nécessitent pas d'infrastructure agentive, consultez Choisir des modèles et une infrastructure pour votre application d'IA générative.
Les sections suivantes décrivent les modèles de conception d'agents courants pour créer un système d'IA agentive fiable et efficace.
Système à agent unique
Un système mono-agent utilise un modèle d'IA, un ensemble défini d'outils et un prompt système complet pour traiter de manière autonome une demande utilisateur ou effectuer une tâche spécifique. Dans ce modèle fondamental, l'agent s'appuie sur les capacités de raisonnement du modèle pour interpréter la requête d'un utilisateur, planifier une séquence d'étapes et décider des outils à utiliser parmi un ensemble défini. Le prompt système façonne le comportement de l'agent en définissant sa tâche principale, son persona et ses opérations, ainsi que les conditions spécifiques d'utilisation de chaque outil.
Le diagramme suivant présente une vue d'ensemble d'un modèle à agent unique :
Un système à agent unique est idéal pour les tâches qui nécessitent plusieurs étapes et l'accès à des données externes. Par exemple, un agent du service client doit interroger une base de données pour trouver l'état d'une commande, ou un assistant de recherche doit appeler des API pour résumer les actualités récentes. Un système non agentique ne peut pas effectuer ces tâches, car il ne peut pas utiliser d'outils de manière autonome ni exécuter un plan en plusieurs étapes pour synthétiser une réponse finale.
Si vous débutez dans le développement d'agents, nous vous recommandons de commencer avec un seul agent. Lorsque vous commencez à développer votre agent avec un système mono-agent, vous pouvez vous concentrer sur l'affinage de la logique de base, du prompt et des définitions d'outils de votre agent avant d'ajouter des composants architecturaux plus complexes.
Les performances d'un seul agent peuvent être moins efficaces lorsqu'il utilise plus d'outils et que la complexité des tâches augmente. Cela peut se traduire par une latence accrue, une sélection ou une utilisation incorrecte des outils, ou l'impossibilité d'effectuer la tâche. Vous pouvez souvent atténuer ces problèmes en affinant le processus de raisonnement de l'agent à l'aide de techniques telles que le modèle ReAct (Reason and Act). Toutefois, si votre workflow exige qu'un agent gère plusieurs responsabilités distinctes, ces techniques peuvent ne pas suffire. Dans ce cas, envisagez un système multi-agent, qui peut améliorer la résilience et les performances en déléguant des compétences spécifiques à des agents spécialisés.
Systèmes multi-agents
Un système multi-agents orchestre plusieurs agents spécialisés pour résoudre un problème complexe qu'un seul agent ne peut pas gérer facilement. Le principe de base consiste à décomposer un objectif important en sous-tâches plus petites et à attribuer chaque sous-tâche à un agent dédié possédant une compétence spécifique. Ces agents interagissent ensuite via des workflows collaboratifs ou hiérarchiques pour atteindre l'objectif final. Les modèles multi-agents offrent une conception modulaire qui peut améliorer l'évolutivité, la fiabilité et la facilité de maintenance du système global par rapport à un agent unique avec un prompt monolithique.
Dans un système multi-agents, chaque agent a besoin d'un contexte spécifique pour effectuer sa tâche efficacement. Le contexte peut inclure de la documentation, des préférences historiques, des liens pertinents, l'historique des conversations ou des contraintes opérationnelles. Le processus de gestion de ce flux d'informations est appelé context engineering. L'ingénierie de contexte inclut des stratégies telles que l'isolation du contexte pour un agent spécifique, la persistance des informations sur plusieurs étapes ou la compression de grandes quantités de données pour améliorer l'efficacité.
Les agents IA introduisent des risques de sécurité uniques et critiques que les pratiques de sécurité déterministes conventionnelles ne sont peut-être pas en mesure d'atténuer de manière adéquate. Utilisez Agent Gateway pour le routage et la sécurité du trafic entrant et sortant, Agent Identity pour l'authentification liée à la charge de travail et le contrôle des accès avec le minimum de privilèges, et Agent Registry pour vous assurer que des outils et sous-agents vérifiés sont utilisés.
Les conseils de cette section ne sont pas exhaustifs. Pour en savoir plus sur les facteurs de conception et les bonnes pratiques, et pour obtenir des recommandations sur la création et le déploiement d'un système d'IA multi-agent, consultez Système d'IA multi-agent dans Google Cloud.
Modèle séquentiel
Le modèle séquentiel multi-agents exécute une série d'agents spécialisés dans un ordre linéaire prédéfini, où la sortie d'un agent sert d'entrée directe à l'agent suivant. Ce modèle utilise un agent de workflow séquentiel qui fonctionne selon une logique prédéfinie sans avoir à consulter un modèle d'IA pour l'orchestration de ses sous-agents.
Le diagramme suivant présente une vue d'ensemble d'un modèle séquentiel multi-agents :
Utilisez le modèle séquentiel pour les processus hautement structurés et reproductibles où la séquence d'opérations ne change pas. Par exemple, un pipeline de traitement des données peut utiliser ce modèle pour qu'un agent d'extraction de données récupère d'abord les données brutes, puis les transmette à un agent de nettoyage des données pour les formater, qui à son tour transmet les données nettoyées à un agent de chargement des données pour les enregistrer dans une base de données.
Le modèle séquentiel peut réduire la latence et les coûts opérationnels par rapport à un modèle qui utilise un modèle d'IA pour orchestrer le workflow des tâches. Toutefois, cette efficacité se fait au détriment de la flexibilité. La structure rigide et prédéfinie du pipeline rend difficile l'adaptation aux conditions dynamiques ou l'omission d'étapes inutiles, ce qui peut entraîner un traitement inefficace ou une latence cumulée plus élevée si une étape inutile est lente.
Schéma parallèle
Le modèle parallèle multi-agent, également appelé modèle simultané, permet à plusieurs sous-agents spécialisés d'effectuer une tâche ou des sous-tâches indépendamment et en même temps. Les résultats des sous-agents sont ensuite synthétisés pour produire la réponse consolidée finale. Comme pour un modèle séquentiel, le modèle parallèle utilise un agent de workflow parallèle pour gérer comment et quand les autres agents s'exécutent sans avoir à consulter un modèle d'IA pour orchestrer ses sous-agents.
Le diagramme suivant présente une vue d'ensemble d'un modèle parallèle multi-agents :
Utilisez le modèle parallèle lorsque des sous-tâches peuvent être exécutées simultanément pour réduire la latence ou recueillir différents points de vue, par exemple pour collecter des données à partir de sources disparates ou évaluer plusieurs options à la fois. Par exemple, pour analyser les commentaires des clients, un agent parallèle peut distribuer une seule entrée de commentaire à quatre agents spécialisés en même temps : un agent d'analyse des sentiments, un agent d'extraction de mots clés, un agent de catégorisation et un agent de détection de l'urgence. Un agent final rassemble ces quatre résultats dans une analyse unique et complète de ces commentaires.
Le modèle parallèle peut réduire la latence globale par rapport à une approche séquentielle, car il peut collecter des informations diverses provenant de plusieurs sources en même temps. Toutefois, cette approche présente des inconvénients en termes de coût et de complexité. L'exécution de plusieurs agents en parallèle peut augmenter l'utilisation immédiate des ressources et la consommation de jetons, ce qui entraîne des coûts opérationnels plus élevés. De plus, l'étape de collecte nécessite une logique complexe pour synthétiser des résultats potentiellement conflictuels, ce qui augmente les frais généraux de développement et de maintenance du système.
Motif en boucle
Le modèle d'agent en boucle multi-agent exécute de manière répétée une séquence de sous-agents spécialisés jusqu'à ce qu'une condition d'arrêt spécifique soit remplie. Ce modèle utilise un agent de workflow en boucle qui, comme les autres agents de workflow, fonctionne selon une logique prédéfinie sans consulter de modèle d'IA pour l'orchestration. Une fois que tous les sous-agents ont terminé leurs tâches, l'agent de boucle évalue si une condition de sortie est remplie. La condition peut être un nombre maximal d'itérations ou un état personnalisé. Si la condition de sortie n'est pas remplie, l'agent de boucle relance la séquence de sous-agents. Vous pouvez implémenter un modèle de boucle dans lequel la condition de sortie est évaluée à tout moment du flux. Utilisez le modèle de boucle pour les tâches qui nécessitent un affinement itératif ou une autocorrection, comme la génération de contenu et l'examen par un agent critique jusqu'à ce qu'il réponde à une norme de qualité.
Le diagramme suivant présente une vue d'ensemble d'un modèle de boucle multi-agents :
Le modèle d'agent en boucle permet de créer des workflows complexes et itératifs. Il permet aux agents d'affiner leur propre travail et de continuer à traiter les données jusqu'à ce qu'une qualité ou un état spécifique soit atteint. Toutefois, le principal inconvénient de ce modèle est le risque de boucle infinie. Si la condition d'arrêt n'est pas correctement définie ou si les sous-agents ne parviennent pas à produire l'état requis pour l'arrêt, la boucle peut s'exécuter indéfiniment. Cela peut entraîner des coûts opérationnels excessifs, une consommation élevée de ressources et des blocages potentiels du système.
Examiner et critiquer le modèle
Le modèle d'examen et de critique multi-agent, également appelé modèle de générateur et de critique, améliore la qualité et la fiabilité du contenu généré en utilisant deux agents spécialisés, généralement dans un workflow séquentiel. Le modèle d'examen et de critique est une implémentation du modèle d'agent de boucle.
Dans le modèle d'examen et de critique, un agent générateur crée une sortie initiale, telle qu'un bloc de code ou un résumé d'un document. Ensuite, un agent critique évalue ce résultat par rapport à un ensemble de critères prédéfinis, tels que l'exactitude factuelle, le respect des règles de mise en forme ou les consignes de sécurité. En fonction de l'évaluation, le critique peut approuver le contenu, le refuser ou le renvoyer au générateur avec des commentaires pour révision.
Le diagramme suivant présente une vue d'ensemble d'un modèle d'examen et de critique multi-agents :
Ce modèle est adapté aux tâches pour lesquelles les résultats doivent être très précis ou respecter des contraintes strictes avant d'être présentés à un utilisateur ou utilisés dans un processus en aval. Par exemple, dans un workflow de génération de code, un agent générateur peut écrire une fonction pour répondre à la requête d'un utilisateur. Ce code généré est ensuite transmis à un agent critique qui agit en tant qu'auditeur de sécurité. L'agent critique a pour tâche de vérifier le code par rapport à un ensemble de contraintes, par exemple en recherchant les failles de sécurité ou en vérifiant qu'il passe tous les tests unitaires, avant que le code ne soit approuvé pour utilisation.
Le modèle de réviseur et de critique peut améliorer la qualité, la précision et la fiabilité des résultats, car il ajoute une étape de vérification dédiée. Toutefois, cette assurance qualité a un coût direct : une augmentation de la latence et des dépenses opérationnelles. Le workflow nécessite au moins un appel de modèle supplémentaire pour l'évaluation du critique. Si le processus inclut des boucles de révision où le contenu est renvoyé pour être affiné, la latence et les coûts s'accumulent à chaque itération.
Modèle d'affinage itératif
Le modèle d'affinement itératif utilise un mécanisme de boucle pour améliorer progressivement un résultat sur plusieurs cycles. Le modèle d'affinement itératif est une implémentation du modèle d'agent en boucle.
Dans ce modèle, un ou plusieurs agents travaillent dans une boucle pour modifier un résultat stocké dans l'état de la session à chaque itération. Le processus se poursuit jusqu'à ce que le résultat atteigne un seuil de qualité prédéfini ou un nombre maximal d'itérations, ce qui évite les boucles infinies.
Le diagramme suivant présente une vue d'ensemble d'un modèle d'affinage itératif multi-agents :
Ce modèle est adapté aux tâches de génération complexes pour lesquelles le résultat est difficile à obtenir en une seule étape. Par exemple, écrire et déboguer un morceau de code, élaborer un plan détaillé en plusieurs parties, ou rédiger et réviser un document long. Par exemple, dans un workflow d'écriture créative, un agent peut générer un brouillon d'article de blog, critiquer le brouillon pour en améliorer la fluidité et le ton, puis réécrire le brouillon en fonction de cette critique. Ce processus se répète en boucle jusqu'à ce que le travail de l'agent réponde à une norme de qualité prédéfinie ou jusqu'à ce que la répétition atteigne un nombre maximal d'itérations.
Le modèle d'affinement itératif peut produire des résultats très complexes ou soignés qui seraient difficiles à obtenir en une seule étape. Toutefois, le mécanisme de boucle augmente directement la latence et les coûts opérationnels à chaque cycle. Ce modèle ajoute également une complexité architecturale, car il nécessite des conditions de sortie soigneusement conçues (par exemple, une évaluation de la qualité ou une limite d'itération maximale) pour éviter des coûts excessifs ou une exécution non contrôlée.
Modèle de coordinateur
Le modèle de coordinateur multi-agent utilise un agent central, le coordinateur, pour diriger un workflow. Le coordinateur analyse et décompose la requête d'un utilisateur en sous-tâches, puis il distribue chaque sous-tâche à un agent spécialisé pour exécution. Chaque agent spécialisé est un expert dans une fonction spécifique, comme l'interrogation d'une base de données ou l'appel d'une API.
Le modèle de coordinateur se distingue par son utilisation d'un modèle d'IA pour orchestrer et router dynamiquement les tâches. En revanche, le modèle parallèle s'appuie sur un workflow codé en dur pour distribuer les tâches en vue d'une exécution simultanée, sans avoir besoin d'orchestration de modèle d'IA.
Le diagramme suivant présente une vue d'ensemble d'un modèle de coordinateur multi-agent :
Utilisez le modèle de coordinateur pour automatiser les processus métier structurés qui nécessitent un routage adaptatif. Par exemple, un agent du service client peut agir en tant que coordinateur. L'agent coordinateur analyse la requête pour déterminer s'il s'agit d'une demande d'état de la commande, d'un retour de produit ou d'une demande de remboursement. En fonction du type de requête, le coordinateur achemine la tâche vers l'agent spécialisé approprié.
Le modèle de coordinateur offre une flexibilité par rapport aux workflows prédéfinis plus rigides. En utilisant un modèle pour acheminer les tâches, le coordinateur peut gérer une plus grande variété d'entrées et adapter le workflow au moment de l'exécution. Toutefois, cette approche présente également des inconvénients. Étant donné que le coordinateur et chaque agent spécialisé s'appuient sur un modèle pour le raisonnement, ce modèle entraîne plus d'appels de modèle qu'un système à agent unique. Bien que le modèle de coordinateur puisse améliorer la qualité du raisonnement, il augmente également le débit de jetons, les coûts opérationnels et la latence globale par rapport à un système à agent unique.
Modèle de décomposition hiérarchique des tâches
Le modèle de décomposition hiérarchique des tâches multi-agents organise les agents dans une hiérarchie à plusieurs niveaux pour résoudre des problèmes complexes qui nécessitent une planification approfondie. Le modèle de décomposition hiérarchique des tâches est une implémentation du modèle de coordinateur. Un agent parent de premier niveau, ou racine, reçoit une tâche complexe et est chargé de la décomposer en plusieurs sous-tâches plus petites et gérables. L'agent racine délègue chaque sous-tâche à un sous-agent spécialisé d'un niveau inférieur. Ce processus peut se répéter sur plusieurs niveaux, avec des agents qui décomposent progressivement les tâches qui leur sont attribuées jusqu'à ce qu'elles puissent être exécutées directement par un agent de nœud de calcul au niveau le plus bas.
Le diagramme suivant présente une vue d'ensemble d'un modèle de décomposition hiérarchique des tâches multi-agents :
Utilisez le modèle de décomposition hiérarchique des tâches pour les problèmes ambigus et ouverts qui nécessitent un raisonnement en plusieurs étapes, comme les tâches impliquant de la recherche, de la planification et de la synthèse. Par exemple, pour mener à bien un projet de recherche complexe, un agent coordinateur décompose l'objectif de haut niveau en plusieurs tâches, comme la collecte d'informations, l'analyse des résultats et la synthèse du rapport final. L'agent coordinateur délègue ensuite ces tâches à des sous-agents spécialisés, tels qu'un agent de collecte de données, un agent d'analyse et un agent de rédaction de rapports, pour qu'ils les exécutent ou les décomposent davantage.
Le modèle de décomposition hiérarchique des tâches est idéal pour résoudre des problèmes très complexes et ambigus, car il les décompose systématiquement en sous-tâches gérables. Ce modèle peut donner des résultats plus complets et de meilleure qualité que les modèles plus simples. Toutefois, cette fonctionnalité avancée présente des inconvénients importants. La structure à plusieurs niveaux ajoute une complexité architecturale considérable, ce qui rend le système plus difficile à concevoir, à déboguer et à entretenir. Les multiples couches de délégation et de raisonnement entraînent également un nombre élevé d'appels de modèle, ce qui augmente considérablement la latence globale et les coûts opérationnels par rapport aux autres modèles.
Motif d'essaim
Le modèle d'essaim multi-agent utilise une approche de communication collaborative de type "tous vers tous". Dans ce modèle, plusieurs agents spécialisés collaborent pour affiner de manière itérative une solution à un problème complexe.
Le diagramme suivant présente une vue d'ensemble d'un modèle d'essaim multi-agent :
Le modèle de nuée utilise un agent répartiteur pour acheminer une requête utilisateur vers un groupe collaboratif d'agents spécialisés. L'agent répartiteur interprète la requête et détermine quel agent du groupe est le mieux adapté pour commencer la tâche. Dans ce modèle, chaque agent peut communiquer avec tous les autres agents, ce qui leur permet de partager des résultats, de critiquer des propositions et de s'appuyer sur le travail des autres pour affiner une solution de manière itérative. Tout agent du swarm peut transmettre la tâche à un autre agent qu'il juge plus apte à gérer la prochaine étape, ou il peut communiquer la réponse finale à l'utilisateur par l'intermédiaire de l'agent coordinateur.
Un essaim ne dispose généralement pas d'un agent superviseur ou coordinateur central pour maintenir le processus sur la bonne voie. L'agent de répartition n'orchestre pas le workflow agentique, contrairement au modèle de coordinateur. À la place, l'agent de répartition facilite la communication entre les sous-agents de l'essaim et l'utilisateur. Pour vous assurer que l'essaim s'arrête et renvoie un résultat, vous devez définir une condition de sortie explicite. Cette condition est souvent un nombre maximal d'itérations, une limite de temps ou l'atteinte d'un objectif spécifique, comme l'obtention d'un consensus.
Utilisez le modèle en essaim pour les problèmes ambigus ou très complexes qui bénéficient d'un débat et d'un affinement itératif. Par exemple, la conception d'un nouveau produit peut impliquer un agent d'étude de marché, un agent d'ingénierie et un agent de modélisation financière. Les agents partageraient leurs premières idées, débattraient des compromis entre fonctionnalités et coûts, et convergeraient collectivement vers une spécification de conception finale qui équilibre toutes les exigences concurrentes.
Le modèle en essaim simule une équipe collaborative d'experts. Il peut donc produire des solutions créatives et de très haute qualité. Cependant, il s'agit du modèle multi-agent le plus complexe et le plus coûteux à mettre en œuvre. L'absence d'un agent qui utilise un modèle d'IA pour orchestrer peut entraîner des boucles improductives ou l'incapacité à trouver une solution. Vous devez donc concevoir une logique sophistiquée pour gérer la communication complexe entre les agents, contrôler le workflow itératif et gérer les coûts opérationnels et la latence importants associés à l'exécution d'une conversation dynamique multitours entre plusieurs agents.
Modèle ReAct (Reason and Act, raisonner et agir)
Le modèle ReAct est une approche qui utilise le modèle d'IA pour formuler ses processus de réflexion et ses actions sous la forme d'une séquence d'interactions en langage naturel. Dans ce modèle, l'agent fonctionne dans une boucle itérative de réflexion, d'action et d'observation jusqu'à ce qu'une condition de sortie soit remplie.
- Réflexion : le modèle réfléchit à la tâche et décide de ce qu'il doit faire ensuite. Le modèle évalue toutes les informations qu'il a recueillies afin de déterminer si la requête de l'utilisateur a été entièrement traitée.
- Action : en fonction de son processus de réflexion, le modèle effectue l'une des deux actions suivantes :
- Si la tâche n'est pas terminée, il sélectionne un outil, puis formule une requête pour recueillir plus d'informations.
- Si la tâche est terminée, il formule la réponse finale à envoyer à l'utilisateur, ce qui met fin à la boucle.
- Observation : le modèle reçoit la sortie de l'outil et enregistre les informations pertinentes dans sa mémoire. Comme le modèle enregistre les résultats pertinents, il peut s'appuyer sur les observations précédentes, ce qui l'empêche de se répéter ou de perdre le contexte.
La boucle itérative se termine lorsque l'agent trouve une réponse concluante, atteint un nombre maximal prédéfini d'itérations ou rencontre une erreur qui l'empêche de continuer. Cette boucle itérative permet à l'agent d'élaborer un plan de manière dynamique, de collecter des preuves et d'ajuster son approche à mesure qu'il progresse vers une réponse finale.
Le diagramme suivant présente une vue d'ensemble du modèle ReAct :
Utilisez le modèle ReAct pour les tâches complexes et dynamiques qui nécessitent une planification et une adaptation continues. Par exemple, prenons l'exemple d'un agent robotique qui doit générer un chemin pour passer d'un état initial à un état cible :
- Réflexion : le modèle réfléchit au chemin optimal pour passer de son état actuel à l'état cible. Au cours du processus de réflexion, le modèle optimise les métriques telles que le temps ou l'énergie.
- Action : le modèle exécute l'étape suivante de son plan en se déplaçant le long d'un segment de chemin calculé.
- Observation : le modèle observe et enregistre le nouvel état de l'environnement. Le modèle enregistre sa nouvelle position et toutes les modifications qu'il perçoit dans l'environnement.
Cette boucle permet à l'agent de respecter les contraintes dynamiques, comme éviter de nouveaux obstacles ou suivre le code de la route, en mettant constamment à jour son plan en fonction de nouvelles observations. L'agent poursuit sa boucle itérative jusqu'à ce qu'il atteigne son objectif ou rencontre une erreur.
Un seul agent ReAct peut être plus simple et plus économique à implémenter et à gérer qu'un système multi-agent complexe. La réflexion du modèle fournit une transcription du raisonnement du modèle, ce qui facilite le débogage. Cependant, cette flexibilité implique des compromis. La nature itérative et à plusieurs étapes de la boucle peut entraîner une latence de bout en bout plus élevée qu'une requête unique. De plus, l'efficacité de l'agent dépend fortement de la qualité du raisonnement du modèle d'IA. Par conséquent, une erreur ou un résultat trompeur d'un outil lors d'une étape d'observation peut se propager et entraîner une réponse finale incorrecte.
Modèle human-in-the-loop
Le modèle human-in-the-loop intègre des points d'intervention humaine directement dans le workflow d'un agent. À un point de contrôle prédéfini, l'agent interrompt son exécution et appelle un système externe pour attendre qu'une personne examine son travail. Ce modèle permet à une personne d'approuver une décision, de corriger une erreur ou de fournir les informations nécessaires avant que l'agent puisse continuer.
Le diagramme suivant présente une vue d'ensemble d'un modèle avec intervention humaine :
Utilisez le modèle human-in-the-loop (avec intervention humaine) pour les tâches qui nécessitent une supervision humaine, un jugement subjectif ou une approbation finale pour les actions critiques. Ces actions incluent l'approbation d'une transaction financière importante, la validation du résumé d'un document sensible ou la fourniture de commentaires subjectifs sur un contenu créatif généré. Par exemple, un agent peut être chargé d'anonymiser un ensemble de données de patients à des fins de recherche. L'agent identifierait et masquerait automatiquement toutes les données de santé protégées, mais s'arrêterait à un point de contrôle final. Il attendrait ensuite qu'un responsable de la conformité valide manuellement l'ensemble de données et approuve sa publication, ce qui permet de s'assurer qu'aucune donnée sensible n'est exposée.
Le modèle human-in-the-loop améliore la sécurité et la fiabilité en insérant le jugement humain dans les points de décision critiques du workflow. Ce modèle peut ajouter une complexité architecturale importante, car il vous oblige à créer et à gérer le système externe pour l'interaction utilisateur.
Modèle de logique personnalisée
Le modèle de logique personnalisée offre une flexibilité maximale dans la conception de votre workflow. Cette approche vous permet d'implémenter une logique d'orchestration spécifique qui utilise du code, comme des instructions conditionnelles, pour créer des workflows complexes avec plusieurs chemins de branchement.
Le schéma suivant illustre un exemple d'utilisation d'un modèle de logique personnalisée pour capturer un processus de remboursement :
Dans le diagramme précédent, voici le workflow agentique pour l'exemple d'agent de remboursement client :
- L'utilisateur envoie une requête à l'agent de remboursement client, qui agit en tant qu'agent coordinateur.
- La logique personnalisée du coordinateur invoque d'abord un agent de validation parallèle, qui distribue simultanément deux sous-agents : l'agent de validation de l'acheteur et l'agent d'éligibilité au remboursement.
- Une fois les résultats recueillis, l'agent coordinateur exécute un outil pour vérifier si la demande est éligible à un remboursement.
- Si l'utilisateur est éligible, le coordinateur transmet la tâche à un agent de traitement des remboursements, qui appelle l'outil
process_refund. - Si l'utilisateur n'est pas éligible, le coordinateur transfère la tâche vers un flux séquentiel distinct, en commençant par l'agent de crédit en magasin et l'agent de décision de crédit de traitement.
- Si l'utilisateur est éligible, le coordinateur transmet la tâche à un agent de traitement des remboursements, qui appelle l'outil
- Le résultat du chemin emprunté est envoyé à l'agent de réponse finale pour qu'il formule la réponse à l'utilisateur.
L'exemple d'agent de remboursement client nécessite une solution unique pour son orchestration au niveau logique, qui va au-delà des approches structurées proposées par d'autres modèles. Ce workflow mélange les modèles, car il exécute une vérification parallèle, puis une branche conditionnelle personnalisée qui redirige vers deux processus en aval complètement différents. Ce type de workflow complexe à modèle mixte est le cas d'utilisation idéal pour le modèle de logique personnalisée.
Utilisez le modèle de logique personnalisée lorsque vous avez besoin d'un contrôle précis sur l'exécution de l'agent ou lorsque votre workflow ne correspond à aucun des autres modèles décrits dans ce document. Toutefois, cette approche augmente la complexité du développement et de la maintenance. Vous êtes responsable de la conception, de l'implémentation et du débogage de l'ensemble du flux d'orchestration, ce qui nécessite plus d'efforts de développement et peut être plus sujet aux erreurs que l'utilisation d'un modèle prédéfini compatible avec un outil tel que Agent Development Kit (ADK).
Pour en savoir plus sur les agents personnalisés et sur la façon d'implémenter une logique personnalisée à l'aide d'ADK, consultez Agents personnalisés.
Comparer les modèles de conception
Le choix d'un modèle d'agent est une décision architecturale fondamentale. Chaque modèle offre différents compromis en termes de flexibilité, de complexité et de performances. Pour déterminer le modèle approprié à votre charge de travail, tenez compte des modèles de conception dans les sections suivantes.
Workflows déterministes
Les workflows déterministes incluent des tâches prévisibles et séquentielles, et ont un chemin de workflow clairement défini du début à la fin. Les étapes de vos tâches sont connues à l'avance, et le processus ne change pas beaucoup d'une exécution à l'autre.
Voici des modèles de conception d'agent pour les workflows déterministes :
- Modèle séquentiel multi-agent
-
Utilisez ce modèle si votre charge de travail présente les caractéristiques suivantes :
- Tâches en plusieurs étapes qui suivent un workflow prédéfini et rigide.
- Ne nécessite pas d'orchestration de modèle.
- Séquence fixe d'opérations. La sortie d'un agent est l'entrée directe de l'agent suivant dans la séquence.
- Modèle parallèle multi-agents
-
Utilisez ce modèle si votre charge de travail présente les caractéristiques suivantes :
- Tâches indépendantes pouvant être exécutées en même temps.
- Ne nécessite pas d'orchestration de modèle.
- Réduit la latence globale en exécutant les sous-tâches simultanément.
- Modèle d'affinement itératif multi-agent
-
Utilisez ce modèle si votre charge de travail présente les caractéristiques suivantes :
- Tâches de génération ouvertes ou complexes difficiles à réaliser en une seule tentative.
- L'agent doit améliorer progressivement le résultat sur plusieurs cycles.
- Ne nécessite pas d'orchestration de modèle.
- Donne la priorité à la qualité du résultat plutôt qu'à la latence.
Workflows nécessitant une orchestration dynamique
Les workflows qui nécessitent une orchestration dynamique impliquent des problèmes complexes pour lesquels les agents doivent décider de la marche à suivre. Dans ces workflows, le système d'IA agentique planifie, délègue et coordonne les tâches de manière dynamique sans script.
Voici des modèles de conception d'agents pour les workflows qui nécessitent une orchestration dynamique :
- Modèle à agent unique
-
Utilisez ce modèle si votre charge de travail présente les caractéristiques suivantes :
- Tâches structurées et en plusieurs étapes qui nécessitent l'utilisation d'outils externes.
- Nécessite un développement rapide pour un prototype de solution en tant que démonstration de faisabilité.
- Modèle de coordinateur multi-agents
-
Utilisez ce modèle si votre charge de travail présente les caractéristiques suivantes :
- Nécessite un routage dynamique vers un sous-agent spécialisé approprié pour les tâches structurées avec des entrées variées.
- Latence élevée due aux multiples appels au modèle d'IA coordinateur pour qu'il puisse diriger les tâches vers le sous-agent approprié.
- Peut entraîner des coûts élevés en raison de plusieurs appels à l'agent coordinateur.
- Modèle de décomposition hiérarchique des tâches multi-agents
-
Utilisez ce modèle si votre charge de travail présente les caractéristiques suivantes :
- Nécessite une orchestration de modèle à plusieurs niveaux pour les tâches complexes, ouvertes et ambiguës.
- Nécessite des résultats complets et de haute qualité, où la décomposition de l'ambiguïté est le principal défi.
- Latence élevée due à une décomposition imbriquée à plusieurs niveaux, ce qui entraîne plusieurs appels au modèle d'IA pour le raisonnement.
- Modèle d'essaim multi-agent
-
Utilisez ce modèle si votre charge de travail présente les caractéristiques suivantes :
- Nécessite un débat collaboratif et un affinement itératif de la part de plusieurs agents spécialisés pour les tâches très complexes, ouvertes ou ambiguës.
- Priorise la synthèse de plusieurs points de vue pour créer une solution complète ou créative.
- Latence et coûts opérationnels élevés en raison de la communication dynamique et globale entre les agents.
Workflows impliquant une itération
Les workflows qui impliquent une itération incluent des tâches dont le résultat final est obtenu par des cycles d'affinage, de commentaires et d'amélioration.
Voici des modèles de conception d'agents pour les workflows impliquant une itération :
- Modèle ReAct
-
Utilisez ce modèle si votre charge de travail présente les caractéristiques suivantes :
- Nécessite qu'un agent raisonne, agisse et observe de manière itérative pour élaborer ou adapter un plan pour des tâches complexes, ouvertes et dynamiques.
- Donne la priorité à un résultat plus précis et plus complet plutôt qu'à la latence.
- Modèle de boucle multi-agent
-
Utilisez ce modèle si votre charge de travail présente les caractéristiques suivantes :
- Nécessite des tâches de surveillance ou d'interrogation qui répètent une action prédéfinie, telle que des vérifications automatisées, jusqu'à ce que l'agent remplisse une condition de sortie.
- Latence imprévisible ou de longue durée en attendant qu'une condition de sortie soit remplie.
- Modèle d'examen et de critique multi-agents
-
Utilisez ce modèle si votre charge de travail présente les caractéristiques suivantes :
- Les tâches nécessitent une étape de validation distincte avant d'être terminées.
- Modèle d'affinage itératif multi-agent
-
Utilisez ce modèle si votre charge de travail présente les caractéristiques suivantes :
- Tâches de génération ouvertes ou complexes difficiles à réaliser en une seule tentative.
- L'agent doit améliorer progressivement le résultat sur plusieurs cycles.
- Ne nécessite pas d'orchestration de modèle.
- Privilégie la qualité de la sortie plutôt que la latence.
Workflows ayant des exigences particulières
Les workflows qui ont des exigences particulières incluent des tâches qui ne suivent pas les modèles agentiques courants. Vos tâches peuvent inclure une logique métier unique ou nécessiter un jugement et une intervention humaine à des points critiques. Dans ce cas, votre système d'IA agentique est conçu sur mesure pour un objectif unique et spécifique.
Voici des modèles de conception d'agents pour les workflows ayant des exigences particulières :
- Modèle human-in-the-loop
-
Utilisez ce modèle si votre charge de travail présente les caractéristiques suivantes :
- Nécessite une supervision humaine en raison de tâches subjectives ou à fort enjeu, qui peuvent inclure des exigences de sécurité, de fiabilité et de conformité.
- Schéma de logique personnalisée
-
Utilisez ce modèle si votre charge de travail présente les caractéristiques suivantes :
- Logique de ramification complexe qui va au-delà d'une séquence linéaire directe.
- Nécessite un contrôle maximal pour combiner des règles prédéfinies avec le raisonnement du modèle.
- Nécessite un contrôle précis des processus pour un workflow qui ne correspond pas à un modèle standard.
Étapes suivantes
- Découvrez comment créer et gérer des systèmes multi-agents à l'aide des primitives ADK.
- Découvrez comment héberger des applications et des agents d'IA sur Cloud Run.
- En savoir plus sur les modèles de conception d'agents : guide pratique pour créer des systèmes intelligents.
- Découvrez comment créer un agent avec ADK.
- Découvrez comment créer des systèmes d'IA multi-agents dans Google Cloud.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.
Contributeurs
Auteur : Samantha He | Rédactrice technique
Autres contributeurs :
- Abdul Saleh | Ingénieur logiciel
- Amina Mansour | Tech Lead, Global Developer Relations & Strategic Content
- Amit Maraj | Ingénieur relations avec les développeurs
- Casey West | Architecture Advocate, Google Cloud
- Jack Wotherspoon | Developer Advocate
- Joe Fernandez | Rédacteur technique
- Joe Shirey | Cloud Developer Relations Manager
- Karl Weinmeister | Directeur des relations avec les développeurs de produits cloud
- Kumar Dhanagopal Développeur de solutions multiproduits
- Lisa Shen | Senior Outbound Product Manager, Google Cloud
- Mandy Grover | Responsable de l'Architecture Center
- Mark Lu | Rédacteur technique
- Megan O'Keefe | Developer Advocate
- Olivier Bourgeois | Ingénieur relations avec les développeurs
- Shir Meir Lador | Responsable de l'ingénierie des relations avec les développeurs
- Vlad Kolesnikov | Ingénieur relations avec les développeurs