Architecture d’un agent IA : modèle, outils et contrôle
L’architecture d’un agent IA organise modèle, instructions, outils, état et contrôleur pour transformer une demande en actions. Elle détermine comment une observation rejoint la décision suivante, où les autorisations sont appliquées, comment les erreurs sont enregistrées et quand une exécution se termine ou s’interrompt.
Ce guide aide lorsque le schéma semble clair mais que vous ne pouvez pas montrer qui exécute l’outil. Suivons une recherche depuis la demande jusqu’à la réponse vérifiée et repérons les décisions qui appartiennent au code.
Idées essentielles
- Séparez la proposition d’action de son exécution.
- Enregistrez une observation avec sa source et son statut.
- Validez l’entrée à la frontière de l’opération.
- Distinguez réussite, échec et interruption.
Cinq composants aux responsabilités distinctes
Les instructions définissent tâche et limites. Le modèle propose la suite. Les outils exécutent des opérations précises. L’état conserve les événements. Le contrôleur relie les parties et décide de poursuivre. Cette séparation permet de localiser un échec : objectif ambigu, proposition incorrecte, outil indisponible ou contrôle acceptant une réponse sans preuve. Modifier le prompt ne répare pas toutes ces causes. Identifiez d’abord la responsabilité concernée, puis faites évoluer la partie correspondante du système.
Suivre une demande au catalogue
Une personne demande une leçon introductive sur l’IA. L’application crée un état contenant l’objectif et des observations vides. Le planificateur propose une recherche avec la clé 'ai'. Le contrôleur vérifie nom et arguments, puis exécute l’appel. Il conserve fiche et statut. La proposition suivante peut terminer à partir de cette observation. Le contrôle final exige que la réponse se réfère à la fiche reçue plutôt qu’à un titre de cours généré.
- 1Objectif
- 2Action proposée
- 3Validation
- 4Appel d’outil
- 5Observation
- 6Décision suivante
L’état dépasse l’historique de conversation
Les messages reconstituent ce qui a été dit, mais l’état opérationnel comprend aussi budget restant, opérations terminées et décisions en attente. Conservez un identifiant de fiche plutôt que toute la base dans chaque demande au modèle. L’état doit être assez petit pour l’inspection et assez explicite pour la reprise. Une exécution interrompue avant relecture reste en attente : un redémarrage ne doit pas la transformer silencieusement en réussite.
Placer les contrôles à la frontière d’exécution
Dire 'utilise seulement le catalogue' dans un prompt exprime une politique. Une fonction qui rejette les autres outils l’applique. Distinguez de la même façon types d’arguments, accès et répétitions. Une erreur reçue doit rester une erreur dans l’état. Pour une opération modifiant un système externe, définissez comment reconnaître un changement déjà terminé avant de réessayer. Une reprise pourrait sinon répéter une modification réussie juste avant la perte de connexion.
Concevoir une petite boucle observable
Précisez les transitions : prêt, outil demandé, observation enregistrée, relecture attendue, terminé et arrêté. Ajoutez les états utilisés par l’exercice et expliquez la sortie de chacun. Journalisez les informations utiles sans collecter inutilement des données personnelles. Un environnement d’orchestration peut gérer persistance et interruptions dans une application plus grande. Comprenez d’abord la boucle : un framework peut l’organiser, mais vous devez définir ce qui rend son résultat acceptable pour votre tâche.
En mots simples
Imaginez un atelier. Le modèle suggère le travail, les outils le réalisent, un carnet note les résultats et le responsable vérifie autorisations et avancement. L’architecture organise ces responsabilités.
À vous de jouer
Dessinez cinq cases : objectif, proposition, validation, recherche et observation. Ajoutez le point où une fiche absente interdit d’inventer une leçon. Marquez les cases capables de modifier des données.
Résultat attendu
Un schéma plaçant exécution et contrôles hors du modèle, enregistrant le statut de recherche et distinguant résultat terminé ou arrêté.
Vérifiez votre réponse: Où faut-il rejeter un appel interdit ?
À la frontière d’exécution, avant l’appel de l’outil. Les instructions seules n’appliquent pas cette barrière.
Questions et réponses
Le modèle est-il le contrôleur ?
Le modèle peut proposer la prochaine action, mais le code reçoit la proposition, la vérifie et appelle l’outil réel. Séparer ces rôles rend les limites inspectables. Un produit peut les regrouper : examinez son chemin d’exécution plutôt que les seules étiquettes du schéma.
Faut-il commencer par un framework d’orchestration ?
Une petite boucle s’étudie avec du code simple. Un framework devient utile pour la persistance, la reprise ou les transitions d’un graphe. Comparez ces besoins à sa documentation et testez un échec avant de l’adopter pour un projet plus important.
Suivez une demande réelle. Rendez explicites exécution, observation et contrôle final avant d’ajouter des fonctions.
Sources et lectures
- Anthropic — Building effective agents ↗Sources consultées:
- LangChain — LangGraph overview ↗Sources consultées:
- Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models ↗Sources consultées: