وكلاء الذكاء الاصطناعي مقابل RAG: كيف يعمل ReAct ولماذا نحتاج إلى الأنظمة متعددة الوكلاء

يستطيع LLM توليد النصوص، لكن إجابة واحدة لا تكفي لمعظم المهام العملية. المطلوب هو التصرف: طلب بيانات من مصدر خارجي، واختيار الأداة المناسبة، والتحقق من النتيجة، وتعديل الخطوة التالية عند الحاجة. هكذا يعمل وكلاء الذكاء الاصطناعي، ولهذا السبب بالتحديد يتحول النهج القائم على الوكلاء بسرعة إلى معيار للأنظمة المبنية على النماذج اللغوية الكبيرة.

الوكيل مقابل LLM البسيط

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

والفرق الجوهري عن أنظمة RAG (Retrieval-Augmented Generation) أن RAG تضيف سياقاً من قاعدة المعرفة قبل التوليد، وهو إثراء سلبي للمدخلات. أما الوكيل فيقرر بنفسه متى يطلب المعلومة وماذا يطلب: يستدعي API، ويشغّل الأكواد، ويقرأ الملفات، ويتواصل مع خدمات خارجية. فهو لا يكتفي بتلقي تلميح، بل يتصرف ويتكيف مع ما تعيده البيئة.

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

كيف يعمل ReAct

يُعد ReAct (Reasoning + Acting) من أبرز الأطر الأساسية للوكلاء وأكثرها دراسة. يمر النموذج بثلاث مراحل متتابعة في كل دورة:

• Thought — التفكير: يصوغ النموذج ما هو معروف لديه وما ينبغي فعله في الخطوة التالية
• Action — اختيار الأداة واستدعاؤها: البحث في الإنترنت، أو استخدام آلة حاسبة، أو إرسال طلب إلى API أو قاعدة بيانات
• Observation — تحليل النتيجة المُعادة والانتقال إلى الدورة التالية

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

وتكمن قوة ReAct في شفافيته. فكل خطوة قابلة للفحص والتنقيح: يمكن رؤية ما «فكّر» فيه النموذج، وما استدعاه، وما حصل عليه في المقابل.

الأنظمة متعددة الوكلاء

الوكيل الواحد محدود بنافذة السياق وبتخصصه وبزمن التنفيذ. وحين تكون المهمة معقدة أو تتطلب عملاً متوازياً، تأتي الأنظمة متعددة الوكلاء، وهي بنية يعمل فيها عدة وكلاء معاً.

يتألف النظام متعدد الوكلاء عادةً من:

• Orchestrator — وكيل المنسّق الذي يقسّم المهمة ويوزع المهام الفرعية على العاملين
• Workers — وكلاء متخصصون في وظائف محددة: البحث، وتوليد الأكواد، والعمل مع البيانات، والتواصل
• Critic / Verifier — وكيل التحقق الذي يراجع نتائج الوكلاء الآخرين قبل التجميع النهائي

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

«النهج القائم على الوكلاء يتحول بسرعة إلى معيار للأنظمة الحديثة

المبنية على LLM» — من سلسلة «الحد الأدنى الأساسي».

مثال عملي: وكيل في Google Colab

في ختام سلسلة «الحد الأدنى الأساسي» يُعرض أصغر وكيل عملي: مساعد لتخطيط الرحلات منفذ في Google Colab. كل شيء قابل لإعادة الإنتاج: لا اعتماديات مخفية، والحد الأدنى من الإعدادات.

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

ماذا يعني ذلك

لم يعد وكلاء الذكاء الاصطناعي مفهوماً أكاديمياً. وفهم الأنماط الأساسية، وهي ReAct والفصل بين orchestrator وworker والبنى متعددة الوكلاء، بات ضرورياً لكل من يبني منتجات على LLM. ومن دون هذا الأساس يصعب التنبؤ بالموضع الذي سينهار فيه النظام، ويكاد يستحيل تنقيحه.