# المقال الذي ازال فعلا كل العقبات في تصميم نظام الوكلاء المتعددين

> Author: Tony Lee
> Published: 2026-02-08
> URL: https://tonylee.im/ar/blog/multi-agent-design-guide-that-actually-helped/
> Reading time: 5 minutes
> Language: ar
> Tags: ذكاء-اصطناعي, وكلاء-ذكاء-اصطناعي, وكلاء-متعددون, هندسة-معمارية, تنسيق

## Canonical

https://tonylee.im/ar/blog/multi-agent-design-guide-that-actually-helped/

## Rollout Alternates

en: https://tonylee.im/en/blog/multi-agent-design-guide-that-actually-helped/
ko: https://tonylee.im/ko/blog/multi-agent-design-guide-that-actually-helped/
ja: https://tonylee.im/ja/blog/multi-agent-design-guide-that-actually-helped/
zh-CN: https://tonylee.im/zh-CN/blog/multi-agent-design-guide-that-actually-helped/
zh-TW: https://tonylee.im/zh-TW/blog/multi-agent-design-guide-that-actually-helped/

## Description

انماط التنسيق وطرق التواصل وادارة الذاكرة ومخاطر بيئة الانتاج - دليل عملي اجاب على كل ما كان يعيقني في تصميم انظمة الوكلاء المتعددين.

## Summary

المقال الذي ازال فعلا كل العقبات في تصميم نظام الوكلاء المتعددين is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts.

## Outline

- لماذا الوكلاء المتعددون
- ثلاثة انماط للتنسيق
  - نمط المشرف (Supervisor)
  - نمط السرب (Swarm)
  - النمط الهرمي (Hierarchical)
- كيف يتواصل الوكلاء
- هندسة الذاكرة لانظمة الوكلاء المتعددين
  - ذاكرة مبنية على الجلسات (Session-Based)
  - ذاكرة النافذة (Window Memory)
  - الذاكرة العرضية (Episodic Memory)
- اعتبارات بيئة الانتاج
  - تكاليف الرموز
  - زمن الاستجابة
  - منع انتشار الاخطاء
- انماط مضادة يجب تجنبها
- الخلاصة

## Content

يعمل فريقنا حاليا على تصميم نظام وكلاء ذكاء اصطناعي. بناء وكيل واحد بدا قابلا للادارة، لكن بمجرد ان حاولنا ربط عدة وكلاء معا، بدات الاسئلة تتراكم.

اي بنية تنسيق نستخدم؟ كيف يتواصل الوكلاء؟ كيف ندير الذاكرة عبر النظام؟

ثم وجدت مقالا كتبه Rohit Ghumare غطى تقريبا كل ما كنت اعاني منه. اليكم تحليلا للافكار الرئيسية مع تجربتي الشخصية.

## لماذا الوكلاء المتعددون

كما ذكرت في منشورات سابقة، الوكلاء المتعددون ليسوا دائما الحل الامثل. لكنني قضيت العام الماضي بأكمله افشل في ادارة السياق مع وكيل واحد.

المشكلة: نافذة السياق لوكيل واحد تمتلئ بسرعة، وعندما تمتلئ يبدا الوكيل بالنسيان. والاسوأ ان محاولة التعامل مع عدة مجالات في وقت واحد تضعف قدرته على الحكم.

الوكلاء المتعددون يحلون هذا بفصل المسؤوليات - لكن ذلك يضيف عبء التنسيق. ادارة هذا العبء هي التحدي الحقيقي، والمقال يتناوله مباشرة.

## ثلاثة انماط للتنسيق

هذا كان الجزء الاكثر عملية. بدلا من الترتيب حسب "ما هو الاكثر اثارة للاعجاب"، يركز المقال على **متى نستخدم ماذا**.

### نمط المشرف (Supervisor)

وكيل مدير يقسم المهام ويوزعها على العمال ويجمع النتائج.

- **الافضل لـ**: المهام التي تنقسم بوضوح الى مهام فرعية، او عند الحاجة الى التتبع والمراجعة
- **الحجم المثالي**: 3-8 عمال
- **انتبه**: كل القرارات تمر عبر المشرف مما قد يخلق اختناقا

### نمط السرب (Swarm)

بدون مدير مركزي. الوكلاء يتواصلون مباشرة نظير لنظير ويتنظمون ذاتيا.

- **الافضل لـ**: المشاكل التي تحتاج وجهات نظر متنوعة، او حيث الاستجابة الفورية مهمة
- **انتبه**: عمل مكرر، حلقات لا نهائية، تقارب دون المستوى الامثل. تصحيح الاخطاء صعب

### النمط الهرمي (Hierarchical)

امتداد تكراري لنمط المشرف. منسق اعلى → مديرون وسيطون → عمال.

- **الافضل لـ**: الانظمة التي تضم اكثر من 10 وكلاء، او عندما تحتاج فصل الاستراتيجية عن التكتيك
- **انتبه**: تكاليف الرموز تتضاعف مع كل طبقة تنسيق

من تجربتي الشخصية، نمط المشرف كان الاكثر استقرارا. المفتاح هو توزيع العمال بكفاءة ومعالجة الاخطاء بشكل صحيح - والا يصبح المشرف نفسه نقطة الفشل.

## كيف يتواصل الوكلاء

اذا كان التنسيق يحدد البنية، فطريقة التواصل تحدد كيف تتدفق المعلومات فعليا بين الوكلاء.

