Systèmes multi-agents

Créez des applications sophistiquées en composant des agents spécialisés en équipes.

Ce que vous allez construire

Dans ce guide, vous allez créer un Système de service client où un coordinateur achemine les requêtes vers des spécialistes :

                        ┌─────────────────────┐
       User Query       │                     │
      ────────────────▶ │    COORDINATOR      │
                        │  "Route to expert"  │
                        └──────────┬──────────┘
                                   │
                   ┌───────────────┴───────────────┐
                   │                               │
                   ▼                               ▼
        ┌──────────────────┐            ┌──────────────────┐
        │  BILLING AGENT   │            │  SUPPORT AGENT   │
        │                  │            │                  │
        │  💰 Payments     │            │  🔧 Tech Issues  │
        │  📄 Invoices     │            │  🐛 Bug Reports  │
        │  💳 Subscriptions│            │  ❓ How-To       │
        └──────────────────┘            └──────────────────┘

Concepts clés :

• Coordinator - Reçoit toutes les requêtes, décide qui les traite
• Specialists - Agents ciblés qui excellent dans des domaines spécifiques
• Transfer - Transfert fluide du Coordinator vers le Specialist

---

Démarrage rapide

1. Créer Votre Projet

cargo new multi_agent_demo
cd multi_agent_demo

Ajoutez les dépendances à Cargo.toml :

[dependencies]
adk-rust = { version = "0.2", features = ["agents", "models", "cli"] }
tokio = { version = "1", features = ["full"] }
dotenvy = "0.15"

Créez le fichier .env avec votre clé API :

echo 'GOOGLE_API_KEY=your-api-key' > .env

2. Exemple de Service Client

Voici un exemple complet et fonctionnel :

use adk_rust::prelude::*;
use adk_rust::Launcher;
use std::sync::Arc;

#[tokio::main]
async fn main() -> std::result::Result<(), Box<dyn std::error::Error>> {
    dotenvy::dotenv().ok();
    let api_key = std::env::var("GOOGLE_API_KEY")?;
    let model = Arc::new(GeminiModel::new(&api_key, "gemini-2.5-flash")?);

    // Specialist: Billing Agent
    let billing_agent = LlmAgentBuilder::new("billing_agent")
        .description("Handles billing questions: payments, invoices, subscriptions, refunds")
        .instruction("You are a billing specialist. Help customers with:\n\
                     - Invoice questions and payment history\n\
                     - Subscription plans and upgrades\n\
                     - Refund requests\n\
                     - Payment method updates\n\
                     Be professional and provide clear information about billing matters.")
        .model(model.clone())
        .build()?;

    // Specialist: Technical Support Agent
    let support_agent = LlmAgentBuilder::new("support_agent")
        .description("Handles technical support: bugs, errors, troubleshooting, how-to questions")
        .instruction("You are a technical support specialist. Help customers with:\n\
                     - Troubleshooting errors and bugs\n\
                     - How-to questions about using the product\n\
                     - Configuration and setup issues\n\
                     - Performance problems\n\
                     Be patient and provide step-by-step guidance.")
        .model(model.clone())
        .build()?;

    // Coordinator: Routes to appropriate specialist
    let coordinator = LlmAgentBuilder::new("coordinator")
        .description("Main customer service coordinator")
        .instruction("You are a customer service coordinator. Analyze each customer request:\n\n\
                     - For BILLING questions (payments, invoices, subscriptions, refunds):\n\
                       Transfer to billing_agent\n\n\
                     - For TECHNICAL questions (errors, bugs, how-to, troubleshooting):\n\
                       Transfer to support_agent\n\n\
                     - For GENERAL greetings or unclear requests:\n\
                       Respond yourself and ask clarifying questions\n\n\
                     When transferring, briefly acknowledge the customer and explain the handoff.")
        .model(model.clone())
        .sub_agent(Arc::new(billing_agent))
        .sub_agent(Arc::new(support_agent))
        .build()?;

    println!("🏢 Customer Service Center");
    println!("   Coordinator → Billing Agent | Support Agent");
    println!();

    Launcher::new(Arc::new(coordinator)).run().await?;
    Ok(())
}

Exemple d'Interaction :

You: I have a question about my last invoice

[Agent: coordinator]
Assistant: I'll connect you with our billing specialist to help with your invoice question.

