ملخص تقني: البرمجة الوكيلة تتطلب المبادرة، لا الاستقلالية فحسب

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

يشهد مشهد تطوير البرمجيات تحولاً من إكمال الكود المضمن إلى وكلاء برمجة مستقلين قادرين على تعديل المستودعات، وإدارة طلبات السحب (Pull Requests)، وتنفيذ روتين مجدول. وبينما تُظهر الأنظمة الحالية استقلالية (Autonomy) كبيرة (القدرة على العمل دون إشراف)، إلا أنها تفتقر إلى تعريف واضح وإطار تقييم لـ المبادرة (Proactivity).

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

• ما تعنيه المبادرة في سياق تطوير البرمجيات.
• كيف تختلف عن الاستقلالية البسيطة.
• معايير القبول التي يجب أن تستوفيها المهام طويلة الأمد والمبادرة.
• المقاييس التي تحدد ما إذا كان سلوك الوكيل غير المطلوب مفيداً أم مجرد اقتحام مزعج.

بدون هذه التعريفات، لا يمكن للمجال تقييم ما إذا كانت "سياسة الاستبصار" (Insight Policy) للوكيل — وهي عملية اتخاذ القرار بشأن ما يهم تالياً — فعالة أم لا.

2. المنهجية والإطار العملي

يقترح المؤلفون إطاراً نظرياً قائماً على التفاعل مختلط المبادرة (Mixed-initiative interaction) (Horvitz, 1999) وتصنيفات الاستقلالية (Händler, 2023). تتكون المنهجية من ثلاثة مكونات رئيسية:

أ. الصياغة القائمة على نظرية القرار

يصيغ البحث السلوك المبادِر باستخدام معادلة قائمة على نظرية القرار حيث يختار الوكيل إجراءً $a^*$ لتعظيم المنفعة المتوقعة مع تقليل تكلفة المقاطعة:
$$a^* = \arg\max_{a \in A} \mathbb{E}_{p(o|a,s_t,E_t)} [U(o; \theta)] - \text{Cost}_{int}(s_t, a; \theta)$$

• فضاء الإجراءات ($A$): يتضمن الإخطار (notify)، والاستفهام (question)، والمسودة (draft)، والأهم من ذلك، الالتزام بالصمت (stay silent).
• الحالة ($s_t$): حالة المطور (الملفات المفتوحة، التقويم، المواعيد النهائية للدورة البرمجية/Sprint).
• تدفق الأحداث ($E_t$): تدفق مستمر من أحداث الكود، المشروع، والتواصل.
• تكلفة المقاطعة ($\text{Cost}_{int}$): تكلفة متغيرة تعتمد على تركيز المطور، مرحلة سير العمل، ووقت التعافي.
• الاستبصار (Insight): يُعرف بأنه فرضية مرتبطة بالسياق وحساسة للوقت، مقترنة بقرار بالتحرك أو الصمت.

ب. تصنيف ثلاثي المستويات للمبادرة

يصنف المؤلفون أنظمة البرمجة الوكيلة إلى ثلاثة مستويات بناءً على قدرتها على حساب حدود المعادلة القرارية:

1. المستوى 1 (التفاعلي - Reactive): يعمل الوكلاء فقط عند استدعائهم صراحة. ليس لديهم حضور مستمر في البيئة أو نموذج زمني بين الطلبات.
2. المستوى 2 (المجدول - Scheduled): يعمل الوكلاء بناءً على جداول زمنية أو محفزات محددة مسبقاً (مثل الـ webhooks أو أحداث GitHub). قد يقومون بتصفية أو ترتيب المخرجات، لكنهم لا يتعلمون سياسة مقاطعة عابرة للسياقات ومخصصة لكل مطور. الصمت هنا ليس خياراً متعلمًا، بل هو مجرد غياب للمحفز.
3. المستوى 3 (الواعي بالموقف - Situation-Aware): يراقب الوكلاء تدفقات الأحداث باستمرار، ويحسبون المنفعة وتكاليف المقاطعة عبر كامل فضاء الإجراءات (بما في ذلك الالتزام بالصمت)، ويحدثون سياستهم ($\theta$) بناءً على ردود فعل المطور. هم من يقررون ماذا يعرضون، ومتى، وما إذا كان عرض أي شيء هو الإجراء الصحيح.

ج. بروتوكول التقييم

يقترح البحث تكييف محاكاة المستخدم النشط (Nathani et al., 2026) لتطوير البرمجيات. بدلاً من تسجيل درجة إتمام المهمة النهائية (كما في SWE-Bench)، يركز التقييم على تدفق الاستبصار (Insight stream).

• جمع الآثار (Trace Collection): آثار سير عمل المطور المختومة زمنياً والقابلة لإعادة التشغيل، والتي تربط بين فروقات المستودع (diffs)، سجلات CI، التواصل، وحالة بيئة التطوير المتكاملة (IDE).
• هيكلية السيناريو: تشمل السيناريوهات طويلة الأمد إشارات ضعيفة، مشتتات، أدلة مؤكدة، ولحظات يكون فيها الصمت هو الإجراء الصحيح.
• المقاييس:
  1. جودة قرار الاستبصار (IDQ): تقيس ما إذا كان الوكيل قد اختار الإجراء الصحيح (إخطار، استفهام، مسودة، صمت) في الوقت الصحيح.
  2. درجة الارتباط بالسياق (CGS): تقيس ما إذا كانت الاستبصارات المعروضة مدعومة بأدلة يمكن استرجاعها (ملفات، فروقات، سجلات) وما إذا كانت الرسالة أمينة لتلك الأدلة.
  3. عائد التعلم (LL): يقيس مدى تحسن الـ IDQ عندما تتكيف السياسة مع ملاحظات المطور مقارنة بسياسة ثابتة.

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

