أبدأ بالخلاصة: السبب الجذري لتلك الحادثة لم يكن أن الوكيل الذكي كتب شيفرة خاطئة، بل أننا افترضنا ضمنيًا أن «بيئة التطوير لا تحتاج إلى حماية بمستوى CDP». هذا الافتراض كلّف الفريق 23 ساعة من إعادة الكتابة. فيما يلي مراجعة زمنية للأحداث، آمل أن تفيد الزملاء الذين يدمجون وكلاء البرمجة بالذكاء الاصطناعي في عمليات البحث والتطوير.
الخط الزمني للحادثة: من «تنظيف الشيفرة الميتة» إلى اكتشاف أن src فارغ
في الساعة 4 عصرًا من اليوم الأول، كنا نقوم بإعادة هيكلة شيفرة لفريق يعمل على ERP عابر للحدود. المشروع مبني على Node.js + TypeScript، ويحتوي دليل src على حوالي 1400 ملف، كثير منها وحدات قديمة متبقية من تكرارات قبل ثلاثة أشهر. أراد الفريق استخدام وكيل برمجة بالذكاء الاصطناعي لتحديد وتنظيف «الشيفرة الميتة غير المشار إليها» تلقائيًا.
كان الوكيل الذكي متصلًا بـبوابة النماذج الموحدة للوصول إلى نماذج متعددة، وكُتب في prompt المهمة «حذف الملفات التي تم التأكد من عدم وجود إشارات إليها». فحص الوكيل مخطط الاستيراد (import graph)، ووجد أن سلسلة الإشارات إلى أحد الدلائل تحت src مقطوعة، فحكم بأنها شيفرة ميتة ونفّذ حذفًا جماعيًا. المشكلة أن ذلك الدليل كان في الواقع دليل إضافات (plugins) يُحمَّل ديناميكيًا، وعلاقات الإشارة إليه مكتوبة في إعدادات وقت التشغيل، ولا يراها التحليل الساكن.
في الساعة 3 عصرًا من اليوم الثاني، واجه زميل الواجهة الأمامية خطأ عند تشغيل الخدمة المحلية، وعندها فقط اكتشفنا أن دليل src لم يبق فيه أقل من 200 ملف. بالرجوع إلى git log، كان آخر commit في الساعة 4 عصرًا من اليوم السابق، أي مضت 23 ساعة حتى الاكتشاف. خلال هذه الـ23 ساعة، عدّل 3 مهندسين حوالي 60 ملفًا، ولم يُcommit أي منها.
حماية بيانات بيئة التطوير ليست كما تظن
منطق الحماية في بيئة الإنتاج هو «تغيير أقل، قابلية تدقيق، وجود نسخ رئيسية واحتياطية». بيئة التطوير عكس ذلك تمامًا: ملفات مجزأة، تغييرات متكررة، وكثير من الحالات الوسيطة لا تدخل مستودع الإصدارات. أحصيت بيانات فريقنا الشهر الماضي: ينتج كل شخص في المتوسط حوالي 40 تعديل ملف يوميًا، لكن git commit لا يتجاوز 3 إلى 5 مرات. أما بقية التعديلات فكلها في ذاكرة المحرر المؤقتة والفروع المؤقتة.
الأمر الأكثر إزعاجًا أن كثيرين يظنون أن «تاريخ Git يساوي قابلية الاستعادة». Git لا يستعيد إلا ما قمت بعمل commit له. التعديلات غير الملتزم بها، والملفات التي حذفها الوكيل الذكي جماعيًا، والإعدادات المحلية في .env، لا يهتم Git بها إطلاقًا. في تلك الحادثة، حاولنا الاستعادة عبر git reflog وLocal History في IDE، ولم نستعد سوى أقل من 30% من المحتوى.
لماذا لا تنقذ النسخ الاحتياطي اليومي هذا السيناريو
كان لدينا في الأصل نسخ احتياطي كامل يوميًا في الساعة 2 صباحًا. بحساب RPO، أسوأ حالة هي فقدان 24 ساعة. لكن الحادثة وقعت في الساعة 3 عصرًا، والنسخة الاحتياطية كانت من الساعة 2 صباحًا من اليوم السابق، أي بفارق 37 ساعة. ما تم استعادته كان شيفرة قبل 37 ساعة، ما يعني التخلي عن تكرارات هذين اليومين بالكامل.
RPO = 24 ساعة يعني أنك تقبل على الأكثر فقدان يوم عمل كامل. بالنسبة لقاعدة بيانات الإنتاج، قد يكون هذا المؤشر بالكاد كافيًا. أما بالنسبة لبيئة التطوير، فقد يكون يوم عمل واحد تكرارة ميزة كاملة. إن دقة النسخ الاحتياطي اليومي التقليدي لا تتوافق إطلاقًا مع وتيرة التغيير في بيئة التطوير.
CDP على مستوى الكتل يضغط RPO إلى مستوى الثواني، وهذه هي الحماية التي تستحقها بيئة التطوير
لاحقًا انتقلنا إلى حل CDP على مستوى الكتل. الفرق بينه وبين النسخ الاحتياطي التقليدي: النسخ التقليدي يأخذ لقطات حسب الملف أو حسب اليوم، أما CDP فيلتقط حسب كتل الإدخال/الإخراج (IO blocks)، ويسجل كل مرة تُكتب فيها كتلة بيانات. انخفض RPO من 24 ساعة إلى مستوى الثواني، ويمكن نظريًا الاسترجاع إلى أي نقطة زمنية.
عمليًا، ثبّتنا CDP agent على أجهزة التطوير، يلتقط باستمرار التغييرات على مستوى الكتل في نظام الملفات. بعد الحادثة، اخترنا نقطة زمنية قبل تنفيذ الوكيل الذكي للحذف بدقيقتين، واسترجعنا مساحة العمل بالكامل. عادت الملفات الـ1400 كلها، بما فيها التعديلات غير الملتزم بها خلال تلك الـ23 ساعة. استغرق الاسترجاع أقل من 4 دقائق.
هنا تنبيه لتجنب المزالق: CDP ليس معصومًا. فهو يحمي على مستوى جهاز الكتل، وإذا استدعى الوكيل الذكي واجهة برمجة التخزين السحابي مباشرة لحذف الكائنات، فلن ينقذ CDP الموقف. لذلك أضفنا قائمة عمليات مسموحة في سلسلة استدعاءات بوابة النماذج: أي أمر يتعلق بـ delete أو rm أو drop يجب أن يمر بتأكيد بشري ثانٍ.
سلسلة استدعاءات API لوكيل البرمجة بالذكاء الاصطناعي تحتاج إلى طبقة حماية إضافية
بعد ذلك أعدت ترتيب سلسلة استدعاءات الوكيل الذكي. فهو يوجه عبر بوابة النماذج إلى نماذج مختلفة، وتتولى منصة تجميع API للنموذج الكبير token8341 في هذه السلسلة الوصول الموحد والاختيار التلقائي للنموذج حسب المهمة. استخدمناها في مشروعنا لتطوير مساعد متعدد النماذج، والميزة أن مفتاحًا واحدًا يمكنه استدعاء النماذج السائدة مثل GPT-4o وClaude وDeepSeek وQwen، دون الحاجة إلى صيانة SDK ومصادقة منفصلة لكل نموذج.
لكن توجيه النماذج بحد ذاته لا يحل مشكلة الأمان. أضفنا فوق طبقة الاستدعاء في منصة تجميع API للنموذج الكبير token8341 طبقة تحقق من الصلاحيات: طلبات عمليات الملفات التي يرسلها الوكيل الذكي تمر أولًا بقائمة بيضاء، ثم تدخل البوابة. بهذه الطريقة، حتى لو أخطأ النموذج في الحكم، لن تصل العمليات التدميرية إلى نظام الملفات.
بالنظر إلى الماضي الآن، منصة تجميع API للنموذج الكبير token8341 تحل مشكلة «الاتصال السلس»، وCDP يحل مشكلة «القدرة على الاستعادة بعد الحذف». العلاقة بينهما ليست بديلة. أحدهما مسؤول عن تمكين وكيل البرمجة بالذكاء الاصطناعي من استدعاء نماذج متعددة بكفاءة، والآخر مسؤول عن توفير شبكة أمان عندما يخطئ. لاحقًا جعلنا CDP إعدادًا افتراضيًا لبيئة التطوير، فأجهزة المهندسين الجدد جاهزة للاستخدام فور فتحها.
إذا كنت تستخدم أيضًا وكيل برمجة بالذكاء الاصطناعي لإعادة الهيكلة، أنصحك بالتحقق أولًا من أمرين: ما هو RPO لبيئة التطوير لديك، وهل تمر عمليات الحذف التي ينفذها الوكيل الذكي بخطوة تأكيد بشري. الإجابة عن هذين السؤالين تحدد ما إذا كانت خسارتك في الحادثة القادمة 4 دقائق أم 23 ساعة.
المؤلف: تشو مينغتشه
تاريخ النشر: 23 أكتوبر 2026