Construire des agents IA efficaces

• Les équipes qui ont réussi à mettre en œuvre des agents basés sur des LLM ont tendance à utiliser des patterns simples et composables plutôt que des frameworks complexes
• Il faut comprendre les différences structurelles entre workflows et agents, et il est recommandé d’introduire toujours le minimum de complexité nécessaire pour aboutir à la meilleure solution
• Divers patterns d’agents (chaînage de prompts, routage, parallélisation, orchestrateur-workers, boucle évaluation-optimisation, etc.) sont utilisés en production, chacun avec ses cas d’usage, avantages et inconvénients
• Lors de l’implémentation d’agents, simplicité, transparence et conception d’interface sont les principes clés, avec une attention particulière à la conception des outils et au prompt engineering
• Les cas où les agents apportent une vraie valeur, notamment dans le support client ou les environnements de développement logiciel, se multiplient progressivement

---

Vue d’ensemble

Au cours de l’année écoulée, Anthropic a travaillé avec des équipes de nombreux secteurs pour construire des agents basés sur de grands modèles de langage (LLM). Dans la pratique, les déploiements d’agents les plus réussis reposaient plus souvent sur des patterns simples et composables que sur des frameworks complexes ou des bibliothèques spécialisées. Ce billet partage des enseignements tirés du travail avec les clients et de l’expérience interne, ainsi que des conseils concrets pour construire des agents efficaces.

Qu’est-ce qu’un agent ?

Un agent peut être défini de différentes manières.

• Pour certains, il s’agit d’un système entièrement autonome capable d’accomplir seul des tâches complexes à l’aide d’outils externes
• Pour d’autres, c’est une implémentation prescriptive qui suit un workflow limité ou un processus prédéfini

Anthropic classe les deux dans la catégorie des systèmes agentiques, tout en distinguant une différence architecturale importante entre workflows et agents.

• Workflow : structure dans laquelle le LLM et les outils sont orchestrés selon des chemins de code prédéfinis
• Agent : le LLM décide lui-même dynamiquement de l’usage des outils et du processus, et garde le contrôle sur la manière d’accomplir la tâche

Ce billet décrit en détail ces deux types de systèmes, et les cas d’usage concrets sont abordés dans l’annexe 1.

Quand utiliser — et ne pas utiliser — des agents

Lors du développement d’une application, il est préférable d’adopter le principe de complexité minimale, en n’ajoutant de la complexité que progressivement et uniquement lorsque c’est nécessaire.

• Les systèmes agentiques peuvent améliorer la performance sur la tâche même s’il faut sacrifier en partie la latence et le coût
• Quand la complexité n’est pas indispensable, un simple appel à un LLM, enrichi d’exemples ou connecté à la recherche, suffit souvent
• Les workflows conviennent aux contextes où la prévisibilité et la cohérence sont essentielles ; les agents sont adaptés là où il faut de la flexibilité et de l’échelle

Quand et comment utiliser un framework

Il existe de nombreux frameworks qui facilitent l’implémentation de systèmes agentiques.

• LangGraph (LangChain)
• Amazon Bedrock AI Agent framework
• Rivet, Vellum, etc.

Ces frameworks simplifient les tâches de bas niveau comme les appels au LLM, la définition et le parsing des outils, ou la composition de chaînes d’appels. Mais une abstraction excessive peut rendre le flux réel des prompts et des réponses opaque ou ajouter une complexité inutile.

• Il est recommandé aux développeurs de commencer autant que possible par utiliser directement l’API du LLM
• Même en utilisant un framework, il faut en comprendre précisément le fonctionnement interne

Des exemples d’implémentation sont disponibles dans anthropic-cookbook.

Building blocks, workflows et patterns d’agents

Anthropic présente plusieurs patterns de systèmes agentiques fréquemment utilisés en environnement de production.

Building block : LLM augmenté

Au cœur d’un système agentique se trouve un LLM enrichi de fonctionnalités comme la recherche, les outils et la mémoire.