يقدم البحث أربع مساهمات محددة:

1. تصنيف ثلاثي المستويات: فصل رسمي بين الاستقلالية والمبادرة، والتمييز بين الوكلاء التفاعليين، والمجدولين، والواعيين بالموقف.
2. تدقيق مقارن: تحليل لخمسة وكلاء برمجة معاصرين (Cursor, GitHub Copilot, Jules, Claude Code, ومرجع معماري لـ LangChain) مقابل خمس معايير عملية (O1–O5).
   • النتيجة: تتجمع الوكلاء المنتشرة حالياً حول المستوى 2. لا يوجد أي منها يوثق علناً حساب تكلفة المقاطعة (O1)، أو الصمت الصريح كإجراء متعلم (O2)، أو تحديث السياسة بناءً على ملاحظات كل مطور (O3).
3. محرك نموذج أولي للمستوى 3: بنية مفهومية تتمحور حول وحدة "الاستبصار"، وتحافظ على نموذج ذهني للمطور وتتعلم من استجابته.
4. مقاييس التقييم: اقتراح IDQ وCGS وLL كوحدات أساسية لقياس السلوك المبادِر، مع تحويل التركيز من إتمام المهام إلى جودة سياسة الاستبصار.

4. النتائج واللقاءات

لا يقدم البحث نتائج تجريبية مقاسة من نظام مستخدم فعلي من المستوى 3؛ بل هو مقترح نظري وقياسي. ومع ذلك، فإن التدقيق للأنظمة الحالية يسفر عن النتائج التالية:

• "فجوة المبادرة": بينما تدعم أنظمة مثل Cursor Automations وClaude Code Routines المهام المجدولة (المستوى 2)، إلا أنها تفتقر إلى دليل على حساب تكاليف المقاطعة أو اعتبار الصمت إجراءً صريحاً ومتعلماً.
• تدقيق O1-O5:
  • O1 (تكلفة المقاطعة): لا يوجد أي وكيل منتشر يوثق حساب هذا الأمر.
  • O2 (الصمت الصريح): لا يوجد وكيل يوثق الصمت كإجراء متعلم في فضاء الإجراءات.
  • O3 (تحديثات التغذية الراجعة): الأدلة ضعيفة؛ بعض الأنظمة توفر ذاكرة، لكن أثر ذلك على قرارات الظهور غير واضح.
  • O4 (عبر السياقات): توجد أدلة جزئية على استيعاب فئات متعددة من السياق.
  • O5 (قناة المبادرة): مستوفى بشكل واسع؛ يمكن للوكلاء عرض الرسائل دون أدوات منفصلة.
• الخلاصة حول الحالة الراهنة: إن الحدود القصوى ليست في ابتكار قدرات جديدة، بل في تكييف أنماط التفاعل الموجودة مع خصوصيات تطوير البرمجيات، وخاصة الحكم على متى يقطع الوكيل حبل أفكار المطور ومتى يلتزم الصمت.

5. الأهمية والادعاءات

يزعم البحث أن الجيل القادم من وكلاء البرمجة يجب ألا يُقيم بمقدار العمل الذي ينجزونه، بل بـ جودة وتحسن سياسة الاستبصار الخاصة بهم.

• تحول في النموذج الفكري: يجب النظر إلى المبادرة كـ "تعاون مختلط المبادرة" وليس مجرد أتمتة. يكون الوكيل مبادراً إذا تعلم أي المساهمات تستحق الانتباه، وأي الأدلة تجعلها موثوقة، وكيف يتكيف بعد تلقي الملاحظات.
• المساءلة: يجعل الإطار المبادرة قابلة للاختبار. من خلال تعريف "الاستبصارات" وقياس IDQ وCGS وLL، يمكن للمجال تجاوز مسميات المنتجات إلى سلوكيات قابلة للقياس.
• الآثار التصميمية: يتطلب وكيل المستوى 3 الحقيقي واجهة تجعل الاستبصارات المؤجلة قابلة للفحص، مما يسم يسمح للمطورين بقبول أو تعديل أو رفض الاقتراحات، وبالتالي توفير حلقة التغذية الراجعة اللازمة للتعلم.
• التواضع: يقر المؤلفون بأن هذا مجرد مقترح. قد تختلف المحاكاة للمطورين عن المستخدمين الحقيقيين، وقد لا تنتقل نتائج المقاطعة من العمل في الوقت الفعلي بسلاسة إلى الرسائل غير المتزامنة. يدعو البحث إلى الإبلاغ عن عدم اليقين والتعامل مع المبادرة كخاصية تتضمن مطورين حقيقيين بدلاً من مجرد درجة اختبار واحدة.

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