دوائر المؤتمرات استقرت على سردية واحدة: مستقبل الذكاء الاصطناعي في المؤسسات هو الأنظمة متعددة الوكلاء. منسقون، وكلاء فرعيون، أدوار متخصصة، بروتوكولات وكيل إلى وكيل. العروض التوضيحية مثيرة للإعجاب. وهي أيضاً في معظمها الإجابة الخاطئة على السؤال الذي تحتاج المنظمة فعلاً إلى حله.
التعدد في الوكلاء ليس بنية معمارية. إنه قرار يستلزم مجموعة محددة من الشروط كي يكون مبرراً.
نمط الضجيج حول تعدد الوكلاء
صُممت CrewAI وLangGraph وAutoGen وقائمة متنامية من أطر التنسيق لتنسيق وكلاء متعددين. الرسالة الضمنية من منظومة الأدوات: إذا كان وكيل واحد مفيداً، فالوكلاء المتعددون أكثر فائدة. الواقع: معظم المهام التي تُصمَّم كسير عمل متعدد الوكلاء تحقق نتائج أفضل مع وكيل واحد محدد النطاق بأدوات جيدة ونافذة سياق واضحة وتعريف دقيق لإتمام العمل.
إضافة وكلاء تضيف تعقيد التنسيق. يجب على المنسق توزيع العمل وإدارة الحالة عبر الوكلاء ومعالجة الإخفاقات على حدود الوكلاء وجمع المخرجات وتوليفها والحفاظ على نتيجة متماسكة رغم التباين في مخرجات كل وكيل فرعي. تتبع إخفاق في نظام متعدد الوكلاء يستلزم تتبع حدود الوكلاء حيث تحولت الحالة أو لُخصت أو ضاعت. كل وكيل يُضاف إلى النظام يضاعف سطح التصحيح.
السؤال الذي ينبغي أن يسبق كل تصميم متعدد الوكلاء: هل تمتلك هذه المهمة خصائص بنيوية لا يستطيع وكيل واحد التعامل معها؟ إذا كانت الإجابة لا، انشر وكيلاً واحداً. التطور هو في قرار البنية المعمارية، لا في عدد الوكلاء.
الحالات الثلاث المشروعة لتعدد الوكلاء
ثلاث خصائص بنيوية تبرر تصميم تعدد الوكلاء. إذا لم تنطبق أيٌّ منها، تابع مع وكيل واحد.
الحالة 1: التوازي الحقيقي. المهام المستقلة فعلاً، التي لا تبعية بين وحداتها، يمكن توزيعها على وكلاء معزولين يعملون في آنٍ واحد. وكيل واحد يعالج 500 عميل محتمل بالتسلسل يستغرق خمس ساعات. خمسمائة وكيل يعالج كل منهم عميلاً واحداً يستغرقون دقائق. المنسق يوزع، الوكلاء الفرعيون يعالجون، المنسق يجمع ويوليف. لا تواصل بين الوكلاء مطلوب. كل وكيل فرعي يتلقى سياقاً كاملاً مكتفياً بذاته لوحدته.
التطبيقات: إثراء بيانات العملاء المحتملين، تدقيق الصفحات عبر موقع ويب، تصنيف المستندات بالجملة، مراجعة الترجمة عبر أزواج اللغات، استخراج بنود العقود من مجموعة عقود كبيرة. الخاصية المشتركة: كل وحدة عمل مستقلة عن كل وحدة أخرى.
الحالة 2: المراجعة التنافسية. وكيل ثانٍ بدور مختلف يراجع مخرجات الوكيل الأول، دون الوصول إلى استدلال الوكيل الأول أو خطواته الوسيطة. هذا ليس فحص جودة. إنه خاصية بنيوية: المراجع لا يرى ما رآه المنفذ، لذا لا يستطيع تبرير خيارات المنفذ. ينتج نقداً أحدث، يكشف الافتراضات التي اتخذها المنفذ دون وعي، ويتلقف أخطاء الاستدلال التي لا تلتقطها المراجعة الذاتية لأن العقل المراجع يقبل بالفعل نفس المنطلقات.
النمط: وكيل المنفذ ينتج مخرجات. وكيل المراجع يتلقى تلك المخرجات إضافةً إلى معايير تقييم صريحة، لكن دون سياق المنفذ أو خطته أو خطواته الوسيطة. وكيل المحكّم يعالج الخلافات الجوهرية. التطبيقات المؤسسية: صياغة العقود مع مراجعة مستقلة للبنود، مقترحات العملاء مع تقييم مستقل للمخاطر، تصميم البنية مع مراجعة أمنية مستقلة، التحليل التقني مع تحقق مستقل.
الحالة 3: التخصص بالأدوار الذي يتطلب سياقاً مختلفاً فعلاً. وكيل البحث يحتاج وصولاً واسعاً إلى مصادر الويب ونوافذ سياق كبيرة للقراءة وحداً أدنى من القيود على ما يسترجعه. وكيل الكتابة يحتاج إرشادات الصوت المؤسسي وقيود الأسلوب ومواصفات الجمهور وبنية المحتوى. وكيل التحرير يحتاج معايير النقد ومعايير الجودة والقدرة على التقييم وفق معيار محدد. إجبار الثلاثة في نافذة سياق واحدة يُدهور كل وظيفة: السياق المطلوب للبحث يُلوث القيود المركزة المطلوبة للكتابة، التي تُلوث المعايير الحادة المطلوبة للتحرير.
إذا لم تكن الحالات الثلاث موجودة، فوكيل واحد بأدوات محددة بدقة وسياق صريح هو البنية المعمارية الصحيحة.
نمط التوازي في التطبيق العملي
بنية التوازي هي نمط منسق-وكيل فرعي مع عزل صارم. كل وكيل فرعي يتلقى سياقاً كاملاً مكتفياً بذاته لوحدة عمله المحددة. لا يتواصل مع وكلاء فرعيين آخرين. لا يصل إلى حالة مشتركة. ينتج مخرجات تتوافق مع مخطط محدد.
Orchestrator
├── distributes: [unit_1, unit_2, ... unit_N]
├── each subagent: receives(complete_context_for_unit_i)
│ produces(structured_output_schema)
└── collects: [output_1, output_2, ... output_N]
synthesizes: final_reportلا تواصل بين الوكلاء على مستوى الوكيل الفرعي. أي تنسيق يحدث على مستوى المنسق، بعد جمع جميع مخرجات الوكيل الفرعي. المنسق لا يزال نقطة قرار واحدة.
OpenSwarm (VRSEN، ترخيص MIT) إطار مفتوح المصدر لهذا النمط، مصمم حول سرب يركز على المنجزات لا على تنسيق الوكلاء التحادثي. [تقدير: التحقق من إحصائيات GitHub الحالية قبل الاستشهاد]؛ التحقق من حالة الصيانة الحالية قبل التبني.
نمط الإخفاق الواجب تجنبه في نمط التوازي: الوكلاء الفرعيون الذين يشاركون الحالة أو يتواصلون مع بعضهم أثناء التنفيذ. بمجرد أن يُصبح التواصل بين الوكلاء مطلوباً، الوحدات لم تعد مستقلة فعلاً، وبنية التوازي غير مبررة. أعد التصميم كتنسيق تسلسلي أو قائم على الرسم البياني.
نمط المراجعة التنافسية
نمط المراجعة التنافسية يعمل بسبب ما لا يراه المراجع. وكيل المنفذ ينتج مخرجات بوصول كامل إلى الهدف والسياق والقيود واستدلاله الوسيط الخاص. وكيل المراجع يتلقى المخرجات فقط، إضافةً إلى معايير مراجعة صريحة. المراجع ليس لديه وصول إلى استدلال المنفذ أو عملية قراره.
هذا العزل مهم. المراجعة الذاتية تفشل لأن العقل الذي يراجع المخرجات يقبل بالفعل نفس المنطلقات التي أنتجتها. منفذ اختار بنية معمارية بسبب قيد محدد لن يشكك في ذلك القيد عند المراجعة الذاتية. مراجع لم يرَ القيد قط سيشكك فيما إذا كانت البنية المعمارية مناسبة. المنظور الجديد خاصية بنيوية للعزل، لا سمة شخصية للمراجع.
وكيل المحكّم: يعالج الخلافات بين المنفذ والمراجع بتحليل كلا الموقفين مقابل المعايير المحددة. ينتج حكماً باستدلال صريح. الحكم مدخل حتمي للخطوة التالية.
التطبيقات المؤسسية حيث يضيف هذا النمط قيمة قابلة للقياس: صياغة العقود مع مراجعة مستقلة للبنود (تكتشف الغموض الذي اعتاده الكاتب)، مقترحات العملاء مع مراجعة المخاطر (تكتشف الالتزامات التي برّرها الكاتب التجاري)، تصميم البنية مع مراجعة الأمان (تكتشف الافتراضات التي قبلها المهندس المعماري)، والتحليل التقني مع التحقق المستقل (تكتشف أخطاء الحساب والمنطلقات الخاطئة).
ميزانية السياق كقيد تصميمي لتعدد الوكلاء
القيد التصميمي الذي تُبنى معظم الأنظمة متعددة الوكلاء دون مراعاته بشكل صريح: لكل وكيل ميزانية سياق محدودة، ويجب أن تكون عمليات تسليم المعلومات بين الوكلاء صريحة حول ما ينتقل بين الوكلاء وبأي شكل.
مبدأ جبل الجليد: نافذة السياق تحتوي فقط على ما يجب أن يكون مرئياً دائماً لوظيفة هذا الوكيل المحددة. كل شيء آخر متاح عبر الأدوات أو استدعاء الذاكرة أو الاسترجاع، لا يُحمَّل في نافذة السياق بشكل افتراضي. وكيل يحمل التاريخ الكامل لنوافذ سياق جميع الوكلاء السابقين يتراكم فيه التلوث في كل خطوة.
انضباط التسليم: وكيل البحث يسلم مخرجات منظمة بالمصادر والنتائج الرئيسية والمنطلقات الصريحة. لا يسلّم محتوى الويب الخام. المحلل يسلم جداول منسقة ونتائج محققة. لا يسلّم نتائج الاستعلام الخام. كل تسليم هو أيضاً بوابة جودة: يجب أن تتوافق المخرجات مع مواصفة إدخال الوكيل المتلقي قبل تمريرها.
بدون انضباط التسليم، تُضخّم الأنظمة متعددة الوكلاء تلوث السياق بدلاً من تقليله. كل وكيل يضيف ضجيجه إلى ضجيج الوكيل السابق. المخرجات النهائية هي توليف من الارتباك المتراكم.
كل تسليم هو أيضاً درز معماري حيث يمكن إدخال أخطاء دون اكتشافها على مستوى الوكيل المنتج. وكيل بحث ينتج ملخصاً بخطأ واقعي يمرر ذلك الخطأ إلى وكيل الكتابة كحقيقة مُسلَّم بها. ابنِ فحوصات جودة صريحة عند كل تسليم، ليس فقط عند المخرجات النهائية.
المعيار الذي يحسم القرار
قبل تصميم أي نظام متعدد الوكلاء، ثلاثة أسئلة:
- هل تمتلك هذه المهمة وحدات عمل مستقلة فعلاً يمكن تشغيلها بالتوازي؟
- هل تتطلب هذه المهمة مراجعة تنافسية حيث يجب ألا يرى المراجع استدلال المنفذ؟
- هل تتطلب هذه المهمة سياقاً مختلفاً فعلاً لوظائف مختلفة لا يمكن أن تتعايش في نافذة واحدة؟
إذا كانت الإجابة الصادقة على الثلاثة لا، فوكيل واحد مُصمَّم جيداً بأدوات جيدة وسياق واضح يحقق الهدف بتكلفة أقل وكمون أقل وتعقيد تصحيح أقل.
نقطة البيانات التي تضع الواقع التجاري في سياقه: Salesforce Agentforce وصلت إلى ما يزيد على 540 مليون دولار في ARR مع أكثر من 18,000 عميل [تقدير: التحقق عبر إفصاحات أرباح Salesforce قبل الاستشهاد]. غالبية حالات الاستخدام المنشورة في تلك القاعدة هي سير عمل بوكيل واحد أو تسلسلية بسيطة. سوق الذكاء الاصطناعي المؤسسي ليس في المقام الأول سوقاً للأسراب المُنسَّقة. إنه سوق للأتمتة الموثوقة المحددة النطاق التي تنتج نتائج قابلة للتدقيق.
التطور هو في اختيار البنية المعمارية الصحيحة للمهمة. ليس في نشر الأكثر تعقيداً.
تعدد الوكلاء هو الخيار الصحيح لمجموعة صغيرة من المهام ذات الخصائص البنيوية المحددة. لغالبية مشاكل الأتمتة المؤسسية، هو هندسة مفرطة تُنشئ عبئاً في الصيانة وتُعقّد التصحيح وتُخفي القيمة البسيطة التي احتاجها العمل فعلاً.
ابنِ الوكيل الواحد بشكل صحيح أولاً. ثم قرر ما إذا كانت بنية المهمة تتطلب المزيد.
للفرق المؤسسية التي تصمم بنيات الوكلاء، تُحدد جولة فرصة الذكاء الاصطناعي البنية المناسبة لحالتك الخاصة قبل البدء في البناء.