تنسيق الوكلاء المتعددين وضوابط المشرف

وكيل ذكاء اصطناعي فردي يصل إلى الإجابة الصحيحة بنسبة 85% من الوقت يبدو جيداً — إلى أن تربط خمسة منها معاً فينخفض معدل نجاحك الشامل من البداية إلى النهاية إلى 44%، أو تربط عشرة فتصل إلى 20%. هذه الحسابات التراكمية للإخفاق هي ما يقتل مشاريع الوكلاء المتعددين بعد اجتيازها مرحلة العرض التوضيحي، والسبب لا يكون تقريباً أبداً نماذج سيئة. إنه التنسيق غير المحكوم. نهجنا هو بناء أنظمة متعددة الوكلاء تكون فيها طبقة التنسيق هي المنتج، محكومة بمشرف حتمي بدلاً من نموذج لغوي كبير آخر يمكن تضليله أو اختراقه.

مشكلة موثوقية الوكلاء المتعددين التي لا يحذّرك منها أحد

الحسابات التراكمية أعلاه هي نمط الإخفاق الذي لا يظهر إلا بعد مغادرة النظام لمرحلة العرض التوضيحي. وجدت دراسة حللت 1,642 أثر تنفيذ عبر سبعة أطر عمل مفتوحة المصدر للوكلاء معدلات إخفاق تتراوح بين 41% و86.7%، مع تسبب أعطال التنسيق في 36.9% من جميع حالات الإخفاق. تتوقع غارتنر أن أكثر من 40% من مشاريع الذكاء الاصطناعي الوكيلي ستُلغى بحلول عام 2027، والسبب الأساسي ليس النماذج السيئة — إنه التنسيق غير المحكوم.

في الأنظمة التي نصممها، يكون المشرف محرك سياسات حتمياً، لا نموذجاً لغوياً كبيراً آخر يمكن تضليله أو اختراقه. يعمل كل وكيل داخل نطاق محدد رسمياً: مخططات مدخلات/مخرجات معرّفة، ووصول مسموح به إلى الأدوات، وميزانيات رموز، وحصص استدعاء لواجهات البرمجة، وحدود لزمن التنفيذ. يتحقق المشرف من كل إجراء يقوم به الوكيل مقابل هذه القيود قبل أن يصبح نافذاً. هذا ليس "إضافة حواجز حماية" — إنه جعل السلوك غير الآمن مستحيلاً معمارياً على مستوى طبقة التنسيق، وهو النهج الذي نفصّله في بحثنا حول بناء بنية الحقيقة بما يتجاوز غلاف النموذج اللغوي الكبير.

لماذا لا توصلك الأطر وحدها إلى هناك

مشهد أطر عمل الوكلاء المتعددين في عام 2026 هو حقل ألغام من الوعود المنكوثة، والفروقات ليست شكلية — إنها الفرق بين نظام يعمل ونظام يخفق بصمت أو يفرط في الإنفاق.

حتى LangGraph، الخيار الأصلح للإنتاج، يحمل حوافّ حادة: فإن الـ ToolNode الافتراضي فيه لا يمكنه التعامل مع الأدوات التي تحتاج إلى القراءة من حالة الرسم البياني أو الكتابة إليها، ويتطلب عدّادات حلقات يدوية لمنع دورات التصحيح الذاتي الجامحة، وتكافح تطبيقات نقاط التحقق فيه مع حل الفروع المتزامنة على نطاق واسع. هذه مشكلات قابلة للحل، لكنها تتطلب نوع الهندسة الذي لا يغطيه ملف README الخاص بأي إطار عمل.

نقيّم الأطر مقابل متطلباتك الفعلية — ميزانية زمن الانتقال، وعدد الوكلاء، وتعقيد الأدوات، واحتياجات الامتثال — ثم نبني طبقة التنسيق التي تقع فوق الإطار، موفّرين ضوابط المشرف، وحوكمة التكلفة، وقابلية المراقبة التي لا يقدّمها أي إطار عمل جاهزاً — طبقة التنسيق المرنة الموصوفة في ورقتنا البيضاء حول بناء بنية ذكاء اصطناعي مؤسسي مرن.

ما الذي يفعله المشرف فعلياً