• Le modèle peut lui-même générer des requêtes de recherche, choisir l’outil approprié et stocker des informations
• Le point clé de l’implémentation est d’adapter ces capacités au cas d’usage et de fournir au LLM une interface claire et documentée

Le Model Context Protocol, récemment publié, permet d’intégrer facilement divers outils tiers.

Explication par type de workflow

Chaînage de prompts

• La tâche est décomposée en une série d’étapes, chaque appel au LLM traitant le résultat de l’étape précédente
• Il est possible de piloter le processus en ajoutant une validation programmatique (gate) à chaque étape
• Exemples d’usage : génération de textes marketing puis traduction, conception d’un plan de document → validation → rédaction du contenu

Routage

• L’entrée est classée puis dirigée vers une tâche suivante adaptée
• Il est possible d’utiliser des prompts et des outils spécialisés selon chaque catégorie
• Exemples d’usage : orientation des demandes client (remboursement, support technique, etc.), choix du modèle selon le niveau de difficulté

Parallélisation

• La tâche est divisée en sous-unités, traitées en parallèle puis agrégées
• Sectioning : chaque partie est traitée indépendamment
• Voting : la même tâche est répétée selon plusieurs perspectives ou prompts, avec recours à un vote majoritaire, etc.
• Exemples d’usage : filtrage des questions utilisateurs et séparation des réponses, évaluation automatique, revue de code

Orchestrateur-workers

• Un LLM central décompose et assigne dynamiquement la tâche, puis plusieurs LLM workers traitent chacun une partie avant assemblage
• Adapté aux sous-tâches non prédéfinies et variables selon l’entrée
• Exemples d’usage : codage impliquant des modifications sur plusieurs fichiers, exploration d’information complexe

Boucle évaluation-optimisation

• Un LLM de réponse et un LLM d’évaluation sont utilisés dans une boucle itérative
• Adapté aux situations où des critères d’évaluation clairs et une amélioration fondée sur le feedback apportent de la valeur
• Exemples d’usage : évaluation de nuances subtiles en traduction littéraire, exploration d’information sur plusieurs tours

Agents

• Avec les progrès des LLM, des agents capables de gérer en production des entrées complexes, du raisonnement et de la planification, l’usage d’outils et la récupération après erreur ont émergé

• Le processus commence par une commande ou une conversation utilisateur → clarification de la tâche → exécution autonome → possibilité de feedback à des points de contrôle intermédiaires → fin à l’achèvement ou selon une condition d’arrêt

• En pratique, le LLM itère en s’appuyant sur les retours de l’environnement (résultats d’outils, exécution de code), et l’ensemble des outils ainsi que leur documentation sont essentiels

• Exemples d’usage : agent de code pour résoudre des tâches SWE-bench, automatisation de l’utilisation d’un ordinateur basée sur Claude

• Champ d’application : problèmes ouverts où il est impossible de prédire le chemin ou les étapes, situations exigeant une confiance dans la prise de décision

• Il faut tenir compte du coût et du risque d’erreurs composites induits par une autonomie accrue ; des tests en sandbox et des garde-fous sont indispensables

Combinaison et personnalisation des patterns

• Les building blocks présentés ne sont pas des règles figées ; ils peuvent être combinés selon de nombreux contextes
• L’essentiel est de choisir la bonne structure via mesure des performances et amélioration itérative, puis d’ajouter de la complexité progressivement

Résumé et principes recommandés

La réussite d’un système LLM ne dépend ni de la complexité ni de la nouveauté technologique, mais du choix de l’approche juste pour l’objectif visé.

• Commencer par des prompts simples, évaluer les performances, optimiser par itérations, puis étendre progressivement la complexité

• Les trois grands principes de conception d’agents

  1. Préserver la simplicité
  2. Donner la priorité à la transparence (clarification dès la phase de conception)
  3. Accorder de l’importance à la documentation et aux tests des outils/interfaces

• Les frameworks permettent de démarrer rapidement, mais en pratique, la capacité à minimiser les couches d’abstraction et à implémenter directement détermine la fiabilité et la maintenabilité

