انهيار حاد! حتى أقوى الذكاء الاصطناعي لا يمكنه التعامل مع التطوير طويل الأمد: كلما زادت كمية الشفرات، انهار النظام بسرعة أكبر

交易股票 فقط راجع محلل شركة جين كيلينغ لقراءة تقارير المحللين؛ موثوقة، احترافية، في الوقت المناسب، شاملة—يساعدك على اكتشاف فرص مواضيع كامنة!

（المصدر：DeepTech ديب تك）

اكتب دالة، والذكاء الاصطناعي شبه لا يُهزم؛ لكن لماذا ينهار نظام ما بعد ذلك؟ ولماذا يبدأ AI بالانهيار؟

في الوقت الراهن، دخلت الذكاء الاصطناعي بالفعل إلى “النصف الثاني”. مع التحسن المستمر في قدرات البرمجة لدى AI، بدأت منتجات مثل OpenClaw بالظهور تدريجيًا، و”CLI everything” باتت تتحقق؛ أي إن AI لا يحتاج إلى تشغيل الكمبيوتر، بل يحول جميع الواجهات إلى واجهة سطر الأوامر (CLI)، فتتحول مهارة بعد أخرى إلى وظائف برمجية.

الآن، لم يعد الـ Agent مجرد أداة محادثة لتنفيذ مهمة واحدة، بل هو يتطور إلى نظام يقوم بتشغيل طويل الأمد، والتفاعل مع العالم الحقيقي، وتنفيذ مهام معقدة. ومع ذلك، ظهر سؤال جديد: خلال التطور المستمر، هل يستطيع AI التكيف مع بيئات جديدة والحفاظ على ثبات قدرات التطوير؟

ذكرت ياو شونيو، كبير علماء الذكاء الاصطناعي في مكتب الرئيس/المدير التنفيذي في Tencent، في مدونة بعنوان The Second Half، أن مهام البرمجة الحقيقية تعتمد بشكل متواصل على بعضها وليست مهامًا مستقلة بالتوازي. لكن في الوقت الحالي لا توجد في الأوساط الأكاديمية معايير من هذا النوع لتقييم القدرات التي يحتاجها AI في هذا السيناريو، بل وحتى يفتقر المجتمع إلى الشجاعة لكسر افتراض استقلال المهام عن بعض—وهو افتراض تم قبوله على نطاق واسع منذ زمن طويل بهدف تبسيط المشكلات.

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

أظهرت النتائج أن أفضل AI يستطيع الأداء بشكل ممتاز في المهام المستقلة للتقييم (يحصل على 80%+). لكن بمجرد دخوله سيناريو واقعي طويل الأمد، وحتى Claude Opus 4.6 ذو أعلى مجموع نقاط—فإنه يحصل فقط على 38.03%. وهذا يعني أن AI يميل إلى الانحراف عن المسار عند تنفيذ مهام تكون فيها درجة الحرية أعلى؛ ولا يزال هناك فجوة كبيرة بينه وبين القدرة الفعلية على التعامل مع التطور البرمجي طويل الأمد والمستمر.

（المصدر：arXiv）

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

تحت عنوان ورقة البحث: «EvoClaw：مقياس تقييم لوكلاء ذكاء اصطناعي للتطور البرمجي المستمر»（EvoClaw: Evaluating AI Agents on Continuous Software Evolution）، نُشرت مؤخرًا على موقع arXiv[1] كنسخة ما قبل النشر.

شكل丨 الورقة البحثية ذات الصلة（المصدر：arXiv）

لماذا تفشل تقييمات البرمجة لدى AI الحالية وتفشل أمام التجربة الواقعية—أين تكمن المشكلة؟

لماذا تفشل بشكل جماعي النماذج الرائدة التي تحصل على درجات عالية في التقييمات المستقلة ضمن اختبار EvoClaw؟ تكمن الجذور في تغيير نمط التقييم.

في الدراسات السابقة، ركزت معظم معايير تقييم البرمجة السائدة (benchmark) على مهام مستقلة: إعطاء قضية (issue) أو طلب سحب (PR، Pull Request)، ثم يقوم النموذج بإصلاح لقطة ثابتة من الشفرة، وبعد اجتياز التحقق تعتبر المهمة مكتملة وينتهي التقييم.

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

（المصدر：arXiv）

