Un guide pratique des trois couches d'architecture que les gens confondent souvent
La confusion est compréhensible. Les trois concepts tournent autour du même modèle, tous les trois influencent la fiabilité, et tous les trois peuvent contenir des « boucles ». Mais ils ne sont pas synonymes. Ils décrivent différentes décisions d'ingénierie, et la distinction est cruciale dès qu'un agent quitte un notebook de démonstration et commence à interagir avec des fichiers, des API, des clients ou du code en production.
LA RÉPONSE EN 30 SECONDES
- L'ingénierie du harnais construit la machinerie autour du modèle
- L'ingénierie des boucles conçoit le cycle de travail et de rétroaction répété
- L'ingénierie des graphes rend explicite la topologie du flux de travail : nœuds, branches, jonctions, transitions d'état et cycles contrôlés
Le modèle mental clair est : environnement → rétroaction → flux
Pourquoi ces termes comptent soudainement
Un modèle de langage brut ne peut pas créer de texte, maintenir un état pour un projet, exécuter une suite de tests, regarder un navigateur, appliquer une règle d'approbation ou redémarrer une tâche échouée. Ces capacités proviennent de l'environnement dans lequel il se trouve. À mesure que le logiciel agentique mûrit, une pile d'ingénierie standard émerge enfin. À la base se trouve le harnais de l'agent, le code qui exécute réellement les modèles. Viennent ensuite les boucles, qui gèrent l'exécution répétée et les contrôles de qualité. Enfin, les graphes cartographient les chemins structurés qui guident l'ensemble du processus.
Les étiquettes ne sont pas encore normalisées de manière cohérente. Dans le cadre actuel, le terme « harnais d'agent » commence à prendre une définition assez spécifique. Le terme « ingénierie des boucles » est apparu comme un terme plus récent parmi les praticiens en 2026. L'ingénierie des graphes doit être comprise de manière pratique plutôt que comme un domaine académique ; c'est simplement le processus de création de flux de travail d'agent en tant que graphes orientés explicites ou machines d'état. Cette distinction pratique est utile car elle empêche un mot à la mode de masquer la véritable question de conception.
Ingénierie du Harnais d'Agent
- Selon Langchain, l'agent est le modèle plus le harnais, et le harnais est le code, la configuration et la logique d'exécution en dehors du modèle. En pratique, cela inclut le prompt système, les définitions d'outils, la mémoire, les systèmes de fichiers, les sandbox, le routage de modèles, les transferts, les hooks middleware, la compaction, les permissions, la journalisation et les interfaces de vérification.
- Le SDK Agents d'OpenAI décrit le même cœur opérationnel d'un point de vue runtime : l'exécuteur appelle le modèle, exécute les appels d'outils, gère les transferts, porte l'état et s'arrête uniquement lorsque l'exécution atteint une condition terminale réelle.
Le mot harnais est utile car il détourne l'attention de l'adoration du modèle. Deux équipes peuvent utiliser le même modèle de base et obtenir des résultats très différents parce que l'une donne au modèle des outils propres, un espace de travail stable, des permissions restreintes et un état observable, tandis que l'autre lui donne un prompt vague et une wrapper API peu fiable. L'intelligence peut être similaire ; les conditions de travail, non. Ce que contient généralement un harnais sérieux :
- Injection de contexte : instructions, faits récupérés, état de la conversation, compétences et politiques spécifiques à la tâche
- Surfaces d'action : API, navigateurs, shells, interpréteurs de code, bases de données et outils compatibles MCP
- Persistance : fichiers, points de contrôle, sessions, journaux de progression, historique git et mémoire à long terme
- Contrôle d'exécution : timeouts, tentatives, budgets, routage de modèles, création de sous-agents et portes d'approbation
- Sécurité et gouvernance : permissions, isolation, listes d'autorisation, gestion des secrets et autorisation humaine
- Observabilité : traces, entrées et sorties des outils, transitions d'état, coût, latence et résultats d'évaluation
Le modèle réside à l'intérieur d'un harnais plus large de contexte, de contrôle, d'action, de persistance et de vérification. Retirez le modèle de votre diagramme d'architecture. Tout ce qui reste fait probablement partie du harnais : les outils, l'accès aux données, le magasin d'état, le sandbox, le middleware, les évaluateurs, la politique de réessai et l'interface utilisateur.
Là où l'ingénierie du harnais montre sa valeur
Le travail sur le harnais est important pour les tâches de longue durée. Dans le codage multi-session, Anthropic a découvert que la simple utilisation de la compaction de contexte n'était pas suffisante. Ce n'était pas un meilleur prompt en soi, mais ils ont fait une bonne configuration qui a créé un initialiseur, un fichier de progression, un historique git et une discipline de travail incrémental pour que chaque nouveau contexte comprenne ce qui s'est passé et ce qu'il reste à faire. C'est un système de travail amélioré en ce qui concerne l'agent. Appliquez l'ingénierie du harnais lorsque l'agent n'a pas une capacité, ne peut pas revenir proprement, perd l'état, accède à trop de choses, ne peut pas être audité, ou agit différemment selon les environnements.
Ingénierie des Boucles
Chaque agent qui utilise un outil a une petite boucle intégrée :
- appeler le modèle
- regarder les résultats
- exécuter les outils
- saisir les observations dans le modèle
- répéter jusqu'à ce qu'une réponse finale soit renvoyée
Lorsque les développeurs construisent ou empilent intentionnellement de nouveaux cycles autour de ce comportement, c'est le début de l'ingénierie des boucles, comme l'appelle OpenAI. Une boucle de vérification, par exemple, permet à l'agent de créer un artefact, d'exécuter le contrôle déterministe ou un correcteur, de recevoir un retour explicite et de répéter uniquement s'il y a des preuves d'erreurs. Une boucle pilotée par les événements réveille l'agent lorsqu'un planning, un webhook ou un nouveau document est reçu. Une boucle d'amélioration analyse les traces et les échecs, modifie les instructions/outils, et teste si la nouvelle version fonctionne mieux. Le cadre de LangChain en 2026 décrit cela comme une pile de boucles et non comme une seule instruction magique while.
L'anatomie d'une boucle bien conçue :
- Déclencheur : ce qui démarre un nouveau cycle ; requête utilisateur, planning, test échoué, nouvelles données ou retour d'évaluateur
- Objectif : un état spécifique à atteindre, pas une instruction vague comme « continuez à vous améliorer »
- État et mémoire : ce que le prochain cycle doit savoir sans rejouer tout
- Politique d'action : ce que l'agent peut modifier, appeler, déléguer ou dépenser
- Preuve : tests, validation de schéma, citations, diffs, métriques ou examen humain
- Retour : une description concise et exploitable de la raison pour laquelle la preuve a échoué
- Règle d'arrêt : succès, limite de budget, timeout, erreur irrécupérable ou escalade humaine
Une boucle de vérification enveloppe la boucle de l'agent avec un correcteur externe et une condition de réussite explicite. Ne bouclez pas sur la confiance. Bouclez sur la preuve. « L'agent dit que c'est fini » n'est pas une condition d'arrêt ; « les tests passent, les liens résolvent, le schéma valide et le réviseur approuve » en est une.
Pourquoi l'ingénierie des boucles n'est pas simplement de l'ingénierie des prompts
Un prompt dit au modèle quoi faire pendant un appel. Une boucle spécifie ce que le système fait après l'appel :
comment il observe les résultats, choisit le retour, décide de continuer ou non, persiste la progression et se termine
La qualité du prompt compte toujours, mais la boucle transforme une instruction unique en un processus géré. Le principal compromis est le coût et la latence. Chaque correcteur, réviseur ou réessai ajoute un autre appel de modèle ou une exécution d'outil. Le conseil général d'Anthropic est de préférer l'architecture la plus simple qui fonctionne et d'ajouter de la complexité agentique uniquement lorsque le gain de performance le justifie. Le même conseil s'applique aux boucles : ajoutez-les là où le coût de l'échec est plus élevé que le coût de la vérification.
Ingénierie des Graphes
L'ingénierie des graphes pose une question différente : non seulement ce que fait l'agent, mais quel composant est autorisé à s'exécuter ensuite. Les étapes sont représentées par des nœuds et les étapes autorisées par des arêtes. Ces arêtes peuvent être utilisées pour indiquer une séquence, un branchement conditionnel, un déploiement parallèle, des jonctions, des boucles et des interruptions humaines. L'état traverse le graphe, et la topologie permet de vérifier le flux de contrôle souhaité. LangGraph est une infrastructure d'orchestration de bas niveau pour les agents avec état et de longue durée, avec une exécution durable, un état et un contrôle humain dans la boucle, et un accent explicite sur le contrôle des agents plutôt que sur une abstraction du flux de travail. La documentation de Microsoft AutoGen est exceptionnellement directe : utilisez un graphe lorsque vous avez besoin d'un contrôle précis sur l'ordre des agents, de différentes étapes suivantes pour différents résultats, d'un branchement déterministe ou de processus complexes en plusieurs étapes avec des cycles. Ce que les ingénieurs des graphes décident réellement :
- Limites des nœuds : quel travail appartient à une fonction déterministe, un appel LLM, un agent spécialiste ou une étape de révision humaine
- Schéma d'état : ce que chaque nœud peut lire ou mettre à jour, et comment les mises à jour parallèles sont fusionnées
- Conditions de routage : quelles preuves envoient le travail en avant, en arrière, sur le côté ou pour escalade
- Concurrence : ce qui peut s'exécuter en parallèle, ce qui doit se rejoindre, et quelles ressources partagées nécessitent une coordination
- Cycles et sorties : où les tentatives sont légales, combien sont autorisées, et ce qui rend le cycle sûr
- Durabilité : où les points de contrôle se produisent et comment l'exécution reprend après une interruption
Le canevas ci-dessus rend les agents, les compétences et les relations inspectables en tant que système composé. L'ingénierie des graphes signifie ici l'ingénierie de l'exécution basée sur des graphes. Ce n'est pas la même chose que l'ingénierie des graphes de connaissances, où le graphe représente des entités et des relations dans les données. Un graphe de flux de travail représente le contrôle et les transitions d'état.
Quand un graphe vaut la peine d'être mis en œuvre
Les graphes sont utiles lorsque le processus a des branches significatives, un travail parallèle, des approbations, des chemins de récupération ou plusieurs agents spécialistes. Ils sont moins utiles lorsque le travail consiste simplement à « donner trois outils à un agent et le laisser travailler ». Un graphe peut améliorer le débogage, mais il peut aussi figer les hypothèses trop tôt. Si le modèle doit inventer dynamiquement le plan, forcer chaque chemin possible dans un diagramme peut rendre le système plus fragile, pas moins.
Comment les trois couches fonctionnent ensemble dans un système réel
Considérez un agent de recherche et de publication responsable de la production d'un briefing industriel factuel.
Remarquez l'imbrication : le graphe s'exécute à l'intérieur du harnais ; une ou plusieurs boucles vivent à l'intérieur du graphe ; et le harnais fournit l'état, les outils et les évaluateurs dont ces boucles ont besoin. Les catégories se chevauchent parce que les couches logicielles se chevauchent, mais chacune donne toujours à l'équipe un levier différent à actionner lorsque le système échoue.
Choisissez la couche d'ingénierie en diagnostiquant la panne
Symptôme
Commencez par
Correctif probable
L'agent ne peut pas accéder aux bonnes données ou à l'outil en toute sécurité.
Harnais
Contrat d'outil, permissions, sandbox, injection de contexte.
L'agent oublie la progression entre les sessions.
Harnais
État durable, points de contrôle, artefacts de progression, compaction.
La première tentative est souvent proche mais pas fiable.
Boucle
Correcteur externe, tests déterministes, retour et réessai limité.
L'agent continue de travailler après le succès ou s'arrête avant la preuve.
Boucle
États terminaux basés sur des preuves et règles d'arrêt tenant compte du budget.
Plusieurs spécialistes doivent s'exécuter dans un ordre contrôlé.
Graphe
Nœuds, arêtes, conditions de routage et jonctions explicites.
Les échecs sont difficiles à localiser dans un processus en plusieurs étapes.
Graphe + harnais
Traces avec état alignées sur les nœuds et les transitions du graphe.
Le flux de travail change trop souvent pour un diagramme fixe.
Harnais plus simple
Gardez le contrôle piloté par le modèle ; retardez la formalisation du graphe.
Les Erreurs Coûteuses Derrière les Architectures d'Agent Faibles
Construire un graphe avant de comprendre le travail
Les équipes traduisent parfois un processus métier en dizaines de nœuds avant d'avoir observé comment un agent capable le résout réellement. Commencez par des traces d'un harnais plus simple, puis formalisez les chemins stables.
Laisser le même modèle écrire et noter sans garde-fous
L'auto-révision peut aider, mais elle est vulnérable aux angles morts partagés. Préférez les contrôles déterministes lorsque c'est possible, un contexte de réviseur séparé, et exigez une approbation humaine pour les actions à fort impact.
Utiliser « continuez d'essayer » comme spécification de boucle
Une boucle de réessai illimitée est une fuite de coûts. Chaque boucle a besoin d'un objectif mesurable, de preuves fraîches, d'un nombre maximum de tentatives et d'un chemin d'escalade nommé.
Traiter le harnais comme un fourre-tout
Plus d'outils et de mémoire ne sont pas automatiquement meilleurs. Un ensemble d'outils encombré augmente les erreurs de sélection, un contexte bruyant augmente la confusion, et des permissions larges augmentent le risque.
Blamer le modèle pour les échecs d'orchestration
Un modèle ne peut pas compenser de manière fiable un état obsolète, des schémas d'outils ambigus, des API cassées ou des conditions de sortie manquantes. Améliorez la couche propriétaire de l'échec.
Une liste de contrôle prête pour la production
- Harnais : Les outils sont-ils précis, documentés et observables ? L'état est-il durable ? Les permissions sont-elles au moindre privilège ? Les opérateurs peuvent-ils mettre en pause, inspecter et reprendre une exécution ?
- Boucle : Quelle preuve prouve le succès ? Quel retour est fourni en cas d'échec ? Combien de tentatives sont autorisées ? Que se passe-t-il lorsque le budget est épuisé ?
- Graphe : Quels chemins doivent être déterministes ? Où le travail peut-il s'exécuter en parallèle ? Quel état est partagé ? Où se trouvent les portes humaines et les chemins de récupération ?
- Évaluation : L'équipe peut-elle rejouer des traces réelles, comparer les versions et attribuer l'amélioration à un changement spécifique plutôt qu'à l'intuition ?
- Opérations : Le coût, la latence, le taux d'échec, le taux d'intervention et le succès au niveau de la tâche sont-ils surveillés en production ?
La Façon la Plus Simple de Se Souvenir de la Différence
L'ingénierie du harnais consiste à doter un modèle de ce dont il a besoin pour fonctionner. La méthodologie de l'ingénierie des boucles est itérative, vérifiable et reprise. Un chemin d'exécution complexe est rendu explicite et contrôlable grâce à l'utilisation de l'ingénierie des graphes. Aucun des trois ne se substitue aux autres. Même si le harnais a perdu son état, un graphe magnifiquement dessiné n'est pas suffisant. Cependant, même avec le meilleur harnais, s'il n'y a pas de preuve ou de règle d'arrêt, c'est une perte d'argent ! Les boucles soigneusement conçues sont encore difficiles à exploiter lorsque le branchement, le parallélisme et les approbations sont intégrés dans le code ad-hoc. Si ces trois couches sont conçues conjointement, des systèmes d'agent fiables émergeront, à condition que l'équipe soit consciente de ce que chaque couche est censée résoudre.
TERMES DE RECHERCHE UTILISÉS PAR LES LECTEURS
- agent harness vs loop engineering
- graph engineering for AI agents
- AI agent orchestration
- LLM agent architecture
- production AI agents
- LangGraph workflows
- AutoGen GraphFlow
- agent verification loops
Sources et Lectures Complémentaires
L'Anatomie d'un Harnais d'Agent - Découvrez comment les harnais d'agent transforment les modèles d'IA en moteurs de travail autonomes. Explorez les composants de base : systèmes de fichiers, sandbox et mémoire.
Les Frameworks LangChain et LangGraph Atteignent les Jalons v1.0 - LangChain 1.0 et LangGraph 1.0 sont là. Construisez plus rapidement des agents IA prêts pour la production avec des outils standardisés, une personnalisation middleware et un état durable.
GraphFlow (Flux de Travail) - AutoGen - Dans cette section, vous apprendrez à créer un flux de travail multi-agent en utilisant , ou simplement « flow » en abrégé. Il utilise une exécution structurée et contrôle précisément la façon dont les agents interagissent pour accomplir une tâche. Nous allons d'abord vous montrer comment créer et exécuter un flux.
L'Art de l'Ingénierie des Boucles - Les agents automatisent le travail réel, mais des performances fiables nécessitent plus qu'un bon modèle, elles nécessitent un harnais soigneusement conçu pour des tâches spécifiques. Cet article explore la boucle d'agent centrale, comment l'empilement et l'extension des boucles construisent des agents plus efficaces, et comment instrumenter chaque niveau avec les primitives LangChain.
Introduction d'AutoGen Studio par Microsoft Research - AutoGen Studio, construit sur le framework open-source flexible AutoGen de Microsoft pour orchestrer les agents d'IA, fournit une interface conviviale qui permet aux développeurs de construire, tester, personnaliser et partager rapidement des solutions d'IA multi-agents, avec peu ou pas de codage.
Comment Construire un Harnais d'Agent Personnalisé - Les agents efficaces sont construits avec des harnais étroitement couplés à la tâche à accomplir. La façon la plus simple de construire un harnais personnalisé est d'utiliser create_agent de LangChain plus le middleware. Ce guide couvre la boucle d'agent centrale et comment vous pouvez la personnaliser pour le cas d'utilisation de votre agent.
Un guide pratique pour construire des agents - Un guide complet pour concevoir, orchestrer et déployer des agents d'IA, couvrant les cas d'utilisation, la sélection de modèles, la conception d'outils, les garde-fous et les modèles multi-agents.
Construire des Agents d'IA Efficaces - Des conseils pratiques et des orientations pour construire des systèmes d'agent uniques et multi-agents prêts pour la production, d'Anthropic et de nos clients.
Sauvegardez ceci pour ne pas le perdre
Suivez @beamnxw pour plus de contenu technique :)
