Comment les agents IA fonctionnent: le modèle, les outils, la mémoire et la boucle de contrôle

Un agent IA fonctionne en combinant un modèle avec des instructions, des outils, de la mémoire et une boucle de contrôle qui décide de façon répétée de la prochaine action. Le modèle fournit des capacités de jugement et de langage, tandis que le logiciel environnant transforme ces capacités en un processus avec état qui peut agir, inspecter les résultats, se remettre d’erreurs et s’arrêter.

Comprendre cette architecture est plus utile que de considérer un agent comme un objet intelligent unique. La plupart des succès et des échecs proviennent de la façon dont les composants interagissent: un modèle excellent peut être sapé par des outils vagues, une mémoire obsolète, des permissions excessives ou une boucle de contrôle dépourvue d’une définition fiable de l’achèvement.

Les cinq composantes essentielles d’un agent IA

1. le Modèle

Le modèle interprète l’objectif, raisonne sur le contexte disponible et sélectionne une action. Dans de nombreux agents actuels, il s’agit d’un grand modèle de langage capable de suivre des instructions et de produire des appels d’outils structurés ainsi que du langage naturel.

Le modèle le plus performant n’est pas automatiquement le meilleur choix pour chaque étape. Un système peut orienter la planification difficile vers un modèle plus puissant, utiliser un modèle plus rapide pour la classification et s’appuyer sur du code déterministe pour la validation. Cette combinaison peut améliorer la vitesse, le coût et la fiabilité.

2. Instructions

Les instructions définissent le rôle, les limites, les priorités et les exigences de sortie de l’agent. Elles peuvent inclure une invite système, un contexte spécifique à la tâche, des politiques, des exemples, des descriptions d’outils et des critères d’arrêt.

De bonnes instructions sont opérationnelles. Elles indiquent à l’agent quelles preuves sont nécessaires, quand demander une approbation, quelles sources sont acceptables et comment reconnaître l’achèvement. Des règles vagues ou contradictoires obligent le modèle à deviner, créant de l’incohérence entre des tâches autrement similaires.

3. Outils

Les outils relient le modèle à des capacités en dehors de son contexte actuel. Un outil peut rechercher sur le web, récupérer un dossier client, exécuter du code, interroger une base de données, contrôler un navigateur ou créer un événement de calendrier.

Le modèle n’exécute généralement pas la fonction lui‑même. Il choisit un outil nommé et propose des arguments structurés. Le runtime de l’agent valide la requête, vérifie les permissions, exécute l’opération et renvoie le résultat. Cette séparation est essentielle: elle permet au logiciel de rejeter les actions mal formées ou dangereuses avant qu’elles n’affectent le monde extérieur.

4. État et Mémoire

L’état représente les informations dont l’agent a besoin pendant l’exécution en cours: l’objectif, la conversation, le plan, les observations, les sorties d’outils et les étapes terminées. La mémoire étend ce concept en conservant des informations utiles au‑delà du contexte immédiat, comme les préférences antérieures, les faits récurrents ou les leçons tirées de tâches précédentes.

Plus de mémoire n’est pas toujours mieux. Les enregistrements non pertinents consomment le contexte et peuvent orienter le modèle vers des hypothèses dépassées. Les systèmes de mémoire efficaces décident quoi stocker, comment l’organiser, quand le récupérer et comment gérer les informations conflictuelles ou expirées.

5. la Boucle de Contrôle

La boucle de contrôle est la couche d’orchestration qui fait avancer le processus. Elle envoie l’état actuel au modèle, reçoit une action proposée, exécute les outils approuvés, consigne l’observation et réinvoque le modèle.

Anthropic décrit un agent comme un modèle de langage augmenté fonctionnant dans une boucle avec des capacités telles que la récupération, les outils et la mémoire dans son guide sur la création d’agents efficaces. OpenAI présente de façon similaire l’exécution d’un agent comme une interaction continue entre le modèle, ses outils et un environnement dans From Model to Agent.

Les interfaces comptent autant que les composants