النمط الذي نلجأ إليه هو التنسيق الحتمي مع استدلال النموذج اللغوي الكبير عند الأطراف. تتولى النماذج اللغوية الكبيرة الحكم — تفسير النية، واستخراج المعاملات المهيكلة، وتقرير أي وكيل متخصص يُستدعى. أما آلة الحالات فتتولى التدفق: التوجيه، والتسلسل، والتوزيع المتوازي، وتجميع الإجماع، والتعافي من الأخطاء. يلتقط التحقق عبر Pydantic كل عملية تسليم بين الوكلاء ضمن حمولات مطبوعة ومفروضة المخطط، بحيث لا يمر أي نص حر بين الوكلاء — وهو ما يزيل نواقل حقن الأوامر والانحراف الدلالي التي تبتلي بنى الوكلاء القائمة على المحادثة.

صُمّم المشرف لفرض أربع فئات من الضوابط:

• ميزانيات الموارد لكل وكيل — حدود الرموز، وحصص استدعاء واجهات البرمجة، ومهل التوقف بحسب الساعة الفعلية.
• قيود وصول الأدوات لكل وكيل — أدلة نظام الملفات، ونقاط نهاية الشبكة، ونطاقات قواعد البيانات.
• بوابات الموافقة على الإجراءات لعمليات الكتابة التي تؤثر في الأنظمة الخارجية.
• قواطع دائرة التكلفة التي توقف التنفيذ عند تجاوز عتبات الإنفاق.

أهداف مستوى الخدمة الموصى بها لنظام محكوم: معدل نجاح يفوق 95%، وزمن انتقال للتسليم أقل من 30 ثانية، ودقة استدعاء الأدوات تفوق 80%.

كوارث موثّقة، جُعلت قابلة للمنع

صُمّمت هذه الضوابط لتحويل الكوارث المعروفة إلى أحداث تُكتشف في دقائق — نهج السلامة الحتمي نفسه العامل في عرض توضيحي فعّال لضوابط السلامة الحتمية لدينا:

• فاتورة الـ 47,000 دولار لواجهة البرمجة الناتجة عن حلقة وكيل تكرارية استمرت 11 يوماً — التُقطت عبر سقف لإنفاق الرموز إضافة إلى كشف الحلقات الدلالي (عتبة تشابه 95% بين المخرجات المتتالية) في دقائق، لا أيام.
• حادثة الـ 60,000 دولار شهرياً للتوسيع التلقائي حيث تسبب الوكلاء في قفزة من 12 إلى 500 عقدة — أُوقفت عبر بوابات إجراءات البنية التحتية التي تتطلب موافقة المشرف قبل تنفيذ أوامر التوسيع.
• خسارة أمازون لـ 6.3 مليون طلبية بسبب وكيل اتبع إرشادات ويكي قديمة — مُنعت عبر التحقق من حداثة المصدر وفرض حدّ معرفي في فحوصات المشرف السابقة للإجراء.

قابلية مراقبة تتتبع حالات الإخفاق عبر حدود الوكلاء

أصعب مشكلة تصحيح أخطاء في أنظمة الوكلاء المتعددين هي أن حالات الإخفاق ذات شكل بياني: هلوسة في استدعاء أداة الوكيل A تصبح سياق إدخال الوكيل B، الذي يصبح مخرَج الوكيل C الواثق لكن الخاطئ. المراقبة التقليدية ترى الوكيل C يخفق ولا فكرة لديها بأن السبب الجذري يبعد قفزتين في المنبع. نصمّم قابلية مراقبة تصوّر تفاعلات الوكلاء كرسوم بيانية موجّهة لا دورية مع تتبّع كامل للمنشأ عند كل عقدة. يُسجَّل كل رسالة بين الوكلاء، واستدعاء أداة، وانتقال حالة، وقرار مشرف مع ربط سببي، بحيث حين يتعطل شيء ما تتتبع رجوعاً من العَرَض إلى إجراء الوكيل الأصلي في ثوانٍ، لا ساعات.

نتكامل مع Langfuse أو LangSmith أو Arize بحسب حزمتك التقنية، ونضيف طبقة قياس مخصص للمقاييس التي لا تلتقطها هذه المنصات أصلاً:

• إسناد الرموز عبر الوكلاء — أي وكيل يستنزف ميزانيتك.
• نسبة عبء التنسيق — أي قدر من إنفاقك هو الوكلاء يتحدثون إلى بعضهم مقابل أداء العمل الفعلي.
• تكرار تدخّل المشرف — كم مرة تتجاوز الطبقة الحتمية سلوك الوكيل.

حزمة البروتوكولات: MCP وA2A وما يقع بينهما

