أنظمة متعددة الوكلاء

قم ببناء تطبيقات متطورة عن طريق تجميع الـ agents المتخصصة في فرق.

ما ستبنيه

في هذا الدليل، ستقوم بإنشاء نظام خدمة عملاء حيث يقوم المنسق بتوجيه الاستفسارات إلى المتخصصين:

                        ┌─────────────────────┐
       استعلام المستخدم       │                     │
      ────────────────▶ │      COORDINATOR      │
                        │  التوجيه إلى خبير  │
                        └──────────┬──────────┘
                                   │
                   ┌───────────────┴───────────────┐
                   │                               │
                   ▼                               ▼
        ┌──────────────────┐            ┌──────────────────┐
        │  BILLING AGENT   │            │  SUPPORT AGENT   │
        │                  │            │                  │
        │  💰 المدفوعات    │            │  🔧 المشاكل التقنية  │
        │  📄 الفواتير     │            │  🐛 تقارير الأخطاء│
        │  💳 الاشتراكات   │            │  ❓ كيفية الاستخدام│
        └──────────────────┘            └──────────────────┘

المفاهيم الأساسية:

  • Coordinator - يتلقى جميع الطلبات، ويقرر من يتعامل معها
  • Specialists - الـ agents المركزة التي تتفوق في مجالات محددة
  • Transfer - التسليم السلس من المنسق إلى المتخصص

البدء السريع

1. إنشاء مشروعك

cargo new multi_agent_demo
cd multi_agent_demo

أضف التبعيات إلى Cargo.toml:

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

أنشئ .env باستخدام مفتاح API الخاص بك:

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

2. مثال خدمة العملاء

إليك مثال عملي كامل:

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(())
}

🏢 مركز خدمة العملاء المنسق ← Billing Agent | Support Agent

مثال التفاعل:

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...

كيفية عمل نقل المهام بين الوكلاء المتعددين

الصورة الكبيرة

عندما تضيف وكلاء فرعيين إلى وكيل رئيسي، يكتسب LLM القدرة على تفويض المهام:

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

تدفق النقل خطوة بخطوة

إليك ما يحدث بالضبط عندما يسأل المستخدم سؤالًا يتعلق بالفواتير:

┌──────────────────────────────────────────────────────────────────────┐
│ 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!                  │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘

ما الذي يجعلها تعمل

المكونالدور
.sub_agent()يسجل المتخصصين تحت الوكيل الرئيسي
transfer_to_agent toolيتم حقنه تلقائيًا عند وجود وكلاء فرعيين
أوصاف Agentتساعد LLM في تحديد أي agent يتعامل مع ماذا
Runnerيكتشف أحداث النقل ويستدعي الـ agent المستهدف
Shared sessionيتم الاحتفاظ بالحالة والسجل عبر عمليات النقل

قبل وبعد إضافة الوكلاء الفرعيين

بدون وكلاء فرعيين - Agent واحد يقوم بكل شيء:

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

مع وكلاء فرعيين - المتخصصون يتعاملون مع مجالهم:

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

أنظمة الوكلاء المتعددين الهرمية

للسيناريوهات المعقدة، يمكنك إنشاء تسلسلات هرمية متعددة المستويات. يمكن لكل Agent أن يكون لديه وكلاء فرعيون خاصون به، مما يشكل شجرة:

مرئي: فريق محتوى من 3 مستويات

                    ┌─────────────────────┐
                    │  PROJECT MANAGER    │  ← المستوى 1: منسق المستوى الأعلى
                    │  "إدارة المشاريع"   │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │  CONTENT CREATOR    │  ← المستوى 2: منسق المستوى المتوسط  
                    │  "تنسيق البحث والكتابة" │
                    └──────────┬──────────┘
                               │
              ┌────────────────┴────────────────┐
              │                                 │
              ▼                                 ▼
   ┌──────────────────┐              ┌──────────────────┐
   │   RESEARCHER     │              │     WRITER       │  ← المستوى 3: المتخصصون
   │                  │              │                  │
   │  📚 جمع الحقائق  │              │  ✍️ كتابة المحتوى │
   │  🔍 تحليل البيانات │              │  📝 تنقيح النص   │
   │  📊 البحث عن مصادر │              │  🎨 الأسلوب والنبرة │
   └──────────────────┘              └──────────────────┘

كيف تتدفق الطلبات إلى الأسفل

