ما هو نظام الوكلاء المتعددين ولماذا تحتاجه المؤسسة؟

المشكلة: عندما يصل المساعد الواحد إلى سقفه

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

الردّ البديهي هو نموذج أكبر أو طلب أطول. لكن المشكلة في هذه الحالة ليست في حجم النموذج، بل في التصميم: كيان واحد مكلّف بالاسترجاع والحساب والتحقق والتنفيذ في الوقت ذاته، دون فصل للمسؤوليات ولا سجل لما فعله. عندما يخطئ، لا يوجد ما يُراجع. هذا هو الفراغ الذي يحاول نظام الوكلاء المتعددين سدّه، لا بزيادة عدد النماذج لمجرد الزيادة، بل بفصل الأدوار وجعل كل خطوة قابلة للملاحظة والتقييم.

• المهمة المركّبة تُخفّض دقة الكيان الواحد حتى مع نموذج قوي.
• الخطأ غير قابل للتشخيص عندما يختلط الاسترجاع بالحساب بالصياغة.
• الحل يبدأ من تقسيم المهمة، لا من تغيير المزوّد.

تعريف واضح: ما هو نظام الوكلاء المتعددين؟

نظام الوكلاء المتعددين هو منظومة من وكلاء ذكاء اصطناعي، لكل منهم دور محدد، ومجموعة أدوات محدودة، ونطاق ذاكرة خاص، وصلاحيات وصول معرّفة، وتعمل جميعها تحت منسّق مركزي يقرر من ينفّذ أي خطوة، وبأي ترتيب، وكيف تُدمج النتائج في مخرج واحد. الفرق الجوهري عن المساعد التقليدي أن الوحدة الأساسية لم تعد «الطلب»، بل «المهمة الموزعة»: استرجاع، تحليل، تحقق، تنفيذ، ثم صياغة.

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

من المهم التمييز بين ثلاثة أشياء تبدو متشابهة: سلسلة خطوات ثابتة (Workflow) ينفّذها النظام بالترتيب نفسه دائمًا؛ ووكيل واحد بأدوات متعددة يقرر بنفسه أي أداة يستخدم؛ ونظام متعدد الوكلاء يوزّع القرار والمسؤولية. النظام المتعدد مفيد فقط عندما يكون التوزيع نفسه هو مصدر القيمة، أي عندما تحتاج أدوارًا مختلفة إلى بيانات مختلفة وصلاحيات مختلفة وأساليب تحقق مختلفة.

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

وكيل واحد أم عدة وكلاء؟ المقارنة التي تحسم القرار

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

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

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

أنماط التنسيق الأربعة الأكثر استخدامًا

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

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

لكل نمط أنماط فشل معروفة: الحلقات المغلقة حين يعيد وكيلان تمرير المهمة دون تقدم؛ وفقدان السياق عند الانتقال بين وكلاء لا يتشاركون نفس الذاكرة؛ وتحميل المسؤولية على الوكيل الأخير حين تظهر النتيجة خاطئة أصلًا من أول خطوة. المعالجة تكون بحدّ أعلى لعدد الخطوات، ومخطط تسليم موحّد يحدد ما يُمرَّر بين الوكلاء، وسجل يربط كل عبارة في المخرج بالمصدر الذي أنتجها.

• موجّه (Router) — أفضل للأسئلة المتنوعة قصيرة المسار، وأضعف في المهام المتسلسلة.
• متسلسل (Pipeline) — أفضل للمراجعة والتحقق، وأبطأ في الاستجابة.
• متوازٍ (Fan-out) — أفضل لقراءة مصادر متعددة، وأعلى كلفة لكل طلب.
• نقد ومراجعة (Critic) — أفضل للمخرجات الحساسة، ويحتاج معايير تحقق صريحة لا انطباعية.

أين يفيد فعليًا وأين يضرّ؟

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

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

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

الحوكمة: الصلاحيات والبيانات والمساءلة

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

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