Annexe 1 : cas d’usage concrets des agents

Support client

Le support client se prête naturellement aux agents grâce à la combinaison d’une interface de chatbot et de l’intégration d’outils.

• Interface conversationnelle et besoin de traitement métier ou de données externes coexistent
• Les outils peuvent se connecter aux informations client, à l’historique des commandes, à la base de connaissances, etc.
• Automatisation de tâches comme les remboursements ou la gestion de tickets
• Il est possible de définir clairement les critères de résolution

Dans les cas d’usage réussis, un modèle de facturation basé sur l’usage — selon un critère de résolution effective — a permis de valider l’efficacité des agents.

Agents de code

Dans les environnements de développement logiciel aussi, l’usage d’agents, notamment pour la résolution automatique de problèmes, a fortement progressé.

• Le code peut être validé via des tests automatisés
• Les résultats des tests peuvent alimenter une amélioration itérative
• La définition du problème est claire et la qualité du livrable peut être mesurée objectivement

Exemple d’implémentation interne chez Anthropic : sur le benchmark SWE-bench Verified, résolution de véritables issues GitHub à partir de la seule description de pull request. Au-delà des tests automatisés, une revue humaine reste importante pour vérifier la conformité aux exigences globales du système.

Annexe 2 : comment faire du prompt engineering pour les outils

Dans tous les systèmes agentiques, les outils sont un élément central.

• Les LLM comme Claude peuvent interagir avec des services externes via l’API en respectant précisément la structure et la définition attendues
• La réponse peut inclure un tool use block
• La définition et la spécification des outils exigent elles aussi une conception aussi minutieuse que le prompt engineering

Conseils pour concevoir le format des outils

• Prévoir suffisamment de tokens pour éviter que le modèle ne tombe dans des « pièges » d’écriture

• Il est recommandé d’utiliser des formats naturels largement rencontrés sur Internet

• Minimiser les surcoûts de formatage inutiles (par ex. comptage des lignes de code, échappement de chaînes, etc.)

• Il faut accorder autant de soin à l’agent-computer interface (ACI) qu’on en met habituellement à la conception d’une human-computer interface (HCI)

• Du point de vue du modèle, la compréhension et l’usage de l’outil doivent être « clairs » ; cela inclut aussi des exemples d’utilisation, les cas limites et le format d’entrée

• Les noms de paramètres et leurs descriptions doivent être conçus avec des termes intuitifs, comme lors de la rédaction d’une documentation (docstring)

• Tester les usages réels avec différentes valeurs d’entrée et améliorer par itérations

• Concevoir les arguments de façon à réduire les erreurs (Poka-yoke)

Lors de la construction de l’agent SWE-bench réel, davantage de temps a été investi dans l’optimisation de la conception des outils que dans le prompt global. Exemple : pour réduire les erreurs de chemin de fichier après sortie du dossier racine, le fait de n’accepter que des chemins absolus a permis un fonctionnement parfait.

[GN⁺]

Avis Hacker News