Un diagramme d’architecture peut donner l’impression que chaque composant est clairement séparé, mais la fiabilité réelle dépend des contrats entre eux. Le modèle a besoin de descriptions d’outils qui distinguent des capacités similaires. Le runtime a besoin d’arguments typés et d’états d’erreur explicites. La récupération de mémoire nécessite des informations de provenance et de fraîcheur. Le vérificateur d’achèvement a besoin de critères testables plutôt que d’une impression vague que la réponse est suffisante.

Considérons un outil de recherche qui renvoie une liste vide. Ce résultat peut signifier qu’aucun enregistrement pertinent n’existe, que la requête était mal formée, que l’utilisateur n’a pas les permissions, ou que le service a expiré. Si l’outil regroupe les quatre conditions dans la même sortie, le modèle ne peut pas raisonner de manière fiable sur ce qui s’est passé. Une interface bien conçue renvoie des preuves structurées: statut, source, horodatage, requête, nombre de résultats et une erreur lisible par machine le cas échéant.

Le même principe s’applique au contexte. Les instructions, les enregistrements autoritaires, les passages récupérés, les notes créées par le modèle et le contenu externe non fiable ne doivent pas être traités comme du texte équivalent. Identifier leur source et leur autorité aide le runtime à appliquer la politique et aide le modèle à pondérer correctement les preuves. Il s’agit d’une forme pratique d’ingénierie du contexte: décider non seulement quelles informations le modèle voit, mais comment ces informations sont organisées et ce que le système lui permet de contrôler.

Un exemple étape par étape

Imaginez un agent chargé de comparer trois fournisseurs potentiels et de préparer une recommandation.

1. Recevoir l’objectif: l’agent lit les critères de décision, la date limite, le budget et la sortie requise.
2. Inspecter le contexte disponible: il vérifie que les noms des fournisseurs, les exigences internes et les documents sources sont présents.
3. Élaborer un plan: il décide de rassembler les prix, les informations de sécurité, les conditions de service et les preuves client pour chaque fournisseur.
4. Sélectionner un outil: il recherche dans un magasin de documents approuvé ou fait appel à un outil de recherche externe.
5. Observer: le runtime renvoie les résultats, y compris d’éventuelles erreurs ou champs manquants.
6. Mettre à jour l’état: l’agent consigne ce qu’il a appris et signale les questions non résolues.
7. S’adapter: il modifie les requêtes, consulte une autre source ou demande à une personne un document indisponible.
8. Vérifier: il s’assure que chaque recommandation est étayée et que les comparaisons utilisent les mêmes critères.
9. Arrêter ou demander une approbation: il produit une recommandation préliminaire, mais laisse la décision d’achat à la personne autorisée.

Le point important est que la séquence n’était pas entièrement codée en dur. Le système a sélectionné les étapes en fonction de ce qu’il a trouvé, mais il a tout de même fonctionné dans les limites prévues.

La planification n’est pas toujours une phase distincte

Certains agents produisent un plan complet avant d’agir. D’autres décident d’une étape à la fois. Beaucoup utilisent un hybride: créer un plan approximatif, exécuter l’action suivante et réviser le plan restant au fur et à mesure que les observations arrivent.

Des plans longs et rigides peuvent devenir obsolètes après le premier résultat inattendu. Les agents purement réactifs peuvent errer ou répéter le travail. Une conception pratique conserve suffisamment de planification pour maintenir la direction tout en permettant une replanification lorsque l’environnement change.

Le cadre ReAct est un exemple fondamental d’entrelacement du raisonnement avec les actions et les observations. Son insight central est qu’un résultat externe peut corriger, affiner ou rediriger l’étape de raisonnement suivante.

Comment les agents savent quand s’arrêter

L’arrêt est un problème de conception du système. Un modèle peut déclarer le succès trop tôt, continuer à peaufiner après que l’objectif a été atteint, ou boucler lorsqu’un outil échoue de façon répétée.

Les agents fiables combinent plusieurs mécanismes d’arrêt:

• Critères d’achèvement: conditions explicites comme les champs obligatoires, les tests réussis ou les citations vérifiées.
• Budgets: limites sur le nombre d’étapes, le temps, les jetons du modèle, les appels d’outils ou le coût.
• Seuils d’erreur: escalade après des échecs répétés ou des observations à faible confiance.
• Portes d’approbation: une pause avant des actions à fort impact ou irréversibles.
• Évaluateurs externes: vérifications déterministes ou modèles séparés qui jugent si la sortie satisfait la tâche.

