كيف تُحسّن Cursor وكيل الذكاء الاصطناعي: من القيود الصارمة (guardrails) إلى السياق الديناميكي

نشرت Cursor دراسة مفصّلة عن تطوير وكيل الذكاء الاصطناعي الخاص بها للبرمجة وتحسينه المستمر. والخلاصة الرئيسية أن نموذجًا لغويًا قويًا واحدًا لا يكفي. فحتى أكثر النماذج تقدمًا تحتاج إلى «إطار عمل» (harness) جيد، أي منظومة متكاملة من الموجّهات (prompts) والأدوات وإدارة السياق ومقاييس التقييم. ولا تكتفي المقالة بعرض النتائج، بل تشرح المنهجية: كيف تختبر Cursor فرضياتها، وكيف تقيس الجودة، وكيف تكيّف البنية مع القدرات الجديدة للنماذج.

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

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

كان النهج القديم يعمل على النحو التالي:

• بعد كل عملية تحرير، كانت تُمرَّر إلى الوكيل أخطاء أداة linter وأداة فحص الأنواع (type-checker)
• كانت تُعاد صياغة طلبات الملفات إذا طلب الوكيل عددًا غير كافٍ من أسطر الكود
• كان عدد الأدوات التي يمكن للوكيل استدعاؤها في الدورة الواحدة محدودًا
• كانت تُقدَّم كمية كبيرة من السياق الثابت: بنية المجلدات ومقتطفات الكود ونسخ مضغوطة من الملفات

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

كيف تُقاس الجودة الفعلية

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

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

• Latency — سرعة تقديم الوكيل لأول استجابة
• Token efficiency — عدد الرموز (tokens) التي أنفقها الوكيل على طلب واحد
• Tool call count — عدد مرات اللجوء إلى الأدوات
• Cache hit rate — عدد مرات إعادة استخدام السياق المخزَّن مؤقتًا

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

ماذا يعني ذلك

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

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