[Agent: billing_agent]
Assistant: Hello! I can help you with your invoice. What specific question do you have about your last invoice?

You: Why was I charged twice?

[Agent: billing_agent]
Assistant: I understand your concern about the duplicate charge. Let me help you investigate this...

Comment fonctionne le transfert multi-Agent

Vue d'ensemble

Lorsque vous ajoutez des sub-agents à un Agent parent, le LLM acquiert la capacité de déléguer des tâches :

                    ┌─────────────────────┐
    User Message    │                     │
   ─────────────────▶    COORDINATOR      │
                    │                     │
                    └──────────┬──────────┘
                               │
           "This is a billing question..."
                               │
              ┌────────────────┴────────────────┐
              │                                 │
              ▼                                 ▼
   ┌──────────────────┐              ┌──────────────────┐
   │  billing_agent   │              │  support_agent   │
   │  💰 Payments     │              │  🔧 Tech Issues  │
   │  📄 Invoices     │              │  🐛 Bug Reports  │
   └──────────────────┘              └──────────────────┘

Flux de transfert étape par étape

Voici exactement ce qui se passe lorsqu'un utilisateur pose une question de facturation :

┌──────────────────────────────────────────────────────────────────────┐
│ ÉTAPE 1 : L'utilisateur envoie un message                            │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   Utilisateur : "Pourquoi ai-je été facturé deux fois sur ma facture ?" │
│                                                                      │
│                              ↓                                       │
│                                                                      │
│   ┌──────────────────────────────────────┐                          │
│   │         Agent COORDINATEUR           │                          │
│   │  Reçoit le message en premier        │                          │
│   └──────────────────────────────────────┘                          │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────────────┐
│ ÉTAPE 2 : Le LLM analyse et décide de transférer                     │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   🧠 Le LLM pense : "Il s'agit d'une facturation sur une facture..."  │
│                  "Facture = sujet de facturation..."                 │
│                  "Je devrais transférer au billing_agent"            │
│                                                                      │
│   📞 Le LLM appelle : transfer_to_agent(agent_name="billing_agent")  │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────────────┐
│ ÉTAPE 3 : Le Runner détecte le transfert et invoque la cible         │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   ┌─────────┐     événement de transfert      ┌─────────────────┐  │
│   │ Runner  │ ─────────────────────▶          │  billing_agent  │  │
│   └─────────┘   (même message utilisateur)      └─────────────────┘  │
│                                                                      │
│   • Le Runner trouve "billing_agent" dans l'arbre d'Agent            │
│   • Crée un nouveau contexte avec le MÊME message utilisateur        │
│   • Invoque immédiatement le billing_agent                           │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────────────┐
│ ÉTAPE 4 : L'Agent cible répond                                       │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   ┌─────────────────────────────────────────┐                       │
│   │           Le billing_agent répond       │                       │
│   │                                         │                       │
│   │  "Je peux vous aider avec votre double   │                       │
│   │   facturation. Laissez-moi enquêter..." │                       │
│   └─────────────────────────────────────────┘                       │
│                                                                      │
│   ✅ L'utilisateur voit une réponse fluide - sans interruption !     │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘

Ce qui rend cela possible

Avant vs Après l'ajout de Sub-Agents

Sans sub-agents - Un Agent fait tout :

User ──▶ coordinator ──▶ Response (handles billing AND support)

Avec sub-agents - Les spécialistes gèrent leur domaine :

User ──▶ coordinator ──▶ billing_agent ──▶ Response (billing expert)
                    ──▶ support_agent ──▶ Response (tech expert)

---

Systèmes multi-agents hiérarchiques

Pour les scénarios complexes, vous pouvez créer des hiérarchies multi-niveaux. Chaque agent peut avoir ses propres sous-agents, formant un arbre :

Visuel : Équipe de contenu à 3 niveaux

                    ┌─────────────────────┐
                    │  PROJECT MANAGER    │  ← Niveau 1 : Coordinateur de haut niveau
                    │  "Gérer les projets"│
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │  CONTENT CREATOR    │  ← Niveau 2 : Coordinateur de niveau intermédiaire
                    │  "Coordonner R&W"   │
                    └──────────┬──────────┘
                               │
              ┌────────────────┴────────────────┐
              │                                 │
              ▼                                 ▼
   ┌──────────────────┐              ┌──────────────────┐
   │   RESEARCHER     │              │     WRITER       │  ← Niveau 3 : Spécialistes
   │                  │              │                  │
   │  📚 Rassembler les faits │              │  ✍️ Écrire le contenu │
   │  🔍 Analyser les données │              │  📝 Peaufiner le texte │
   │  📊 Trouver des sources │              │  🎨 Style et ton   │
   └──────────────────┘              └──────────────────┘

