SmolAgents: كيف تبني نظام ذكاء اصطناعي متعدد الوكلاء بالاعتماد على الكود والتنسيق الديناميكي

يُظهر SmolAgents أن أنظمة الذكاء الاصطناعي متعددة الوكلاء لا يجب أن تكون ثقيلة أو معقدة الصيانة. ففي التطبيق موضوع التحليل، يبني المؤلفون بنية عملية تضم وكلاء صغارًا قادرين على التفكير المنطقي، وتشغيل الكود، واختيار الأدوات المناسبة للمهمة، وتمرير العمل بعضهم إلى بعض. والفكرة ليست عرض دردشة جديدة مزوَّدة بدوال، بل إرساء أساس لسيناريوهات جاهزة للإنتاج (production-ready)، يتصرف فيها الوكيل منفِّذًا للمهام، لا مجرد مولّد للنصوص.

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

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

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

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

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

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