🤖 AI

SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration

تقدم الورقة البحثية SWE-CI، وهو أول معيار مرجعي على مستوى المستودع مبني على حلقات التكامل المستمر لتقييم قدرة وكلاء النماذج اللغوية الكبيرة على صيانة الكود البرمجي على المدى الطويل من خلال مطالبتهم بحل مهام تطور معقدة ومتعددة الالتزامات (commits) عبر فترات ممتدة، مما ينقل التركيز من مجرد الصحة الوظيفية الساكنة ذات الخطوة الواحدة إلى جودة الكود الديناميكية والمستدامة.

المؤلفون الأصليون: Jialong Chen, Xander Xu, Hu Wei, Chuan Chen, Bing Zhao

نُشر 2026-03-05

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Jialong Chen, Xander Xu, Hu Wei, Chuan Chen, Bing Zhao

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

تخيل أنك توظف مهندسًا معماريًا جديدًا لبناء منزل.

الطريقة القديمة (المعايير السابقة):
تعطي المهندس المعماري مخططًا واحدًا: "ابنِ مطبخًا به مغسلة وموقد". فيسلمك المطبخ. تتحقق من المغسلة والموقد، وهما يعملان! فتعطيه نجمة ذهبية.
ما المشكلة؟ أنت لا تعرف ما إذا كان قد استخدم مواد رخيصة ستتعفن خلال شهر، أو ما إذا كان قد بنى المطبخ بطريقة تجعل من المستحيل إضافة غرفة طعام لاحقًا. في العالم الحقيقي، المنازل لا تُبنى في يوم واحد؛ بل يتم العيش فيها، وتغييرها، وتوسيعها على مدار عقود. الاختبارات القديمة كانت تتحقق فقط مما إذا كان المنزل "جاهزًا" في اليوم الأول، وليس مما إذا كان بإمكانه الصمود بينما تكبر العائلة فيه.

الطالطريقة الجديدة (SWE-CI):
تقدم هذه الورقة البحثية اختبارًا جديدًا يسمى SWE-CI. بدلًا من مطالبة الذكاء الاصطناعي ببناء مطبخ لمرة واحدة، يقولون له:
"إليك هذا المنزل كما كان في عام 2020. على مدار الـ 71 يومًا القادمة، ستحتاج العائلة إلى إضافة غرفة أطفال، ثم مكتب منزلي، ثم نظام ألواح شمسية، وأخيرًا طابق ثاني. مهمتك ليست فقط بناء الغرفة الأولى؛ بل هي الحفاظ على بقاء المنزل بأكله قائمًا، آمنًا، وسهل التوسع خلال الـ 71 يومًا القادمة."

الفكرة الجوهرية: "المنزل الذي يستمر في التغير"

قام الباحثون ببناء معيار باستخدام 100 مشروع برمجيات حقيقي (مثل مكتبات Python الشهيرة). لم ينظروا فقط إلى نقطتي البداية والنهاية؛ بل نظروا إلى الرحلة بأكملها بينهما.

الجدول الزمني: في المتوسط، تغطي كل مهمة 233 يومًا من التاريخ الحقيقي مع 71 تحديثًا (commit).
التحدي: يجب على الذكاء الاصطناعي أن يعمل كفريق برمجيات لا يكتفي بإصلاح خطأ ما ثم يرحل. عليه أن يحافظ على "صحة" الكود أثناء إضافة ميزات جديدة، وإصلاح الميزات القديمة، والتأكد من أن الأشياء الجديدة لا تكسر الأشياء القديمة.

كيف يختبرون الذكاء الاصطناعي: فريق "المهندس والمعماري والبنّاء"

لجعل الأمر واقعيًا، لم يطلبوا من الذكاء الاصطناعي "الإصلاح" فحسب؛ بل قسموا الذكاء الاصطناعي إلى دورين، محاكيين بذلك شركة برمجيات حقيقية:

