الذكاء الاصطناعي الوكيلي لا ينشئ عادةً نسخًا احتياطية قبل التصرف

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

واليوم، أثار تعاون أكاديمي جديد من الولايات المتحدة ذلك الشعور الذي يقشعر له البدن؛ إذ بحث في مدى إحراق نماذج الذكاء الاصطناعي الوكيلي المتقدمة جسورها قبل اتخاذ إجراءات ضارة، وبسرعة تفوق ما تحتاج إليه لكتابة «توقّف!» (تلميح: أبقِ الكلمة جاهزة في الحافظة).

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

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

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

لا شك في أن أليكسي غريغورييف، مؤسس منصة DataTalks.Club التعليمية، كان سيقدّر نهجًا أكثر ترويًا وحذرًا؛ فقد حذف وكيل Claude Code الذي يستخدمه بنية الإنتاج التحتية ونسخها الاحتياطية أثناء نقل الخوادم في مارس الماضي، ما أدى إلى فقدان بيانات الموقع الإلكتروني الممتدة على مدار عامين ونصف.

ومن الحوادث الحديثة الأخرى التي تجسد تهور الوكلاء على هذا النحو، حذف وكيل Cursor قاعدة بيانات الإنتاج ونسخها الاحتياطية لدى PocketOS، مزوّد برمجيات تأجير السيارات، في أبريل، ما عطل حجوزات العملاء لأكثر من يومين؛ وقيام وكيل البريد الإلكتروني OpenClaw بحذف رسائل من صندوق الوارد لدى أحد باحثي Meta AI في فبراير، رغم تكرار التعليمات الموجهة إليه بالتوقف.

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

تمهّل قليلًا

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

لمحة عن مشكلة النسخ الاحتياطي التي تناولتها الدراسة والحل المقترح. في 205 سيناريوهات، لم تنشئ ستة نماذج متقدمة من الذكاء الاصطناعي نسخًا احتياطية للحالة الحرجة إلا في 15.2% من المهام. أما نظام BackUpper الذي ابتكره الباحثون، فقد غطّى جميع الإجراءات الحرجة، وبلغ متوسط تشابه البيانات المستعادة مع الأصل 92.2% (انظر أدناه لمعرفة سبب صعوبة بلوغ نسبة 100%).

من أبرز ما كشفته الدراسة الجديدة مدى إغفال النماذج المتقدمة إنشاء نسخ احتياطية قبل الإقدام على إجراءات قد تنطوي على مخاطر. ووجد الباحثون أن GPT-5.6-Terra أنشأ نسخًا احتياطية للبيانات الحرجة في 4.4% فقط من الحالات؛ وأن النسبة لم تتجاوز 5.9% لدى GPT-5.6-Sol في الحالات المختبرة؛ بينما بلغت 2.4% فقط لدى Gemini 3.7-Flash.

حتى أفضل النماذج أداءً، Claude Opus-5، لم ينشئ نسخًا احتياطية للبيانات الحرجة في أكثر من ثلث الحالات المختبرة.

وجاء في الورقة البحثية^†:

«يُنجز الوكلاء، في المتوسط، 86.1% من المهام عبر ستة نماذج متقدمة، لكنهم لا يحفظون نسخة احتياطية من الحالة قبل لحظات الندم إلا في 15.2% من الحالات. ولا يفعل GPT 5.6-Sol في Codex ذلك إلا في 5.9% من المهام، بينما لا تتجاوز النسبة 2.9% لدى DeepSeek V4-Pro في Hermes.

«تُظهر هذه النتائج أن وعي الوكلاء الحاليين بأهمية النسخ الاحتياطي لا يزال محدودًا، وأنهم بحاجة إلى دعم مخصص لإنشاء النسخ الاحتياطية».

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

في العمليات اليومية، مثل ترقية البرامج، يتبع النظام مجموعة من القواعد البسيطة؛ أما في الحالات الأكثر تعقيدًا، فيستعين بنموذج ذكاء اصطناعي أصغر لتحديد ما ينبغي حفظه.

في الاختبارات، غطّى BackUpper جميع الإجراءات الحرجة، وكانت البيانات المستعادة مطابقة للأصل بنسبة 92.2%، مقابل تكلفة إضافية قدرها 0.014 دولار لكل مهمة؛ وهي تكلفة ليست كبيرة في هذا السياق، لكنها تمثل إنفاقًا كبيرًا على نماذج اللغة الكبيرة المتقدمة التي تخدم مليارات العملاء. ولعل هذا ما يجعل الاستعانة بخدمة خارجية من هذا النوع، أو تضمين هذه الإمكانية في أطر العمل نفسها، سبيلًا أرجح لتحسين الوضع، بدلًا من انتظار إصلاح أصيل من عمالقة التقنية (الذين يُتوقع منهم منطقيًا تمرير التكاليف الإضافية إلى المستهلكين، إما عبر رفع الأسعار أو تضخم عدد الرموز).

