الدعم الفني للمطورين ينتقل من روبوتات الدردشة إلى ثلاثة أدوار لوكلاء الذكاء الاصطناعي

قبل عامين كان «الذكاء الاصطناعي في الدعم» يعني روبوت دردشة بأزرار، يجيب وفق قوالب جاهزة ويثير استياء المستخدمين. وفي 2026 تعتمد خدمات دعم المطورين نموذجًا مختلفًا. فهي لا تقوم على بوت ذكي واحد، بل على ثلاث مجموعات من الوكلاء لكل منها مهمة مختلفة. تفحص المجموعة الأولى السجلات والشيفرة، وتجمع الثانية السياق للمهندس، وتفتح الثالثة Pull Request يتضمن الإصلاح بأمر من الإنسان. هذا ما تصفه مادة حديثة على Habr عن هذا الاتجاه. لا يتضمن الإعلان أي قياسات للفعالية، لذلك يتناول ما يلي بنية النهج ومنطقه، لا نسب توفير مثبتة.

ثلاثة أدوار بدلًا من بوت واحد

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

• يقرأ وكيل التشخيص سجلات CI وتتبعات الأخطاء وتاريخ الـcommits، ويبحث عن السبب المحتمل لفشل البناء.
• يجمع وكيل الإعداد للمهندس إصدار SDK والبيئة وخطوات إعادة إنتاج المشكلة والتذاكر المرتبطة بها.
• يعدّ وكيل التنفيذ الرقعة ويفتح Pull Request، لكن فقط بعد أمر صريح من الإنسان.
• تشمل حلقة الرقابة المراجعة وتشغيل الاختبارات وسجلًّا بإجراءات كل وكيل.

الدور الثالث هو الأكثر دلالة. فالوكيل لا يدمج التغييرات بنفسه، بل يقترحها في صورة PR، ويبقى القرار للمهندس.

لماذا دعم المطورين تحديدًا

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

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

أين المخاطر

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

من أين يبدأ الفريق

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

• نسبة التذاكر التي تبيّن أن السياق المجموع فيها صحيح؛
• الوقت حتى أول رد مفيد؛
• نسبة الـPR المقبولة دون تعديلات؛
• عدد الطلبات المتكررة حول المسألة نفسها.

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