ADK-Rust

Systèmes Multi-Agents

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

Aperçu de la hiérarchie des agents

Rendering architecture…

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 :

  • Coordinateur - Reçoit toutes les requêtes, décide qui les traite
  • Spécialistes - Agents ciblés qui excellent dans des domaines spécifiques
  • Transfert - Passage de relais fluide du coordinateur au spécialiste

Démarrage Rapide

1. Créez votre projet

cargo new multi_agent_demo
cd multi_agent_demo

Ajoutez des dépendances à Cargo.toml :

[dependencies]
adk-rust = "2.0.0"
tokio = { version = "1", features = ["full"] }
dotenvy = "0.15"

Créez .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-agents

Vue d'ensemble

Lorsque vous ajoutez des sous-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 :

┌──────────────────────────────────────────────────────────────────────┐
│ STEP 1: User sends message                                           │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   User: "Why was I charged twice on my invoice?"                     │
│                                                                      │
│                              ↓                                       │
│                                                                      │
│   ┌──────────────────────────────────────┐                          │
│   │         COORDINATOR AGENT            │                          │
│   │  Receives message first              │                          │
│   └──────────────────────────────────────┘                          │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────────────┐
│ STEP 2: LLM analyzes and decides to transfer                         │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   🧠 LLM thinks: "This is about an invoice charge..."                │
│                  "Invoice = billing topic..."                        │
│                  "I should transfer to billing_agent"                │
│                                                                      │
│   📞 LLM calls: transfer_to_agent(agent_name="billing_agent")        │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────────────┐
│ STEP 3: Runner detects transfer and invokes target                   │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   ┌─────────┐     transfer event      ┌─────────────────┐           │
│   │ Runner  │ ─────────────────────▶  │  billing_agent  │           │
│   └─────────┘   (same user message)   └─────────────────┘           │
│                                                                      │
│   • Runner finds "billing_agent" in agent tree                       │
│   • Creates new context with SAME user message                       │
│   • Invokes billing_agent immediately                                │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────────────┐
│ STEP 4: Target agent responds                                        │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   ┌─────────────────────────────────────────┐                       │
│   │           billing_agent responds        │                       │
│   │                                         │                       │
│   │  "I can help with your duplicate        │                       │
│   │   charge. Let me investigate..."        │                       │
│   └─────────────────────────────────────────┘                       │
│                                                                      │
│   ✅ User sees seamless response - no interruption!                  │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘

Ce qui fait que ça marche

ComposantRôle
.sub_agent()Enregistre les spécialistes sous le parent
transfer_to_agent toolInjecté automatiquement lorsque des sous-agents existent
Descriptions des agentsAident le LLM à décider quel agent gère quoi
RunnerDétecte les événements de transfert et invoque l'agent cible
Session partagéeÉtat et historique conservés lors des transferts

Avant et après l'ajout de sous-agents

Sans sous-agents - Un seul agent fait tout :

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

Avec sous-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 multiniveaux. Chaque agent peut avoir ses propres sous-agents, formant un arbre :

Visuel : Équipe de Contenu à 3 Niveaux

                    ┌─────────────────────┐
                    │  PROJECT MANAGER    │  ← Level 1: Top-level coordinator
                    │  "Manage projects"  │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │  CONTENT CREATOR    │  ← Level 2: Mid-level coordinator  
                    │  "Coordinate R&W"   │
                    └──────────┬──────────┘
                               │
              ┌────────────────┴────────────────┐
              │                                 │
              ▼                                 ▼
   ┌──────────────────┐              ┌──────────────────┐
   │   RESEARCHER     │              │     WRITER       │  ← Level 3: Specialists
   │                  │              │                  │
   │  📚 Gather facts │              │  ✍️ Write content │
   │  🔍 Analyze data │              │  📝 Polish text  │
   │  📊 Find sources │              │  🎨 Style & tone │
   └──────────────────┘              └──────────────────┘

Comment les Requêtes Descendent

User: "Create a blog post about electric vehicles"
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  PROJECT MANAGER: "This is a content task"                  │
│  → transfers to content_creator                             │
└─────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  CONTENT CREATOR: "Need research first, then writing"       │
│  → transfers to researcher                                  │
└─────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  RESEARCHER: "Here's what I found about EVs..."             │
│  → provides research summary                                │
└─────────────────────────────────────────────────────────────┘

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 d'invites :

  • "Créez un article de blog sur l'IA dans les soins de santé" → PM → Content Creator → Writer
  • "Recherchez des véhicules électriques" → 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 multiniveaux)
  • Les noms d'agents doivent être uniques au sein de la hiérarchie
  • Les descriptions aident le LLM à décider à quel agent transférer

Rédiger des Instructions de Transfert Efficaces

