قام مساعد برمجة مدعوم بالذكاء الاصطناعي يعمل ضمن طابور خادم من الفئة المجانية بكتابة ملف ترحيل المخطط (schema-migration) بعد أن اختفت قاعدة "تجميد عمليات الترحيل" (freeze migrations) الخاصة بالنظام أثناء عملية ضغط السياق التلقائي. يوضح هذا الحادث أن الاعتماد على التعليمات القائمة على الأوامر (prompts) لفرض السلامة قد يؤدي إلى نتائج عكسية عندما يتم تلخيص جلسات الدردشة الطويلة.
ماذا حدث
عمل وكيل برمجة مشترك باستخدام أمر نظام (system prompt) يحتوي على قاعدة واحدة: عدم إنشاء أو تعديل ملفات الترحيل (migration files). حافظت هذه القاعدة على تجميد عمليات ترحيل المخطط في فرع الإصدار (release branch) بينما استخدم المطورون الوكيل لإجراء تعديلات روتينية.
خلال جلسة مطولة، تجاوزت المحادثة حد الرموز (token limit) الخاص بالنموذج. استدعى الخادم عملية ضغط السياق (context compaction)، مستبدلاً سجل الدردشة الكامل بملخص قصير للبقاء ضمن ميزانية الرموز. احتفظ الملخص بذكر مسارات الملفات ولكنه حذف القيد السلبي ("do not write to migrations/**"). عندما أنشأ النموذج استجابته التالية، لم تعد قاعدة التجميد موجودة في ذاكرته العاملة.
اقترح الوكيل بعد ذلك تعديلاً في SQL لتحسين سرعة الاستعلام. وقامت الأداة المرافقة بحفظ التغيير كملف ترحيل على القرص. اجتازت اختبارات الوحدة (Unit tests) لأنها لا تنفذ أبداً عمليات ترحيل SQL الخام، ولم يتم اكتشاف التعديل إلا لاحقاً في مقارنة مراجعة الكود (code-review diff).
لماذا يهم هذا الأمر
- اختفاء الحواجز الوقائية (Guardrails): السياسات على مستوى الأوامر (Prompt-level) متقلبة. عندما يتم ضغط سياق النموذج، يمكن فقدان أي بند يبدأ بـ "لا تفعل"، مما يترك النظام حراً في تنفيذ إجراءات محظورة.
- اختبارات الوحدة ليست كافية: الاختبارات التي لا تشغل سكربتات الترحيل قد تعطي شعوراً زائفاً بالأمان. تسلل التغيير لأن مجموعة الاختبارات لم تقم أبداً بتجربة كود SQL الجديد.
- تأخر المراجعة البشرية: بحلول الوقت الذي رأى فيه المراجع الفرق (diff)، كان ملف الترحيل قد تم اعتماده (committed) بالفعل، مما تطلب عملية تراجع (rollback) أو تنظيفاً إضافياً.
لم يتسبب الخطأ في انقطاع الخدمة، لكنه فرض عملاً إضافياً للتراجع عن ترحيل غير ضروري ورفع خطر وقوع خطأ مماثل يؤثر على قواعد البيانات الحية.
كيف فشل الحاجز الوقائي
- قاعدة تعتمد على الأوامر فقط – كانت قاعدة التجميد موجودة كنص عادي في أمر النظام.
- جلسة طويلة – نمت الدردشة لتتجاوز نافذة سياق النموذج.
- الضغط (Compaction) – استبدل الخادم النص الكامل بملخص غني بالأسماء.
- فقدان القيد السلبي – أغفل الملخص تعليمات "لا تفعل"، مما أدى إلى محو القاعدة.
- مخرجات النموذج – بدون القاعدة، أنشأ النموذج استجابة تؤدي لإنشاء ملف ترحيل.
تميل أدوات التلخيص إلى الاحتفاظ بالأسماء (مسارات الملفات، أسماء الدوال) وحذف النفي، وهذا هو السبب في اختفاء القاعدة بصمت.
الحل: نقل الحواجز الوقائية إلى مسار الكتابة
بدلاً من تضمين المحظورات في الأمر (prompt)، قم بفرضها حيث يلمس الكود القرص.
- إنشاء ملف سياسة (مثل
agent_policy.txt) يسرد المسارات المحظورة مثلschema/**أوmigrations/**. - إضافة سكربت ما قبل التطبيق (pre-apply script) يقرأ ملف السياسة ويفحص كل "فرق" (diff) قبل تشغيل أداة التطبيق.
- الفشل عند الإغلاق (Fail closed) إذا كان ملف السياسة مفقوداً، أو فارغاً، أو إذا لمس "الفرق" مساراً محظوراً.
- لا تطلب من النموذج التأكيد على قائمة المحظورات؛ فالتأكيد هو مجرد إشارة وليس وسيلة فرض.
التجميد القائم على الأوامر فقط مقابل الحواجز القائمة على القرص
| الجانب | التجميد القائم على الأوامر فقط | البوابة القائمة على القرص |
|---|---|---|
| خطر الضغط | يمكن أن تختفي القاعدة | يظل ملف السياسة سليماً |
| تغطية اختبار الوحدة | قد تفشل في اكتشاف الكتابات المحظورة | فحص المسار يمنع الكتابة بغض النظر عن الاختبارات |
| توقيت المراجعة البشرية | قد يكون الضرر قد تم اعتماده بالفعل | لا تبدأ الكتابة أبداً، ولا يرى المراجع أي تغيير |
| جهد التنفيذ | ضئيل (مجرد سطر في الأمر) | سكربت صغير + ملف سياسة |
وجهة نظر معارضة
ما يجب مراقبته لاحقاً
الخلاصة
إذا كنت بحاجة إلى قاعدة يجب عدم تجاهلها أبداً — مثل "لا ترحيلات أثناء التجميد" — فقم بتخزينها على القرص وفرضها عند نقطة الكتابة. لا يمكن لنص الأمر وحده ضمان الديمومة بمجرد ضغط سياق النموذج.