User: "أنشئ منشور مدونة عن السيارات الكهربائية"
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  PROJECT MANAGER: "هذه مهمة محتوى"                           │
│  → يحول إلى content_creator                                 │
└─────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  CONTENT CREATOR: "أحتاج إلى البحث أولاً، ثم الكتابة"          │
│  → يحول إلى researcher                                      │
└─────────────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────────┐
│  RESEARCHER: "إليك ما وجدته عن السيارات الكهربائية..."         │
│  → يقدم ملخص البحث                                          │
└─────────────────────────────────────────────────────────────┘

مثال كامل على الكود

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")?);

    // المستوى 3: المتخصصون النهائيون
    let researcher = LlmAgentBuilder::new("researcher")
        .description("يبحث في المواضيع ويجمع معلومات شاملة")
        .instruction("أنت متخصص في البحث. عندما يُطلب منك البحث في موضوع ما:\n\
                     - اجمع الحقائق والبيانات الرئيسية\n\
                     - حدد المحاور الرئيسية والمواضيع الفرعية\n\
                     - لاحظ المصادر أو المراجع المهمة\n\
                     قدم ملخصات بحث شاملة ومنظمة جيدًا.")
        .model(model.clone())
        .build()?;

    let writer = LlmAgentBuilder::new("writer")
        .description("يكتب محتوى مصقولًا بناءً على البحث")
        .instruction("أنت كاتب محتوى. عندما يُطلب منك الكتابة:\n\
                     - أنشئ محتوى جذابًا وواضحًا\n\
                     - استخدم نبرة مناسبة للجمهور\n\
                     - هيكل المحتوى منطقيًا\n\
                     - صقل المحتوى من حيث القواعد والأسلوب\n\
                     أنتج محتوى احترافيًا جاهزًا للنشر.")
        .model(model.clone())
        .build()?;

    // المستوى 2: منسق المحتوى
    let content_creator = LlmAgentBuilder::new("content_creator")
        .description("ينسق إنشاء المحتوى عن طريق تفويض البحث والكتابة")
        .instruction("أنت قائد إنشاء المحتوى. لطلبات المحتوى:\n\n\
                     - إذا كان هناك حاجة إلى RESEARCH: حول إلى researcher\n\
                     - إذا كان هناك حاجة إلى WRITING: حول إلى writer\n\
                     - للتخطيط أو النظرة العامة: تعامل بنفسك\n\n\
                     نسق بين مراحل البحث والكتابة.")
        .model(model.clone())
        .sub_agent(Arc::new(researcher))
        .sub_agent(Arc::new(writer))
        .build()?;

    // المستوى 1: مدير المستوى الأعلى
    let project_manager = LlmAgentBuilder::new("project_manager")
        .description("يدير المشاريع وينسق مع فريق المحتوى")
        .instruction("أنت مدير مشروع. للطلبات الواردة:\n\n\
                     - لمهام إنشاء CONTENT: حول إلى content_creator\n\
                     - لحالة PROJECT STATUS أو الأسئلة العامة: تعامل بنفسك\n\n\
                     تتبع الأهداف والمواعيد النهائية الشاملة للمشروع.")
        .model(model.clone())
        .sub_agent(Arc::new(content_creator))
        .build()?;

    println!("📊 نظام وكلاء متعددين هرمي");
    println!();
    println!("   project_manager");
    println!("       └── content_creator");
    println!("               ├── researcher");
    println!("               └── writer");
    println!();

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

Agent Hierarchy:

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

أمثلة على الأوامر:

  • "أنشئ منشور مدونة عن الذكاء الاصطناعي في الرعاية الصحية" ← PM ← Content Creator ← Writer
  • "ابحث عن السيارات الكهربائية" ← PM ← Content Creator ← Researcher

تكوين العميل الفرعي

أضف العملاء الفرعيين إلى أي LlmAgent باستخدام طريقة البناء 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()?;

نقاط رئيسية:

  • يمكن لكل عميل أن يحتوي على عدة عملاء فرعيين
  • يمكن للعملاء الفرعيين أن يحتويوا على عملائهم الفرعيين (تسلسلات هرمية متعددة المستويات)
  • يجب أن تكون أسماء العملاء فريدة ضمن التسلسل الهرمي
  • تساعد الأوصاف الـ LlmAgent في تحديد العميل الذي يجب التحويل إليه

كتابة تعليمات تحويل فعالة

لتحويلات العملاء الناجحة، قدم تعليمات وأوصافًا واضحة:

