L'article qui a vraiment debloque ma conception multi-agents

Mon equipe travaille actuellement sur la conception d’un systeme agentique. Construire un seul agent semblait maitrisable, mais des qu’on a voulu en connecter plusieurs, les questions se sont accumulees.

Quelle structure d’orchestration utiliser ? Comment les agents communiquent-ils ? Comment gerer la memoire a travers le systeme ?

J’ai alors decouvert un article de Rohit Ghumare qui couvrait pratiquement tous les points sur lesquels je bloquais. Voici un resume des idees cles, accompagne de ma propre experience.

Pourquoi le multi-agents

Comme je l’ai mentionne dans des articles precedents, le multi-agents n’est pas toujours la reponse. Mais j’ai passe toute l’annee derniere a echouer dans la gestion du contexte avec un agent unique.

Le probleme : la fenetre de contexte d’un agent unique se remplit vite, et une fois pleine, l’agent commence a oublier. Pire encore, quand un seul agent gere plusieurs domaines simultanement, sa capacite de jugement se degrade.

Le multi-agents resout ce probleme en separant les responsabilites - mais cela introduit un surcout de coordination. Gerer ce surcout est le vrai defi, et l’article l’aborde de front.

Trois patterns d’orchestration

C’etait la section la plus pratique. Au lieu de classer par « ce qui est impressionnant », l’article se concentre sur quand utiliser quoi.

Pattern Superviseur (Supervisor)

Un agent gestionnaire decompose les taches, les distribue aux travailleurs et synthetise les resultats.

• Adapte pour : Les taches qui se decoupent clairement en sous-taches, ou quand la tracabilite est necessaire
• Echelle ideale : 3 a 8 travailleurs
• Attention : Toutes les decisions passent par le superviseur, ce qui peut creer un goulot d’etranglement

Pattern Essaim (Swarm)

Pas de gestionnaire central. Les agents communiquent en pair-a-pair et s’auto-organisent.

• Adapte pour : Les problemes necessitant des perspectives variees, ou quand la reactivite en temps reel compte
• Attention : Travail en double, boucles infinies, convergence sous-optimale. Le debogage est penible

Pattern Hierarchique (Hierarchical)

Extension recursive du pattern superviseur. Coordinateur de haut niveau → managers intermediaires → travailleurs.

• Adapte pour : Systemes avec plus de 10 agents, ou quand strategie et tactique doivent etre clairement separees
• Attention : Les couts en tokens explosent a chaque couche de coordination

D’experience personnelle, le pattern superviseur est le plus stable. La cle, c’est la bonne distribution des taches et la gestion des erreurs - sinon le superviseur lui-meme devient le point de defaillance.

Comment les agents communiquent

Si l’orchestration definit la structure, la communication definit comment l’information circule reellement entre les agents.

• Etat partage (Shared State) : Tous les agents lisent et ecrivent dans un meme objet d’etat. Simple a implementer, facile a deboguer. La plupart des equipes devraient commencer par la
• Passage de messages (Message Passing) : Communication asynchrone via un bus d’evenements. A utiliser quand un couplage lache entre agents est necessaire
• Transfert (Handoff) : Passage de relais explicite avec transfert complet du contexte. Fonctionne bien pour les pipelines a ordre fixe

Architecture memoire pour les systemes multi-agents

Le probleme fondamental est simple : comment partager l’etat sans provoquer de conflits ? L’article le decompose en trois patterns.

Memoire basee sur les sessions (Session-Based)

Chaque agent travaille dans un etat local isole. Les modifications sont fusionnees dans la memoire partagee uniquement a la fin de la session.

• Adapte pour : Les travailleurs paralleles qui doivent operer independamment sans interference
• Fonctionnement : L’agent prend un instantane de l’etat partage au debut de la session, travaille localement, fusionne les deltas a la fin
• Avantage : Traitement parallele sans conflit

Memoire a fenetre glissante (Window Memory)

Une fenetre glissante ne conserve que les N derniers echanges. Les entrees plus anciennes sont compressees en resumes.

• Adapte pour : Les longues conversations ou il faut maintenir le contexte sans bruler des tokens
• Fonctionnement : Quand la fenetre deborde, le tiers le plus ancien est resume et compresse
• Avantage : Empeche la croissance illimitee de l’etat

Memoire episodique (Episodic Memory)

Stocke l’historique de collaboration de combinaisons d’agents specifiques et l’utilise pour eclairer les decisions futures.

• Adapte pour : Les equipes d’agents qui collaborent frequemment et doivent s’ameliorer sur la base des resultats passes
• Fonctionnement : Enregistre quelles combinaisons d’agents ont reussi ou echoue sur quelles taches
• Avantage : Permet des decisions comme « cette combinaison a bien fonctionne la derniere fois - reutilisons-la »

Considerations pour la production

Couts en tokens

• Superviseur + 4 travailleurs : environ 1K pour la decomposition + 12K pour les travailleurs + 2K pour la synthese = environ 15K tokens par tache
• La meme tache avec un agent unique : environ 4K tokens. Le cout de coordination est presque 4 fois superieur
• Optimisation : Mettre en cache les instructions du superviseur, structurer les sorties des travailleurs, n’invoquer les travailleurs que si necessaire

Latence

• A 2-5 secondes par appel LLM, 4 agents en serie representent plus de 12 secondes. En parallele, 3-4 secondes
• Les taches independantes doivent toujours etre parallelisees

Propagation des erreurs

• Timeouts : Obligatoires a chaque couche
• Disjoncteurs (Circuit breakers) : Arreter d’appeler un agent apres N echecs consecutifs
• Degradation gracieuse : Les fonctionnalites essentielles doivent fonctionner meme si certains agents sont indisponibles
• Isolation de l’etat : La defaillance d’un travailleur ne doit jamais corrompre l’etat partage

Si on ne peut pas l’observer, on ne peut pas le corriger. Le monitoring est un prerequis des le premier jour.

Anti-patterns a eviter

• Sur-orchestration : Lier des agents qui pourraient fonctionner independamment
• Agent omnipotent : Un agent qui fait tout rend le multi-agents inutile
• Ignorer les couts : Deployer sans suivi des tokens mene a des factures surprises
• Pas de fallback : Supposer que chaque agent sera toujours disponible

Ce qu’il faut retenir

La conclusion de l’article m’a marque :

Construire un agent. Identifier ou il atteint ses limites. Ajouter un deuxieme agent a ce point de rupture. Ajouter un superviseur si necessaire. Repeter.

J’ai commence avec une conception hierarchique ambitieuse et j’ai fini par simplifier a un superviseur avec trois travailleurs. La lecon : construire d’abord une collaboration stable entre deux agents, puis evoluer a partir de la.

Si vous etes en train de concevoir un systeme multi-agents, je vous recommande de lire l’article original.

Source : Building Effective Multi-Agent Systems