قال دنغ غانغدا، طالب دكتوراه في جامعة جنوب كاليفورنيا والمؤلف الأول للورقة، لـ DeepTech: «حجم commit والإصدار (release) الحالية—إما أنها صغيرة جدًا أو خشنة جدًا. لذلك فإن سجل التطوير هذا لا يعكس عملية تطور البرمجيات».

شكل丨 دنغ غانغدا（المصدر：المقابَل）

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

（المصدر：arXiv）

ولكي يدعم الفريق استخراج تاريخ تطور برمجي عالي الجودة من عدد كبير من مستودعات الأكواد مفتوحة المصدر، اقترح الباحثون—بناءً على قدرات AI الرائدة القوية—خطًا آليًا تقوده Agents، يسمى DeepCommit. وقد تحقق لأول مرة إعادة بناء سجل تطوير Git المزعج إلى مخطط تبعيات مهام Milestone دقيق وقابل للتحقق ومتجانس وظيفيًا (Milestone DAG)، ولإنشاء بيئة تقييم لكل Milestone. يتضمن ذلك ثلاث مراحل رئيسية: معالجة مسبقة لتاريخ Git، وبناء DAG تقوده Agents، ثم تهيئة بيئة Milestone والتحقق.

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

وهذا يعني أنه عند تفكيك الترتيب الكامل للـ commit وإعادة تجميعه وربطه، قد تواجه حالات تعذر تطبيق الـ commit، وعدم تطابق الواجهات، وظهور أخطاء ترجمة واسعة النطاق. ولمعالجة هذه المشكلة، صمّم الباحثون حلقة إصلاح تكرارية: يقوم Agent بتحليل سجلات الأخطاء بشكل نشط، ويعدل Dockerfile ديناميكيًا لضمان قابلية التنفيذ.

والأهم من ذلك، أنه يضيف الاعتماديات الضمنية التي تم إغفالها بناءً على الـ DAG الأصلي؛ عبر ضبط علاقات القيود الخاصة بالـ Milestone من حيث الترتيب، يتم حل مشكلات تعارض الواجهات بشكل مناسب. وبعد تكرارات متواصلة، تم أخيرًا تحقيق تجميع صحيح لـ 87.1% من حالات الاختبار الأصلية.

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

شكل丨 مخطط بنية خط DeepCommit（المصدر：arXiv）

قام الباحثون بمقارنة مخطط التطور الذي ينشئه DeepCommit تلقائيًا مع الترميز اليدوي الذي يقوم به خبراء بشريون. وكان مما فاجأهم أن المنطق التنظيمي لكليهما مختلف ويكمل أحدهما الآخر.

على وجه التحديد، عادةً ما يحدد الـ Milestone لدى الخبراء البشر في نافذة زمنية محلية: يضعون الموضوع أولاً ثم يعيدون تجميع الـ submissions، وهي طريقة تقطيع دلالي من أعلى إلى أسفل؛ بينما يهدف DeepCommit إلى ضمان الدقة المطلقة، فمن علاقات الاعتماد بين commits ينطلق، ويعيد بناء مسار تطور البرمجيات من أسفل إلى أعلى، مع التركيز أكثر على البنية الطوبولوجية وقيود التنفيذ.

وبالنسبة للتقييم، هذا يوضح أن نقطة قوة DeepCommit تكمن في استخلاص بنية Milestone قابلة للتنفيذ وقابلة للتحقق من تاريخ تطوير الكود. ومن النتائج، يستطيع DeepCommit تصفية مهام Milestone عالية الجودة والمناسبة للتقييم، وكذلك تكون قابلة للتنفيذ والتحقق في البيئات الحقيقية، ما يوفر ضمانات لموثوقية التقييم.

بمجرد الدخول إلى التطوير الحقيقي، لماذا تنخفض درجات النموذج بشكل جماعي إلى النصف؟

يغطي EvoClaw خمس لغات برمجية سائدة، تشمل Python وJava وGo وRust وTypeScript. وتغطي المشاريع المختارة أطول دورة تطوير حقيقية تصل إلى 750 يومًا.

في مؤشرات التقييم، لم يستخدم فريق البحث معدل النجاح البسيط، بل قدم بُعدين أكثر جوهرية—الاسترجاع (Recall) والدقة (Precision)—مع احتساب الوزن وفق F1 كدرجة لكل Milestone. حيث يقيس الاسترجاع اكتمال تنفيذ الوظائف، بينما تلتقط الدقة مدى تدمير النموذج للكود الموجود سلفًا عند إضافة وظائف جديدة.