تعليمات العميل الأصل

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()?;

أوصاف العملاء الفرعيين

let billing_agent = LlmAgentBuilder::new("billing_agent")
    .description("يتعامل مع أسئلة الفواتير: المدفوعات، الفواتير، الاشتراكات، المبالغ المستردة")
    .instruction("أنت متخصص فواتير. ساعد في مشكلات الدفع والاشتراك.")
    .model(model.clone())
    .build()?;

let support_agent = LlmAgentBuilder::new("support_agent")
    .description("يتعامل مع الدعم الفني: الأخطاء، الأعطال، استكشاف الأخطاء وإصلاحها، أسئلة الكيفية")
    .instruction("أنت متخصص دعم فني. قدم إرشادات خطوة بخطوة.")
    .model(model.clone())
    .build()?;

أفضل الممارسات:

  • استخدم أسماء عملاء وصفية تشير بوضوح إلى غرضهم
  • اكتب أوصافًا مفصلة - يستخدمها الـ LlmAgent لاتخاذ قرار التحويلات
  • قم بتضمين كلمات مفتاحية محددة في الأوصاف التي تتطابق مع طلبات المستخدم المحتملة
  • قدم قواعد تفويض واضحة في تعليمات العميل الأصل
  • استخدم مصطلحات متسقة عبر أوصاف العملاء

اختبار نظام العملاء المتعددين الخاص بك

تشغيل الأمثلة

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

# Run the hierarchical example  
cargo run --bin hierarchical

أمثلة على أوامر الاختبار

خدمة العملاء:

  • "لدي سؤال حول فاتورتي الأخيرة" → يجب أن يوجه إلى billing_agent
  • "التطبيق يتعطل باستمرار" → يجب أن يوجه إلى support_agent
  • "كيف أقوم بترقية خطتي؟" → يجب أن يوجه إلى billing_agent
  • "مرحبًا، أحتاج إلى مساعدة" → يجب أن يبقى مع coordinator للتوضيح

هرمي:

  • "إنشاء منشور مدونة حول الذكاء الاصطناعي في الرعاية الصحية" → PM → Content Creator → Writer
  • "بحث تاريخ المركبات الكهربائية" → PM → Content Creator → Researcher
  • "ما هي حالة مشاريعنا الحالية؟" → يجب أن يبقى مع project_manager

تصحيح مشكلات التحويل

إذا لم تكن التحويلات تعمل كما هو متوقع:

  1. تحقق من أسماء العملاء - يجب أن تتطابق تمامًا في استدعاءات التحويل
  2. راجع الأوصاف - اجعلها أكثر تحديدًا وغنية بالكلمات المفتاحية
  3. وضح التعليمات - كن صريحًا بشأن وقت التحويل
  4. اختبر الحالات الحدية - جرب الطلبات الغامضة لمعرفة سلوك التوجيه
  5. ابحث عن مؤشرات التحويل - [Agent: name] يوضح أي عميل يستجيب

تعليمات عامة

الاستخدام الأساسي

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()?;

التعليمات العامة مقابل تعليمات الوكيل

  • تعليمات عامة: تُطبق على جميع Agents في التسلسل الهرمي، وتحدد الشخصية/السياق العام
  • تعليمات الوكيل: خاصة بكل Agent، وتحدد دوره وسلوكه الخاص

يتم تضمين كلتا التعليمات في سجل المحادثة، مع ظهور التعليمات العامة أولاً.

تعليمات عامة ديناميكية

للسيناريوهات الأكثر تقدمًا، يمكنك استخدام Global Instruction Provider يقوم بحساب التعليمات ديناميكيًا:

use adk_core::GlobalInstructionProvider;