Architectures d’agents courantes

Une boucle à agent unique est la conception la plus simple: un modèle utilise de façon répétée les outils jusqu’à ce qu’il termine. Elle est plus facile à déboguer et souvent suffisante.

Un routeur classe la requête et l’envoie à une invite spécialisée, un ensemble d’outils ou un modèle. Le routage réduit les choix non pertinents et peut appliquer des politiques différentes à différents travaux.

Une architecture orchestrateur‑travailleur permet à un agent principal de créer des sous‑tâches et de les déléguer à des travailleurs, puis de synthétiser leurs résultats. Cela est utile lorsque le travail peut s’exécuter en parallèle ou nécessite des spécialités différentes, mais cela augmente la consommation de jetons et les modes d’échec de coordination.

Une boucle évaluateur‑optimiseur sépare la génération de la critique. Un composant produit une réponse ; un autre la vérifie selon des critères définis ; le premier la révise. Cela fonctionne bien lorsque la qualité est mesurable et que l’amélioration par itération justifie le coût supplémentaire.

Ce qui tourne généralement mal

• Descriptions d’outils médiocres: le modèle choisit la mauvaise capacité ou fournit des arguments invalides.
• Contexte illimité: de longues transcriptions se remplissent de détails non pertinents et enterrent les informations décisives.
• Erreurs silencieuses d’outil: un résultat vide ou partiel est pris pour une observation valide.
• Ancrage faible: l’agent agit sur une hypothèse au lieu de vérifier le système d’enregistrement.
• Autonomie excessive: l’agent peut prendre des actions conséquentes sans une frontière de révision appropriée.
• Absence d’évaluation de trajectoire: les équipes jugent la réponse finale mais n’inspectent pas comment l’agent y est parvenu.

Principes de conception pour des agents fiables

Commencez avec l’architecture la plus petite capable de résoudre la tâche. Un flux de travail déterministe doit gérer les étapes connues ; réservez la discrétion du modèle aux décisions qui nécessitent réellement une interprétation. Donnez à chaque outil un objectif restreint, des entrées typées, des états d’erreur explicites et un accès au principe du moindre privilège.

Rendez l’état visible. Enregistrez chaque appel d’outil, résultat, nouvelle tentative, approbation et décision du modèle nécessaires au diagnostic. Compressez le vieux contexte au lieu de l’ajouter indéfiniment, et conservez les données autoritaires séparément des résumés générés par le modèle.

Concevez le runtime de façon à ce que les échecs soient explicites. Un outil doit distinguer « aucun enregistrement trouvé » de « requête échouée », et le magasin d’état doit distinguer les faits vérifiés des résumés générés par le modèle. Sinon, le modèle pourrait interpréter une absence due à un dépassement de délai comme une preuve que quelque chose n’existe pas.

Enfin, évaluez le système complet. Exécutez la même tâche plusieurs fois, mesurez le succès et l’utilisation des ressources, et inspectez les trajectoires pour détecter des violations de politique ou des raccourcis fragiles. Le guide d’Anthropic sur les évaluations d’agents souligne que les agents ont besoin de tâches, d’essais répétables, de transcriptions et d’évaluateurs — pas d’une poignée de démonstrations impressionnantes.

Ce qu’il faut retenir sur le fonctionnement des agents IA

Un agent IA est une boucle conçue, pas seulement un modèle intelligent. Le modèle décide ; les outils agissent ; la mémoire transporte l’état ; l’environnement renvoie des preuves ; et la boucle de contrôle détermine ce qui se passe ensuite.

Lorsque ces parties possèdent des interfaces et des limites claires, un agent peut gérer des travaux ouverts que l’automatisation conventionnelle ne peut anticiper. Lorsqu’elles n’en ont pas, l’autonomie amplifie l’ambiguïté. La qualité d’un agent dépend donc autant de la conception du système, des permissions et de l’évaluation que du modèle sous‑jacent.