اختبر فريق البحث تركيبات متعددة من الأطر والنماذج مثل Claude Code وOpenHands. أظهرت النتائج أنه في التقييمات المستقلة، كانت درجات النماذج الرائدة غالبًا ضمن 80%-90%، لكن بعد إجراء اختبار EvoClaw انخفضت بشكل حاد جماعيًا. وفي ذلك، حصل Claude Opus 4.6 صاحب أعلى درجة فقط على 38.03%.

شكل丨 النتائج الرئيسية للتجارب في EvoClaw（المصدر：arXiv）

يحصل GPT 5.3 Codex على 28.88% فقط من الدرجة الإجمالية، وهو أقل من Opus4.6 وبالتالي في المركز الثاني. ومن حيث المستودعات، أظهر GPT 5.3 Codex أداءً أضعف في مشروعين Rust (Nushell وripgrep)، بينما في بقية المستودعات يمكن أن يقترب من Opus4.6 أو يتجاوزه. أما في نسبة الحل الكاملة، حتى Gemini 3 Pro الأعلى لا يتجاوز 13.37%، ومعظم ما يُنفذ بشكل صحيح هي مهام لا تحتوي على اعتماديات مسبقة تقريبًا.

وفقًا لما تم الإطلاع عليه، يتحكم الباحثون في إجمالي التكلفة ضمن نطاق معقول؛ على سبيل المثال، تبلغ تكلفة إجراء تقييم كامل واحد مع Claude Opus 4.5 حوالي 500 دولار. أما Kimi K2.5 وGemini 3 Flash فتبقيان التكلفة ضمن 50 دولارًا. وتكون تكلفة النماذج الصغيرة أقل.

（المصدر：arXiv）

فإذا أُعطي النموذج نافذة تطوير أطول، فهل سيتمكن أخيرًا من إكمال المشروع بنسبة 100%؟

تقدم الدراسة إجابة بالنفي: بغض النظر عن طول نافذة التطوير، ستصطدم جميع النماذج في النهاية بـ “سقف” (天花板). كلما جاء تنفيذ المهمة لاحقًا، وكلما كان مستوى الطبقة (DAG) أعمق، كلما انخفضت الدرجة ونسبة الحل. وتُثبت نتائج الاستقراء خارج الدالة المشبعة (saturation function extrapolation) أنه حتى Opus 4.6 الأفضل، ستظل الدرجة التراكمية محبوسة عند خط لا يتجاوز تقريبًا 45% كنقطة مقاربة.

«على الرغم من أن Opus 4.6 ذكر في موقع Anthropic الرسمي أنه يتفوق على 4.5 في مهام طويلة الأمد، إلا أنه لم يقدم مؤشرات تقييم تفصيلية. وEvoClaw يُعد تحققًا من زاوية أخرى من كلامهم.» قال دنغ غانغدا.

بالإضافة إلى ذلك، تم رصد فروق ملحوظة بين عائلات النماذج المختلفة في التجارب. تحديدًا، أداء Claude وGPT في سيناريو التطور المستمر يتحسن بثبات مع تحديث الإصدارات. ومن بين ذلك، يثبت Opus 4.6 في البرمجة طويلة الأمد أنه الأفضل في صيانة النظام؛ بينما GPT 5.3 ينخفض ترتيبه في المركز الثاني بسبب ضعف أدائه في مجموعة بيانات Rust.

（المصدر：arXiv）

الأكثر مفاجأة هو أن عائلة Gemini تُظهر اتجاهًا مختلفًا تمامًا: من 3 Flash إلى 3 Pro ثم إلى 3.1 Pro. كل جيل يبدأ أسرع في المراحل المبكرة ويقدم أداءً أفضل في البداية، لكن أداءه على المدى الطويل لا يتحسن بشكل ملحوظ. فسر دنغ غانغدا ذلك بقوله: «إن الانحدار الواضح لأداء Gemini في التشغيل طويل الأمد يعني أنه لا يسوء فقط في اتباع التعليمات، بل يتجاهل بشكل متزايد متطلبات مواصفات النظام للبرمجيات (SRS)، كما أنه يفتقر إلى القدرة على صيانة نظام البرمجيات الذي يقوم ببنائه».

عندما قام الباحثون بتفكيك الدرجة الإجمالية أكثر إلى Recall وPrecision ظهر نمط أكثر إثارة للاهتمام: الـ Recall يرتفع تقريبًا بشكل مستمر ويتجه نحو نمو خطي. وهذا يعني أنه حتى عندما تصبح قاعدة الكود أكثر فوضوية وأكثر هشاشة، يظل Agent قادرًا على تنفيذ أهداف الوظائف الجديدة المحددة حاليًا.