• Cet article commence par clarifier ce qu’il entend par « AI agents », et c’est particulièrement ce qui m’a marqué. La définition utilisée ici est celle d’un « système dans lequel un LLM gère de façon dynamique ses propres processus et l’usage des outils, et contrôle lui-même la manière dont la tâche est exécutée ». J’ai aussi apprécié la distinction faite entre « agent » et « workflow », ainsi que la manière dont plusieurs patterns de workflow pratiques sont présentés. J’avais également rédigé à l’époque mes propres notes sur ce texte : notes sur building-effective-agents. Plus récemment, le billet d’Anthropic sur la construction d’un système de recherche multi-agent m’a aussi semblé intéressant, et j’ai également publié des notes complémentaires à ce sujet : notes sur le système de recherche multi-agent

  • Je pense que la définition de workflow utilisée dans cet article n’est pas exacte. Aujourd’hui, de nombreux moteurs de workflow ne suivent plus un chemin de code prédéfini et fonctionnent souvent, dans les faits, de manière très proche d’un agent. L’auteur semble avoir redéfini le terme workflow pour établir une distinction, mais en pratique un agent n’est lui aussi qu’un workflow sous forme de boucle, piloté dynamiquement selon les réponses du LLM. Les moteurs de workflow récents sont eux aussi très dynamiques

  • L’un des co-auteurs de Building Effective Agents a également donné une conférence sur ce texte à l’AIE, et l’accueil a été excellent : vidéo YouTube

  • L’article sur la recherche multi-agent est vraiment excellent, mais je ne suis pas d’accord avec l’idée avancée dans Building Effective AI Agents selon laquelle « construire le système from scratch, sans framework, est préférable d’un point de vue pédagogique ». Le premier avantage d’un bon framework, c’est qu’il permet d’expérimenter facilement avec différents LLM, y compris de manière indépendante du fournisseur

  • Je me demande quel framework d’AI agent Anthropic utilise. Je n’ai pas l’impression qu’ils aient déjà rendu public leur framework interne

  • Merci pour ces notes supplémentaires ; c’est aussi devenu récemment un sujet très important pour moi

• Dans l’IA, six mois paraissent une éternité. J’ai relu cet article plusieurs fois il y a encore quelques mois, mais aujourd’hui j’ai clairement l’impression que le développement d’agents a atteint un goulet d’étranglement. Même les dernières versions de Gemini donnent plutôt l’impression d’une régression en termes de performances

  • Faire tourner plusieurs agents en même temps coûte cher, ce qui réduit le RoI. Par exemple, un agent DeepSearch pour les actions utilise 6 agents et coûte environ 2 dollars par requête. L’orchestration multi-agent est difficile à maîtriser, et plus les modèles sont puissants, moins le besoin de multi-agent se fait sentir. À l’inverse, plus les modèles sont faibles, plus la valeur business d’IA spécialisées et étroites augmente. C’est ce que j’ai constaté en pratique

  • Je suis curieux de savoir pourquoi tu as l’impression que les agents ont régressé. Pourquoi ne peuvent-ils pas simplement se dupliquer eux-mêmes, travailler en parallèle 24/7, se vérifier et s’améliorer en continu ?

  • Résoudre le problème du prompt injection est extrêmement difficile, et cela devient un goulet d’étranglement majeur

