انتقل إلى المحتوى الرئيسي

العمارة متعددة الوكيل

توظف AuroraSOC 16 وكيلًا متخصصًا في الذكاء الاصطناعي تم تنظيمهم في طوبولوجيا المحور والتحدث. تشرح هذه الصفحة القرارات المعمارية وراء هذا التصميم وكيفية تعاون الوكلاء.

لماذا تعدد الوكلاء المتخصصين؟​

يعاني وكيل واحد للأغراض العامة من اتساع نطاق العمليات الأمنية. يعتبر:

  • يحتاج محلل البرامج الضارة إلى معرفة عميقة بالهندسة العكسية وقواعد YARA وسلوك بيئة العزل (Sandbox)
  • يحتاج محلل الامتثال إلى معرفة أطر عمل NIST وISO 27001 وHIPAA وPCI-DSS
  • يحتاج متخصص أمان CPS إلى فهم البروتوكولات الصناعية (Modbus، DNP3، OPC UA)

** لا يمكن لأي موجه LLM واحد أن يغطي جميع هذه المجالات بشكل فعال. ** يسمح التخصص بما يلي:

  1. مطالبات النظام المركزة — يتمتع كل وكيل بشخصية مخصصة يتمتع بخبرة في المجال
  2. مجموعات الأدوات ذات الصلة — يرى كل وكيل فقط الأدوات ذات الصلة بنطاقه
  3. الذاكرة المحسنة — يتم ضبط إعدادات الذاكرة المسبقة حسب نوع الوكيل
  4. قياس مستقل — قياس العوامل الساخنة دون قياس العوامل الباردة

طوبولوجيا المحور والتحدث​

المنسق​

المنسق هو الوكيل الوحيد الذي يمكنه التواصل مباشرة مع جميع الوكلاء الآخرين. هو - هي:

  1. يتلقى المهام من المستخدمين أو مسار الأحداث
  2. تحليل المهمة لتحديد المتخصصين المطلوبين
  3. الإرساليات تعمل باستخدام HandoffTools (واحدة لكل وكيل متخصص)
  4. المجاميع تنتج من متخصصين متعددين
  5. تجميع الرد النهائي

لا يقوم المنسق بإجراء التحليل الأمني ​​الفعلي - فهو منسق.

HandoffTools​

يتم عرض كل وكيل متخصص للمنسق باعتباره HandoffTool:

# From aurorasoc/agents/orchestrator/server.py
handoff_tools = []
for agent_type in AgentType:
    if agent_type != AgentType.ORCHESTRATOR:
        tool = HandoffTool(
            agent=agent_type.value,
            description=f"Delegate to {agent_type.value} specialist"
        )
        handoff_tools.append(tool)

وهذا يعني أن برنامج LLM الخاص بـ Orchestrator يرى أدوات مثل:

  • handoff_security_analyst — "تفويض إلى متخصص في محلل الأمان"
  • handoff_threat_hunter — "مفوض إلى متخصص في صياد التهديدات"
  • handoff_malware_analyst — "تفويض إلى متخصص في محلل البرامج الضارة"
  • ... (المجموع 15)

اتصال الوكيل: بروتوكول A2A​

يتواصل الوكلاء عبر HTTP باستخدام بروتوكول Agent-to-Agent (A2A):

لماذا A2A على استدعاءات الوظائف المباشرة؟​

يقتربالايجابياتسلبيات
استدعاءات الوظائف المباشرةسريع وبسيطاقتران محكم، عملية واحدة، بدون تحجيم
** قائمة انتظار الرسائل **منفصلة وقابلة للتطويرمعقدة وغير متزامنة ويصعب تصحيحها
بروتوكول A2Aبروتوكول قياسي منفصل ولكنه متزامن وقابل للنشر بشكل مستقلحمل HTTP (الحد الأدنى)

تم اختيار A2A للأسباب التالية:

  • يعمل كل وكيل باعتباره خدمة HTTP مستقلة (حاوية منفصلة)
  • يمكن نشر الوكلاء على أجهزة مختلفة للتوسع
  • البروتوكول موحد — يمكن لأي وكيل متوافق مع A2A الانضمام
  • عمليات التحقق من السلامة وقواطع الدائرة تعمل بشكل طبيعي مع HTTP

الإرسال الموازي​

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

تقوم وظيفة dispatch_parallel() في وحدة الإرسال بإرسال الطلبات بشكل متزامن باستخدام asyncio.gather()، مما يقلل وقت التحقيق بشكل كبير.

نمط مصنع الوكيل​

يتم إنشاء جميع الوكلاء بواسطة AuroraAgentFactory:

يتلقى كل وكيل:

  1. ** موجه نظام متخصص ** من prompts.py
  2. ThinkTool كأداة أولى (مفروض في الخطوة 1 للاستدلال)
  3. ** أدوات MCP الخاصة بالمجال ** ذات الصلة بدورها
  4. TieredAgentMemory مع إعداد مسبق يتوافق مع احتياجات الذاكرة الخاصة به
قرار التصميم: المصنع المركزي

لماذا مصنع واحد بدلا من أن يقوم كل وكيل ببناء نفسه؟ لأن:

  1. الاتساق — يتبع جميع الوكلاء نفس نمط البناء
  2. التكوين — مكان مركزي لتعديل إنشاء الوكيل
  3. الاختبار — من السهل محاكاة المصنع لاختبارات الوحدة
  4. المخزون — مصدر واحد للحقيقة لجميع أنواع الوكلاء