Comment les requêtes descendent

Utilisateur : "Créer un article de blog sur les véhicules électriques"
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  PROJECT MANAGER : "Ceci est une tâche de contenu"          │
│  → transfère à content_creator                              │
└─────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  CONTENT CREATOR : "Besoin de recherche d'abord, puis de rédaction"│
│  → transfère à researcher                                   │
└─────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  RESEARCHER : "Voici ce que j'ai trouvé sur les VE..."      │
│  → fournit un résumé de recherche                           │
└─────────────────────────────────────────────────────────────┘

Exemple de code complet

use adk_rust::prelude::*;
use adk_rust::Launcher;
use std::sync::Arc;

#[tokio::main]
async fn main() -> std::result::Result<(), Box<dyn std::error::Error>> {
    dotenvy::dotenv().ok();
    let api_key = std::env::var("GOOGLE_API_KEY")?;
    let model = Arc::new(GeminiModel::new(&api_key, "gemini-2.5-flash")?);

    // Level 3: Leaf specialists
    let researcher = LlmAgentBuilder::new("researcher")
        .description("Researches topics and gathers comprehensive information")
        .instruction("You are a research specialist. When asked to research a topic:\n\
                     - Gather key facts and data\n\
                     - Identify main themes and subtopics\n\
                     - Note important sources or references\n\
                     Provide thorough, well-organized research summaries.")
        .model(model.clone())
        .build()?;

    let writer = LlmAgentBuilder::new("writer")
        .description("Writes polished content based on research")
        .instruction("You are a content writer. When asked to write:\n\
                     - Create engaging, clear content\n\
                     - Use appropriate tone for the audience\n\
                     - Structure content logically\n\
                     - Polish for grammar and style\n\
                     Produce professional, publication-ready content.")
        .model(model.clone())
        .build()?;

    // Level 2: Content coordinator
    let content_creator = LlmAgentBuilder::new("content_creator")
        .description("Coordinates content creation by delegating research and writing")
        .instruction("You are a content creation lead. For content requests:\n\n\
                     - If RESEARCH is needed: Transfer to researcher\n\
                     - If WRITING is needed: Transfer to writer\n\
                     - For PLANNING or overview: Handle yourself\n\n\
                     Coordinate between research and writing phases.")
        .model(model.clone())
        .sub_agent(Arc::new(researcher))
        .sub_agent(Arc::new(writer))
        .build()?;

    // Level 1: Top-level manager
    let project_manager = LlmAgentBuilder::new("project_manager")
        .description("Manages projects and coordinates with content team")
        .instruction("You are a project manager. For incoming requests:\n\n\
                     - For CONTENT creation tasks: Transfer to content_creator\n\
                     - For PROJECT STATUS or general questions: Handle yourself\n\n\
                     Keep track of overall project goals and deadlines.")
        .model(model.clone())
        .sub_agent(Arc::new(content_creator))
        .build()?;

    println!("📊 Hierarchical Multi-Agent System");
    println!();
    println!("   project_manager");
    println!("       └── content_creator");
    println!("               ├── researcher");
    println!("               └── writer");
    println!();

    Launcher::new(Arc::new(project_manager)).run().await?;
    Ok(())
}

Hiérarchie des agents :

project_manager
└── content_creator
    ├── researcher
    └── writer

Exemples de requêtes :

• "Create a blog post about AI in healthcare" → PM → Content Creator → Writer
• "Research electric vehicles" → PM → Content Creator → Researcher

Configuration des sous-agents

Ajoutez des sous-agents à n'importe quel LlmAgent en utilisant la méthode de construction sub_agent() :

let parent = LlmAgentBuilder::new("parent")
    .description("Coordinates specialized tasks")
    .instruction("Route requests to appropriate specialists.")
    .model(model.clone())
    .sub_agent(Arc::new(specialist_a))
    .sub_agent(Arc::new(specialist_b))
    .build()?;

