Comment fonctionnent les transferts d’agents dans les systèmes multi-agents

des capacités de raisonnement des LLM avec la mémoire, la planification et l’utilisation d’outils (créant ce que nous appelons agents) a élargi la gamme de tâches que les LLM peuvent effectuer.

Cependant, un seul agent seul a ses limites. Lorsqu’elle est associée à trop d’outils ou à un contexte trop vaste, cela conduit souvent à de mauvaises décisions et à des réponses médiocres.

C’est pourquoi systèmes multi-agents ont gagné en popularité, car ils nous permettent d’aborder des cas d’utilisation de plus en plus complexes.

Les systèmes multi-agents connectent de nombreux agents spécialisés qui travaillent ensemble, chacun se concentrant sur une tâche spécifique, tandis que le système achemine les requêtes vers l’expert approprié.

Considérez-le comme une équipe d’experts collaborant, chacun apportant ses propres compétences spécialisées grâce à une approche « diviser pour régner ».

Dans cet article, nous explorerons clairement l’un des notions clés dans les systèmes multi-agents : comment les agents se transfèrent le contrôle.

Contenu

(1) Introduction à LangGraph
(2) Définition des transferts d’agent
(3) Exemple de scénario
(4) Transferts dans LangGraph

Voici le lien vers le dépôt GitHub qui l’accompagne.

---

(1) Introduction à LangGraph

[Optional Reading]

LangGraph est un cadre d’orchestration open source permettant de créer des systèmes agentiques avec état, basés sur LLM, qui gèrent de manière fiable des tâches complexes.

Il permet aux développeurs de concevoir des flux de travail sous forme de graphiques, chaque graphique étant constitué de nœuds (représentant des tâches ou des appels LLM) et de bords (représentant le flux de contrôle).

LangGraph est mon framework de choix pour créer des systèmes agentiques en raison de ses principaux atouts :

• Contrôlabilité de bas niveau qui offre un contrôle précis sur les transitions, les états et la manière dont chaque agent s’exécute.
• Transparent et intuitif flux de travail basés sur des graphiques qui rendent la logique complexe facile à comprendre, à configurer et à tracer.
• Flexible sans chat workflows qui prennent en charge l’orchestration agentique au-delà des agents conversationnels (par exemple, des frameworks comme Génération automatique)

L’image ci-dessous montre à quoi ressemble un flux de travail basé sur des graphiques conçu pour la génération augmentée de récupération :

---

(2) Définition des transferts d’agent

Tout d’abord, comprenons ce que signifie un transfert.

Un transfert agent est le moment où un agent passe le contrôle directement et dynamiquement à un autre agent après avoir terminé son travail.

Ceci est important car nous voulons que les tâches soient acheminées vers l’agent le mieux équipé pour fournir un réponse contextuelle.

En termes techniques, un transfert se produit lorsqu’un agent transfère le contrôle, la responsabilité ou le contexte conversationnel à un autre agent pour assurer la continuité et la pertinence de l’interaction.

L’image ci-dessous illustre une architecture à trois agents basée sur le superviseur modèle, dans lequel un agent central coordonne les agents travailleurs spécialisés (un agent de recherche et un agent rédacteur de documents).

Dans ce cas, les transferts peuvent se produire dans les deux sens entre le superviseur et chaque agent ouvrier.

Chaque travailleur acquiert sa spécialisation grâce à l’intégration d’un ensemble spécifique d’outils et d’invites personnalisées.

Supposons que la requête de l’utilisateur soit «Rechercher comment l’utilisation des médias sociaux affecte la santé mentale des adolescents».

L’agent superviseur, conscient des nature de la requête de l’utilisateur et le agents ouvriers à sa dispositionconfiera la tâche au recherche agent pour effectuer le tour suivant.

Voici le flux :

1. Agent superviseur analyse l’intention de l’utilisateur et décide qu’il a besoin d’aide de l’agent de recherche
2. Superviseur passe le contrôle (et État*) à l’agent de recherche
3. L’agent de recherche effectue la tâche et décide s’il faut retransmettre à l’agent superviseur ou mettre fin à la conversation.

* L’état est la mémoire à court terme du système multi-agent, capturant les conversations récentes et les informations clés afin que chaque agent puisse agir de manière appropriée en fonction du contexte et des informations préalables.

---

(3) Exemple de scénario

Examinons l’exemple de scénario pour ancrer notre procédure pas à pas.

