ماذا يفعل وكيل الذكاء الاصطناعي فعلًا على نسخة ServiceNow
يُستخدم تعبير «الذكاء الاصطناعي الوكيلي» ليعني كل شيء ولا شيء. هذه هي النسخة العملية: ما الذي يقرؤه الوكيل، وما الذي يكتبه، وأين يجب أن يتوقف، وكيف تميّز وكيلًا مفيدًا فعلًا عن روبوت محادثة بتسمية جديدة.
معظم ما يُكتب عن «الذكاء الاصطناعي الوكيلي لـ ServiceNow» يصف قدرة دون أن يصف آلية. وهذا يجعل تقييمه مستحيلًا. لذا هذه هي النسخة الآلية: ما الذي يلمسه الوكيل فعلًا في النسخة، وأي الأجزاء صعب.
الوكيل حلقة، لا ميزة
روبوت المحادثة يحوّل عبارة إلى ردّ. أما الوكيل فيشغّل حلقة: يقرأ الحالة، ويقرر الخطوة التالية، وينفّذها، ويلاحظ ما حدث، ثم يقرر من جديد. ويتوقف حين يتحقق الهدف أو حين يصل إلى حد رسمته أنت.
على نسخة ServiceNow، تلمس هذه الحلقة أربعة أشياء:
- الجداول: قراءة
incidentوsc_requestوcmdb_ciوأي جداول مخصصة تحمل عمليتك الفعلية - قواعد العمل والتدفقات (Flows): يشغّل الوكيل الأتمتة القائمة بدل إعادة تنفيذها
- ACLs: يعمل الوكيل بصفة شخص ما، ويرث صلاحياته تمامًا
- سجل التدقيق: كل كتابة يجريها منسوبة إلى جهة، أو ينبغي ألا يُسمح له بإجرائها
والنقطة الثالثة هي التي تحدد هل ينجو النشر من المراجعة الأمنية.
العمل المفيد غير لامع
تُظهر العروض التوضيحية وكيلًا يحلّ حادثة معقدة من البداية إلى النهاية. أما العمل الذي يغطي تكلفته فعلًا فهو أكثر مللًا:
- الفرز (triage) والتوجيه. قراءة وصف نصي حر وإسناد الفئة والاستعجال والمجموعة الصحيحة، وهي الخطوة التي يؤديها البشر بلا اتساق وتُفسد كل مقياس لاحق.
- الإثراء. جلب عنصر التهيئة ذي الصلة والتغييرات الأخيرة عليه والحوادث المشابهة السابقة إلى السجل قبل أن يفتحه إنسان.
- مسودات الردود. إنتاج ردّ يحرره المسؤول عن التذكرة ويرسله، لا ردّ يرسله الوكيل دون إشراف.
- إغلاق الحلقة. تحديث السجل بما فعله الوكيل، ليرى القارئ التالي، إنسانًا كان أو وكيلًا، تاريخًا متماسكًا.
لاحظ أن ثلاثًا من هذه الأربع تنتهي بإنسان. وهذا ليس قيدًا يجب هندسته بعيدًا؛ إنه التصميم نفسه.
أين يجب أن يتوقف الوكيل
الحد الذي يستحق الرسم ليس «ما مدى ذكاء النموذج»، بل ما القابل للتراجع عنه.
يستطيع الوكيل أن يفعل بحرية ما يسهل التراجع عنه: إضافة ملاحظة عمل، واقتراح فئة، وصياغة نص، والتنبيه إلى تكرار. وينبغي ألا يفعل ما يصعب التراجع عنه أو يستحيل دون إنسان في الحلقة: الموافقة على تغيير، وإغلاق P1، ومراسلة عميل، ولمس بيانات CMDB في الإنتاج، ومنح صلاحية وصول.
هذا الحد قرار تهيئة، لا قدرة نموذج. دوّنه قبل أن تبني أي شيء.
كيف تميّز الوكيل الحقيقي من روبوت محادثة أُعيد تغليفه
أربعة أسئلة تفرق بينهما سريعًا:
- ماذا يقرأ؟ إن كان الجواب «قاعدة المعرفة»، فهو واجهة بحث. الوكيل الحقيقي يقرأ حالة السجلات الحية.
- ماذا يستطيع أن يكتب، وبصفة من؟ إن لم يستطع الكتابة فليس وكيلًا. وإن كتب بحساب مسؤول مشترك فهو عبء.
- ماذا يحدث حين يخطئ؟ ينبغي أن يكون هناك جواب محدد: تراجع، أو طابور مراجعة، أو بوابة موافقة. لا «النموذج دقيق جدًا».
- هل تستطيع أن ترى ما فعله؟ كل إجراء منسوب، وموجود في سجل التدقيق، بلغة يستطيع غير المهندس متابعتها.
فإن عجز مورّد عن الإجابة عن هذه الأربعة، فما لديه عرض توضيحي.
القيد الصادق
الوكلاء جيدون في أجزاء القراءة والربط والصياغة. وهم غير موثوقين في كل ما يتطلب معرفة لا توجد إلا في رأس أحدهم: أي فريق يملك خدمة ما فعلًا رغم ما تقوله CMDB، وأي عميل يجب ألا يتلقى ردًّا آليًّا، وأي تغيير «روتيني» عطّل الإنتاج في الربع الماضي.
النسخ التي يعمل فيها الوكلاء جيدًا هي النسخ التي أصبحت فيها هذه المعرفة الضمنية صريحة. وهذا يعني أن مشروع الوكيل كثيرًا ما يكون مشروع جودة بيانات يرتدي قبعة أكثر إثارة.
ليس ذلك سببًا لتجنبه. إنه سبب لتحديد نطاقه بصدق.