La manière dont les sous-agents et les systèmes multi-agents répartissent le travail et les jetons de coût.
Sous-agents contre systèmes multi-agents : la conception orchestrateur-travailleur, quatre topologies, le coût en tokens de chacune, et les cas où un seul agent est préférable.
Sources: Subagents vs. Multi-Agent Systems: The Complete Guide to How AI Agents Actually Work Together
Pourquoi un agent isolé atteint ses limites
Tout ceux qui ont vu fonctionner Claude Code, LangGraph ou la fonction de recherche de Claude ont observé le moment où l’assistant cesse de répondre seul et va chercher de l’aide. Un assistant chargé de rechercher des fichiers apparaît, fouille partout, puis revient avec des résultats. Une question de recherche consulte discrètement une douzaine de sources en moins de temps qu’il ne faut à une personne pour ouvrir deux onglets. Le modèle n’est pas soudainement devenu plus intelligent : c’est une petite équipe qui effectue le travail.
Ci-dessous, une explication simple de la manière dont ce travail d’équipe est organisé, abordant les sous-agents, les systèmes multi-agents, leur architecture de base et leur coût.
Un agent unique, c’est-à-dire un modèle qui fonctionne en boucle avec des outils, est capable de nombreuses choses : il lit des fichiers, navigue sur Internet, écrit du code et raisonne à travers de multiples étapes. Cependant, trois limites sont intégrées dans sa conception :
- Une seule fenêtre de contexte. Tout ce que l’agent lit, pense et fait se cumule dans le même espace. Lors d’une tâche d’exploration longue, les résultats des outils finissent par faire oublier la question initiale.
- Une seule ligne d’exécution. Le travail s’effectue séquentiellement. Cinquante recherches de deux secondes chacune prennent plus de quatre-vingt-dix secondes avant que toute écriture ne commence.
- Une seule perspective. Un seul prompt influence chaque décision, ce qui rend difficile pour l’agent de considérer simultanément deux approches concurrentes ou de détecter ses propres points aveugles.
Les sous-agents et les systèmes multi-agents constituent deux solutions à ce problème, souvent combinées. Le reste explique ce qu’ils sont, comment ils sont mis en place, et quand ils se révèlent utiles.
Qu’est-ce qu’un sous-agent
Un subagent est un assistant à portée restreinte lancé au sein d’une session. Il s’occupe d’une tâche unique et ciblée dans sa propre fenêtre de contexte, puis fait un rapport.
Claude Code en est un bon exemple. Si la session de codage principale doit comprendre une partie inconnue d’un codebase, elle peut confier cette exploration à un subagent afin de libérer la conversation principale. Le subagent :
- commence avec une fenêtre de contexte propre et vierge
- dispose généralement d’un ensemble plus restreint d’outils
- exécute son propre cycle étroit de lecture, de recherche et de raisonnement
- envoie un résumé à la session parente et conserve le texte de la conversation pour lui-même
La valeur ici est l’isolation, et non une intelligence supplémentaire. La conversation principale ne voit jamais les cinquante fichiers ouverts par l’assistant, seulement les trois phrases importantes, de sorte que le fil principal reste clair tout au long d’une longue session sans être envahi par du bruit.
Quelques caractéristiques définissent ce modèle tel que des outils comme Claude Code le mettent en œuvre :
- Les sous-agents existent dans une seule session. Ce sont un moyen de déléguer des tâches, et non des processus indépendants en cours d’exécution.
- Ils ne peuvent généralement pas lancer de sous-agents eux-mêmes, ce qui maintient la hiérarchie simple et facile à suivre.
- La définition d’un sous-agent est écrite une seule fois et réutilisée. En fournissant à un sous-agent destiné à un réviseur un prompt système fixe ainsi qu’une courte liste d’outils, il fonctionnera de manière identique à chaque invocation.
Qu’est-ce qu’un système multi-agents
Un système multi-agents a une structure différente. Plusieurs agents indépendants, chacun disposant de son propre contexte, de ses propres outils et parfois de son propre modèle, poursuivent un objectif commun, généralement au cours d’un processus plus long ou plus complexe que celui d’une simple délégation pour une seule session.
La fonction de recherche d’Anthropic est l’exemple public le plus connu. Une question large n’est pas répondue directement. Au lieu de cela, un agent principal élabore une approche et crée plusieurs subagents, chacun examinant un angle différent en même temps. Leurs résultats sont fusionnés, vérifiés pour leur exactitude et restitués sous forme de réponse unique.
Ensemble, un agent principal, des spécialistes parallèles et une étape de synthèse finale forment le modèle que la plupart des systèmes multi-agents de production utilisent aujourd’hui, et c’est ce design qui est examiné dans le reste de cet article.
Où les deux concepts diffèrent
Ces termes sont utilisés de manière interchangeable en ligne, ce qui engendre de la confusion. La distinction réelle est présentée ici.
Le moyen le plus simple de s’en souvenir : un sous-agent est une technique utilisée à l’intérieur d’un agent, tandis qu’un système multi-agents est une architecture conçue autour de plusieurs agents. En pratique, de nombreux systèmes multi-agents sont construits à partir du modèle du sous-agent. Un agent principal qui emploie des sous-agents est les deux à la fois.
L’architecture de l’orchestrateur et des travailleurs
Presque tous les systèmes multi-agents utilisés en production, y compris la fonction de recherche d’Anthropic, le modèle de superviseur de LangGraph et le modèle de sous-agent de Claude Code, représentent une variante d’un même schéma : orchestrateur et travailleurs.
Chaque composant a une responsabilité spécifique :
- Agent principal (orchestrateur). Il lit la requête, élabore une stratégie et évalue l’effort nécessaire pour accomplir la tâche. Ce jugement est plus important qu’il n’y paraît. Les versions initiales de ces systèmes lançaient parfois cinquante sous-agents pour une question qui n’en nécessitait qu’un seul.
- Mémoire ou espace de travail temporaire. Le plan est enregistré en dehors de la conversation. Les sessions prolongées peuvent dépasser la fenêtre de contexte du modèle, et si cela se produit en cours de route, le plan doit survivre à la troncation et ne pas disparaître avec elle.
- Sous-agents. Chacun reçoit un objectif précis, un format de sortie défini, des conseils sur les outils et sources à utiliser, ainsi que des limites claires afin que deux d’entre eux ne se répètent pas silencieusement mutuellement. Chacun exécute sa propre boucle de recherche, d’évaluation et de perfectionnement.
- Agent de citation (ou étape de synthèse et de validation). Une étape distincte compare le brouillon avec le matériel de source et relie chaque affirmation à son origine. Séparer cette tâche de l’écriture de l’agent principal améliore considérablement la précision factuelle, puisque ce n’est pas celui qui a produit les affirmations qui les vérifie.
Le diagramme utilise deux types de flèches. Les flèches pleines indiquent des tâches exécutées vers le bas, tandis que les flèches pointillées représentent des résultats synthétisés envoyés vers le haut. Cette asymétrie est intentionnelle : les sous-agents renvoient un résultat condensé et non l’intégralité de leur historique de travail, ce qui évite que le contexte de l’agent principal ne s’enfle.
Le flux de travail de la question à la réponse
En mettant de côté les composants, voici l’ordre des événements, de la question tapée par l’utilisateur jusqu’à la réponse finale.
Quelques étapes méritent une attention particulière :
- Étape 2 (réfléchir avant de planifier) a plus d’importance qu’il n’y paraît. C’est ici que le système détermine l’effort nécessaire pour traiter la requête : une vérification rapide peut nécessiter un seul agent et quelques appels d’outils, tandis qu’une question complexe peut exiger dix ou plus de sous-agents avec des tâches clairement définies.
- Étape 7 (boucle de retour) distingue un système agent de un pipeline fixe. Rien n’est prédéfini, car l’agent principal examine les résultats et choisit entre répondre ou continuer à chercher. C’est aussi là que les choses échouent le plus souvent. Un agent trop réticent à revenir en arrière fournit des réponses succinctes, tandis qu’un agent trop enthousiaste à le faire perd du temps et des ressources à chercher des sources qui n’existent pas.
- Étapes 8 et 9, la citation en tant qu’étape distincte, existent parce qu’un agent chargé d’écrire une réponse et d’évaluer lui-même ses sources a tendance à formuler des affirmations trop catégoriques qui se révèlent fausses. Une seconde vérification indépendante permet de détecter cela.
Quatre façons d’organiser plusieurs agents
Le modèle classique consiste en un orchestrateur et des travailleurs, mais ce n’est pas le seul. Selon la manière dont une tâche est réellement divisée, l’une des quatre topologies générales conviendra mieux que les autres.
Lorsqu’il n’est pas clair lequel choisir, les équipes de production suivent généralement une règle empirique : privilégier une hiérarchie avec un superviseur pour tout ce qui est destiné à la production, et conserver des schémas en réseau ou en grille pour les travaux exploratoires ou de recherche où le flux ne peut pas être défini à l’avance. Les designs en grille ont l’air élégants sur un diagramme, mais ils sont systématiquement les plus difficiles à déboguer.
Pourquoi cela fonctionne : l’économie des tokens
Il est utile d’être précis quant aux raisons pour lesquelles les systèmes multi-agents surpassent les agents uniques dans les tâches qu’ils accomplissent, car la réponse n’est pas « plus d’agents signifie plus d’intelligence ».
Dans les évaluations internes d’Anthropic, une configuration où Claude Opus 4 prend la tête avec Claude Sonnet 4 en tant qu’agents secondaires a surpassé un seul agent Claude Opus 4 de 90,2 % sur un benchmark de recherche interne. Lorsque l’analyse a examiné les raisons, la capacité a expliqué la majeure partie de cette différence. Sur un benchmark de recherche complexe, l’utilisation des tokens seule expliquait environ 80 % de la variation des performances, tandis que le nombre d’appels aux outils et le choix du modèle couvraient le reste.
En bref, l’avantage dans les tâches à large portée et riches en informations provient principalement de la capacité. En répartissant le travail sur des fenêtres de contexte distinctes, le système dispose d’une marge de raisonnement bien plus grande que celle offerte par une seule fenêtre, et chaque agent secondaire compresse ce qu’il lit en un rapport succinct.
La capacité n’est pas gratuite. Les données de production indiquent que les workflows à agents consomment environ quatre fois plus de tokens qu’un échange de chat ordinaire, et les workflows multi-agents près de quinze fois plus. Ce facteur multiplicateur doit déterminer si l’architecture vaut la peine d’être utilisée, ce qui nous amène au point suivant.
Lorsqu’un système multi-agents est le mauvais outil
La plupart des écrits sur l’architecture des agents omettent cette partie, or c’est elle qui permet de protéger à la fois le temps et le budget en tokens.
La tâche doit être divisée en éléments véritablement indépendants. Lorsque les sous-tâches dépendent fortement les unes des autres, les répartir entre des agents ajoute des coûts de coordination sans véritable parallélisme. Les questions de recherche distinctes se prêtent bien à cette division, tandis que l’écriture d’une fonction cohérente ne le fait généralement pas.
Le codage est le contre-exemple le plus évident. La propre description d’Anthropic est sans équivoque : la plupart des tâches de codage comportent moins de sous-tâches pouvant être exécutées en parallèle que la recherche, et les agents actuels ne sont pas encore fiables pour coordonner et transférer des tâches en temps réel. D’autres benchmarks confirment ce constat. Une évaluation académique a montré que les configurations de codage multi-agents consommaient de 4 fois à plus de 200 fois plus de tokens qu’un agent unique équivalent, tandis qu’une analyse sectorielle indiquait que les systèmes multi-agents performaient de 39 à 70 pour cent pire qu’un agent unique sur des tâches strictement séquentielles.
Les erreurs se propagent. Une hypothèse erronée chez un seul agent reste une erreur isolée. Au sein d’un système coordonné, elle peut se transmettre au fil des transferts de tâches et s’amplifier. Une analyse a estimé une amplification d’environ 4 fois avec une orchestration centralisée, et des résultats encore bien pires lorsque les agents agissent de manière indépendante sans coordination.
Le rendement doit couvrir les coûts. Avec un multiplicateur proche de 15 fois, les architectures à plusieurs agents conviennent aux tâches à haute valeur et haute complexité telles que la recherche approfondie, l’analyse multidomaine et les gros refacteurs. Pour tout ce qu’un agent unique bien guidé et équipé de bons outils peut accomplir en une seule passe, ces systèmes sont un excès.
Un test rapide s’applique : lorsque l’on ne parvient pas à définir ce que chaque agent devrait gérer et ce que les autres ne gèrent pas, la solution réside probablement dans un agent unique plus performant plutôt que dans l’ajout d’autres agents.
Leçons tirées de leur développement
La rétrospective d’Anthropic sur son système de recherche fait partie des comptes rendus publics les plus honnêtes sur ce qui se passe lorsque une démonstration fonctionnelle devient une configuration multi-agents en production. Les leçons les plus transférables, résumées :
- Les instructions constituent le levier principal. Comme elles guident chaque agent, de légères modifications dans la formulation des consignes données par l’orchestrateur ont un impact considérable sur le fait que les sous-agents se répètent ou laissent des lacunes.
- Une délégation trop floue entraîne des redondances. Une instruction comme « rechercher la pénurie de semi-conducteurs » semble claire mais ne l’est pas en réalité. Dans les systèmes initiaux, plusieurs sous-agents ont exploré le même angle, car personne n’avait indiqué où s’arrêtait une tâche. Une bonne instruction précise l’objectif, le format attendu du résultat ainsi que les limites du champ d’action de chaque agent.
Un schéma minimal du modèle
Ce qui suit est un aperçu simplifié, indépendant de tout framework, de l’orchestrateur et des travailleurs. Les tentatives répétées, le streaming et la mémoire persistante sont omis afin que la structure de la logique soit facile à comprendre ; il s’agit d’un pseudocode pouvant être adapté à LangGraph, au Claude Agent SDK ou à une boucle API basique.
def run_research(query: str) -> str:
# 1. Lead agent plans
plan = lead_agent.think_and_plan(query)
memory.save("plan", plan) # survives context truncation
findings = []
subtasks = plan.subtasks # explicit objective + boundaries per subtask
# 2. Spawn subagents in parallel, not sequentially
results = run_in_parallel([
subagent.execute(task=subtask, tools=subtask.allowed_tools)
for subtask in subtasks
])
findings.extend(results)
# 3. Lead agent decides: enough evidence, or loop again?
while not lead_agent.has_sufficient_evidence(findings):
new_subtasks = lead_agent.refine_plan(findings)
more_results = run_in_parallel([
subagent.execute(task=t, tools=t.allowed_tools)
for t in new_subtasks
])
findings.extend(more_results)
# 4. Synthesize, then verify citations in a separate pass
draft = lead_agent.synthesize(findings)
cited_answer = citation_agent.attach_citations(draft, findings)
return cited_answer
Deux détails méritent une attention particulière, et aucun d’eux n’apparaît généralement dans les exemples simplifiés. Le premier est run_in_parallel : l’exécution successive des sous-agents annule en grande partie les gains de vitesse. Le second concerne la boucle while explicite qui permet de replanifier, car une seule série fixe de sous-agents ne peut s’adapter lorsque la première passe laisse plus de questions que de réponses.
Vérifications avant déploiement
Avant de publier un sous-agent ou un flux de travail multi-agents, vérifiez les points suivants :
- Chaque sous-agent dispose d’un objectif, d’un format de sortie et de limites de tâche bien définis, et non simplement d’une instruction en une ligne.
- Les sous-agents s’exécutent en parallèle chaque fois qu’ils sont réellement indépendants.
- Le plan est enregistré dans le stockage et non seulement conservé dans la conversation, au cas où le contexte serait tronqué.
Lectures complémentaires
- Lorsque deux agents battent un seul : un copilote d’analyse de code LangGraph fonctionnant des deux manières — Créez un évaluateur de code en tant qu’agent unique, puis en tant qu’Analyseur associé à un Évaluateur de risques dans LangGraph, afin de comprendre les trois cas où l’utilisation de systèmes multi-agents justifie les coûts.
- Notes pratiques : Devenir l’un des 1 % des meilleurs utilisateurs d’agents Hermes : le guide complet n° — Guide pas à pas des Notes pratiques : Devenir l’un des 1 % des meilleurs utilisateurs d’agents Hermes : le guide complet n°, incluant des modèles de contrats, des vérifications et des blocs de code prêts à l’emploi pour les équipes souhaitant mettre en œuvre ce modèle.