نظام متعدد الوكلاء (Multi-Agent System، واختصاره MAS) هو طريقة عمل يتقاسم فيها عدة وكلاء ذكاء اصطناعي الأدوار ويعملون بالتوازي لإنجاز مهمة واحدة. يقسّم وكيلٌ منسِّق العمل، ويبحث الوكلاء المنفِّذون (الوكلاء الفرعيون) أو يكتبون كلٌّ في سياقه المستقل، ثم يجمع المنسِّق النتائج.
لكن زيادة عدد الوكلاء لا تجعل النظام أذكى تلقائيًّا. ففي تجربة أجراها باحثون من Google Research وغيرها على ستة أنواع من المهام، جاءت إعدادات الوكلاء المتعددين أفضل من الوكيل الواحد بنحو 81% كحدٍّ أقصى في الأعمال القابلة للتقسيم، وأسوأ بما يصل إلى 70% في الأعمال التي يجب أن تسير خطوة بخطوة. يشرح هذا المقال التعريف والأنماط الخمسة، ثم يعتمد على تلك التجربة وعلى ما نشرته Anthropic وCognition وغيرهما ليساعدك على الحكم في أيّ الأعمال يفيد هذا النهج وفي أيّها يضرّ.
متعدد الوكلاء = فريق يتقاسم الأدوار ويعمل بالتوازي
— بدلًا من أن يُطلب كل شيء من ذكاء اصطناعي واحد، يتقاسم فريق صغير من المتخصصين العمل
لكلٍّ منهم نافذة سياق خاصة به، ويعملون بالتوازي.
يتحقق المنسِّق من النتائج قبل جمعها — وقد أظهرت التجارب أن وجود هذا المنسِّق المتحقِّق أو غيابه يغيّر كثيرًا مدى انتشار الأخطاء.
جدول المحتويات
- 1. ما هو نظام متعدد الوكلاء؟
- 2. لماذا نجعل عدة نماذج ذكاء اصطناعي تتعاون؟
- 3. الأنماط الخمسة
- 4. ما أظهرته التجارب: أين يفيد وأين يضرّ
- 5. كيف تستخدمه المنتجات الفعلية
- 6. التكلفة: نحو 15 ضعف رموز المحادثة
- 7. جدول القرار: هل تستخدمه؟
- 8. أساسيات التصميم وأنواع الإخفاق الشائعة
- 9. كيف يُكتب كل نمط في أدوات SDK الرئيسية
- الخلاصة
- الأسئلة الشائعة
1. ما هو نظام متعدد الوكلاء؟
نظام متعدد الوكلاء (Multi-Agent System، MAS) هو طريقة عمل يتعاون فيها عدة وكلاء ذكاء اصطناعي لحل مهمة واحدة. لكل وكيل تعليماته الخاصة (الموجِّه)، وأدواته، وسياقه، ويصلون معًا إلى الهدف العام بتبادل النتائج.
اللبنة الأساسية، أي الوكيل الواحد، تُدير بمفردها حلقة «فكِّر ← استخدم أداة ← انظر إلى النتيجة»، كما شرحنا في ما هو وكيل الذكاء الاصطناعي. وأقرب طريقة لفهم نظام متعدد الوكلاء هي اعتباره تلك الحلقة مضافًا إليها تقسيم الأدوار والتوازي.
كيف يختلف عن الوكيل الواحد
| الجانب | وكيل واحد | متعدد الوكلاء |
|---|---|---|
| البنية | ذكاء اصطناعي واحد يُدير الحلقة | عدة نماذج تعمل معًا |
| السياق | كل شيء في نافذة واحدة | مقسَّم حسب الدور (لا تختلط المعلومات غير المترابطة) |
| التوازي | خطوة بعد خطوة في الغالب | يمكن للمنفِّذين التقدّم في الوقت نفسه |
| انتشار الأخطاء | تتراكم أخطاؤه الخاصة | من دون مُتحقِّق، يصل خطأ المنفِّذ مباشرة إلى النتيجة النهائية |
| التكلفة | أقل (نحو 4 أضعاف المحادثة) | أعلى (نحو 15 ضعف المحادثة) |
| يُجيد | العمل المتسلسل الذي تعتمد فيه كل خطوة على سابقتها | البحث والمقارنة والتحقق القابلة للتقسيم إلى أجزاء مستقلة |
مضاعِفات الرموز هي الأرقام التي نشرتها Anthropic عن ميزة البحث لديها (How we built our multi-agent research system، 13 يونيو 2025). التفاصيل في القسم 6.
2. لماذا نجعل عدة نماذج ذكاء اصطناعي تتعاون؟
نقطة البداية هي: «إن كان وكيل واحد يكفي، فاستخدم وكيلًا واحدًا». تحتاج إلى نظام متعدد الوكلاء حين تصطدم بثلاثة جدران يصعب على الوكيل الواحد تجاوزها بحكم بنيته.
ثلاثة جدران يصعب على الوكيل الواحد تجاوزها
مثالًا على الأثر، أعلنت Anthropic أن ميزة البحث (Research) في Claude، بإعداد يتولّى فيه Claude Opus 4 دور المنسِّق وClaude Sonnet 4 دور المنفِّذين، تفوّقت بنسبة 90.2% على Opus 4 وحده في تقييمها الداخلي لمهام البحث (المصدر نفسه). ويذكر المقال نفسه أن كمية الرموز المستخدمة وحدها فسّرت 80% من تباين الأداء (في BrowseComp، وهو تقييم للبحث). أي أن معظم قوة نظام متعدد الوكلاء تأتي من تشغيل سياقات منفصلة جنبًا إلى جنب لقراءة ما يفوق قدرة وكيل واحد.
3. الأنماط الخمسة
لأنظمة الوكلاء المتعددين بضعة أشكال معتادة. تختلف تسمياتها من منتج لآخر، لكنها تعود في الغالب إلى الخمسة التالية. ونذكر أيضًا، حيث ينطبق ذلك، الفئة المقابلة في تجربة القسم 4 (مستقل، مركزي، لامركزي، هجين).
3-1. المنسِّق والمنفِّذون (الأكثر استخدامًا)
يقسّم منسِّق (Orchestrator) واحد العمل ويوزّعه على عدة منفِّذين (وكلاء فرعيين). يعمل كل منفِّذ في سياق منفصل ويعيد نتيجته إلى المنسِّق. وهو في تصنيف التجربة الإعداد المركزي (Centralized). على هذا النمط تقوم ميزة البحث لدى Anthropic، والوكلاء الفرعيون في Claude Code، وطريقة «استدعاء وكيل كأداة» في OpenAI Agents SDK (Agent.as_tool()).
3-2. التسليم (Handoff: تتابع المسؤولين)
يمرّر الوكلاء زمام المحادثة قائلين عمليًّا: «من هنا تتولّى أنت». وفي توثيق OpenAI Agents SDK يصبح المتخصص الذي يتلقّى التسليم هو الوكيل النشط لبقية الدور. يناسب أعمال الاستقبال، مثل تحويل استفسار من مكتب الاستقبال إلى الفوترة أو الدعم الفني. أما Swarm، السلف التجريبي لهذه الأداة، فيذكر الآن في مستودعه أنه استُبدل بـAgents SDK، لذا ينبغي أن تعتمد المشاريع الجديدة على Agents SDK.
3-3. التسلسل الهرمي (فريق من الفرق)
شجرة يقع فيها منسِّقون وسطاء تحت المنسِّق الرئيسي، وتحتهم المنفِّذون. في Claude Code يمكن للوكلاء الفرعيين تشغيل وكلائهم الفرعيين حتى ثلاث طبقات افتراضيًّا (التوثيق الرسمي)، كما أتاح Cursor في الإصدار 2.5 (فبراير 2026) للمنفِّذين تشغيل منفِّذين. كل طبقة إضافية تزيد الرموز والانتظار، فحدِّد سقفًا للعمق.
3-4. الندّ للندّ (النقاش والتوافق)
لا منسِّق هنا: يطرح عدة وكلاء آراءهم على قدم المساواة ويكرّرون حتى يتوافقوا. وهو في تصنيف التجربة الإعداد اللامركزي (Decentralized). تشير أبحاث Multi-Agent Debate إلى تحسّن الدقة الواقعية والاستدلال. ويميل إلى الأداء الجيد في الأعمال التي تتطلب مقارنة وجهات نظر متعددة، مثل البحث على الويب (القسم 4).
3-5. خط الإنتاج (ترتيب ثابت)
يمرّ العمل على الوكلاء بترتيب ثابت، مثل «بحث ← هيكلة ← تحقق ← إخراج». ولأن برنامجًا، لا الذكاء الاصطناعي، هو من يقرّر أيّ وكيل يعمل تاليًا، تكون النتائج مستقرة ويسهل معرفة موضع الخلل. ويقدّم OpenAI Agents SDK «السلسلة» (تمرير مخرجات وكيل مدخلاتٍ للتالي) و«حلقات التقييم» (التناوب بين وكيل منتِج ووكيل مقيِّم) بوصفها أنماطًا تُبنى بالشيفرة.
الأنماط الخمسة في لمحة
4. ما أظهرته التجارب: أين يفيد وأين يضرّ
أيّ نمط يفوز يتغيّر بحسب طبيعة العمل. والورقة التي وضعت أرقامًا لذلك هي Towards a Science of Scaling Agent Systems لباحثين من Google Research وGoogle DeepMind وجهات أخرى (أحدث إصدار في أبريل 2026). وباستخدام ثلاث عائلات من النماذج — GPT وGemini وClaude — تقارن خمسة إعدادات (وكيل واحد وأربعة إعدادات متعددة الوكلاء) على ستة أنواع من المهام و260 تركيبة (عُرضت في مدوّنة Google Research في يناير 2026، والـ180 إعدادًا المذكورة في المدونة تخص الإصدار الأول).
المصدر: القسم 4.2 من الورقة. في إصلاح الشيفرة وفي التخطيط جاءت كل الإعدادات متعددة الوكلاء المختبَرة أسوأ من الوكيل الواحد، والمعروض هو الأقل خسارة (إصلاح الشيفرة من −2.1% إلى −14.9%، والتخطيط من −39.1% إلى −70.0%).
تبرز ثلاثة أمور.
- المكسب الكبير في الأعمال القابلة للتقسيم فقط: في التحليل المالي يمكن بحث الإيرادات والتكاليف والأسواق كلٌّ على حدة ثم جمعها في النهاية، فتفوّق الإعداد المركزي على الوكيل الواحد بنحو 81%.
- يأتي بنتيجة عكسية في الأعمال المعتمدة على الترتيب: في مهمة التخطيط، حيث تحدّد كل خطوة الخطوة التالية، جاءت كل الإعدادات أسوأ من الوكيل الواحد. فتقسيم العمل يجعل افتراضات المنفِّذين تتباعد، ويستهلك الجهد في التنسيق.
- إصلاح الشيفرة لم يتحسّن أيضًا: تكتب Anthropic كذلك أن معظم مهام البرمجة تضمّ أجزاءً قابلة للتوازي فعلًا أقل مما في البحث (مقالها)، وهذا يتّسق مع النتيجة.
المنسِّق المتحقِّق يحدّ من انتشار الأخطاء
قاست الورقة نفسها مدى انتقال أخطاء المنفِّذين إلى النتيجة النهائية في كل إعداد (كمضاعَف، مع اعتبار الوكيل الواحد = 1).
مستقل (بلا تشاور ولا تحقق)
17.2×
تُوضع النتائج جنبًا إلى جنب فقط، فتبقى الأخطاء
لامركزي (نقاش بين أنداد)
7.8×
يصحّح النقاش بعض الأخطاء، لكن لا أحد مسؤول عن التحقق
هجين
5.1×
منسِّق مع بعض التشاور بين المنفِّذين
مركزي (المنسِّق يتحقق)
4.4×
يتحقق المنسِّق من نتائج المنفِّذين قبل جمعها
المصدر: الجدول 5 في الورقة (Error Amp). وفي الجدول نفسه بلغ متوسط عدد الأدوار لكل مهمة 7.2 للوكيل الواحد، مقابل 27.7 للمركزي و44.3 للهجين.
«إذا كان وكيل واحد يحلّ 45% أو أكثر، فإضافة وكلاء تميل إلى أن تأتي بنتيجة عكسية». تذكر الورقة أنه في المهام التي تتجاوز فيها دقة الوكيل الواحد نحو 45%، تميل إضافة الوكلاء إلى خفض النتيجة. وتدعم التجربة هذا الترتيب: قِس أولًا بوكيل واحد، ولا تقرّر إضافة المزيد إلا بعد رؤية هذا الرقم.
5. كيف تستخدمه المنتجات الفعلية
ميزة البحث لدى Anthropic: عدد المنفِّذين بحسب صعوبة السؤال
ميزة Research في Claude مثال كلاسيكي على نمط المنسِّق والمنفِّذين: يقسّم المنسِّق السؤال، ويبحث المنفِّذون بالتوازي، ويجمع المنسِّق النتائج. وأنفع ما في التصميم المنشور أن الموجِّه ينصّ على عدد المنفِّذين المطلوب بحسب صعوبة السؤال (مقالها).
| نوع السؤال | عدد المنفِّذين | استدعاءات الأدوات |
|---|---|---|
| التحقق من معلومة بسيطة | 1 (المنسِّق وحده) | 3–10 |
| مقارنة مباشرة | 2–4 | 10–15 لكلٍّ منهم |
| بحث معقّد | أكثر من 10 أحيانًا | لكل منفِّذ مسؤولية مفصولة بوضوح |
تذكر Anthropic أن الإصدارات الأولى، قبل هذه القواعد، وقعت في أخطاء مثل تشغيل 50 منفِّذًا لسؤال بسيط. وإذا بنيت نظامك، فأسرع طريق هو وضع هذا الجدول كما هو في الموجِّه قاعدةً لتحديد حجم العمل. كما أن الانتقال إلى استدعاء البحث والأدوات الأخرى بالتوازي قلّص زمن البحث في الأسئلة المعقدة بما يصل إلى 90%.
الوكلاء الفرعيون في Claude Code وCodex
في Claude Code يمكنك إسناد البحث والمراجعة وما يشبههما إلى وكلاء فرعيين. يعمل كل وكيل فرعي في سياقه الخاص ولا يعيد إلى الوكيل الرئيسي إلا ملخصًا، فلا يمتلئ السياق الرئيسي. افتراضيًّا يمكن أن يعمل حتى 20 في وقت واحد، بتداخل يصل إلى ثلاث طبقات. والفرق بينه وبين «فرق الوكلاء» التي يتحاور فيها المنفِّذون أثناء العمل مشروح في الوكلاء الفرعيون مقابل فرق الوكلاء في Claude Code، وكيفية طلب العمل المتوازي مقارنةً بـCodex في الوكلاء الفرعيون المتوازون في Codex وClaude Code.
Devin (Cognition): من «لا تبنِه» إلى «نسِّق»
في يونيو 2025 نشرت Cognition مقال «Don't Build Multi-Agents»، ورأت فيه أن المنفِّذين المتوازين الذين لا يعرفون قرارات بعضهم يُنتجون نتائج متعارضة. ومبدآه هما: «شارِك السياق، وشارِك مسار عمل الوكيل كاملًا لا الرسائل المفردة فقط» و«الأفعال تحمل قرارات ضمنية، والقرارات المتعارضة تُفضي إلى نتائج سيئة».
وفي مارس 2026 أطلقت الشركة نفسها ميزة يقسّم فيها Devin مهمة كبيرة ويُسندها إلى عدة نسخ من Devin تعمل بالتوازي، كلٌّ في آلته الافتراضية الخاصة. يتابع Devin الرئيسي التقدّم، ويحلّ التعارضات ويجمع النتائج. فهي لم تتخلَّ عن التوازي، بل استقرّت على تصميم يتحمّل فيه الوكيل الرئيسي تعارضات المنفِّذين، وهذا يوافق ما رأيناه في القسم 4 عن المنسِّق المتحقِّق.
Cursor: المضيّ دون انتظار المنفِّذين
في الإصدار 2.5 (17 فبراير 2026) جعل Cursor الوكلاء الفرعيين يعملون بشكل غير متزامن، ليواصل الوكيل الرئيسي عمله دون انتظار. ويمكن للمنفِّذين أيضًا تشغيل منفِّذين خاصين بهم. وتكتب Anthropic بدورها أن التنفيذ المتزامن، حيث ينتظر المنسِّق انتهاء المنفِّذين، يخلق اختناقات، فصار عدم إبقاء الوكيل الرئيسي منتظرًا مشكلة مشتركة بين الشركات.
6. التكلفة: نحو 15 ضعف رموز المحادثة
تكتب Anthropic أن الوكلاء يستهلكون نحو 4 أضعاف رموز المحادثة، وأنظمة الوكلاء المتعددين نحو 15 ضعفًا (مقالها). وبتطبيق ذلك على حالتك يكون التقدير كالتالي.
مثال على التقدير (المضاعِفات من ميزة البحث لدى Anthropic، وتختلف بحسب العمل)
سؤال يكلّف 10,000 رمز في المحادثة ← نحو 40,000 مع وكيل واحد، ونحو 150,000 رمز مع نظام متعدد الوكلاء.
مع 100 طلب يوميًّا: المحادثة مليون، والوكيل الواحد 4 ملايين، ومتعدد الوكلاء 15 مليون رمز. اضرب ذلك في سعر الرمز من قائمة الأسعار الرسمية للنموذج الذي تستخدمه.
الرموز ليست الشيء الوحيد الذي يزيد
افصل بين الحدود التي توقِف التنفيذ والأهداف الإرشادية
حين يشغّل المنفِّذون منفِّذين ويدخل شيء ما في حلقة، تتضخّم التكلفة بسرعة. عند البناء باستخدام Claude هناك نوعان من الحدود يعملان بطريقتين مختلفتين.
| الحد | أين يُضبط | هل يوقِف التنفيذ؟ |
|---|---|---|
| سقف الإنفاق | max_budget_usd في Claude Agent SDK (وmaxBudgetUsd في TypeScript) | نعم (لا يُشغَّل منفِّذون جدد ويُنهى الاستعلام) |
| عمق التداخل | متغير البيئة CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH (الافتراضي 3، والقيمة 1 تلغي التداخل) | نعم (يؤدّي منفِّذو الطبقة الأخيرة العمل بأنفسهم) |
| المنفِّذون المتزامنون | متغير البيئة CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS (الافتراضي 20) | نعم (لا يُشغَّل منفِّذون فوق الحد) |
| ميزانية المهمة | task_budget في Claude API (تجريبية، والحد الأدنى 20,000 رمز) | لا (هدف إرشادي يوزّع به النموذج جهده) |
المصادر: Subagents in the Agent SDK وTask budgets (تحققنا منها في 12 نوفمبر 2026). وتنطبق الحدود الثلاثة التي توقِف التنفيذ على TypeScript SDK v0.3.219 وPython SDK v0.2.127 وما بعدهما، وفي الإصدارات الأقدم قد لا يوجد بعضها أو تختلف قيمها الافتراضية. يصف التوثيق ميزانية المهمة بأنها إرشادية لا إلزامية، فاجمعها مع سقف الإنفاق أو max_tokens عندما تحتاج إلى إيقاف التنفيذ بيقين.
7. جدول القرار: هل تستخدمه؟
بجمع ما سبق، تحسم خمسة أسئلة معظم القرارات. أجب عنها من الأعلى إلى الأسفل، وإن وقع أيٌّ منها في جانب «وكيل واحد» فابدأ بوكيل واحد.
| السؤال | يرجّح متعدد الوكلاء | يرجّح وكيلًا واحدًا | الأساس |
|---|---|---|---|
| هل يمكن تقسيم العمل إلى أجزاء مستقلة؟ | نعم (حسب الشركة، أو المستند، أو الزاوية) | كل خطوة تعتمد على النتيجة السابقة | التحليل المالي +80.8%، والتخطيط من −39.1% إلى −70.0% |
| ما مستوى أداء الوكيل الواحد الآن؟ | دقة منخفضة مع وكيل واحد | وكيل واحد يحلّ نحو 45% أو أكثر | ورقة Google Research وآخرين |
| هل يحتاج المنفِّذون إلى مشاركة السياق نفسه؟ | تكفي معلومات كل منفِّذ | تتعارض النتائج ما لم يرَ الجميع السياق نفسه (معظم البرمجة) | Anthropic وCognition |
| هل يتّسع له سياق واحد؟ | المواد كثيرة جدًّا ويفيض سياق الوكيل الواحد | يتّسع له سياق وكيل واحد | كمية الرموز فسّرت 80% من تباين الأداء |
| هل تستحق النتيجة 15 ضعف الرموز؟ | قيمة عالية لكل طلب (تقارير البحث والتدقيق والمقارنة) | معالجة روتينية كثيفة، أو استقبال يتطلب ردًّا فوريًّا | نحو 15 ضعفًا وفق Anthropic |
وتنصح Anthropic أيضًا في دليلها لبناء الوكلاء بالبحث عن أبسط حل ممكن وعدم إضافة التعقيد إلا عند الحاجة. خطوات البدء وأمثلة الشيفرة المصغّرة في كيف تبني نظامًا متعدد الوكلاء، وطريقة بناء أول وكيل منفرد في كيف تبني وكيل ذكاء اصطناعي.
8. أساسيات التصميم وأنواع الإخفاق الشائعة
① أعطِ كل منفِّذ هدفه وشكل مخرجاته وأدواته وحدوده
تكتب Anthropic أن التعليمات الغامضة تجعل المنفِّذين يسيئون فهم المهمة، أو يكرّرون عمليات البحث نفسها التي أجراها غيرهم، أو يفوتهم ما يحتاجون إليه من معلومات. حدِّد لكل منفِّذ (1) الهدف، و(2) الشكل المطلوب للإعادة، و(3) الأدوات والمصادر المسموح بها، و(4) حدود المهمة. والوكيل الفرعي في Claude Agent SDK لا يتسلّم محادثة الوكيل الرئيسي، فكل ما يُمرَّر إليه هو الموجِّه الذي تستدعيه به (التوثيق الرسمي)، لذا اكتب فيه مسارات الملفات والقرارات المتخذة.
② حدِّد عمق البحث المطلوب
لا يُحسن المنفِّذون أن يقرّروا بأنفسهم إلى أيّ حدّ يبحثون. اكتب قواعد للحجم مثل جدول القسم 5، واضبط معها عمق الاستدلال. يمكن تحديد effort في Claude لكل منفِّذ، وتقبل تعريفات الوكلاء في Agent SDK القيم من low إلى max. إبقاء المنفِّذين البسيطين خفيفين ومنفِّذي التحقق عميقين يكبح التكلفة.
③ اجعل التحقق جزءًا من عمل المنسِّق
كما أظهر القسم 4، نشر الإعداد المركزي — حيث يتحقق المنسِّق من النتائج قبل جمعها — أخطاءً أقل بكثير من الإعداد المستقل الخالي من التحقق (4.4× مقابل 17.2×). أدرِج في تعليمات المنسِّق خطوة للبحث عن التناقضات بين نتائج المنفِّذين والتحقق من الأدلة قبل قبولها.
④ اعرف أنواع الإخفاق
صنّف باحثون من جامعة كاليفورنيا في بيركلي وجهات أخرى حالات الإخفاق إلى 3 فئات و14 نوعًا، بالاعتماد على أكثر من 1,600 سجلّ تنفيذ من سبعة أنظمة متعددة الوكلاء (Why Do Multi-Agent LLM Systems Fail?). ويصلح قائمةَ تحقق عند مراجعة التصميم.
| الفئة | ما يحدث | العلاج |
|---|---|---|
| مشكلات التصميم | يتجاهل الوكلاء تعليمات الدور أو المهمة، أو يكرّرون الخطوات نفسها، أو لا يعرفون متى يتوقفون | كتابة الأدوار والنطاق وشروط الانتهاء في الموجِّهات |
| عدم التوافق بين الوكلاء | تتعارض الافتراضات، ولا تُنقل المعلومات اللازمة، وتُتجاهل مساهمات الوكلاء الآخرين | مشاركة مسار العمل كاملًا، وحلّ المنسِّق للتعارضات |
| نقص التحقق | الانتهاء قبل الأوان، أو عدم التحقق، أو التحقق السطحي | تعيين من يتحقق (المنسِّق أو منفِّذ للتحقق) |
⑤ ابنِ التسجيل من البداية
إن لم تستطع رؤية ما يفعله نظام متعدد الوكلاء فلن تستطيع إصلاحه. سجّل منذ اليوم الأول مدخلات كل منفِّذ ومخرجاته، والزمن، والرموز، والأدوات المستدعاة. وعن التقييم، تذكر Anthropic أنها بدأت بنحو 20 استعلامًا يعكس الاستخدام الفعلي، وجعلت ذكاءً اصطناعيًّا يقيّمها وفق معايير محددة. ومراقبة تغيّر مجموعة صغيرة من الاستعلامات، بدل انتظار منظومة تقييم كبيرة، هي الطريق العملي.
9. كيف يُكتب كل نمط في أدوات SDK الرئيسية
يحمل النمط نفسه أسماء مختلفة في كل SDK. وللمفاضلة بينها (سرعة النماذج الأولية، والنضج للإنتاج، واستهلاك الرموز) راجع مقارنة أُطر وكلاء الذكاء الاصطناعي؛ أما هنا فنكتفي بتوضيح العنصر المقابل لكل نمط من القسم 3.
| SDK | المنسِّق والمنفِّذون | التسليم / خط الإنتاج |
|---|---|---|
| Claude Agent SDK | يُعرَّف المنفِّذون في agents ويُستدعَون بأداة Agent (اسمها السابق Task) | لا عنصر مخصّصًا، وخط الإنتاج يكون باستدعاء الوكلاء بالترتيب من شيفرتك |
| OpenAI Agents SDK | يُستدعى المنفِّذون كأدوات عبر Agent.as_tool() | يُمرَّر الزمام بالتسليم (handoffs)، وتُبنى السلاسل والتشغيل المتوازي بالشيفرة |
| LangGraph | تفرّع من عقدة المنسِّق إلى عقد المنفِّذين | يُكتب الترتيب والتفرّعات والحلقات رسمًا بيانيًّا من عقد وحواف |
| Strands Agents (AWS) | يُستدعى المنفِّذون كأدوات عبر Agents as Tools | في Swarm يسلّم المنفِّذون العمل لبعضهم، وفي Graph أو Workflow يُحدَّد الترتيب |
| Microsoft Agent Framework | يوفّر أنماط تنسيق الوكلاء المتعددين عناصرَ جاهزة | يُحدَّد الترتيب بوصفه سير عمل (workflow) |
أرشفت Microsoft مستودع AutoGen ولم تعد تقدّم له إصلاحات للأخطاء ولا إصلاحات أمنية (تحققنا من ذلك في 12 نوفمبر 2026). ويوصي المستودع باستخدام خلفه Microsoft Agent Framework في المشاريع الجديدة. أمثلة الشيفرة المصغّرة لكل SDK في كيف تبني نظامًا متعدد الوكلاء.
الخلاصة
- نظام متعدد الوكلاء يوزّع الأدوار على عدة نماذج ذكاء اصطناعي تعمل بالتوازي لإنجاز مهمة واحدة. وهو يتجاوز جدران الوكيل الواحد: فيضان السياق، وغياب التوازي، وكون الصانع هو المتحقِّق.
- الأنماط الخمسة هي: المنسِّق والمنفِّذون، والتسليم، والتسلسل الهرمي، والندّ للندّ، وخط الإنتاج. والأكثر استخدامًا هو المنسِّق والمنفِّذون.
- الفائدة تتوقف على العمل. ففي تحليل مالي قابل للتقسيم تفوّق على الوكيل الواحد بنسبة +80.8%، وفي تخطيط يعتمد على الترتيب خسر بين 39.1% و70.0%، ولم يتحسّن إصلاح الشيفرة أيضًا.
- مع منسِّق متحقِّق انخفض انتشار الأخطاء من 17.2× (المستقل) إلى 4.4×.
- الرموز نحو 15 ضعف المحادثة (ونحو 4 أضعاف لوكيل واحد). اضبط الإنفاق والعمق والتزامن بحدود توقِف التنفيذ فعلًا.
- ترتيب القرار: ابنِ وقِس أولًا بوكيل واحد، ولا تفصل في منفِّذين إلا الأجزاء القابلة للتقسيم التي ثبت أن وكيلًا واحدًا لا يكفيها.
الأسئلة الشائعة
س1. هل نظام متعدد الوكلاء أفضل دائمًا من وكيل منفرد ذكي؟
لا. تفوّقت ميزة البحث لدى Anthropic على الوكيل الواحد بنسبة 90.2%، لكن ذلك في بحث قابل للتقسيم إلى أجزاء مستقلة. وفي تجربة Google Research وآخرين جاءت كل الإعدادات متعددة الوكلاء أسوأ من الوكيل الواحد في مهمة التخطيط المعتمدة على الترتيب. كل شيء يتوقف على قابلية العمل للتقسيم.
س2. هل يفيد تعدد الوكلاء في البرمجة؟
جعل عدة منفِّذين يكتبون أجزاءً من الإصلاح نفسه لا يفيد عادةً. ففي التجربة جاءت كل الإعدادات متعددة الوكلاء أدنى من الوكيل الواحد في إصلاح الشيفرة (SWE-bench Verified)، بين −2.1% و−14.9%. في المقابل، إسناد أعمال مستقلة مثل البحث والمراجعة وتشغيل الاختبارات إلى منفِّذين لإبقاء السياق الرئيسي فارغًا استخدامٌ نموذجي للوكلاء الفرعيين في Claude Code.
س3. هل يمكن الانتقال من وكيل واحد إلى متعدد الوكلاء تدريجيًّا؟
نعم. ابنِ أولًا بوكيل واحد وقِس الدقة والرموز والزمن، وحين يتضح أين يفيض السياق أو ما الذي يمكن أن يجري بالتوازي، افصل تلك الأجزاء وحدها في منفِّذين. أما إن صمّمت كل شيء متعدد الوكلاء من البداية، فلن تستطيع قياس ما يفيد فعلًا.
س4. هل هناك بروتوكول اتّصال موحَّد بين الوكلاء؟
في ربط الوكلاء بالأدوات والبيانات أصبح MCP (Model Context Protocol) المعيار الفعلي. نشأ في Anthropic، وتبرّعت به في ديسمبر 2025 إلى Agentic AI Foundation التابعة لـ Linux Foundation، وتبنّاه OpenAI وMicrosoft وAWS وآخرون. أما التواصل بين الوكلاء فله A2A (Agent2Agent) الذي نشأ في Google وانتقل أيضًا إلى Linux Foundation. واندمج ACP (Agent Communication Protocol) من IBM في A2A في أغسطس 2025.
س5. هل تمنع ميزانية المهمة انفلات التكلفة؟
ليس وحدها. ميزانية المهمة في Claude API هدف إرشادي يوزّع به النموذج جهده، ويقول التوثيق إنها غير إلزامية. ولإيقاف التنفيذ بيقين، اضبط سقف الإنفاق في Agent SDK (max_budget_usd) وحدود عمق التداخل وعدد المنفِّذين المتزامنين (جدول القسم 6).
س6. هل «الوكلاء الفرعيون» و«متعدد الوكلاء» شيئان مختلفان؟
الوكلاء الفرعيون هم المنفِّذون في نمط المنسِّق والمنفِّذين داخل نظام متعدد الوكلاء. في Claude Agent SDK يبقى الوكيل الرئيسي واحدًا، ولا يستدعي المنفِّذين بأداة Agent إلا عند الحاجة. أما الإعدادات التي يتحاور فيها المنفِّذون مباشرة أثناء العمل (مثل فرق الوكلاء في Claude Code) فهي أقرب إلى نمط الندّ للندّ أو الهجين.