في هذا السياق تأتي منصات مثل Pilardin كمساحة عمل واحدة تجمع RAG على مستندات المؤسسة وموصّلات الأنظمة الحيّة ووحدات Matrix المتخصصة تحت طبقة حوكمة مشتركة، بحيث لا يُبنى لكل وكيل نظام صلاحيات منفصل. يمكن الاطلاع على وحدات Matrix لمعرفة كيف تُوزّع الأدوار، وعلى صفحة الأسعار لتقدير نطاق التنفيذ قبل الالتزام.

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

خطوات عملية لتقييم الجاهزية قبل البناء

قبل كتابة أي كود، ارسم المهمة على ورق: ما الخطوات الفعلية التي يقوم بها الموظف اليوم، وأين يحدث الخطأ أكثر، وأي خطوة تحتاج بيانات لا يجوز أن يراها غير المخوّلين. هذا الرسم هو الذي يحدد عدد الوكلاء، لا العكس. كثير من المشاريع تفشل لأنها بدأت من «كم وكيلًا نبني؟» بدلًا من «أين تنكسر المهمة؟».

بعد ذلك ابنِ مجموعة تقييم صغيرة من ثلاثين إلى خمسين حالة حقيقية مع الإجابة الصحيحة المعروفة، وشغّلها في كل نسخة. راقب ثلاث نسب: دقة المخرج النهائي، ونسبة الحالات التي توقف فيها النظام وأحالها إلى إنسان، ومتوسط عدد الانتقالات لكل مهمة. النسبة الثانية ليست فشلًا بل مؤشر نضج؛ النظام الذي يعرف متى يتوقف أقل خطرًا من الذي يجيب دائمًا بثقة.

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

الخلاصة: التنسيق أهم من عدد الوكلاء

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

أما عندما تكون الحاجة غير موجودة، فإن إضافة الوكلاء تنتج تعقيدًا يبدو ذكيًا في العرض التقديمي ويثقل التشغيل بعد ستة أشهر. ابدأ صغيرًا، قِس بدقة، واحتفظ بقرار التوسّع معلّقًا على أدلة من بيانات التقييم لا على حماس الفريق. بهذا الترتيب يتحول نظام الوكلاء المتعددين من مفهوم تسويقي إلى بنية تُحاسَب على نتائجها.

• ابدأ من المهمة، لا من عدد الوكلاء.
• افصل الصلاحيات قبل أن تفصل الأدوار.
• اجعل كل انتقال بين وكيلين قابلًا للتسجيل والمراجعة.

FAQ

هل نظام الوكلاء المتعددين هو نفسه RAG؟

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

كم عدد الوكلاء المناسب للبداية؟

اثنان أو ثلاثة كحد أقصى، مع منسّق واحد. الهدف في النسخة الأولى ليس تغطية كل الحالات، بل إثبات أن التقسيم يرفع الدقة أو يقلّل المخاطر. كل وكيل إضافي يضيف كلفة وزمن استجابة وسطح فشل، ولا يُضاف إلا بعد أن تُظهر بيانات التقييم أن الخطوة الحالية هي نقطة الضعف.

هل يمكن تشغيل النظام داخل شبكة المؤسسة؟

نعم، وهذا شرط في كثير من القطاعات. يتطلب الأمر أن يعمل الاسترجاع والاستدلال على بنية تحتية مملوكة للمؤسسة أو داخل شبكتها، مع سجلات محفوظة للمراجعة. هذا ما تتيحه منصات مثل Pilardin عبر تشغيل وحدات RAG وMatrix داخل نطاق المؤسسة بدلًا من إرسال المستندات إلى خدمات خارجية.

كيف نقيس نجاح النظام؟

بثلاثة مؤشرات على الأقل: دقة المخرج النهائي مقابل إجابة مرجعية معروفة، ونسبة الحالات التي أحالها النظام إلى مراجعة بشرية، ومتوسط عدد الانتقالات والكلفة لكل مهمة. مؤشر رابع مفيد هو نسبة العبارات في المخرج التي يمكن ربطها بمصدر محدد؛ انخفاضها يعني أن النظام بدأ يستنتج بدلًا من أن يستشهد.

هل يزيد النظام المتعدد التكلفة دائمًا؟

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