Pour des transferts d'agents 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("You are a customer service coordinator. Analyze each request:\n\n\
                 - For BILLING questions (payments, invoices, subscriptions):\n\
                   Transfer to billing_agent\n\n\
                 - For TECHNICAL questions (errors, bugs, troubleshooting):\n\
                   Transfer to support_agent\n\n\
                 - For GENERAL greetings or unclear requests:\n\
                   Respond yourself and ask clarifying questions")
    .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("Handles billing questions: payments, invoices, subscriptions, refunds")
    .instruction("You are a billing specialist. Help with payment and subscription issues.")
    .model(model.clone())
    .build()?;

let support_agent = LlmAgentBuilder::new("support_agent")
    .description("Handles technical support: bugs, errors, troubleshooting, how-to questions")
    .instruction("You are a technical support specialist. Provide step-by-step guidance.")
    .model(model.clone())
    .build()?;

Meilleures Pratiques :

  • Utilisez des noms d'agents 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 probables des utilisateurs
  • 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'agents

Tester Votre Système Multi-Agent

Exécution des Exemples

cargo run --manifest-path examples/tier_examples/enterprise/Cargo.toml --bin 14-enterprise-multi-agent

Exemples d'Invites de Test

Service Client:

  • "J'ai une question concernant ma dernière facture" → Doit être dirigé vers billing_agent
  • "L'application plante sans cesse" → Doit être dirigé vers support_agent
  • "Comment puis-je mettre à niveau mon forfait ?" → Doit être dirigé vers billing_agent
  • "Bonjour, j'ai besoin d'aide" → Doit rester avec 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 ?" → Doit rester avec project_manager

Débogage des problèmes de transfert

Si les transferts ne fonctionnent pas comme prévu :

  1. Vérifiez les noms des agent - 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 observer le comportement de routage
  5. Recherchez les indicateurs de transfert - [Agent: name] indique quel agent répond

Instruction Globale

Utilisation de base

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 Agent

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

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

Instructions Globales Dynamiques

Pour des scénarios plus avancés, vous pouvez utiliser un fournisseur d'instruction globale 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 Agent prennent 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 des valeurs de l'état de session dans les modèles d'instruction.

Modèles Multi-Agents Courants

Modèle Coordinateur/Dispatcher

Un agent central achemine les requêtes vers des sous-agents 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: I have a question about my last invoice

[Agent: coordinator]
Assistant: I'll connect you with our billing specialist.
🔄 [Transfer requested to: billing]

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

User: Why was I charged twice?

[Agent: billing]
Assistant: Let me investigate that duplicate charge for you...

Points Clés :

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

Décomposition Hiérarchique des Tâches

Hiérarchies multi-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 les Agents de Workflow

Les systèmes multi-agents fonctionnent bien avec les agents de workflow (Sequential, Parallel, Loop) :

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 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 session, la rendant disponible aux agents suivants.

AgentTool : État et Transmission d'Artefacts

Lors de l'utilisation de AgentTool pour envelopper des agents en tant qu'outils, les changements d'état et les artefacts des sous-agents sont automatiquement transmis au contexte parent :

use adk_tool::AgentTool;

// Create a sub-agent that modifies state
let data_processor = LlmAgentBuilder::new("data_processor")
    .instruction("Process the data and save results.")
    .output_key("processed_data")
    .model(model.clone())
    .build()?;

// Wrap as a tool - state_delta and artifact_delta are forwarded
let processor_tool = AgentTool::new(Arc::new(data_processor));

// Parent agent can use the tool and see state changes
let coordinator = LlmAgentBuilder::new("coordinator")
    .instruction("Use the data_processor tool, then access {processed_data}.")
    .model(model.clone())
    .tool(Arc::new(processor_tool))
    .build()?;

AgentTool exécute les sous-agents en mode non-streaming (StreamingMode::None) en interne, de sorte que le sous-agent accumule sa réponse complète avant de la renvoyer au parent. Cela évite les problèmes où des morceaux de streaming partiels pourraient produire des résultats vides.

Cela permet un flux de données transparent entre les agents parent et enfant lors de l'utilisation du modèle AgentTool.

Exécution de Systèmes Multi-Agents

Utilisation du Lanceur

Le Launcher offre un moyen facile 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 --manifest-path examples/tier_examples/enterprise/Cargo.toml --bin 14-enterprise-multi-agent

# Use a generated API project when you need HTTP serving
cargo adk new multi_agent_api --template api

Fonctionnalités :

  • Indicateurs d'agent : Montre 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 des conversations : Maintient le contexte entre les transferts d'agents

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 se passent la main
  3. Vérifiez les réponses immédiates des agents cibles sans relancer la requête
  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 sous-agents sont ajoutés via .sub_agent()
  • Vérifiez les descriptions des agents - le LLM les utilise pour décider des transferts
  • Passez en revue 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 d'agent et des descriptions 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: Maintenez des 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 sous-agents corrects pour différentes requêtes

Sujets connexes

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