تركتُ وكيلاً مدفوعاً بالذكاء الاصطناعي يدير مسار CI/CD الخاص بي لمدة شهر. وبحلول نهاية التجربة، كان الوكيل يقوم بإصلاح عمليات البناء الفاشلة، وفتح طلبات السحب (pull requests)، وإعادة تشغيل المهام، ولم يتبقَّ سوى خطوة واحدة للموافقة البشرية. تُظهر هذه التجربة أن الـ DevOps "القائم على الوكلاء" (agentic) يمكن أن ينقل عمليات الفرز الروتينية من المكاتب الخلفية إلى "عقل آلي"، لكنها تكشف أيضاً عن حواجز الحماية الضرورية لمنع النظام المستقل من أن يصبح مصدراً جديداً للمخاطر.
لماذا كانت هذه التجربة مهمة
لا تزال معظم فرق البرمجيات تتعامل مع الذكاء الاصطناعي كأداة إكمال تلقائي متطورة—أداة تقترح سطراً من الكود أو تشرح رسالة خطأ. في عام 2025، ينتقل القطاع من "الذكاء الاصطناعي الذي يساعدك على الكتابة" إلى "الذكاء الاصطناعي الذي يتخذ الإجراءات". يمكن للوكيل الفاعل أن يقرأ السجلات (logs)، ويقرر الإصلاح، ويطبقه، ويتعلم من النتيجة—كل ذلك دون أن يكتب المطور أمراً واحداً.
الفكرة الأساسية: مسار عمل قائم على الوكلاء
مسار العمل القائم على الوكلاء ليس نموذجاً واحداً ضخماً يتمتع بوصول غير مقيد إلى بيئة الإنتاج. بل هو منسق محدود النطاق يقوم بتنسيق أدوات متخصصة، ويحتفظ بالسياق، ويعمل خلف حواجز حماية صارمة. تحاكي الحلقة الأساسية عملية استكشاف الأخطاء وإصلاحها التي يقوم بها البشر:
- الإدراك – سحب السجلات، ومخرجات الاختبار، والمقاييس.
- التفكير – تحليل الفشل، والتخطيط لأكثر طرق الإصلاح أماناً.
- التنفيذ – استدعاء أداة محددة النطاق لتطبيق رقعة برمجية، أو ترقية تبعية، أو إعادة تشغيل مهمة.
- التعلم – تسجيل النتيجة ليكون القرار التالي مبنياً على معلومات أفضل.
كانت البنية التحتية التي حافظت على سلامة التجربة كالتالي:
- منصة CI/CD – لجدولة وتشغيل المهام.
- المنسق (Orchestrator) – "العقل" الذي يستقبل البيانات، ويدير حلقة التحكم، ويقرر ما يجب فعله.
- الأدوات – "الأيدي" التي تنفذ إجراءات ملموسة (مثل فتح PR، أو تحديث إصدار).
- مخزن السياق – ذاكرة خفيفة للفشل والإصلاحات الأخيرة.
- حواجز الحماية (Guardrails) – حدود صارمة تمنع الوكيل من لمس بيئة الإنتاج مباشرة أو إجراء تغييرات دون موافقة بشرية صريحة.
من خلال إبقاء نموذج اللغة الكبير (LLM) بعيداً عن عمليات الكتابة المباشرة في بيئة الإنتاج، قلل النظام من سطح الهجوم مع السماح للنموذج بالتفكير في المشكلة.
شهر في حياة الوكيل
الأسبوع الأول – المراقبة للقراءة فقط
عمل الوكيل في وضع "الشرح فقط". كانت كل عملية بناء فاشلة تُنشئ رسالة على Slack تلخص الخطأ وتقترح الأسباب المحتملة. لم يتغير أي كود. أثبتت هذه المرحلة أن خطوات الإدراك والتفكير تعمل على سجلات حقيقية، ومنحت الفريق الثقة في أن الوكيل يفهم قاعدة الكود.
الأسبوع الثاني – اقتراح الإصلاحات
خلال الأيام السبعة التالية، قام المنسق بفتح طلبات سحب (pull requests) للمشكلات منخفضة المخاطر، مثل فشل فحص التنسيق (linting) أو التبعيات القديمة. قام المهندسون بمراجعة طلبات السحب قبل دمجها.
الأسبوع الثالث – الإجراءات المحكومة
مع تفعيل سير عمل الموافقة، حصل الوكيل على إذن لإعادة تشغيل المهام في بيئة غير إنتاجية. عندما تفشل عملية بناء، يقوم المنسق تلقائياً بتثبيت الإصدار الصحيح لتبعية معطلة، ويفتح طلب سحب (PR)، وبعد دمج الطلب، يعيد تشغيل مسار العمل.
الأسبوع الرابع – قياس الأثر
ركز الأسبوع الأخير على قياس النتائج، وتتبع عدد حالات الفشل التي تمكن الوكيل من حلها.
الإيجابيات: التخلص من العمل الممل
أظهرت التجربة أن وكيل الذكاء الاصطناعي يمكنه التعامل مع الأجزاء المتكررة من CI/CD: قراءة السجلات، واكتشاف الأنماط المعروفة، وتحديث الإصدارات، وإعادة تشغيل المهام. لم يكن على المهندسين سوى الموافقة على التغييرات النهائية والتحقيق في حالات الفشل القليلة التي لم يتمكن الوكيل من حلها. عملياً، كان ذلك يعني تنبيهات أقل في منتصف الليل، وتقليلاً في تشتت التركيز (context-switching)، وحلقة تغذية راجعة أسرع للمطورين.
المخاطر وكيفية التخفيف منها
- إصلاحات خاطئة بثقة – أحياناً طبق الوكيل رقعة برمجية تعالج العرض فقط وتخفي خطأً أعمق. ساهمت حواجز الحماية التي تتطلب موافقة بشرية على أي تغيير يمس كود الإنتاج في كبح هذا الخطر.
- فرط الضجيج – التنبيهات غير المفلترة قد تطغى على التنبيهات الحقيقية.
- توسع النطاق – منح النموذج وصولاً غير مقيد يؤدي بسرعة إلى آثار جانبية غير مقصودة. منع الفصل الصارم في البنية التحتية بين الـ LLM (التفكير) والأدوات (التنفيذ) الوكيل من إجراء تغييرات عشوائية.
خطة نشر تدريجية للفرق الأخرى
إذا أرادت مؤسستك تجربة مسار عمل قائم على الوكلاء، فاتبع هذا المسار التدريجي:
- إعداد المنسق (orchestrator) – خدمة خفيفة الوزن يمكنها استدعاء الـ LLM، وتخزين السياق، واستدعاء واجهات برمجة تطبيقات CI/CD.
- تحديد الضوابط الوقائية (guardrails) – وضع قائمة بيضاء لمهام CI/CD التي يمكن للوكيل تشغيلها، وطلب الموافقة على طلبات السحب (PR)، ومنع أي عمليات كتابة مباشرة في بيئة الإنتاج.
- الأسبوع الأول: وضع المراقبة – تزويد المنسق بالسجلات (logs) والسماح له بنشر ملخصات تشخيصية في قناة دردشة.
- الأسبوع الثاني: وضع الاقتراحات – السماح للوكيل بفتح طلبات سحب (PRs) للإصلاحات غير الحرجة؛ مع الإبقاء على المراجعة البشرية إلزامية.
- الأسبوع الثالث: الإجراء المنضبط – منح الإذن بإعادة تشغيل المهام في بيئات الإعداد (staging) أو الاختبار (test) بعد دمج طلب السحب (PR).
- الأسبوع الرابع: المقاييس والضبط – تتبع حالات الفشل التي تم فرزها، والنتائج الإيجابية الخاطئة، والوقت الذي تم توفيره؛ وضبط عتبات التنبيه والضوابط الوقائية بناءً على ذلك.
- التكرار والتحسين – توسيع مجموعة الأدوات (مثل عمليات التراجع التلقائية، والمسح الأمني) فقط بعد اجتياز كل قدرة جديدة لنفس فحوصات السلامة.
الحجة المضادة
يشير المتشككون إلى أن الوكلاء قد يخطئون بثقة. لم تقضِ التجربة على هذا القلق؛ بل أظهرت فقط أن الضوابط الوقائية المنضبطة تتيح لك جني الفوائد مع إبقاء المخاطر تحت السيطرة.
الخلاصة
يمكن لوكيل الذكاء الاصطناعي الذي يدير حلقة التحكم في CI/CD أن يحول عملية الفرز اليدوية ورد الفعل إلى خط أنابيب (pipeline) شبه ذاتي الإصلاح، بشرط عزل النموذج، وفرض خطوات موافقة صارمة، والبدء بنهج يعتمد على المراقبة أولاً وبمخاطر منخفضة. لا تكمن القيمة الحقيقية في استبدال المهندسين، بل في تخفيف أعباء المهام المملة والمتكررة التي تحافظ على استقرار خطوط الأنابيب وتسمح للمطورين بالتركيز على البناء.