GitLab Duo CLI: حوكمة وكلاء الذكاء الاصطناعي في مسارات CI/CD

أضافت GitHub مؤخرًا إلى Copilot CLI دعم bring-your-own-key (BYOK) والنماذج المحلية. ويستطيع المطورون توجيه الطلبات عبر مزوّدهم الخاص أو تشغيل النموذج بالكامل دون اتصال (offline). لكن اختيار النموذج ليس سوى البداية. فالتعقيد الحقيقي يبدأ حين يشرع الذكاء الاصطناعي في تنفيذ إجراءات عبر مسار تسليم البرمجيات (software delivery pipeline) بأكمله: تشغيل عمليات البناء وتعديل إعدادات CI/CD. وعندها تصبح القرارات المعمارية التي تقوم عليها أداة سطر الأوامر حاسمة.

نهجان لأدوات CLI المعتمدة على الذكاء الاصطناعي

يعمل Copilot على مستوى محطة عمل المطوّر الفردية. ولم توفر GitHub إدارة على مستوى المؤسسة: لا توجد رقابة على النموذج الذي يستخدمه الفريق، ولا تدقيق لما فعله الوكيل تحديدًا ولماذا.

أما GitLab Duo CLI فتقوم على تصور مختلف. فهي مبنية على GitLab Duo Agent Platform، ومصممة للمطوّر الذي يعمل من الطرفية وللفرق التي تؤتمت فيها الوكلاء مهام security وverification وcompliance وdeployment في عشرات المشاريع ذات دورات الإصدار المختلفة.

تدعم GitLab Duo CLI وضع headless، وهو وضع غير تفاعلي قابل للبرمجة النصية (scriptable) ومدمج في مسارات CI/CD. وتمتد إدارة الحوكمة هنا حتى نهاية المسار.

لماذا لا يساوي اختيار النموذج الحوكمة

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

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

• ما الذي يملك هذا الوكيل صلاحية الوصول إليه؟
• ما المسموح له بفعله؟
• ما الإجراءات التي نفذها، وهل أستطيع إثبات ذلك؟
• هل يمكن اختطاف الوكيل (hijacked) عبر prompt injection؟

تعالج GitLab Duo CLI ذلك على مستوى المنصة. ففي الوضع التفاعلي لا يُنفَّذ أي إجراء دون موافقة بشرية. ويُدمج كشف prompt injection في GitLab Duo Agent Platform، ويحجب محاولات اختطاف الوكيل بأوامر خبيثة. ويحصر composite identity وصول الوكيل في ما هو مخوَّل به صراحةً فقط. ويصبح كل إجراء ينفذه الذكاء الاصطناعي قابلًا للتدقيق. كما تتيح ملفات مثل AGENTS.md وSKILL.md للفريق تحديد المهام والإجراءات المسموحة للوكيل بدقة.

السيناريو الرئيسي: أتمتة CI/CD

تحقق أدوات CLI المعتمدة على الذكاء الاصطناعي أقصى قيمة عند تصحيح مسار معطّل في نهاية السبرنت، وفي مهام التطوير متعددة الخطوات. لكن هذا بالذات هو السيناريو الذي يتسع فيه الفارق بين الإعدادات الخاصة بكل مطوّر (per-developer) والحوكمة على مستوى المنصة (platform-level governance) أكثر من غيره.

حين يعمل الوكيل داخل المسار، لا يكون المطوّر موجودًا إلى جانبه، ولن يتمكن من ملاحظة محاولة prompt injection أو سلوك غير متوقع من النموذج. لذا يجب أن تكون ضوابط الأمان مدمجة في المنصة وتعمل بالطريقة نفسها في جميع سير العمل (workflows) والبيئات.

ماذا يعني ذلك

على قادة الهندسة (engineering leaders) أن يطرحوا الأسئلة الصحيحة: هل تتطلب الأداة ضوابط بمستوى المؤسسات (enterprise-level)؟ وهل سيعمل نموذج الأمان حين لا يراقب أحد؟ فمرونة النموذج ودعم العمل دون اتصال مهمان، لكن بنية الحوكمة الكامنة تحتهما هي التي تحسم ما إذا كان بإمكانكم تشغيل هذه الأداة في بيئة الإنتاج (production).