المهندس المعماري (العقل): يقوم هذا العميل بفحص الأجزاء المعطلة من المنزل (الاختبارات الفاشلة) ويقول: "حسنًا، السقف يسرب، ونحن بحاجة إلى نافذة جديدة. لنضع خطة لإصلاح التسريب أولاً، لكن لا تقلق بشأن النافذة الآن."
البنّاء (اليدان): يأخذ هذا العميل الخطة ويقوم فعليًا بكتابة الكود لإصلاح التسريب.

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

النتيجة: "درجة جاهزية المستقبل" (EvoScore)

في الاختبارات القديمة، إذا كان الكود يعمل في النهاية، تحصل على 100%. في SWE-CI، يستخدمون درجة خاصة تسمى EvoScore.

فكر في الأمر مثل درجة الائتمان لجودة الكود:

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

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

ماذا وجدوا؟

الذكاء الاصطناعي يتحسن، لكنه لم يصل بعد: النماذج الأحدث أفضل بكثير من النماذج القديمة في هذا المجال، لكنها لا تزال تعاني في "اللعبة الطويلة". إنها بارعة في الإصلاحات السريعة، لكنها غالبًا ما تخلق "ديونًا تقنية" (كود فوضوي) يضر بها لاحقًا.
الشركات المختلفة لها أساليب مختلفة: يبدو أن بعض نماذج الذكاء الاصطناعي (مثل نماذج Claude) تهتم أكثر بالاستقرار طويل الأمد، بينما يندفع البعض الآخر لإصلاح المشكلة الفورية ويتجاهلون الفوضى المستقبلية.
مشكلة "صفر تراجع": تفشل معظم نماذج الذكاء الاصطناعي في الحفاظ على استقرار الكود. في الاختبار، كسرت معظم النماذج الميزات الموجودة مسبقًا أكثر من 75% من الوقت عند محاولة تطوير الكود على مدى فترة طويلة.

الخلاصة

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

SWE-CI هو النادي الرياضي الجديد حيث ندرب الذكاء الاصطناعي ليس فقط على رفع الأوزان الثقيلة (كتابة الكود)، بل على الجري في ماراثون (صيانة الكود) دون أن يتعثر في رباط حذائه.

إليك ملخص تقني مفصل لورقة البحث بعنوان "SWE-CI: تقييم قدرات الوكلاء في صيانة قواعد الأكواد عبر التكامل المستمر."

1. بيان المشكلة

بينما أظهرت وكلاء النماذج اللغوية الكبيرة (LLM) قدرات قوية في مهام هندسة البرمجيات الساكنة وذات الخطوة الواحدة (مثل إصلاح خطأ واحد أو توليد دالة)، إلا أن المعايير الحالية تفشل في محاكاة واقع تطوير البرمجيات المهني.

الفجوة: تطوير البرمجيات في العالم الحقيقي هو عملية طويلة الأمد تتميز بتغيرات معقدة في المتطلبات، وتكرارات الميزات، والصيانة المستمرة.
قصور المعايير الحالية: تعتمد النماذج الحالية (مثل SWE-bench وHumanEval) على التقييم القائم على اللقطات (Snapshot-based evaluation). حيث يتلقى الوكيل متطلباً ثابتاً وينتج حلاً من خطوة واحدة. وهذا يفشل في قياس القابلية للصيانة (Maintainability)، حيث يمكن لوكيل يكتب إصلاحات هشة ومبرمجة بشكل صلب (hard-coded) أن يجتاز نفس الاختبارات التي يجتازها وكيل يكتب كوداً نظيفاً وقابلاً للتوسع. إن عواقب التصميم السيئ (الديون التقنية) لا تصبح مرئية إلا عندما يجب تطوير قاعدة الأكواد بمرور الوقت.
التحدي الجوهري: هناك نقص في المعايير التي تقيم قدرة الوكيل على استدامة جودة الكود من خلال التطور طويل الأمد، حيث تتراكم القرارات الماضية وتؤثر على التعديلات المستقبلية.