Points Clés :

• Chaque Agent peut avoir plusieurs sous-agents
• Les sous-agents peuvent avoir leurs propres sous-agents (hiérarchies multi-niveaux)
• Les noms d'Agent doivent être uniques au sein de la hiérarchie
• Les descriptions aident le LLM à décider vers quel Agent transférer

Écrire des instructions de transfert efficaces

Pour des transferts d'Agent réussis, fournissez des instructions et des descriptions claires :

Instructions de l'Agent parent

let coordinator = LlmAgentBuilder::new("coordinator")
    .description("Main customer service coordinator")
    .instruction("Vous êtes un coordinateur de service client. Analysez chaque demande :\n\n\
                 - Pour les questions de FACTURATION (paiements, factures, abonnements) :\n\
                   Transférer à billing_agent\n\n\
                 - Pour les questions TECHNIQUES (erreurs, bugs, dépannage) :\n\
                   Transférer à support_agent\n\n\
                 - Pour les salutations GÉNÉRALES ou les demandes peu claires :\n\
                   Répondez vous-même et posez des questions de clarification")
    .model(model.clone())
    .sub_agent(Arc::new(billing_agent))
    .sub_agent(Arc::new(support_agent))
    .build()?;

Descriptions des sous-agents

let billing_agent = LlmAgentBuilder::new("billing_agent")
    .description("Gère les questions de facturation : paiements, factures, abonnements, remboursements")
    .instruction("Vous êtes un spécialiste de la facturation. Aidez avec les problèmes de paiement et d'abonnement.")
    .model(model.clone())
    .build()?;

let support_agent = LlmAgentBuilder::new("support_agent")
    .description("Gère le support technique : bugs, erreurs, dépannage, questions de type 'comment faire'")
    .instruction("Vous êtes un spécialiste du support technique. Fournissez des conseils étape par étape.")
    .model(model.clone())
    .build()?;

Bonnes Pratiques :

• Utilisez des noms d'Agent descriptifs qui indiquent clairement leur objectif
• Rédigez des descriptions détaillées - le LLM les utilise pour décider des transferts
• Incluez des mots-clés spécifiques dans les descriptions qui correspondent aux demandes utilisateur probables
• Donnez des règles de délégation claires dans les instructions de l'Agent parent
• Utilisez une terminologie cohérente dans toutes les descriptions d'Agent

Tester votre système multi-Agent

Exemples d'exécution

# Run the customer service example
cargo run --bin customer_service

# Run the hierarchical example  
cargo run --bin hierarchical

Exemples d'invites de test

Service client :

• "J'ai une question concernant ma dernière facture" → Devrait être acheminé vers billing_agent
• "L'application ne cesse de planter" → Devrait être acheminé vers support_agent
• "Comment puis-je mettre à niveau mon forfait ?" → Devrait être acheminé vers billing_agent
• "Bonjour, j'ai besoin d'aide" → Devrait rester avec le coordinator pour clarification

Hiérarchique :

• "Créer un article de blog sur l'IA dans le domaine de la santé" → PM → Content Creator → Writer
• "Rechercher l'histoire des véhicules électriques" → PM → Content Creator → Researcher
• "Quel est l'état de nos projets actuels ?" → Devrait rester avec le project_manager

Débogage des problèmes de transfert

Si les transferts ne fonctionnent pas comme prévu :

1. Vérifiez les noms d'Agent - Ils doivent correspondre exactement dans les appels de transfert
2. Examinez les descriptions - Rendez-les plus spécifiques et riches en mots-clés
3. Clarifiez les instructions - Soyez explicite sur le moment de transférer
4. Testez les cas limites - Essayez des requêtes ambiguës pour voir le comportement d'acheminement
5. Recherchez les indicateurs de transfert - [Agent: name] indique quel Agent répond

Instruction Globale

Utilisation Basique

let agent = LlmAgentBuilder::new("assistant")
    .description("A helpful assistant")
    .global_instruction(
        "You are a professional assistant for Acme Corp. \
         Always maintain a friendly but professional tone. \
         Our company values are: customer-first, innovation, and integrity."
    )
    .instruction("Help users with their questions and tasks.")
    .model(model.clone())
    .build()?;

Instruction Globale vs Instruction d'Agent