يستند هذا الإطار إلى RegretBench، وهو معيار يضم 205 مهام، بُني على حالات واقعية فقد فيها أشخاص بيانات تمنوا لاحقًا لو أنهم احتفظوا بها. ويختبر ما إذا كانت وكلاء الذكاء الاصطناعي تستبق الأحداث وتحافظ على تلك البيانات قبل إجراء تغييرات قد يتعذر التراجع عنها. واستُقيت الوقائع التي تضمها المجموعة من نقاشات وتقارير منشورة على الإنترنت، على منصات منها X.com وGitHub وStack Overflow.

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

قد تبدو نسبة 92% محبطة لمن يسعى إلى الكمال، لكن المؤلفين يشيرون إلى وجود عقبات تقنية تحول دون استعادة بعض أنواع البيانات:

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

في الاختبارات، أمكن استعادة حالة مطابقة للأصل بنسبة 33.8% بعد وقوع الضرر بالفعل، مقارنةً بنسبة 14.3% فقط من دون استعادة.

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

يدعم BackUpper كلًا من Claude Code وCodex وHermes وOpenHands وDeepSeek Harness وOpenClaw؛ وقد أتاح المؤلفون الكود، إلى جانب مجموعة البيانات المرتبطة به (لكن يجب تقديم طلب للحصول على إذن بذلك عبر نموذج)؛ كما تتوفر معلومات إضافية قليلة، إلى جانب فيديو توضيحي قصير جدًا وبسيط، على موقع المبادرة.

المنهجية

عند إعداد RegretBench، استُبعد عمدًا ما كانت أنظمة النسخ الاحتياطي المدمجة في الوكلاء تحميه من البيانات، ليتسنى اختبار مدى إدراك الوكلاء أنفسهم لموعد إنشاء نسخة احتياطية. ثم جُمعت سيناريوهات الاختبار بمساعدة Claude Opus-5 وGPT-5.6-Sol، وخضعت لمراجعة يدوية للتأكد من أنها تعمل وتعكس الوقائع الأصلية بدقة.

تغطي اختبارات RegretBench البالغ عددها 205 خمسة مجالات: عمليات الطرفية؛ وقواعد البيانات؛ وتطبيقات الويب؛ والبريد الإلكتروني؛ وعمليات التطوير والتشغيل. وتأتي الوقائع نفسها أساسًا من منصات تطوير البرمجيات والإنتاجية (44.4%)؛ والنقاشات الاجتماعية أو المجتمعية (39%)؛ والأرشيفات والتقارير الإعلامية (16.6%):

مصادر الوقائع الواقعية التي يستند إليها RegretBench، موزعة على ثلاث فئات. 

النماذج المتقدمة الستة التي خضعت للتقييم هي Claude Opus-5 وClaude Sonnet-5 ضمن Claude Code؛ وGPT-5.6-Sol وGPT-5.6-Terra ضمن Codex؛ وGemini 3.7-Flash وDeepSeek V4-Pro ضمن Hermes.

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

استُخدم حكمان يعملان بالذكاء الاصطناعي، وكلاهما مدعوم بنموذج Claude Sonnet-5، لتقييم الأداء. وحُسب معدل اجتياز المهام (PR) بناءً على نسبة المهام التي نُفذت فيها جميع طلبات المستخدم. ولتقييم النسخ الاحتياطي، جرى التحقق من كل تعديل خارج مساحة العمل (OOW) للتأكد من حفظ معلومات كافية مسبقًا تتيح استعادة البيانات.

شملت مقاييس النسخ الاحتياطي Regret Moment Backup Rate (RMBR)، الذي يعكس الإجراءات المحددة المرتبطة بحالات فقدان البيانات الموثقة؛ وOut-of-Workspace Backup Rate (OWBR)، الذي يعكس جميع التغييرات المنفذة خارج دليل عمل الوكيل.

جرى أيضًا التحقق من تقييمات محكِّم النسخ الاحتياطي بمقارنتها بتعليقات بشرية، وبلغت نسبة الاتفاق 95.3%.