• Je me demande comment les agents gèrent le task queueing, les race conditions et les autres problèmes de concurrence. Dans les articles sur les workflows multi-agents, on lit souvent qu’un agent orchestrateur pilote l’ensemble, mais je me suis toujours demandé si, en pratique, cela ne demandait pas une architecture bien plus complexe et un glue code plus intelligent. Ou bien est-ce que tout cela fonctionne vraiment comme une « magie automatique » ?

  • Le standard, pour les agents, est que les outils s’exécutent séquentiellement, donc il n’y a pas vraiment à se soucier de la concurrence. Maintenant, plusieurs modèles prennent aussi en charge les appels d’outils en parallèle : si le modèle demande « exécute ces trois outils », le harness peut les lancer en parallèle ou en séquence, puis transmettre les résultats à l’étape suivante. Anthropic utilise de manière plus poussée des configurations multi-agents, où un agent de niveau supérieur délègue des tâches en parallèle à des agents subordonnés. Cette astuce est utilisée dans Claude Code, et elle est aussi détaillée dans ces notes de rétro-ingénierie (claude-trace) ainsi que dans cet article sur le fonctionnement de Claude Research (multi-agent-research-system). Nous n’en sommes encore qu’aux tout débuts de la découverte des patterns d’usage d’outils par les LLM, et le fait que les modèles soient vraiment devenus bons dans l’usage d’outils ne date que des six derniers mois, donc le potentiel d’évolution reste important

  • C’est aussi pour cela que je préfère de plus en plus laisser le LLM produire directement du code pour gérer les tool calls, plutôt que de tout faire passer par du JSON. La bibliothèque smolagents de Huggingface utilise cette approche, où le LLM génère du code d’appel de fonctions Python. Si l’on veut des appels d’outils en parallèle, il suffit de l’indiquer dans le prompt, et le LLM doit aussi gérer la synchronisation. Bien sûr, exécuter du code généré par le LLM pose ses propres problèmes, mais il existe plusieurs solutions

  • Retour d’expérience avec l’interface web de Codex. J’avais un plan de refactorisation trop long pour être mené d’un seul coup, et j’ai utilisé la fonction « ask » pour le découper en plusieurs tâches, puis regrouper celles qui pouvaient être parallélisées. Le LLM a réparti le travail d’une manière proche de celle d’une vraie équipe, mais comme il n’y avait pas d’hypothèse de communication entre les tâches, la perte de contexte était énorme. J’ai tenté l’expérience même si cela a pris plus de temps que de le faire moi-même, puis j’ai finalement traité les tâches en séquence, en donnant à chaque session un prompt détaillé pour chaque tâche (objectif, méthode, validation, documentation, etc.). En résumé, un agent orchestrateur peut servir pour des tâches très simples, mais son champ d’application est plus limité qu’on ne l’imagine

  • Rien ne fonctionne automatiquement comme par magie. Les caractéristiques opérationnelles auxquelles il faut faire attention dans les systèmes classiques doivent aussi être développées pour les agents IA. Si l’on regarde seulement des démos d’agents IA et qu’on pense pouvoir remplacer le code d’une équipe au spaghetti code par quelques prompts d’IA bien propres, on risque d’être trompé. Cela peut fonctionner dans quelques cas, mais au final tout le code a une raison d’exister dans le système ; et si l’on finit par tout retranscrire dans le LLM, on a alors perdu sa direction

  • Pour les agents de code, un pattern émergent consiste à isoler le travail dans des conteneurs, puis à revoir et fusionner les résultats avec git. Un exemple est l’usage de conteneurs et de MCP dans container-use, utile pour le travail de code en parallèle. Pour d’autres usages métier, des constructeurs de workflows comme n8n, Zapier ou CrewAI restent également très utilisés

• Cet article rappelle qu’il faut commencer par « la chose la plus simple possible », puis n’ajouter de la vraie complexité que lorsqu’elle devient nécessaire. Avec des appels LLM clairement définis et un peu de glue logic simple, on peut construire des systèmes plus fiables, plus faciles à déboguer et moins coûteux. À l’inverse, les systèmes d’agents qui paraissent impressionnants créent souvent davantage de problèmes

• J’espère que l’IA deviendra réellement utile aux gens

• C’est très bien qu’Anthropic partage ce type d’informations techniques, mais je pense qu’ils devraient aussi proposer une version plus accessible pour les non-spécialistes. Par exemple, si une équipe marketing veut adopter des agents, elle a besoin d’un guide pour définir les spécifications à un niveau élémentaire. Il y a bien quelques éléments à ce sujet dans la fin de l’article et dans l’annexe, mais cela reste malgré tout centré sur l’implémentation et la question du « comment construire »

• (Décembre 2024 — avec le recul, cela donne l’impression de remonter à très longtemps)

  • Ahhh, donc on retourne à devoir se creuser la tête et écrire 100 % du code nous-mêmes comme des hommes des cavernes, en décembre 2024 commentaire lié

  • Je trouve que cet article tient remarquablement bien dans le temps. Personnellement, je continue à m’en servir comme référence, et il ne me semble pas du tout dépassé. C’était aussi un texte qui donnait une nouvelle image d’Anthropic comme « partenaire concret pour le développement d’outils IA »

• À mon avis, l’hype autour des agents est aujourd’hui largement retombée

  • Désormais, tout le monde s’intéresse plutôt à l’AI Agency

• Information complémentaire : cet article avait déjà fait l’objet de discussions à l’époque discussion HN originale

• J’apprécie le fait que cet article adopte une approche réaliste, sans exagération ni effet de mode. Beaucoup de gens construisent des systèmes d’agents parce que c’est tendance, sans vraiment se demander si leur tâche nécessite réellement un agent, et je trouve cette tendance critiquable