الذكاء الاصطناعي الوكيل، وموقعه الحقيقي في الأنظمة التي نبنيها

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

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

ماذا نعني بـ«الوكيل» تحديداً

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

المساعد المُبرمج مسبقاً الذي يجيب بشكل جيد عن الأسئلة الشائعة، مثل مربع البحث في أداة Care Team الخاصة بنا، مفيد فعلاً. لكنه ليس «وكيلاً» — فهو لا يتخذ إجراءات ولا يسلسل قرارات من تلقاء نفسه. هذا الفرق مهم، لأنه بالضبط حيث يبدأ العمل الهندسي الحقيقي.

الأساس موجود بالفعل في معظم ما نبنيه

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

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

إلى أين يتجه هذا، حالة استخدام تلو الأخرى

لا شيء مما يلي هو ميزة مطروحة اليوم — هذا هو الاتجاه الذي تشير إليه هذه الأسس، قطاعاً بقطاع:

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

كيف نتعامل مع الأمر — بوعي، لا بشكل افتراضي

تتضمن بنيتنا التقنية بالفعل العناصر اللازمة لذلك: TensorFlow وPyTorch وOpenCV لجانب النمذجة، وOllama لتشغيل النماذج على بنية تحتية نتحكم بها. الهدف ليس ربط واجهة برمجية لذكاء اصطناعي خارجي بكل منتج — بل الحفاظ على بيانات الأعمال والعملاء داخل بنية تحتية نتحكم بها كلما كان ذلك ممكناً عملياً. وهو نفس المبدأ الذي دفعنا لبناء نظام بحث بالكلمات المفتاحية خاص بنا لأداة Care Team بدلاً من توجيه كل سؤال من الزوار عبر نموذج خارجي.

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

أين نقف اليوم

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

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