النتائج

للتحقق مما إذا كان ضعف الوعي بالنسخ الاحتياطي ناجمًا عن نماذج الذكاء الاصطناعي أم عن الأُطر التي تشغّلها، جرى أولًا تقييم Claude Opus-5 وGPT-5.6-Sol وDeepSeek V4-Pro، كلٌّ على حدة، باستخدام 60 مهمة من RegretBench ضمن Claude Code وCodex وHermes.

لم تختلف كثيرًا نسبة المهام التي نُسخت فيها البيانات المهمة احتياطيًا بين الأُطر، ما يشير إلى أن المسؤولية تقع أساسًا على النماذج نفسها. كما دُرس الارتباط بين القدرات العامة للذكاء الاصطناعي والوعي بالنسخ الاحتياطي باستخدام GPT-5.4 وGPT-5.5 وGPT-5.6-Sol.

على الرغم من التحسينات المتتالية في القدرات العامة، لم يُسجَّل تحسّن مماثل في الوعي بالنسخ الاحتياطي:

نتائج اختبار RegretBench لستة نماذج من الذكاء الاصطناعي. إلى اليسار: معدلات إنجاز المهام مقارنةً بنسبة الإجراءات المهمة التي نُسخت احتياطيًا مسبقًا، ما يكشف عن معدلات نجاح مرتفعة، لكن عن وعي محدود بالنسخ الاحتياطي لدى معظم النماذج. إلى اليمين: متوسط عدد استدعاءات الأدوات لكل مهمة، مع إبراز عمليات النسخ الاحتياطي باللون الأزرق. حقق Claude Opus-5 أعلى معدل للنسخ الاحتياطي، لكن 8.9% من استدعاءاته للأدوات خُصصت للنسخ الاحتياطي.

كما دُرس الارتباط بين القدرات العامة للذكاء الاصطناعي والوعي بالنسخ الاحتياطي باستخدام GPT-5.4 وGPT-5.5 وGPT-5.6-Sol. وعلى الرغم من التحسينات المتتالية في القدرات العامة، لم يظهر تحسّن مقابل في الوعي بالنسخ الاحتياطي.

BackUpper

يوفر BackUpper أربع طبقات من الحماية، تختلف كل منها في مقدار الموارد التي تتطلبها: تستبدل الطبقة الأولى الأوامر المدمرة ببدائل قابلة للتراجع، مثل نقل الملفات إلى سلة المهملات؛ وتقرن الطبقة الثانية العمليات بأوامر النسخ الاحتياطي، مثل تسجيل إصدارات الحزم قبل ترقيتها؛ وتنشئ الطبقة الثالثة لقطات من ملفات مساحة العمل المتأثرة؛ أما الطبقة الرابعة فتستخدم وكيلًا فرعيًا من GPT-5.6-Luna لتحديد البيانات المتأثرة بالعمليات الأكثر تعقيدًا وحفظها.

عند تفعيل BackUpper، شمل النسخ الاحتياطي كل إجراء يغيّر الحالة في النماذج الستة جميعها، مقارنةً بمتوسط معدلات نسخ احتياطي بلغ 15.2% للإجراءات المهمة و17.4% للتغييرات الأخرى من دونه:

تغطية النسخ الاحتياطي ونتائج الاستعادة باستخدام BackUpper. إلى اليسار: تُظهر الأشرطة الزرقاء والبرتقالية معدلات النسخ الاحتياطي لكل نموذج للإجراءات المهمة وللتغييرات الأخرى خارج مساحة العمل. وتشير الحدود المتقطعة باللون الأخضر الداكن إلى دقة الاستعادة، فيما تُظهر الحدود المنقطة باللون الأخضر الفاتح تغطية كاملة للنسخ الاحتياطي بنسبة 100% باستخدام BackUpper. إلى اليمين: مقارنة دقة الاستعادة عبر خمس فئات من الأدوات باستخدام BackUpper (بالأخضر)، والاستعادة لاحقًا باستخدام Claude Opus-5 (بالبنفسجي)، وعدم الاستعادة (بالرمادي). حقق BackUpper أعلى دقة في جميع الحالات.

أكد المراجعون البشريون نجاح 94% من النسخ الاحتياطية التي قيّمها المقيم الآلي على أنها ناجحة.

