كيف تجعل Cursor وكيلها القائم على AI أفضل: من guardrails إلى السياق الديناميكي

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

تطور نافذة السياق

عندما كانت Cursor تطور وكيلها الأول للترميز في أواخر 2024، لم تكن نماذج اللغة جيدة بعد في اختيار ما يجب إدراجه في السياق بشكل مستقل. لذلك قضت الفريق أشهراً في تطوير حواجز الحماية — قيود وقواعد صارمة توجه الوكيل في الاتجاه الصحيح. كان النهج القديم يبدو هكذا:

• بعد كل تحرير، توفر للوكيل أخطاء linter وتحذيرات type-checker
• أعادت كتابة طلبات الملفات إذا طلب الوكيل عدداً قليلاً جداً من أسطر الكود
• حددت عدد الأدوات التي يمكن للوكيل استدعاؤها في دورة واحدة
• وفرت الكثير من السياق الثابت — هيكل المجلدات وأجزاء الكود والإصدارات المضغوطة من الملفات

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

كيف يتم قياس الجودة الحقيقية

تحديد ما إذا كان التحسن يعمل فعلاً هو مهمة غير تافهة بالنسبة للمنتج. تستخدم Cursor نهجاً على مستويين، يجمع بين الاختبارات الاصطناعية والبيانات الحقيقية من المستخدمين. في المستوى الأول توجد معايير عامة (مثل CursorBench) توفر صورة سريعة عن الجودة وتسمح بالمقارنة عبر الزمن. لكن حتى المعايير الجيدة تعكس فقط الاستخدام الحقيقي بشكل تقريبي. يمكن للوكيل أن ينجح بشكل مثالي في الاختبار في ظروف المختبر لكن يفشل في العمل الحقيقي. لذا في المستوى الثاني، تجري Cursor اختبارات A/B على المستخدمين الحقيقيين، مقارنة عدة متغيرات من الهياكل في نفس الوقت. هنا تظهر المقاييس التي تحتاج حقاً:

• Latency — مدى سرعة قدم الوكيل الإجابة الأولى
• Token efficiency — عدد الرموز المستخدمة لكل طلب
• Tool call count — عدد مرات استدعاء الأدوات
• Cache hit rate — عدد مرات إعادة استخدام السياق المخزن

لكن المقياس الأهم هو Keep Rate. هذه هي نسبة الكود الذي يبقى في قاعدة الكود بعد أسبوع أو شهر من إكمال المهمة. إذا أعاد المستخدمون بشكل متكرر صياغة الكود المُنشأ أو اضطروا إلى إصلاح الأخطاء يدوياً — ينخفض Keep Rate. هذا يشير: الوكيل لم ينجح.

ما يعنيه هذا

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