العائق الحقيقي في الـ Precision: فـ Agent يجد صعوبة في الحفاظ على النظام الحالي، إذ تتجاوز سرعة تراكم أخطاء العودة قدرته على إصلاح هذه المشكلات. وهذا هو السبب الجذري وراء توقف التطوير طويل الأمد في النهاية.

شكل丨 اليسار: رسم توضيحي لسلسلة الأخطاء؛ اليمين: توزيع سلاسل الأخطاء（المصدر：arXiv）

ولفهم السبب الجوهري وراء فقدان النماذج السيطرة أثناء التكرار، اقترح فريق البحث إطار تحليل سلاسل الأخطاء (Error Chains). تتبعوا كل اختبار بدءًا من أول مرة يحدث فيها خطأ، وراقبوا ما إذا كانت الأخطاء تُورث أو تنتشر أو تُتجاوز أو تُصلح في Milestones اللاحقة.

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

تقييم عام لتوفير أدوات Debug لـ AI Harness

في الآونة الأخيرة، ظهر مفهوم “Harness Engineering” الرائج جدًا، ويهدف إلى تهيئة كامل عملية تطوير البرمجيات لتناسب بيئات يمكن لـ Agent المشاركة فيها. يوفّر معيار EvoClaw اختبارًا تجريبيًا عامًا (playground) مناسبًا لتطوير الكود طويل الأمد وتقييم تطوره، وهو ملائم لتصحيح إطار AI Harness.

على سبيل المثال، حالات الفشل المذكورة في هذه الدراسة: إذا ظهر أن Agent يتصرف باندفاع في التكرار فجأة، أو يقوم باستمرار بتحرير الكود ثم التحقق منه، فمن المرجح أنه واجه صعوبات. في هذه الحالة، يمكن بناء حواجز حماية (护栏) في المواقع المقابلة لاكتشاف المشكلات مبكرًا والتدخل البشري في الوقت المناسب، وبالتالي تحسين الكفاءة.

وبما أن معماريات النموذج تمنح Agent طبيعة عامة تتمثل في أن “تنفيذ وظائف جديدة” أقوى من “الحفاظ على الوظائف القديمة طويلة الأمد”، فهل سيؤدي ذلك في المستقبل إلى ظهور أشكال برمجية وأنماط تطوير جديدة؟

على سبيل المثال، قد تؤكد البرمجيات أكثر على المرونة والتوافق، وتجرى تغييرات واسعة النطاق أكثر موثوقية وتتم إعادة تنظيمها؛ أو قد تكون أكثر “مرة واحدة” (一次性)، حيث يتم توليد منطق الأعمال المحدد في الوقت الفعلي ولا حاجة لصيانته، ويكون التركيز على تعزيز مكونات قابلة لإعادة الاستخدام وبنية تحتية.

يعتقد فريق البحث أنه في أنماط التطوير، يمكن تخفيف القيود على جودة البرمجيات بشكل مناسب لتقليل عدد مرات تدخل البشر، مقابل زيادة إنتاجية التدفق (throughput)، وبالتالي تسريع التكرار البرمجي.

قال دنغ غانغدا: «تُظهر هذه الدراسة أننا نسير على طريق صحيح، وأن قدرات البرمجة طويلة الأمد لدى AI لم تصل إلى عنق زجاجة بعد، ويمكن أن تتحسن بثبات مع مرور الوقت. وهناك احتمال أن تتحول ذات يوم—من تغيير كمي في درجات الترتيب—إلى تغيير نوعي يغير العالم.»

ومع تطور التكنولوجيا، قد تتطور AI مستقبلاً من تقليل مشاركة البشر في تطوير البرمجيات تدريجيًا، إلى قيام AI بتقديم احتياجات جديدة بشكل مستقل لتطوير قاعدة الأكواد، ثم إلى أن تتجاوز AI البشر تمامًا وتتخلى عن البشر، وفي النهاية تحقق تطورًا ذاتيًا مستمرًا.

المراجع:

1. الورقة البحثية ذات الصلة：

2. الصفحة الرئيسية للمشروع：

التنسيق：ليو يا كون

كم هائل من المعلومات، وتفسير دقيق، كل ذلك في تطبيق Sina Finance APP