- **الحالة المشتركة (Shared State)**: كل الوكلاء يقرأون ويكتبون في كائن حالة واحد. بسيط التنفيذ وسهل التصحيح. معظم الفرق يجب ان تبدأ من هنا
- **تمرير الرسائل (Message Passing)**: تواصل غير متزامن عبر ناقل احداث. استخدمه عندما تحتاج ربطا فضفاضا بين الوكلاء
- **التسليم (Handoff)**: تمرير صريح للعصا مع نقل كامل للسياق. يعمل جيدا لخطوط الانتاج ذات الترتيب الثابت

## هندسة الذاكرة لانظمة الوكلاء المتعددين

مشكلة الذاكرة الجوهرية مباشرة: *كيف نشارك الحالة دون احداث تعارضات؟* المقال يقسمها الى ثلاثة انماط.

### ذاكرة مبنية على الجلسات (Session-Based)

كل وكيل يعمل في حالة محلية معزولة. التغييرات تدمج في الذاكرة المشتركة فقط عند انتهاء الجلسة.

- **الافضل لـ**: العمال المتوازيون الذين يحتاجون العمل باستقلالية دون تداخل
- **كيف يعمل**: الوكيل يأخذ لقطة من الحالة المشتركة عند بدء الجلسة، يعمل محليا، ويدمج الفروقات في النهاية
- **الميزة**: معالجة متوازية بدون تعارضات

### ذاكرة النافذة (Window Memory)

نافذة منزلقة تحتفظ فقط بآخر N تبادل. المدخلات القديمة تضغط الى ملخصات.

- **الافضل لـ**: المحادثات الطويلة حيث تحتاج الحفاظ على السياق دون حرق الرموز
- **كيف يعمل**: عندما تفيض النافذة، يتم تلخيص وضغط الثلث الاقدم
- **الميزة**: يمنع النمو غير المحدود للحالة

### الذاكرة العرضية (Episodic Memory)

تخزن تاريخ التعاون لتركيبات محددة من الوكلاء وتستخدمه لاتخاذ قرارات مستقبلية.

- **الافضل لـ**: فرق الوكلاء التي تتعاون بشكل متكرر ويجب ان تتحسن بناء على النتائج السابقة
- **كيف يعمل**: يسجل اي تركيبات وكلاء نجحت او فشلت في اي مهام
- **الميزة**: يتيح قرارات مثل "هذه التركيبة نجحت في المرة السابقة - لنستخدمها مجددا"

## اعتبارات بيئة الانتاج

### تكاليف الرموز

- مشرف + 4 عمال: حوالي 1K للتقسيم + 12K للعمال + 2K للتجميع = تقريبا 15K رمز لكل مهمة
- نفس المهمة بوكيل واحد: حوالي 4K رمز. تكلفة التنسيق تقريبا 4 اضعاف
- **التحسين**: تخزين تعليمات المشرف مؤقتا، هيكلة مخرجات العمال كبيانات منظمة، استدعاء العمال فقط عند الحاجة

### زمن الاستجابة

- بمعدل 2-5 ثوان لكل استدعاء LLM، 4 وكلاء تسلسليا تعني اكثر من 12 ثانية. بالتوازي 3-4 ثوان
- المهام المستقلة يجب ان تعمل دائما بالتوازي

### منع انتشار الاخطاء

- **انتهاء المهلة**: اجباري في كل طبقة
- **قاطع الدائرة**: ايقاف استدعاء وكيل بعد N فشل متتالي
- **التدهور الرشيق**: الوظائف الاساسية يجب ان تعمل حتى لو بعض الوكلاء معطلون
- **عزل الحالة**: فشل عامل يجب الا يلوث الحالة المشتركة

اذا لم تستطع مراقبته، لن تستطع اصلاحه. المراقبة متطلب من اليوم الاول.

## انماط مضادة يجب تجنبها

- **الافراط في التنسيق**: ربط وكلاء يمكنها العمل باستقلالية
- **الوكيل الخارق**: وكيل واحد يفعل كل شيء يلغي الغرض من تعدد الوكلاء
- **تجاهل التكاليف**: النشر بدون مراقبة الرموز يؤدي الى فواتير مفاجئة
- **بدون خطة بديلة**: افتراض ان كل الوكلاء ستكون متاحة دائما

## الخلاصة

خاتمة المقال بقيت محفورة في ذهني:

> ابنِ وكيلا واحدا. حدد اين ينكسر. اضف وكيلا ثانيا عند نقطة الانكسار. اضف مشرفا اذا لزم الامر. كرر.

بدأت بتصميم هرمي طموح وانتهيت بتبسيطه الى مشرف مع ثلاثة عمال. الدرس: ابدأ ببناء تعاون مستقر بين وكيلين، ثم توسع من هناك.

اذا كنت في منتصف تصميم نظام وكلاء متعددين، انصحك بقراءة المقال الاصلي.

المصدر: [Building Effective Multi-Agent Systems](https://lnkd.in/gWsXEi25)

## Related URLs

- Author: https://tonylee.im/en/author/
- Publication: https://tonylee.im/en/blog/about/
- Related article: https://tonylee.im/ar/blog/ai-loop-repeat-ralph-rlm-autoresearch-2026/
- Related article: https://tonylee.im/ar/blog/anthropic-cowork-agent-for-everyone/
- Related article: https://tonylee.im/ar/blog/claude-code-task-ai-native-engineer/

## Citation

- Author: Tony Lee
- Site: tonylee.im
- Canonical URL: https://tonylee.im/ar/blog/multi-agent-design-guide-that-actually-helped/

## Bot Guidance

- This file is intended for AI agents, search assistants, and text-mode retrieval.
- Prefer citing the canonical article URL instead of this text endpoint.
- Use the rollout alternates when you need the same article in another prioritized language.

---

Author: Tony Lee | Website: https://tonylee.im
For more articles, visit: https://tonylee.im/ar/blog/
This content is original and authored by Tony Lee. Please attribute when quoting or referencing.