• Instruction Globale : Appliquée à tous les agents de la hiérarchie, définit la personnalité/le contexte général.
• Instruction d'Agent : Spécifique à chaque agent, définit son rôle et son comportement particuliers.

Les deux instructions sont incluses dans l'historique de conversation, l'instruction globale apparaissant en premier.

Instructions Globales Dynamiques

Pour des scénarios plus avancés, vous pouvez utiliser un fournisseur d'instructions globales qui calcule l'instruction dynamiquement :

use adk_core::GlobalInstructionProvider;

let provider: GlobalInstructionProvider = Arc::new(|ctx| {
    Box::pin(async move {
        // Access context information
        let user_id = ctx.user_id();
        
        // Compute dynamic instruction
        let instruction = format!(
            "You are assisting user {}. Tailor your responses to their preferences.",
            user_id
        );
        
        Ok(instruction)
    })
});

let agent = LlmAgentBuilder::new("assistant")
    .description("A personalized assistant")
    .global_instruction_provider(provider)
    .model(model.clone())
    .build()?;

Injection de Variables d'État

Les instructions globales et d'agent prennent toutes deux en charge l'injection de variables d'état à l'aide de la syntaxe {variable} :

// Set state in a previous agent or tool
// state["company_name"] = "Acme Corp"
// state["user_role"] = "manager"

let agent = LlmAgentBuilder::new("assistant")
    .global_instruction(
        "You are an assistant for {company_name}. \
         The user is a {user_role}."
    )
    .instruction("Help with {user_role}-level tasks.")
    .model(model.clone())
    .build()?;

Le framework injecte automatiquement les valeurs de l'état de session dans les modèles d'instruction.

Modèles multi-Agent courants

Modèle Coordinateur/Distributeur

Un Agent central achemine les requêtes vers des sous-Agent spécialisés :

let billing = LlmAgentBuilder::new("billing")
    .description("Handles billing and payment questions")
    .model(model.clone())
    .build()?;

let support = LlmAgentBuilder::new("support")
    .description("Provides technical support")
    .model(model.clone())
    .build()?;

let coordinator = LlmAgentBuilder::new("coordinator")
    .instruction("Route requests to billing or support agents as appropriate.")
    .sub_agent(Arc::new(billing))
    .sub_agent(Arc::new(support))
    .model(model.clone())
    .build()?;

Exemple de conversation :

User: J'ai une question concernant ma dernière facture

[Agent: coordinator]
Assistant: Je vais vous mettre en relation avec notre spécialiste de la facturation.
🔄 [Transfert demandé à : billing]

[Agent: billing]
Assistant: Bonjour ! Je peux vous aider avec votre facture. 
Quelle question spécifique avez-vous ?

User: Pourquoi ai-je été facturé deux fois ?

[Agent: billing]
Assistant: Laissez-moi enquêter sur cette double facturation pour vous...

Points clés :

• Le coordinator analyse la requête et la transfère à l'Agent billing
• L'Agent billing répond immédiatement dans le même tour
• Les messages suivants continuent avec l'Agent billing
• Les indicateurs de transfert (🔄) montrent quand les transferts se produisent

Décomposition hiérarchique des tâches

Hiérarchies à plusieurs niveaux pour décomposer des tâches complexes :

// Low-level specialists
let researcher = LlmAgentBuilder::new("researcher")
    .description("Researches topics and gathers information")
    .model(model.clone())
    .build()?;

let writer = LlmAgentBuilder::new("writer")
    .description("Writes content based on research")
    .model(model.clone())
    .build()?;

// Mid-level coordinator
let content_creator = LlmAgentBuilder::new("content_creator")
    .description("Creates content by coordinating research and writing")
    .sub_agent(Arc::new(researcher))
    .sub_agent(Arc::new(writer))
    .model(model.clone())
    .build()?;

// Top-level manager
let project_manager = LlmAgentBuilder::new("project_manager")
    .description("Manages content creation projects")
    .sub_agent(Arc::new(content_creator))
    .model(model.clone())
    .build()?;

Combinaison avec des Agents de workflow

Les systèmes multi-Agent fonctionnent bien avec les Agents de workflow (SequentialAgent, ParallelAgent, LoopAgent) :

use adk_agent::workflow::{SequentialAgent, ParallelAgent};

