Cursor شغّلت مئات الوكلاء أكثر من 3 أسابيع لنقل كودها من Solid إلى React
Cursor وجّهت نظام وكلاء متعدد على كودها نفسه: وكلاء يخططون ويقسمون المهام، ووكلاء ينفذون، ووكيل حَكَم يقرر يكملون أو لا.
- الجهة
- Cursor
- المجال
- البرمجة
- الأداة
- Cursor
- المصدر
- Agent Use Cases + Cursor: Scaling long-running autonomous coding
نُشر المصدر: 14 يناير 2026
وش كانت المشكلة؟
الوكيل الواحد يشتغل زين في المهام الصغيرة، لكنه بطيء في مشروع كبير مثل نقل الكود كامل لإطار ثاني.
وش سوّوا؟
وكلاء التخطيط يستكشفون الكود ويسوون مهام، ويقدرون يطلقون مخططين فرعيين لأجزاء محددة. كل وكيل منفذ ياخذ مهمة وحدة، وفي نهاية كل دورة وكيل حَكَم يقرر هل يكملون، والدورة الجاية تبدأ من جديد. التصاميم الأولى بالأقفال والتنسيق الذاتي فشلت.
النتيجة حسب المصدر
- النقل من Solid إلى React أخذ أكثر من ثلاث أسابيع، بتعديلات +266K/-193K سطر.
- الكود نجح في اختبارات CI والفحوصات الأولى.
- Cursor تقول إنه لسا يحتاج مراجعة دقيقة.
الأرقام منقولة كما نشرها المصدر، وما تحققنا منها بشكل مستقل. وقصص العملاء غالبًا من الشركة اللي تبيع الأداة، فنتيجتك ممكن تختلف.
وش تتعلم منها؟
من مدونة Cursor، ومذكورة على Agent Use Cases. Cursor تقول إن صياغة التعليمات (البرومبت) أهم من الأدوات والنماذج، وإن الوكلاء أحيانًا يطوّلون زيادة ويحتاجون بداية جديدة كل فترة.
كيف تسويها بنفسك؟
- قسّم المشروع لمهام مستقلة.
- خلّ وكيل يخطط ووكلاء ينفذون.
- كل وكيل ياخذ مهمة وحدة بس.
- راجع التقدم في نهاية كل دورة.
- ابدأ دورة جديدة كل فترة عشان ما ينحرفون.
- راجع الكود بدقة قبل الدمج.
برومبت جاهز تبدأ فيه
عدّل اللي بين الأقواس [ ] على وضعك. ولا تلصق بيانات عملاء أو أرقام هويات في أداة ما تعرف سياستها.
حالات وأدلة قريبة
المصدر
آخر تحديث للصفحة: 12 نوفمبر 2026