استُعيدت الحالة الأصلية بمتوسط تشابه بلغ 92.2%، مقارنةً بـ33.8% باستخدام Claude Opus-5، و14.3% من دون استعادة (انظر الصورة أعلاه). وعُزي معظم ما تبقى من اختلافات إلى المعرّفات التي أُنشئت مجددًا والبيانات الوصفية البسيطة، بما فيها مؤشرات قراءة رسائل البريد الإلكتروني، كما ذُكر سابقًا.

هل تفعلها بنفسك..؟

عندما أُعطيت الوكلاء تعليمات مفصلة لإنشاء نسخ احتياطية بأنفسهم، حُميت 81.4% من الإجراءات المهمة، مقارنةً بـ100% باستخدام BackUpper. وعُزي ثلاثة أرباع حالات الإخفاق إلى أن النسخ الاحتياطية لم تتضمن معلومات كافية للاستعادة.

مقارنة معدلات النسخ الاحتياطي عبر خمسة أساليب، اختُبرت على 205 مهام باستخدام ستة نماذج من الذكاء الاصطناعي. يوضح المخطط الأيسر النسخ الاحتياطية التي أُنشئت قبل تنفيذ إجراءات ندم المستخدمون عليها لاحقًا؛ أما المخطط الأيمن فيوضح حماية التغييرات الأخرى خارج مساحة العمل. حقق BackUpper تغطية كاملة في الفئتين، مقارنةً بـ81.4% و80.5% عندما زُوّدت الوكلاء بتعليمات مفصلة للنسخ الاحتياطي.

مع التخزين المؤقت للمطالبات، انخفضت تكلفة النسخ الاحتياطي لكل مهمة من 0.344 دولار إلى 0.014 دولار، كما انخفض زمن الاستجابة بنسبة 31.7%. واحتاجت العملية إلى عدد من الرموز أقل بسبعة أضعاف، ويُعزى ذلك إلى حد كبير إلى تنفيذ العمليات الروتينية من دون مساعدة الذكاء الاصطناعي.

في 40 مهمة إضافية من Terminal-Bench 4 وDeepSWE، تحققت تغطية للنسخ الاحتياطي بنسبة 100% باستخدام GPT-5.6-Sol وClaude Opus-5، من دون خفض معدلات إنجاز المهام.

كانت سياسات النسخ الاحتياطي الانتقائية الثلاث التي خضعت للتقييم هي التغييرات عالية التأثير، للتغييرات المهمة؛ وما يتجاوز الطلب، للتغييرات الخارجة عن تعليمات المستخدم؛ والعمل البشري، للمواد التي ألّفها البشر. وبلغ متوسط درجة F1 هنا 84.5% مقارنةً بأحكام البشر.

اختُبر BackUpper أيضًا لمعرفة مدى قدرته على تعلّم قواعد قابلة لإعادة الاستخدام للنسخ الاحتياطي. وبعد 30 مهمة طرفية إضافية، ارتفعت التغطية القائمة على القواعد من 14.9% إلى 31.2%، ما قلّل الاعتماد على الوكيل الفرعي GPT-5.6-Luna.

الخلاصة

بدأتُ خوض تجارب الذكاء الاصطناعي الوكيل متأخرًا عما ينبغي، بالنظر إلى طبيعة عملي؛ لكن الحالة التي تسبق ألفا بوضوح لضبط الذكاء الاصطناعي الوكيل لنفسه أخافتني وأبعدتني إلى أن قررت قبل بضعة أسابيع أخيرًا إطلاق العنان لـCodex داخل جهاز افتراضي يعمل بنظام Windows.

حتى في بيئة الجهاز الافتراضي، أحدد نطاق تعليماتي بعناية شديدة، مدركًا ميل Astra إلى الاندفاع بلا تروٍّ، والاكتفاء بتقديم الاعتذارات حين لا يعود ثمة سبيل للتراجع عن فقدان البيانات أو إفساد الشيفرة؛ ويتضمن جزء من إطار عمل Python الذي أعمل على تطويره هناك وظيفةً تدريجيةً بنقرة واحدة «حفظ ملف ‎.7z على مجلد مشترك عبر الشبكة» تضغط إطار العمل بأكمله وتُنشئ له نسخة احتياطية، وأستخدمها مرارًا.

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

* بعنوان خذ نسخة احتياطية قبل أن تندم: قياس الوعي بالنسخ الاحتياطي وأتمتته لدى وكلاء البرمجة.

^† التشديد من المؤلفين لا مني؛ أما أي روابط تشعبية، فقد أضفتها استنادًا إلى الاستشهادات الواردة في النص.

نُشر لأول مرة يوم الخميس 22 أكتوبر 2026