بروتوكول سياق النموذج من Anthropic (97 مليون عملية تثبيت بحلول مارس 2026، وأصبح الآن تحت مؤسسة Linux) يوحّد كيفية اتصال الوكلاء بالأدوات الخارجية. بروتوكول Agent2Agent من Google يتولى تعاون الوكلاء عبر البائعين مع أكثر من 50 شريكاً في الصناعة. توفّر AWS Bedrock استضافة مُدارة متعددة الوكلاء مع توجيه مشرف هرمي. هذه قدرات حقيقية، لا وعوداً جوفاء.

لكن لا أحد منها يوفّر طبقة الحوكمة. يعرّف MCP وصول الأدوات، لا تفويض الأدوات لكل وكيل. ويعرّف A2A الرسائل عبر البائعين، لا وضع ميزانيات التكلفة أو الموافقة على الإجراءات. ويوجّه مشرف Bedrock المهام لكنه لا يفرض قيوداً حتمية على سلوك الوكلاء. الفجوة بين "قدرة الوكلاء على التحدث إلى الأدوات وإلى بعضها" و"عمل الوكلاء ضمن تنسيق محكوم وقابل للتدقيق ومضبوط التكلفة" هي حيث تعيش هندستنا المخصصة، عمل الأنظمة العميقة الذي نعرضه في بحثنا حول عبور فجوة الذكاء الاصطناعي التوليدي من الأغلفة إلى أنظمة الذكاء الاصطناعي العميقة.

متى يكون تعدد الوكلاء هو البنية الخاطئة

سنخبرك بألا تبني نظاماً متعدد الوكلاء إن كان وكيل واحد يتولى عبء عملك. توجيه مايكروسوفت نفسه صريح: "اجعل الوكيل الواحد هو الافتراضي. لا تُدخِل بنية متعددة الوكلاء إلا حين يكون لديك دليل على أن التعقيد الإضافي يقدّم قيمة متناسبة." تستجيب الوكلاء المفردة أسرع بنسبة 30–50% دون عبء التواصل بين الوكلاء، وأنظمة الوكلاء المتعددين تصل إلى نقطة تعادل العائد على الاستثمار بعد الحلول أحادية الوكيل بـ 8–14 شهراً.

وكيل واحد جيد البناء هو الاستثمار الأفضل حين:

• تُحلّ مهمتك في مرور منطقي واحد.
• يكون حجمك أقل من 10,000 عملية في اليوم مع نمو متوقع.
• تحتاج إلى مسارات تدقيق بسيطة مع عزل واضح للأخطاء.

يستحق تعدد الوكلاء تعقيده حين تكون لديك قدرات متمايزة فعلاً تتطلب وصولاً مختلفاً إلى الأدوات، أو خيارات نماذج مختلفة، أو ميزانيات زمن انتقال مختلفة؛ أو حين تحتاج إلى تنفيذ متوازٍ عبر مهام فرعية مستقلة؛ أو حين تتفوق الوكلاء المتخصصون بمجموعات مهارات ضيقة ومختبَرة جيداً على وكيل واحد بموجّه منتفخ. إطار اتخاذ القرار يهمّ أكثر من اختيار التقنية، ونحن نطبّقه قبل كتابة أي شيفرة تنسيق.

ما الذي نقدّمه

تُحدَّد أي مشاركة لتنتج:

• تقييم إطار عمل مقابل متطلباتك المحددة — لا رسم مقارنة عاماً.
• بنية مشرف بمواصفات سياسات حتمية يمكن لفريق الامتثال لديك مراجعتها.
• عزل بيئة لكل وكيل مع ضوابط وصول للأدوات وميزانيات موارد.
• حوكمة التكلفة مع أسقف لإنفاق الرموز وقواطع دائرة.
• قياس قابلية المراقبة مع تتبّع سببي عبر الوكلاء.
• بيئة محاكاة لاختبار سير عمل الوكلاء المتعددين مع حقن الأعطال.
• أدلة تشغيل لسيناريوهات الإخفاق الموثّقة في الإنتاج: تتالي مهل الوكلاء، والمخرجات المتعارضة، ونفاد الموارد، وانتهاكات سياسات المشرف، وحالات الجمود في التنسيق التي لا توثّقها الأطر.

بناء نظام متعدد الوكلاء داخلياً يستغرق من 6 إلى 18 شهراً وقرابة 500,000 دولار في رواتب هندسة الأقدمية قبل أن تحصل على طبقة تنسيق بمستوى الإنتاج. نهجنا يضغط ذلك إلى أسابيع من التصميم المعماري والبناء، مستنداً إلى أنماط إخفاق الأطر المصنّفة أعلاه بدلاً من إعادة اكتشافها على حسابك.