let provider: GlobalInstructionProvider = Arc::new(|ctx| {
    Box::pin(async move {
        // الوصول إلى معلومات السياق
        let user_id = ctx.user_id();
        
        // حساب التعليمات الديناميكية
        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()?;

حقن متغيرات الحالة

تدعم كل من التعليمات العامة وتعليمات الوكيل حقن متغيرات الحالة باستخدام صيغة {variable}:

// تعيين الحالة في Agent أو 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()?;

يقوم إطار العمل تلقائيًا بحقن القيم من حالة الجلسة في قوالب التعليمات.

أنماط الوكلاء المتعددين الشائعة

نمط المنسق/الموزع

يقوم وكيل مركزي بتوجيه الطلبات إلى وكلاء فرعيين متخصصين:

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()?;

مثال على المحادثة:

User: لدي سؤال حول فاتورتي الأخيرة

[Agent: coordinator]
Assistant: سأصلك بأخصائي الفواتير لدينا.
🔄 [تم طلب التحويل إلى: billing]

[Agent: billing]
Assistant: مرحباً! يمكنني مساعدتك بخصوص فاتورتك. ما هو سؤالك بالتحديد؟

User: لماذا تم خصم المبلغ مرتين؟

[Agent: billing]
Assistant: دعني أتحقق من هذا الخصم المكرر لك...

النقاط الرئيسية:

  • يقوم المنسق بتحليل الطلب ويحوله إلى وكيل الفوترة.
  • يستجيب وكيل الفوترة فوراً في نفس الدور.
  • تستمر الرسائل اللاحقة مع وكيل الفوترة.
  • تُظهر مؤشرات التحويل (🔄) متى تحدث عمليات التسليم.

تفكيك المهام الهرمي

تسلسلات هرمية متعددة المستويات لتفكيك المهام المعقدة:

// 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()?;

الدمج مع وكلاء سير العمل

تعمل أنظمة الوكلاء المتعددين بشكل جيد مع وكلاء سير العمل (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()?;

التواصل بين الوكلاء

يتواصل الوكلاء في التسلسل الهرمي من خلال حالة الجلسة المشتركة:

// 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()?;

يحفظ إعداد output_key تلقائياً الاستجابة النهائية للوكيل في حالة الجلسة، مما يجعلها متاحة للوكلاء اللاحقين.

تشغيل أنظمة متعددة الوكلاء

استخدام Launcher

يوفر Launcher طريقة سهلة لتشغيل واختبار أنظمة متعددة الوكلاء:

use adk_rust::Launcher;

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

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

أوضاع التشغيل:

# وضع وحدة التحكم التفاعلي
cargo run --example multi_agent -- chat

# وضع خادم الويب مع واجهة المستخدم
cargo run --example multi_agent -- serve
cargo run --example multi_agent -- serve --port 3000

الميزات:

  • مؤشرات Agent: توضح أي Agent يستجيب [Agent: coordinator]
  • تصور النقل: يعرض أحداث النقل 🔄 [Transfer requested to: billing_agent]
  • التسليم السلس: يستجيب Agent الهدف فوراً بعد النقل
  • سجل المحادثات: يحافظ على السياق عبر عمليات نقل Agent

اختبار عمليات النقل

للتحقق من أن نظامك متعدد الوكلاء يعمل بشكل صحيح:

  1. تحقق من ظهور أسماء Agent بين قوسين عند استجابتهم
  2. ابحث عن مؤشرات النقل (🔄) عندما يقوم Agent بعمليات تسليم
  3. تحقق من الاستجابات الفورية من Agent الهدف دون إعادة المطالبة
  4. اختبر أنواع الطلبات المختلفة لضمان التوجيه الصحيح
  5. تحقق من حالات الحافة مثل النقل إلى Agent غير موجود

تصحيح أخطاء مشكلات النقل

إذا كانت عمليات النقل لا تعمل:

  • تحقق من إضافة sub-agents عبر .sub_agent()
  • تحقق من أوصاف Agent - يستخدم LLM هذه لتحديد عمليات النقل
  • راجع التعليمات - يجب أن يذكر Parent متى يتم النقل
  • تحقق من أسماء Agent - يجب أن تتطابق تماماً في استدعاءات النقل
  • قم بتمكين التسجيل لرؤية إجراءات النقل في تدفق الأحداث

أفضل الممارسات

  1. أوصاف واضحة: اكتب أسماء وأوصاف Agent واضحة لمساعدة LLM على اتخاذ قرارات نقل جيدة
  2. تعليمات محددة: أعط كل Agent تعليمات واضحة ومركزة لدوره
  3. استخدم تعليمات عامة: قم بتعيين شخصية وسياق متسقين عبر جميع Agent
  4. إدارة الحالة: استخدم output_key ومتغيرات الحالة لاتصال Agent
  5. الحد من عمق التسلسل الهرمي: حافظ على التسلسل الهرمي ضحلاً (مستويان إلى 3 مستويات) لتحسين قابلية الصيانة
  6. اختبر منطق النقل: تحقق من أن Agent يقومون بالنقل إلى sub-agents الصحيحين للطلبات المختلفة

ذات صلة


السابق: ← Workflow Agents | التالي: Graph Agents →