Les agents sont utiles car ils nous aident à automatiser les tâches en agissant dans le monde réel. Mais pour qu'ils accomplissent un travail de valeur de manière fiable, il faut plus qu'un bon modèle : un cadre soigneusement conçu et adapté à un ensemble de tâches est nécessaire.
L'algorithme de base d'un agent est simple : donner le contexte au LLM et le laisser appeler des outils en boucle jusqu'à ce que la tâche soit terminée. C'est la boucle la plus fondamentale. Mais c'est loin d'être la seule boucle qui anime les agents. @swyx a récemment écrit un excellent article sur le "loopcraft : l'art d'empiler les boucles", l'idée que l'on peut empiler et étendre les boucles pour construire des agents plus efficaces.
Voici comment nous envisageons cette pile, et comment instrumenter chaque niveau avec les primitives de LangChain.
Boucle 1 : L'agent
Au cœur, un agent n'est qu'un modèle qui appelle des outils en boucle jusqu'à ce qu'une tâche soit terminée.
C'est ce que create_agent de LangChain vous offre. Choisissez n'importe quel modèle, branchez des outils, et vous obtenez une boucle d'agent fonctionnelle. Les outils sont ce qui donne à l'agent la capacité d'agir dans le monde réel.
Prenons l'exemple de notre agent de documentation interne (que nous utiliserons comme fil conducteur pour le reste de cet article). Au premier niveau de boucle, il reçoit une demande d'amélioration de la documentation. Le modèle planifie et rédige des modifications, et il utilise des outils pour cloner des dépôts, lire des fichiers, écrire des docs, ouvrir une pull request, etc.
Niveau 2 : Boucle de vérification
La boucle d'agent fait le travail, mais elle ne produit pas toujours un résultat correct ou cohérent du premier coup. Lorsque la cohérence est importante, il est souvent utile de l'envelopper dans une boucle de vérification qui vérifie la sortie et renvoie des commentaires au modèle en cas d'insuffisance.
La boucle de vérification ajoute un évaluateur : quelque chose qui vérifie la sortie de l'agent par rapport à une grille d'évaluation et, si elle échoue, renvoie le résultat avec des commentaires. Les évaluateurs peuvent être déterministes ou agentiques (le LLM comme juge en est un exemple classique).
RubricMiddleware gère ce modèle, ou vous pouvez le configurer avec un hook after_agent sur create_agent.
Pour notre exemple de rédacteur de documentation, l'évaluateur exécute des tests après chaque tentative, vérifiant que tous les liens fonctionnent, que toutes les vérifications CI réussissent et que le diff se limite à ce qui a été réellement demandé. Aucune relecture manuelle n'est nécessaire pour détecter ces types d'erreurs.
Un compromis : l'ajout de la vérification augmente la latence et le coût par exécution. Cela vaut le coup quand la qualité prime sur la vitesse, ce qui est le cas dans la plupart des cas d'usage en production.
Niveau 3 : Boucle pilotée par les événements
L'une des parties les plus importantes du développement d'agents est la couche d'intégration : connecter votre agent à votre écosystème pour qu'il puisse fonctionner en arrière-plan.
La boucle pilotée par les événements connecte votre agent à votre écosystème. Un événement se déclenche — un nouveau document arrive, un planning se déclenche, un webhook est reçu — et l'agent s'exécute. L'agent n'est pas quelque chose que vous invoquez manuellement ; c'est un composant qui fonctionne en continu au sein d'un système plus vaste.
LangSmith Deployment prend en charge l'infrastructure de déclenchement, y compris les plannings cron et les webhooks. Un exemple populaire de crons en action est les "heartbeats" dans openclaw, qui transforment votre agent en un assistant proactif toujours actif.
Notre agent de documentation est propulsé par Fleet, notre constructeur d'agents sans code. Les channels et schedules de Fleet gèrent les déclencheurs pilotés par les événements et les cron. Nous utilisons un channel pour lancer l'agent de documentation à chaque fois qu'un message est envoyé dans notre canal Slack #docs-plz.
Niveau 4 : Boucle d'optimisation (Hill climbing)
Les trois premières boucles automatisent le travail. La quatrième (et sans doute la plus importante) automatise l'amélioration !
Chaque exécution d'agent produit une trace : un enregistrement de ce que le modèle a fait, des outils qu'il a appelés, des retours de l'évaluateur, etc. Ces traces contiennent des signaux de grande valeur sur ce qui fonctionne et ce qui ne fonctionne pas. La boucle d'optimisation exécute un agent d'analyse sur ces traces et utilise les résultats pour réécrire le cadre avec une configuration améliorée. Cela peut inclure des ajustements de prompt/outil ou de l'évaluateur.
Dans LangSmith, vous pouvez utiliser Engine, notre agent d'analyse de traces, pour instrumenter cette quatrième boucle.
Pour terminer l'analogie avec l'agent de documentation, nous exécutons Engine sur les traces de cet agent pour détecter d'éventuels problèmes. Lorsque plusieurs traces signalent un problème potentiel, un ticket est créé demandant des modifications du prompt ou de l'outil incriminé.
Le point clé ici est que la flèche de retour ne revient pas simplement au début — elle atteint l'intérieur et met directement à jour la boucle d'agent. Chaque cycle de la boucle externe rend les boucles internes plus efficaces.
En perspective :
la configuration des prompts et des outils sont les éléments les plus simples à améliorer, mais ce ne sont pas les seules options. Pour les équipes utilisant des modèles open-weight, la boucle d'optimisation peut alimenter un fine-tuning par apprentissage par renforcement, en utilisant les résultats des traces ou des évaluations comme signal d'entraînement pour améliorer le modèle lui-même. Le contexte auxiliaire comme la mémoire et les compétences récupérées peut être amélioré de la même manière. La boucle est le modèle ; ce qu'elle optimise vous appartient.
Supervision et expertise humaine
L'automatisation ne signifie pas supprimer les humains de la boucle. À chaque niveau, il existe des points naturels où la supervision humaine apporte de la valeur. Un évaluateur automatisé peut vérifier si les liens fonctionnent ; il faut un humain pour remarquer que le cadrage n'est pas adapté au public. Ce type de jugement, issu du contexte, de l'expérience et du goût, est précisément là où la relecture humaine trouve sa place.
Une certaine expertise doit être codifiée dans les prompts/outils eux-mêmes, mais pour les actions sensibles, une relecture humaine en direct est essentielle (pensez aux transactions financières, opérations BD, etc.). LangChain permet d'instrumenter facilement ces points de contact dans chaque boucle :
- Dans la boucle d'agent, exiger une saisie humaine avant les actions/appels d'outils sensibles
- Dans la boucle de vérification, un humain peut agir comme évaluateur pour les flux de travail sensibles
- Dans la boucle applicative, un humain peut approuver les sorties avant qu'elles ne soient renvoyées à l'utilisateur final
- Dans la boucle d'optimisation, les améliorations du cadre peuvent passer par une relecture humaine avant le déploiement
Tous les frameworks open source de LangChain font de l'ajout d'un "humain dans la boucle" une primitive de première classe.
Synthèse
Si vous préférez une vue plus tabulaire, voici comment ces quatre boucles s'empilent :
Boucle
Ce qu'elle fait
Impact
Primitive LangChain
1 : Boucle d'agent
(modèle + outils)
Le modèle appelle des outils de manière répétée jusqu'à ce qu'une tâche soit terminée
Automatiser le travail
create_agent
, tout modèle supporté par LangChain
2 : Boucle de vérification
(agent + évaluateur)
L'agent s'exécute, la sortie est notée par rapport à une grille, réessayée avec des commentaires si elle échoue
Assurer la qualité
RubricMiddleware
3 : Boucle événementielle
(vérification + système)
Les événements déclenchent des exécutions d'agent qui mettent à jour un système réel
Travailler à grande échelle
LangSmith Deployment / Channels Fleet
4 : Boucle d'optimisation
(système + moteur)
Les traces de production alimentent un agent d'analyse qui améliore la configuration du cadre
Amélioration continue
LangSmith Engine
Voici à quoi ressemble l'ingénierie des boucles — ou loopcraft, comme le dit @swyx — dans la pratique. Des leaders de l'IA comme Steipete, Boris, et Andrej sont tous arrivés à la même conclusion : le potentiel des agents réside dans les boucles que vous construisez autour d'eux.
Nous réfléchissons aux boucles 1 et 2 depuis un certain temps. Mais l'accent devrait se déplacer vers les boucles 3 et 4, où la valeur se multiplie en intégrant les agents dans votre écosystème, qui s'améliorent continuellement en réponse à vos critères.
Satya pose les enjeux organisationnels : les entreprises qui construisent des boucles d'apprentissage tôt, où le jugement humain et le capital de jetons se cumulent, construiront un avantage difficile à reproduire.
Remerciements
Merci à @Vtrivedy10 , @masondrxy , @hwchase17 , et @huntlovell pour leur relecture attentive.
