Ce document fournit des conseils pour vous aider à choisir un modèle de conception pour votre système d'IA agentive. Les modèles de conception d'agent sont des approches architecturales courantes pour créer des applications agentives. 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 complexe des workflows en plusieurs étapes. Les agents sont excellents pour résoudre les problèmes en temps réel à l'aide de données externes et pour automatiser les tâches nécessitant beaucoup de connaissances. Les agents d'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 générative et d'assistance. Pour en savoir plus sur les différences entre les agents d'IA et les applications d'IA non agentiques, 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 agentiques et sur la façon dont leur architecture diffère de celle des systèmes non agentiques, tels que ceux qui utilisent le raisonnement direct du modèle ou la génération augmentée par récupération (RAG).
Pour obtenir un résumé des conseils sur les modèles d'agents, consultez la section Comparer les modèles de conception plus loin dans ce document.
Présentation du processus de conception
Voici les étapes générales à 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'agents 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éexaminer régulièrement 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 suivantes ne constituent pas des checklists exhaustives pour la planification. Utilisez ces questions comme point de départ pour identifier l'objectif principal de votre système agentique et sélectionner le modèle de conception le plus adapté.
- 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 les 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 à fort enjeu, des opérations critiques pour la sécurité ou des approbations subjectives nécessitant un jugement humain ?
Si votre charge de travail est prévisible ou très 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 la synthèse d'un document, la traduction de texte ou la classification des commentaires des clients. Pour savoir comment choisir des composants d'architecture pour les applications d'IA générative qui ne nécessitent pas d'infrastructure agentique, 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'agent courants pour créer un système d'IA agentique fiable et efficace.
Système à agent unique
Un système mono-agent utilise un modèle d'IA, un ensemble d'outils défini et une invite système complète 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 quels outils utiliser à partir d'un ensemble défini. La requête 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 montre une vue d'ensemble d'un modèle à agent unique :
Un système mono-agent 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 dernières actualités. 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 êtes au début du développement de votre agent, nous vous recommandons de commencer par un seul agent. Lorsque vous commencez à développer votre agent avec un système à agent unique, vous pouvez vous concentrer sur l'affinage de la logique de base, de l'invite et des définitions d'outils de votre agent avant d'ajouter des composants architecturaux plus complexes.
Les performances d'un agent unique peuvent être moins efficaces lorsqu'il utilise plus d'outils et lorsque les tâches deviennent plus complexes. Cela peut se traduire par une latence accrue, une sélection ou une utilisation incorrecte de l'outil, ou un échec de 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 d'utiliser un système multi-agents, 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 une invite 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é ingénierie du contexte. L'ingénierie du 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é.
La création d'un système multi-agents nécessite des considérations supplémentaires en termes d'évaluation, de sécurité, de fiabilité et de coût par rapport à un système mono-agent. Par exemple, les systèmes multi-agents doivent implémenter des contrôles d'accès précis pour chaque agent spécialisé, concevoir un système d'orchestration robuste pour assurer une communication fiable entre les agents et gérer l'augmentation des coûts opérationnels liée à la surcharge de calcul de l'exécution de plusieurs agents. Pour obtenir un exemple d'architecture de référence permettant de créer un système multi-agent, consultez Systèmes d'IA multi-agents 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 la mise en forme, 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 à des conditions dynamiques ou l'omission d'étapes inutiles, ce qui peut entraîner un traitement inefficace ou une latence cumulative plus élevée si une étape inutile est lente.
Modèle parallèle
Dans le modèle parallèle multi-agents, également appelé modèle simultané, plusieurs sous-agents spécialisés effectuent une tâche ou des sous-tâches de manière indépendante et simultanée. Les résultats des sous-agents sont ensuite synthétisés pour produire la réponse consolidée finale. Semblable à un modèle séquentiel, le modèle parallèle utilise un agent de workflow parallèle pour gérer la façon dont les autres agents s'exécutent et le moment où ils le font, 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 diverses perspectives, par exemple en collectant des données provenant de sources disparates ou en évaluant plusieurs options à la fois. Par exemple, pour analyser les commentaires des clients, un agent parallèle peut distribuer une seule entrée de commentaires à 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 sorties 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. Cependant, cette approche implique des compromis en termes de coûts 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 la charge de développement et de maintenance du système.
Motif de boucle
Le modèle d'agent de boucle multi-agents 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 redémarre la séquence de sous-agents. Vous pouvez implémenter un modèle de boucle où la condition de sortie est évaluée à n'importe quel moment du flux. Utilisez le modèle de boucle pour les tâches qui nécessitent un affinage itératif ou une auto-correction, 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 montre une vue d'ensemble d'un modèle de boucle multi-agents :
Le modèle d'agent de boucle permet de créer des workflows itératifs complexes. Il permet aux agents d'affiner leur propre travail et de continuer le traitement 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 forte consommation de ressources et des blocages potentiels du système.
Examiner et critiquer un modèle
Le modèle d'examen et de critique multi-agents, é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 cette sortie 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 convient 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 réussit tous les tests unitaires, avant que le code ne soit approuvé pour utilisation.
Le modèle d'examen 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é entraîne directement 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'affinage itératif utilise un mécanisme de boucle pour améliorer progressivement un résultat sur plusieurs cycles. Le modèle d'affinage itératif est une implémentation du modèle d'agent de boucle.
Dans ce modèle, un ou plusieurs agents fonctionnent 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 convient aux tâches de génération complexes pour lesquelles il est difficile d'obtenir le résultat 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 de rédaction créative, un agent peut générer un brouillon d'article de blog, le critiquer pour le flux et le ton, puis le réécrire 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'affinage itératif peut produire des résultats très complexes ou soignés qu'il serait difficile d'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 de la complexité architecturale, car il nécessite des conditions de sortie soigneusement conçues (comme une évaluation de la qualité ou une limite d'itération maximale) pour éviter des coûts excessifs ou une exécution incontrôlée.
Modèle de coordinateur
Le modèle de coordinateur multi-agents 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 envoie chaque sous-tâche à un agent spécialisé pour exécution. Chaque agent spécialisé est un expert dans une fonction spécifique, comme interroger une base de données ou appeler 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-agents :
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 faire office de coordinateur. L'agent coordinateur analyse la demande pour déterminer s'il s'agit d'une demande d'état de commande, de retour de produit ou de remboursement. En fonction du type de requête, le coordinateur transmet la tâche à l'agent spécialisé approprié.
Le modèle de coordinateur offre de la flexibilité par rapport aux workflows plus rigides et prédéfinis. En utilisant un modèle pour router 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 conduire à un raisonnement de meilleure qualité, 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 nécessitant 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é de 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 soient suffisamment simples pour qu'un agent de nœud de calcul au niveau le plus bas puisse les exécuter directement.
Le diagramme suivant montre 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 de recherche, de planification et de synthèse. Par exemple, pour mener à bien un projet de recherche complexe, un agent coordinateur décompose l'objectif général 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 les exécuter ou les décomposer 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 générer 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 Swarm
Le modèle d'essaim multi-agents 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 montre une vue d'ensemble d'un modèle de swarm multi-agents :
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 demande et détermine quel agent de l'essaim 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 groupe 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 manque généralement d'un agent superviseur ou coordinateur central pour assurer le bon déroulement du processus. L'agent répartiteur n'orchestre pas le workflow agentique, contrairement au modèle de coordinateur. Au lieu de cela, l'agent répartiteur facilite la communication entre les sous-agents du swarm et l'utilisateur. Pour vous assurer que le swarm 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 la réalisation d'un objectif spécifique, comme la recherche d'un consensus.
Utilisez le modèle de nuée pour les problèmes ambigus ou très complexes qui nécessitent un débat et 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 partagent des idées initiales, débattent des compromis entre les fonctionnalités et les coûts, et convergent 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é. Toutefois, il s'agit du modèle multi-agents le plus complexe et le plus coûteux à implémenter. L'absence d'un agent utilisant un modèle d'IA pour l'orchestration 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 et multitours entre plusieurs agents.
Modèle "Raisonner et agir" (ReAct)
Le modèle ReAct est une approche qui utilise le modèle d'IA pour encadrer ses processus de pensée 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.
- Thought (Réflexion) : le modèle réfléchit à la tâche et décide de la prochaine étape. 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 le résultat 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 d'itérations prédéfini 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 recueillir des preuves et d'ajuster son approche à mesure qu'il s'approche de la réponse finale.
Le diagramme suivant montre 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. 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 de l'environnement qu'il perçoit.
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 agent ReAct unique peut être plus simple et plus économique à implémenter et à gérer qu'un système multi-agents complexe. La réflexion du modèle fournit une transcription du raisonnement du modèle, ce qui facilite le débogage. Toutefois, 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 suspend 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 pour les tâches qui nécessitent une supervision humaine, un jugement subjectif ou une approbation finale pour les actions critiques. Il peut s'agir d'approuver une transaction financière importante, de valider le résumé d'un document sensible ou de fournir un avis subjectif 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 informations de santé protégées, mais il s'arrêterait à un point de contrôle final. Il attend ensuite qu'un responsable de la conformité humain 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 diagramme 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 appelle 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 collectés, l'agent coordinateur exécute un outil pour vérifier si la demande peut faire l'objet d'un remboursement.
- Si l'utilisateur est éligible, le coordinateur transmet la tâche à un agent chargé du 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 chargé du traitement des remboursements, qui appelle l'outil
- Le résultat du chemin emprunté est envoyé à l'agent de réponse final pour formuler 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 en parallèle, puis une branche conditionnelle personnalisée qui redirige vers deux processus en aval complètement différents. Ce type de workflow complexe à plusieurs modèles 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 de développement d'agents tel que Agent Development Kit (ADK).
Pour en savoir plus sur les agents personnalisés et sur l'implémentation d'une logique personnalisée à l'aide de l'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 dont le chemin est 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 exemples de modèles de conception d'agent pour les workflows déterministes :
| Caractéristiques de la charge de travail | Modèle de conception d'agent |
|---|---|
|
Modèle séquentiel multi-agent |
|
Modèle parallèle multi-agents |
|
Modèle d'affinage itératif multi-agents |
Workflows nécessitant une orchestration dynamique
Les workflows qui nécessitent une orchestration dynamique incluent des problèmes complexes pour lesquels les agents doivent déterminer la meilleure façon de procéder. Le système d'IA agentique doit planifier, déléguer et coordonner les tâches de manière dynamique, sans script prédéfini. Voici des modèles de conception d'agents pour les workflows qui nécessitent une orchestration autonome et dynamique :
| Caractéristiques de la charge de travail | Modèle de conception d'agent |
|---|---|
|
Modèle à agent unique |
|
Modèle de coordinateur multi-agents |
|
Modèle de décomposition hiérarchique des tâches multi-agents |
|
Modèle de nuage multi-agents |
Workflows impliquant une itération
Les workflows impliquant une itération incluent les tâches où 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 :
| Caractéristiques de la charge de travail | Modèle de conception d'agent |
|---|---|
|
Modèle ReAct |
|
Modèle de boucle multi-agents |
|
Modèle d'examen et de critique multi-agents |
|
Modèle d'affinage itératif multi-agents |
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 moments critiques. Votre système d'IA agentif est une machine personnalisée conçue pour un seul objectif spécifique. Voici des modèles de conception d'agents pour les workflows qui ont des exigences particulières :
| Caractéristiques de la charge de travail | Modèle de conception d'agent |
|---|---|
|
Modèle human-in-the-loop |
|
Schéma de logique personnalisée |
É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 agentiques : guide pratique pour créer des systèmes intelligents
- Découvrez comment créer un agent avec Agent Development Kit.
- 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 | Cadre de l'équipe Cloud Platform Evaluations
- 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 | Responsable des relations avec les développeurs cloud
- Karl Weinmeister | Responsable 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