2. المنهجية

يقترح المؤلفون SWE-CI، وهو أول معيار على مستوى المستودع (Repository-level) مبني على نموذج حلقة التكامل المستمر (CI loop).

أ. صياغة المهام: التقييم القائم على التطور

على عكس النهج القائم على اللقطات حيث يكون المتطلب $r$ ثابتاً ( $r \equiv \text{require}(c_0, c^*)$ )، يستخدم SWE-CI حلقة تكرارية:

توليد المتطلبات الديناميكي: في كل خطوة $i$ ، يتم اشتقاق المتطلب $r_i$ من الفجوة بين قاعدة الأكواد الحالية $c_i$ وقاعدة الأكود "المرجعية" (Oracle) $c^*$ .
التحديث التكراري: يقوم الوكيل بتعديل قاعدة الأكواد لإنتاج $c_{i+1} = \text{code}(c_i, r_i)$ .
انتشار العواقب: يضمن هذا انتشار الأخطاء أو عيوب التصميم في التكرارات المبكرة إلى الخطوات اللاحقة، مما يجعل جودة القرار طويل الأمد قابلة للملاحظة.

ب. تنظيم البيانات

تتكون مجموعة البيانات من 100 مهمة مستخرجة من 68 مستودع بايثون (Python) متميزاً من GitHub.

معايير الاختيار: يجب أن تكون المستودعات مدارة بنشاط (>3 سنوات)، ولديها >500 نجمة، وتمتلك اختبارات وحدة (Unit tests)، وتستخدم تراخيص تسمح بالاستخدام.
النطاق: تمثل كل مهمة انتقالاً بين التزام أساسي (Base commit) والتزام مرجعي (Oracle commit)، ويمتد عبر متوسط 233 يوماً و71 التزاماً متتالياً.
التصفية: تتضمن العملية استخراج المتواليات القصوى ذات التبعيات غير المتغيرة، وبناء بيئات Docker، وتصفية التغييرات الكبيرة في الكود (>1,000 سطر معدل) وفجوات الاختبار (>5 اختبارات ناجحة مختلفة).

ج. بروتوكول التقييم ثنائي الوكلاء

لمحاكاة فرق البرمجيات المهنية، يستخدم SWE-CI سير عمل "المعماري – المبرمج" (Architect–Programmer):

الوكيل المعماري (Architect Agent): يحلل فجوة الاختبار بين الكود الحالي والكود المرجعي. يقوم بعمليات التلخيص (تحديد الأسباب الجذرية)، التحديد (تحديد الملفات المصدر)، والتصميم (إنشاء وثيقة متطلبات عالية المستوى). ويقيد مخرجاته بـ 5 متطلبات ملحة وعالية المستوى لمنع الإفراط في التصميم.
الوكيل المبرمج (Programmer Agent): يتلقى متطلبات المعماري وينفذ خطوات الاستيعاب، التخطيط، والبرمجة لتنفيذ التغييرات.
الحلقة: تتكرر هذه الدورة (حتى 20 تكراراً) حتى يجتاز الوكيل جميع الاختبارات المرتبطة بالالتزام المستهدف.

د. المقاييس: التغيير الطبيعي وEvoScore

التغيير الطبيعي ( $a(c)$ ): مقياس يتراوح من -1 إلى 1 يقيس التقدم بالنسبة للخط الأساسي ( $c_0$ ) والهدف ( $c^*$ ). وهو يعاقب التراجعات (كسر الوظائف التي كانت تعمل سابقاً) بشكل أكثر صرامة مما يكافئ التحسينات، باستخدام تطبيع غير متماثل.
درجة التطور (EvoScore): متوسط مرجح للتغييرات الطبيعية عبر $N$ $N$ من التكرارات:
$e = \frac{\sum \gamma^i a(c_i)}{\sum \gamma^i}$
- $\gamma \ge 1$ : يتم إعطاء وزن أكبر للتكرارات اللاحقة. وهذا يكافئ الوكلاء الذين يحافظون على جودة الكود مع تقدم التطور بدلاً من أولئك الذين يسعون لتحقيق مكاسب سريعة في البداية ولكنهم يراكمون ديوناً تقنية.