Nous mettrons en place un assistant immobilier capable de répondre aux requêtes liées aux propriétés à Singapour. Il est conçu comme un trois agents système basé sur le populaire superviseur modèle.

Dans ce scénario, nous avons un gestionnaire immobilier (superviseur) ayant accès à deux agents ouvriers spécialisés :

• Agent de profil immobilier: Gère les requêtes liées aux détails de la propriété du logement.
• Agent d’historique des transactions : Gère les requêtes liées aux transactions immobilières et aux tendances du marché.

Le routage a été simplifié pour être Sens Unique c’est-à-dire une fois que l’agent travailleur a terminé sa tâche, la conversation se termine.

Pour que la coordination fonctionne, l’agent superviseur doit être conscient de son rôle, du flux de travail global et des agents à sa disposition. Nous faisons cela avec une invite comme celle-ci :

Notez que les instructions relatives aux critères de transfert sont explicitement définies dans l’invite.

Le code pour le supervisor Le nœud pour le routage conditionnel est le suivant :

Alors que les systèmes multi-agents peuvent suivre différents modèles de conception et s’adapter à beaucoup plus de nœuds, cet exemple simple nous permet de nous concentrer sur l’idée des transferts d’agents.

La capture d’écran suivante montre le résultat de notre système multi-agent immobilier pour une requête utilisateur :

Comme nous nous concentrerons sur les transferts d’agents, je vais pas détailler l’intégralité LangGraph code de configuration (par exemple, invites, nœuds, appels LLM). Cependant, vous pouvez trouver l’implémentation du code dans ce dépôt GitHub.

---

(4) Transferts dans LangGraph

Il existe deux mécanismes pour les transferts d’agents dans LangGraph :

• Bords conditionnels
• Objet de commande

(4.1) Bords conditionnels (transfert basé sur le routage statique)

Une arête conditionnelle est la méthode classique de routage graphique pour transférer le contrôle entre agents.

Dans un graphique, les nœuds font le travail tandis que les bords indiquent quoi faire ensuite.

Les bords sont des fonctions qui décident de la logique de routage (c’est-à-dire quel nœud exécuter ensuite). Ce routage peut être constitué de transitions fixes directes ou basé sur des conditions spécifiques (c’est-à-dire des bords conditionnels).

En termes simples, le flux dans un bord conditionnel est la suivante :

1. Un nœud génère une sortie
2. La sortie est transmise au front conditionnel en tant qu’entrée
3. La fonction dans le bord conditionnel l’évalue et choisit le prochain nœud à exécuter

Dans LangGraph, nous définissons des arêtes conditionnelles en appelant add_conditional_edges sur un StateGraph exemple:

graph.add_conditional_edges(source="start_node", path=routing_function)

• source L’argument fait référence au nœud de départ. Cela signifie qu’une fois ce nœud terminé, le routage conditionnel entre en jeu.
• path L’argument prend la fonction conditionnelle et sa valeur de retour contrôle le nœud suivant vers lequel le graphique se déplace.

Explorons d’abord la fonction de routage (should_continue) de notre exemple immobilier :

Voici ce que fait la fonction de routage :

1. Lisez la dernière réponse du superviseur et décidez quoi faire ensuite.
2. Vérifiez si le superviseur a explicitement demandé de confier la tâche à l’un des deux agents.
3. Lorsque le superviseur nomme un agent de travail, la fonction renvoie le nom de cet agent sous forme de chaîne, déclenchant un transfert vers cet agent.
4. Si le superviseur n’a demandé aucun agent de travail, la fonction renvoie "end"ce qui signifie que le superviseur a répondu et que le flux de travail se termine.

Une fois la fonction de routage configurée, nous définissons ensuite les arêtes conditionnelles :

• Le supervisorLe nœud sert de point d’entrée source du flux, où il reçoit et analyse d’abord la requête de l’utilisateur.
• Une fois le traitement terminé par le superviseur, la fonction de routage should_continue entre en jeu, examinant la réponse du superviseur pour déterminer la décision de transfert.
• Le path_map dict traduit les valeurs de retour de la fonction de routage en cibles graphiques. Ceci est nécessaire car should_continue peut revenir “end”lequel path_map se transforme en ENDle signal d’arrêt de LangGraph.

Ce qui précède montre essentiellement comment fonctionnent les transferts d’agent : le superviseur génère des chaînes spécifiques que la fonction conditionnelle utilise pour acheminer vers l’agent suivant ou se terminer.