// Create specialized agents
let validator = LlmAgentBuilder::new("validator")
    .instruction("Validate the input data.")
    .output_key("validation_result")
    .model(model.clone())
    .build()?;

let processor = LlmAgentBuilder::new("processor")
    .instruction("Process data if {validation_result} is valid.")
    .output_key("processed_data")
    .model(model.clone())
    .build()?;

// Combine in a sequential workflow
let pipeline = SequentialAgent::new(
    "validation_pipeline",
    vec![Arc::new(validator), Arc::new(processor)]
);

// Use the pipeline as a sub-agent
let coordinator = LlmAgentBuilder::new("coordinator")
    .description("Coordinates data processing")
    .sub_agent(Arc::new(pipeline))
    .model(model.clone())
    .build()?;

Communication entre les Agents

Les Agents dans une hiérarchie communiquent via un état de Session partagé :

// Agent A saves data to state
let agent_a = LlmAgentBuilder::new("agent_a")
    .instruction("Analyze the topic and save key points.")
    .output_key("key_points")  // Automatically saves output to state
    .model(model.clone())
    .build()?;

// Agent B reads data from state
let agent_b = LlmAgentBuilder::new("agent_b")
    .instruction("Expand on the key points: {key_points}")
    .model(model.clone())
    .build()?;

La configuration output_key enregistre automatiquement la réponse finale d'un Agent dans l'état de la Session, la rendant disponible pour les Agents suivants.

Exécution de systèmes multi-agents

Utilisation du Launcher

Le Launcher offre un moyen simple d'exécuter et de tester des systèmes multi-agents :

use adk_rust::Launcher;

let coordinator = /* your multi-agent setup */;

Launcher::new(Arc::new(coordinator))
    .run()
    .await?;

Modes d'exécution :

# Interactive console mode
cargo run --example multi_agent -- chat

# Web server mode with UI
cargo run --example multi_agent -- serve
cargo run --example multi_agent -- serve --port 3000

Fonctionnalités :

• Indicateurs d'Agent : Indique quel Agent répond [Agent: coordinator]
• Visualisation des transferts : Affiche les événements de transfert 🔄 [Transfer requested to: billing_agent]
• Transferts fluides : L'Agent cible répond immédiatement après le transfert
• Historique de conversation : Maintient le contexte à travers les transferts d'Agent

Test des transferts

Pour vérifier que votre système multi-agents fonctionne correctement :

1. Vérifiez que les noms des Agents apparaissent entre crochets lorsqu'ils répondent
2. Recherchez les indicateurs de transfert (🔄) lorsque les Agents transfèrent
3. Vérifiez les réponses immédiates des Agents cibles sans nouvelle sollicitation
4. Testez différents types de requêtes pour assurer un routage approprié
5. Vérifiez les cas limites comme le transfert vers des Agents inexistants

Débogage des problèmes de transfert

Si les transferts ne fonctionnent pas :

• Vérifiez que les sub-agents sont ajoutés via .sub_agent()
• Vérifiez les descriptions des Agents - le LLM les utilise pour décider des transferts
• Relisez les instructions - le parent devrait mentionner quand transférer
• Vérifiez les noms des Agents - ils doivent correspondre exactement dans les appels de transfert
• Activez la journalisation pour voir les actions de transfert dans le flux d'événements

Bonnes pratiques

1. Descriptions claires : Rédigez des noms et des descriptions d'Agent descriptifs pour aider le LLM à prendre de bonnes décisions de transfert
2. Instructions spécifiques : Donnez à chaque Agent des instructions claires et ciblées pour son rôle
3. Utilisez une instruction globale : Définissez une personnalité et un contexte cohérents pour tous les Agents
4. Gestion de l'état : Utilisez output_key et des variables d'état pour la communication entre Agents
5. Limitez la profondeur de la hiérarchie : Gardez les hiérarchies peu profondes (2-3 niveaux) pour une meilleure maintenabilité
6. Testez la logique de transfert : Vérifiez que les Agents transfèrent aux bons sub-agents pour différentes requêtes

Liens associés

• LLM Agent - Configuration de base de l'Agent
• Agents de Workflow - Agents Séquentiels, Parallèles et Loop
• Sessions - Gestion de l'état de Session

---

Précédent : ← Agents de Workflow | Suivant : Graph Agents →