3. المساهمات الرئيسية

تحول في النموذج: يقدم أول معيار ينقل التقييم من الصحة الساكنة إلى القابلية للصيانة الديناميكية عبر حلقة التكامل المستمر.
مجموعة بيانات واقعية: يوفر 100 مهمة عالية الدقة تمثل تاريخ تطوير حقيقي لعدة أشهر، مما يلتقط إدارة التبعيات المعقدة وتطور الميزات طويل الأمد.
بروتوكول تقييم مبتكر: نظام التقييم الثنائي (المعماري-المبرمج) يحاكي عمليات التكامل المستمر في الواقع، ويفصل بين تحليل المتطلبات والتنفيذ لتشخيص فشل الوكيل بشكل أفضل.
مقياس جديد (EvoScore): يقترح نظام تسجيل يركز على الوزن المستقبلي، والذي يقدر بوضوح استقرار الكود طويل الأمد على حساب اجتياز الاختبارات قصير الأمد.

4. النتائج التجريبية

قام المؤلفون بتقييم 18 نموذجاً من 8 مزودين (بما في ذلك Claude, GPT, GLM, DeepSeek, إلخ) باستخدام أكثر من 10 مليارات توكن من الحوسبة.

الملاحظة 1: تسارع التقدم: قدرات صيانة الكود تتحسن بسرعة. النماذج الأحدث (بعد عام 2026) تتفوق بشكل كبير على سابقاتها. يتصدر Claude Opus المجموعة، يليه GLM-5.
الملاحظة 2: تحيز المزود: تظهر الشركات المزودة استراتيجيات متميزة فيما يتعلق بالقابلية للصيانة.
- التركيز طويل الأمد: تميل نماذج MiniMax وDeepSeek وGPT إلى التحسين من أجل المكاسب طويلة الأمد (درجات أعلى عندما تكون $\gamma > 1$ ).
- التركيز قصير الأمد: تميل نماذج Kimi وGLM إلى إعطاء الأولوية للعوائد الفورية.
- الاستقرار: تظهر نماذج Qwen وDoubao وClaude أداءً ثابتاً بغض النظر عن معامل الوزن.
الملاحظة 3: الصراع مع التراجع (Regression): تواجه نماذج LLM الحالية صعوبة في السيطرة على التراجعات (كسر الوظائف الموجودة).
- معظم النماذج لديها معدل تراجع صفري أقل من 0.25.
- نموذجان فقط من Claude-Opus تجاوزا معدل 0.5 في التراجع الصفري.
- يشير هذا إلى أنه بينما تعد نماذج LLM جيدة في الإصلاحات الساكنة، فإنها تفشل في الحفاظ على استقرار الكود بشكل موثوق عبر دورات تطوير ممتدة ومتعددة الجولات.

5. الأهمية

القيمة التشخيصية: يكشف SWE-CI أن "الصحة الوظيفية" غير كافية لتقييم الوكلاء في السيناريوهات الواقعية. فهو يكشف عن تراكم "الديون التقنية" التي تغفلها المعايير الساكنة.
الاتجاه البحثي: يقدم إشارة واضحة لمجتمع الذكاء الاصطناعي بأن تدريب النماذج المستقبلي يجب أن يعطي الأولوية لـ التخطيط طويل الأمد، والاتساق الهيكلي، وتجنب التراجع بدلاً من مجرد اجتياز الاختبارات الفوري.
التقييس: من خلال إنشاء معيار صارم على مستوى المستودع مع حلقة تكامل مستمر، يضع SWE-CI معياراً جديداً لتقييم القدرة الحقيقية على "الهندسة" لوكلاء الذكاء الاصطناعي، متجاوزاً مجرد توليد الكود نحو التطور المستدام للبرمجيات.