---

(4.2) Objet de commande (transfert dynamique)

Bords conditionnels fonctionnent bien pour des flux simples et prévisibles, mais une fois que la logique devient plus complexe, relier ensemble de nombreuses arêtes conditionnelles peut devenir fastidieux et peu intuitif.

Pour rendre les workflows multi-agents plus flexibles et plus faciles à concevoir, le Command taper a été introduit pour combiner les mises à jour d’état et le flux de contrôle.

Cela simplifie les choses en permettant aux nœuds de renvoyer un Command objet qui met à jour l’état du graphique et spécifie le prochain nœud à exécuter.

Au lieu de compter sur bords prédéfinis, le nœud peut lui-même déterminer directement et dynamiquement l’étape suivante basée sur sa propre logique au moment de l’exécution.

Cela permet graphiques sans bords, où le routage vit avechin agents plutôt que dans un fouillis de règles conditionnelles, ce qui permet d’orchestrer les transferts de manière plus propre et plus flexible.

Voici un code minimal à utiliser Command dans un router nœud:

Dans ce qui précède, le nœud d’agent de routeur lit l’état, décide de ce qui doit être exécuté ensuite et renvoie un Command qui met à jour l’état du graphique et pointe vers le nœud suivant.

Puisque le nœud choisit l’étape suivante en utilisant le goto argument, il n’est pas nécessaire de définir des arêtes conditionnelles avec add_conditional_edges.

Command fait en sorte que la logique de transfert se situe dans les nœuds plutôt que dans les bords. Par conséquent, nous attendons le code dans notre supervisor nœud pour être plus long :

• Le nœud superviseur appelle un LLM pour renvoyer unSupervisorDecision objet de sortie structuré contenant deux choses clés: à quel agent transférer le message et tout contexte pertinent, comme le nom de la propriété extrait du message de l’utilisateur.
• Si aucun agent travailleur n’est nécessaire, le superviseur répond directement. Le nœud renvoie un Command qui met à jour les messages avec la réponse et termine le graphique.
• Si un transfert est nécessaire, le nœud crée un dictionnaire de mise à jour. Il inclut un message de routage du superviseur et le contexte extrait (par exemple, le nom de la propriété) dans l’état du graphe, afin que l’agent suivant puisse l’utiliser immédiatement.
• Enfin, le nœud renvoie un Command qui spécifie le prochain agent utilisant goto et applique les mises à jour d’état (c’est-à-dire la mise à jour property_name).

Le Literal["transaction_history_agent", "property_profile_agent"] le type indice nous permet de générer le diagramme graphique Mermaid complet même lorsque nous n’avons pas explicitement défini les bords. Le flux de transfert réel est géré par le goto paramètre.

Avec Commandles nœuds décident directement quel agent s’exécutera ensuite et quoi transmettre. Il élimine les règles de routage distinctes et maintient la logique de transfert propre.

---

(4.3) Quand utiliser des arêtes conditionnelles ou une commande ?

Voici comment choisir les bords conditionnels par rapport à la commande pour les transferts :

Utilisez des arêtes conditionnelles lorsque:

• Il vous suffit de décider quel nœud s’exécutera ensuite en fonction de la configuration actuelle. état du graphique, sans changer il.

Utiliser <strong>Command</strong> quand:

• Votre nœud doit modifier son état et déterminer simultanément le nœud suivant.
• Ceci est utile dans les transferts multi-agents où le routage vers un autre agent nécessite généralement de transmettre certaines informations à cet agent.

Dans mon travail, j’ai largement opté pour l’utilisation Command au lieu d’arêtes conditionnelles étant donné que de nombreux systèmes multi-agents nécessitent des mises à jour coordonnées de l’état des graphes parallèlement aux décisions de routage.

---

Envelopper le tout

Les transferts d’agents constituent le mécanisme de base qui permet à un système multi-agent de fonctionner efficacement. Dans cet article, nous avons expliqué comment ces transferts fonctionnent dans la pratique, LangGraph servant de couche d’implémentation pour les exprimer à l’aide du routage conditionnel ou du Command objet.

Quel que soit le cadre que nous utilisons, l’idée reste la même : des transferts clairs et cohérents permettent aux agents de travailler ensemble.

Vérifier ce dépôt GitHub pour l’implémentation du code.