Construire des agents IA efficaces
(anthropic.com)- D’après l’expérience de terrain d’Anthropic, les agents LLM qui réussissent partent souvent de patterns simples et composables plutôt que de frameworks complexes
- Les systèmes agentiques se divisent entre des workflows qui suivent un chemin de code prédéfini, et des agents où le LLM décide dynamiquement de la procédure et de l’usage des outils
- De nombreuses applications LLM n’ont besoin que d’un seul appel au LLM enrichi de recherche et d’exemples in-context, et la complexité ne devrait augmenter que si les évaluations en prouvent l’efficacité
- Les frameworks permettent de démarrer rapidement, mais leur couche d’abstraction peut compliquer le débogage en masquant les prompts et les réponses
- Les agents autonomes sont puissants sur les problèmes ouverts, mais exigent des coûts plus élevés et présentent un risque d’accumulation d’erreurs, d’où la nécessité de tests en sandbox, de garde-fous et d’une conception claire des outils
Distinction fondamentale des systèmes agentiques
- Les systèmes agentiques sont un terme large, qui va des systèmes entièrement autonomes opérant indépendamment sur de longues durées jusqu’aux implémentations suivant des workflows prédéfinis
- Anthropic considère toutes ces variantes comme des systèmes agentiques, mais les distingue architecturalement en deux catégories
- Workflows : le LLM et les outils sont orchestrés selon un chemin de code prédéfini
- Agents : le LLM dirige et contrôle dynamiquement la manière d’exécuter la tâche, la procédure et l’usage des outils
Comment décider quand utiliser un agent
- Pour les applications LLM, il est recommandé de partir de la solution la plus simple possible, puis d’augmenter la complexité uniquement si nécessaire
- Les systèmes agentiques impliquent un compromis entre de meilleures performances sur la tâche et davantage de latence et de coûts ; il faut donc d’abord vérifier si ce compromis est réellement nécessaire
- Même lorsqu’un certain niveau de complexité est requis, les critères de choix diffèrent
- Pour des tâches bien définies, les workflows apportent prévisibilité et cohérence
- Pour des tâches nécessitant une forte flexibilité à grande échelle et des décisions pilotées par le modèle, les agents sont plus adaptés
- Dans de nombreux cas, il suffit d’optimiser un seul appel au LLM avec de la recherche et des exemples in-context
Quand utiliser un framework
- Les outils présentés pour implémenter des systèmes agentiques incluent Claude Agent SDK, Strands Agents SDK by AWS, Rivet, Vellum
- Ces frameworks simplifient les tâches standard de bas niveau, comme les appels au LLM, la définition et le parsing des outils, ou l’enchaînement des appels, ce qui permet de démarrer plus vite
- Cependant, cette couche d’abstraction supplémentaire peut compliquer le débogage en masquant les prompts et les réponses réels
- Elle peut aussi inciter à ajouter de la complexité inutile, même lorsque des configurations simples suffisent
- Il est généralement préférable pour les développeurs de commencer par utiliser directement l’API du LLM
- Beaucoup de patterns peuvent être implémentés en quelques lignes de code
- Même avec un framework, il faut comprendre le fonctionnement du code sous-jacent
- De mauvaises hypothèses sur le fonctionnement interne sont une cause fréquente d’erreurs côté client
- Des implémentations d’exemple sont disponibles dans le cookbook
Bloc de base : le LLM augmenté
- Le bloc de base des systèmes agentiques est un LLM augmenté avec des capacités comme la recherche, les outils ou la mémoire
- Les modèles actuels peuvent utiliser activement ces capacités en générant directement des requêtes de recherche, en sélectionnant les bons outils et en décidant quelles informations conserver
- Lors de l’implémentation, il faut se concentrer sur deux points
- Adapter les capacités au cas d’usage
- Fournir des interfaces documentées faciles à utiliser pour le LLM
- Une approche d’implémentation présentée est le Model Context Protocol
- Les développeurs peuvent s’intégrer à un écosystème d’outils tiers via une simple client implementation
Patterns de workflow
-
Prompt chaining
- Le prompt chaining consiste à découper une tâche en étapes séquentielles, où chaque appel au LLM traite la sortie du précédent
- Des vérifications programmatiques peuvent être insérées à chaque étape intermédiaire pour confirmer que le processus suit la bonne trajectoire
- Ce pattern convient lorsque la tâche se décompose proprement en sous-tâches fixes
- Le principal compromis consiste à accepter davantage de latence pour réduire la difficulté de chaque appel au LLM et améliorer ainsi la précision
- Exemples
- Générer un texte marketing puis le traduire dans une autre langue
- Rédiger le plan d’un document, vérifier qu’il respecte les critères, puis rédiger le document à partir de ce plan
-
Routage
- Le routage consiste à classifier l’entrée avant de l’envoyer vers un traitement spécialisé en aval
- Il permet de séparer les responsabilités et de créer des prompts plus spécialisés
- Sans cette structure, une optimisation pour un type d’entrée peut dégrader les performances sur d’autres types
- Il fonctionne bien lorsque des catégories distinctes appellent des traitements séparés et que le LLM, ou un modèle/algorithme de classification plus traditionnel, peut les identifier correctement
- Exemples
- Acheminer des requêtes de service client comme les questions générales, les demandes de remboursement ou le support technique vers des processus, prompts et outils différents
- Router les questions simples et générales vers un modèle plus petit et plus économique comme Claude Haiku 4.5, et les questions difficiles ou atypiques vers un modèle plus puissant comme Claude Sonnet 4.5
-
Parallélisation
- La parallélisation consiste à faire traiter une tâche simultanément par le LLM, puis à agréger les sorties par programmation
- Il existe deux variantes principales
- Sectionnement : découper la tâche en sous-tâches indépendantes exécutées en parallèle
- Vote : exécuter plusieurs fois la même tâche pour obtenir des sorties variées
- C’est efficace lorsqu’on peut accélérer le traitement en divisant la tâche, ou lorsqu’il faut plusieurs points de vue ou tentatives pour augmenter la fiabilité
- Sur des tâches complexes, confier chaque angle d’analyse à un appel séparé au LLM permet de mieux se concentrer sur chaque aspect
- Exemples
- Un garde-fou où une instance du modèle traite la requête utilisateur pendant qu’une autre vérifie les contenus ou demandes inappropriés
- Dans l’évaluation des performances d’un LLM, chaque appel évalue un aspect différent des performances du modèle
- Plusieurs prompts examinent des vulnérabilités dans du code et signalent un problème si nécessaire
- Dans l’évaluation du caractère inapproprié d’un contenu, plusieurs prompts et un seuil de vote permettent d’équilibrer faux positifs et faux négatifs
-
Orchestrateur-travailleurs
- Le pattern orchestrateur-travailleurs repose sur un LLM central qui décompose dynamiquement la tâche, la délègue à des LLM workers, puis agrège les résultats
- Il convient aux tâches complexes dont les sous-tâches nécessaires ne peuvent pas être prédites à l’avance
- Il peut ressembler à la parallélisation, mais la différence clé est la flexibilité
- En parallélisation, les sous-tâches sont prédéfinies
- En orchestrateur-travailleurs, l’orchestrateur décide des sous-tâches en fonction de l’entrée
- Exemples
- Un produit de coding qui effectue à chaque fois des modifications complexes dans plusieurs fichiers
- Une tâche de recherche qui collecte et analyse des informations potentiellement pertinentes depuis plusieurs sources
-
Évaluateur-optimiseur
- Le pattern évaluateur-optimiseur est une boucle où un appel au LLM produit une réponse, et un autre appel au LLM l’évalue et fournit un feedback
- Il est particulièrement efficace lorsqu’il existe des critères d’évaluation clairs et qu’une amélioration itérative apporte une valeur mesurable
- Deux signaux indiquent qu’il convient bien
- Quand un humain formule clairement un feedback, la réponse du LLM s’améliore réellement
- Le LLM est capable de fournir ce type de feedback
- Cela ressemble au processus d’écriture itératif par lequel passe un auteur humain pour produire un document abouti
- Exemples
- En traduction littéraire, un LLM évaluateur critique les nuances qu’un LLM de traduction peut manquer au premier passage
- Dans une tâche de recherche complexe, l’évaluateur détermine si une recherche supplémentaire est nécessaire
Agents autonomes
- Les agents commencent à être utilisés en production à mesure que les LLM deviennent capables de comprendre des entrées complexes, de raisonner et planifier, d’utiliser des outils de façon fiable et de se remettre d’erreurs
- La tâche commence par une instruction humaine ou une conversation
- Une fois la tâche clarifiée, l’agent élabore un plan et agit de manière autonome
- Il peut revenir vers l’humain s’il a besoin d’informations supplémentaires ou d’un jugement
- Pendant l’exécution, il est important d’obtenir à chaque étape des signaux de validation réels depuis l’environnement
- Par exemple : résultats d’appel d’outil, résultats d’exécution de code
- Cela permet d’évaluer l’avancement
- L’agent peut s’arrêter à des checkpoints ou en cas de blocage pour demander un feedback humain
- Les tâches se terminent souvent à leur achèvement, mais il est aussi courant de définir des conditions d’arrêt comme un nombre maximal d’itérations afin de garder le contrôle
- L’implémentation elle-même est souvent simple
- Un agent est généralement un LLM qui utilise des outils dans une boucle en s’appuyant sur le feedback de l’environnement
- Il faut donc concevoir avec soin et clarté l’ensemble d’outils et leur documentation
- Conditions d’utilisation
- Problèmes ouverts pour lesquels le nombre d’étapes nécessaires est difficile ou impossible à prévoir
- Tâches pour lesquelles on ne peut pas coder en dur un chemin fixe
- Situations où le LLM peut opérer sur plusieurs tours et où un certain niveau de confiance dans ses décisions est nécessaire
- Contraintes
- L’autonomie implique des coûts plus élevés et un risque d’accumulation d’erreurs
- Des tests approfondis en environnement sandbox et des garde-fous adaptés sont recommandés
- Exemples
- Un agent de coding qui résout des SWE-bench tasks nécessitant des modifications dans plusieurs fichiers
- L’implémentation de référence “computer use”, où Claude utilise un ordinateur pour effectuer des tâches
Combiner et personnaliser les patterns
- Les blocs de base présentés ne sont pas des recettes figées, mais des patterns communs que les développeurs peuvent adapter et combiner selon leur cas d’usage
- Comme pour les capacités LLM en général, la clé du succès réside dans la mesure des performances et l’amélioration itérative de l’implémentation
- Il ne faut ajouter de la complexité que si elle améliore réellement les résultats
Principes d’implémentation
- Dans l’univers des LLM, la réussite ne consiste pas à construire le système le plus sophistiqué, mais le bon système pour le besoin réel
- L’ordre recommandé est le suivant
- Commencer par des prompts simples
- Optimiser les prompts au moyen d’évaluations complètes
- N’ajouter un système agentique multi-étapes que si la solution simple ne suffit pas
- Lors de l’implémentation d’un agent, trois principes sont importants
- Préserver la simplicité de la conception
- Donner la priorité à la transparence en montrant explicitement les étapes de planification de l’agent
- Concevoir avec soin l’agent-computer interface, ou ACI, grâce à une documentation et des tests rigoureux des outils
- Les frameworks aident à démarrer rapidement, mais en passant en production, il peut aussi être nécessaire de réduire les couches d’abstraction et de construire à partir de composants de base
Domaines d’application concrets
-
Support client
- Le support client combine une interface de chatbot familière avec une extension fonctionnelle via l’intégration d’outils
- Il existe plusieurs raisons pour lesquelles il se prête naturellement à des agents plus ouverts
- Les interactions de support suivent un flux conversationnel tout en nécessitant l’accès à des informations et actions externes
- Des outils peuvent être intégrés pour récupérer des données client, l’historique des commandes ou des documents de base de connaissances
- Des actions comme le traitement d’un remboursement ou la mise à jour d’un ticket peuvent être réalisées par programmation
- Le succès peut être mesuré clairement à partir d’une résolution définie par l’utilisateur
- Plusieurs entreprises ont montré la viabilité de cette approche avec des modèles tarifaires à l’usage qui ne facturent que les résolutions réussies
-
Agents de coding
- Le développement logiciel a montré un fort potentiel, à mesure que les capacités des LLM évoluaient de la complétion de code à la résolution autonome de problèmes
- Plusieurs raisons expliquent l’efficacité des agents
- Les solutions de code peuvent être vérifiées par des tests automatisés
- Les agents peuvent utiliser les résultats des tests comme feedback pour améliorer itérativement leurs solutions
- L’espace du problème est bien défini et structuré
- La qualité de la sortie peut être mesurée objectivement
- Dans l’implémentation d’Anthropic, les agents peuvent résoudre de vrais issues GitHub du benchmark SWE-bench Verified à partir de la seule description de la pull request
- Même si les tests automatisés aident à valider les fonctionnalités, la revue humaine reste essentielle pour vérifier qu’une solution répond bien aux exigences plus larges du système
Prompt engineering des outils
- Dans tout système agentique, les outils ont de fortes chances d’être un composant essentiel
- Les Tools permettent à Claude d’interagir avec des services externes et des API
- La structure exacte et les définitions sont spécifiées dans l’API
- Quand Claude planifie un appel d’outil, la réponse API inclut un tool use block
- La définition et la spécification des outils méritent autant d’attention en prompt engineering que le prompt global
-
Choisir le format des outils
- Une même tâche peut être spécifiée de plusieurs façons
- L’édition de fichier peut être exprimée sous forme de diff ou comme une réécriture complète du fichier
- Une sortie structurée peut être renvoyée sous forme de code dans du Markdown ou de code dans du JSON
- Du point de vue de l’ingénierie logicielle, ces différences de format peuvent être convertibles sans perte, mais pour un LLM certains formats sont beaucoup plus difficiles à produire
- Écrire un diff impose de savoir à l’avance combien de lignes changent dans l’en-tête du chunk avant d’écrire le nouveau code
- Écrire du code dans du JSON nécessite en plus d’échapper les retours à la ligne et les guillemets
- Lors du choix du format d’un outil, il faut éviter d’enfermer le modèle dans une contrainte de format inutile
- Lui laisser suffisamment de tokens de réflexion avant qu’il ne soit forcé dans un format rigide
- Rester aussi proche que possible de formats qu’il rencontre naturellement dans les textes d’Internet
- Supprimer le surcoût de format comme compter précisément les lignes sur des milliers de lignes de code ou échapper des chaînes de code
- Une même tâche peut être spécifiée de plusieurs façons
-
Concevoir l’ACI
- Il faut investir autant d’effort dans la conception de l’agent-computer interface (ACI) que dans l’interface homme-machine (HCI)
- Une bonne définition d’outil inclut souvent des exemples d’usage, des edge cases, des exigences de format d’entrée et des frontières claires avec les autres outils
- Les noms de paramètres et leurs descriptions doivent être ajustés pour faciliter la compréhension du modèle
- C’est comparable à la rédaction d’un excellent docstring pour un développeur junior de l’équipe
- C’est particulièrement important quand de nombreux outils se ressemblent
- Il faut tester l’usage des outils par le modèle
- Lors de la création de l’agent pour SWE-bench, plus de temps a été consacré à l’optimisation des outils qu’au prompt global
- L’agent faisait des erreurs avec un outil utilisant des chemins de fichiers relatifs après avoir quitté le répertoire racine
- Une fois l’outil modifié pour exiger systématiquement des chemins de fichiers absolus, le modèle a utilisé cette méthode sans erreur
1 commentaires
Commentaires sur Hacker News
Je pense que cet article reste l’un des bons textes sur le sujet. J’ai particulièrement apprécié qu’il définisse clairement dès le début ce qu’il entend par agent IA
Ici, il est défini comme « un système dans lequel le LLM pilote dynamiquement son propre processus de traitement et l’usage des outils, tout en gardant le contrôle sur la manière d’accomplir la tâche »
J’ai aussi trouvé très bonne la façon dont il distingue « agent » et « workflow », tout en décrivant plusieurs patterns de workflow utiles
J’avais laissé quelques notes sur cet article à sa sortie : https://simonwillison.net/2024/Dec/20/building-effective-age...
Il y a aussi un article plus récent d’Anthropic, https://www.anthropic.com/engineering/built-multi-agent-rese... — « How we built our multi-agent research system » — qui est lui aussi très intéressant, et dont j’ai également pris des notes : https://simonwillison.net/2025/Jun/14/multi-agent-research-s...
Pour apprendre, ça peut se défendre, mais le premier avantage d’un bon framework est de permettre de tester facilement des LLM de fournisseurs différents
On dirait une tentative de redéfinir le workflow pour maintenir une distinction, mais la plupart des agents ne sont en réalité que des workflows itératifs qui appellent dynamiquement quelque chose en fonction de la réponse du LLM. Les moteurs de workflow modernes sont très dynamiques
Je pense que le meilleur conseil de tout l’article, et de loin, est celui-ci : « simplifier les tâches standard de bas niveau comme les appels au LLM, la définition et le parsing des outils, ou l’enchaînement des appels peut faciliter le démarrage, mais cela crée souvent une couche d’abstraction supplémentaire qui masque les prompts et les réponses de base, ce qui complique le débogage. Cela pousse aussi à ajouter de la complexité alors qu’une composition plus simple suffirait. Je recommande aux développeurs de commencer par utiliser directement l’API du LLM »
Fondamentalement, utiliser un énorme framework pour envoyer un tableau de chaînes à un service web n’a aucun sens
Sur un projet en entreprise, nous avons aussi supprimé LangChain et LangGraph : en pratique, ils n’apportaient aucune valeur et ne faisaient qu’augmenter la complexité. On finissait par écrire plus de code à cause du boilerplate du framework que sans lui
On peut exécuter toutes les étapes de génération d’images avec Stable Diffusion ou écrire directement le code shader, mais dès qu’on a plus d’un flux ou d’une tâche et qu’on est en phase d’expérimentation, utiliser comfy-UI ou un shader graph est beaucoup plus propre
Six mois ont passé, et dans l’IA cela ressemble déjà à une période assez longue. J’ai relu cet article plusieurs fois il y a quelques mois, mais aujourd’hui il semble clair que le développement d’agents a atteint un goulot d’étranglement
Même les dernières versions de Gemini donnent l’impression de régresser
L’orchestration multi-agent est difficile à contrôler, et plus les modèles progressent, moins le besoin de multi-agent paraît important. À l’inverse, plus les performances des modèles sont faibles, plus une IA à périmètre étroit devient pertinente d’un point de vue business
Existe-t-il des exemples d’agents qui, en production réelle, permettent d’économiser de l’argent à l’entreprise et font un travail qui apporte une vraie valeur ? Je ne parle pas de cas du genre écrire du texte pour remplir le vide dans un paquet de chips.
https://www.gbif.org/news/6aw2VFiEHYlqb48w86uKSf/chatipt-sys...
C’est encore en bêta.
D’après le communiqué de presse, le chatbot de Rukaya Johaadien fournit une assistance conversationnelle aux étudiants et chercheurs qui disposent de données sur la biodiversité mais publient ces données pour la première fois, ou seulement rarement. Il aide à nettoyer et standardiser les tableurs, à créer des métadonnées de base, puis guide la publication de jeux de données bien structurés sur GBIF.org au format Darwin Core Archive.
Jusqu’à présent, il était difficile de publier à grande échelle des données de haute qualité issues de thèses de doctorat ou de master, ou de petites études sur la biodiversité. La standardisation des données demandait en général des connaissances en langages de programmation, en techniques de gestion des données et en logiciels spécialisés.
L’accès à l’Integrated Publishing Toolkit (IPT), l’application centrale de partage de données du réseau GBIF, est aussi compliqué pour les débutants. Comme le temps et les ressources des responsables de nœuds sont limités, et que les utilisateurs occasionnels oublient facilement chaque année la procédure exacte et les détails, la seule formation ne suffit pas à lever les barrières logistiques et linguistiques.
« La standardisation des données est difficile, et on ne devient pas biologiste parce qu’on aime coder ou Excel ; beaucoup de données potentiellement précieuses sont donc abandonnées. En voyant à quel point les grands modèles de langage sont devenus performants pour générer du code et travailler sur les données, j’ai créé un outil qui guide les utilisateurs non techniques avec des questions simples, traite autant que possible les données désordonnées, puis les publie rapidement et automatiquement sur GBIF », explique-t-il.
Pour chaque alerte ou ticket entrant, l’agent mène une pré-enquête sur les API, bases de données, etc. pertinents afin d’identifier les faux positifs et d’apporter davantage de contexte sur les vrais problèmes. Cela réduit le temps humain nécessaire et accélère le traitement.
Ils utilisent le même raisonnement agentique pour les tâches d’exploration : au-delà du simple text-to-SQL, le LLM enquête à leur place pendant 2 à 10 minutes dans Splunk, Databricks, etc.
En interne, ils disposent d’outils comme une couche sémantique au-dessus des bases de données, ainsi que des analyseurs à grande échelle de logs, de texte et de dataframes.
J’ai essayé un workflow n8n que j’ai construit moi-même, presque identique à la configuration décrite dans l’article. Il m’a coûté 3 dollars et au moins 3 minutes pour obtenir une réponse à une question simple.
Pour l’instant, je vais continuer à utiliser la recherche classique.
Cet article rappelle bien qu’il faut commencer par la chose la plus simple qui fonctionne, puis n’ajouter de la complexité que lorsqu’elle est vraiment nécessaire.
Avec seulement quelques appels LLM bien définis et une logique d’assemblage légère, on obtient le plus souvent un système plus fiable, plus facile à déboguer et bien moins coûteux à exécuter. Les agents sophistiqués et riches en fonctionnalités créent souvent plus de problèmes qu’ils n’en résolvent.
Travaillant dans une entreprise qui a de vrais agents en production, et pas seulement des workflows, je ne peux absolument pas être d’accord avec la phrase d’ouverture ici : « utilisez un framework d’agents comme LangGraph ».
Nous avons fait exactement cela, puis avons dû tout jeter au bout d’un mois ; ensuite, nous avons tout reconstruit depuis zéro, et nous avons maintenant un système qui passe plutôt bien à l’échelle.
Pour être juste, il y a peut-être une place pour les frameworks d’agents. Mais le domaine des agents est encore beaucoup trop jeune pour qu’un framework soit vraiment assez bon.
J’ai même un avis un peu plus opposé : le domaine avance si vite qu’il est possible qu’un framework vraiment assez bon n’émerge jamais.
Les frameworks facilitent les débuts, mais la couche d’abstraction supplémentaire peut masquer les prompts et les réponses, compliquer le débogage et ajouter de la complexité là où une configuration plus simple suffirait. C’est pourquoi ils recommandent de commencer par utiliser directement l’API du LLM, d’autant que beaucoup de ces patterns peuvent être implémentés en quelques lignes de code.
J’ai vu beaucoup de commentaires disant que les équipes pragmatiques avaient pour la plupart abandonné LangChain, LangGraph, Haystack, Crew et autres au profit d’un code interne plus simple, mais j’ai encore du mal à voir concrètement comment des éléments comme l’appel d’outils sont réellement implémentés dans la pratique.
Si vous avez des liens ou des documents qui ont servi de base à votre travail, pourriez-vous les partager ?
C’est un article de décembre 2024, mais étrangement il donne l’impression de dater d’il y a très longtemps.
C’est l’article qui m’a fait revoir Anthropic comme un « partenaire pragmatique » pour le développement d’outils IA.
https://news.ycombinator.com/item?id=44260988
On dirait que la hype autour des agents est un peu retombée maintenant.
L’idée d’utiliser des « patterns simples et composables » est étrangement rassurante.
J’aime le fait que l’adage « faire une seule chose, mais bien » reste toujours valable après toutes ces décennies. La composabilité, c’est le top.