وكلاء Cursor السحابيون في مايو 2026: فجوتان ما زالتا بلا حل

حصل وكلاء Cursor السحابيون في 13 مايو على بيئات تدعم مستودعات متعددة. وبحسب صفحة المنتج لدى Cursor، بات وكلاء مستقلون يعملون داخل بيئات سحابية معزولة ينشئون أكثر من 30% من طلبات السحب التي تدمجها الشركة.

وكلاء Cursor السحابيون: ما الذي صدر فعلياً في 13 مايو؟

الميزة الأبرز هي بيئات الوكلاء السحابية متعددة المستودعات. أصبح بإمكان الوكيل الآن العمل عبر عدة مستودعات ضمن بيئة واحدة مضبوطة مسبقاً، امتداداً لمساحات العمل متعددة الجذور التي أطلقتها Cursor في 24 أبريل. ويمكن إعادة استخدام البيئة بين الجلسات؛ وهذه هي الفائدة العملية، إذ لم يعد إعداد جهاز التطوير نفسه مطلوباً في كل مرة يبدأ فيها وكيل مهمة.

تتمحور عملية الإعداد حول Dockerfile. تظل أسرار البناء محصورة في خطوة البناء ولا تُمرَّر إلى الوكيل أثناء التشغيل، ما يعالج أكثر الأخطاء شيوعاً في بنية الوكلاء: أن يتسرب مفتاح API مضمن في عملية البناء إلى ذاكرة عمل الوكيل. وتستطيع Cursor أيضاً إعداد Dockerfile بعد فحص المستودعات للتعرف إلى الأدوات والاعتماديات. لكن هذه الآلية ما زالت في إصدار تجريبي خاص لفرق Enterprise.

أما أكبر قفزة في الأداء فجاءت من التخزين المؤقت للطبقات. فعمليات البناء التي تجد نتيجة في ذاكرة التخزين المؤقت أصبحت أسرع بنسبة 70%، لأن إعادة البناء تقتصر على طبقات Dockerfile التي تغيرت. وعندما تُشغّل فرق العمل الوكلاء مراراً، يكون هذا هو الفارق بين الانتظار وإنجاز العمل.

الجانب التشغيلي هو ما لا يزال المنافسون يقللون من أهميته. لكل بيئة سجل إصدارات يتيح الرجوع إلى إصدار سابق، وهذه الصلاحية مقصورة على المسؤولين. كما يسجل سجل التدقيق كل إجراء ينفذه أعضاء الفريق على البيئات. وتُضبط قوائم السماح بالاتصالات الصادرة ونطاقات الأسرار لكل بيئة على حدة، لذلك لا يمكن الوصول إلى سر متاح للبيئة A من البيئة B. قد تبدو هذه بنية تحتية مملة، لكنها ضرورية قبل السماح لوكيل بفتح طلبات سحب تمس شيفرة الإنتاج.

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

نسبة طلبات السحب المدمجة لدى Cursor هي الدليل الأقوى

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

منذ 2 سبتمبر 2026، تتيح Self-Hosted Machines من Cursor للفرق نقل تعديل الملفات وأوامر الطرفية وأدوات استخدام الحاسوب وتنفيذ MCP المحلي إلى عُقد تشغيل يديرها العميل، فيما تبقي Cursor دورة الوكيل والاستدلال والتخطيط في سحابتها. بذلك أُغلقت فجوة موقع التنفيذ الخاص، لكن Cursor لم تتحول إلى بيئة تشغيل دائمة قابلة للبرمجة.

لم يعد معيار الاختيار هو العمل ضمن جلسة مؤقتة في مقابل التشغيل الدائم. تحتفظ Cursor بحالة المحادثة في أنظمتها الخلفية كي يمكن الرجوع إلى عمليات التشغيل واستئنافها، كما تستطيع Self-Hosted Team Pools استعادة مساحة عمل دخلت في حالة سبات. التمييز الأدق اليوم هو بين حالة وكيل يديرها المورّد وحالة تطبيق قابلة للبرمجة. إذ تتيح Cloudflare حالة SQLite مستقلة لكل Agent وخطوات Workflow دائمة تتحكم فيها عبر الشيفرة.

ما الذي تنجزه حزمة Cloudflare Workers وAgents SDK لدي بالفعل؟

أشغّل ستة وكلاء في بيئة الإنتاج على Cloudflare. بيئة التشغيل هي Workers، أما الحالة فتعيش في Durable Objects مع قاعدة SQLite لكل مثيل، وتتولى Cloudflare Workflows تنسيق المهام طويلة التشغيل. بنيت ذلك منفرداً وعلى حساب واحد، وقد شرحت تفاصيله هنا. بلغت تكلفة حزمة Cloudflare كاملة $19.14 في أبريل 2026. هذا رقم من فاتورة إنتاج مؤرخة، وليس سعراً معلناً للمنصة. وتعرض Cursor سعر Enterprise بعبارة Custom؛ كما تتطلب Team Pools خطة Enterprise، بينما تظل Self-Hosted Machines خاضعة لتكلفة النموذج المختار إضافة إلى فاتورة عُقد التشغيل لديك.

تختلف هذه الحزمة عن منتج Cursor الحالي في ثلاثة جوانب.

مستودعات متعددة، تتحكم فيها الشيفرة. يستطيع Worker جلب الموارد عبر HTTP أثناء التشغيل. ويمكن لـBrowser Run، التي كانت تُسمى Browser Rendering، التحكم في متصفح بلا واجهة عندما لا يتوفر السياق إلا عبر موقع ويب. وتقدم Cursor الوصول إلى مستودعات متعددة في صورة إعداد بيئة قابل لإعادة الاستخدام؛ أما Cloudflare فتترك لك بناء منطق الجلب والمصادقة والتعامل مع المستودعات. ليست إحداهما أفضل أو أسوأ؛ إنما تختلف واجهة التحكم.

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

حدود دائمة للخطوات، لا تنفيذاً تلقائياً لمرة واحدة بالضبط. في Workflows، يمكن إعادة محاولة كل خطوة على حدة، كما يمكنها تسجيل حالة تتيح استمرار التنفيذ بعد تعطل الشبكة أو البنية التحتية. تقبل step.do إعدادات إعادة المحاولة لكل خطوة، ويوقف NonRetryableError المحاولات عند الإخفاقات النهائية، وتكون معرّفات المثيلات فريدة داخل كل Workflow. لكن الخطوة قد تُنفذ أكثر من مرة، وتطلب Cloudflare صراحةً تصميم الاستدعاءات ذات الآثار الجانبية بحيث تكون آمنة عند تكرارها. الميزة هي أن المطور يحدد آليات الديمومة وإعادة المحاولة، لا أن المنصة تمنع تلقائياً تكرار طلبات السحب أو رسائل البريد الإلكتروني أو الرسوم.

الفجوتان اللتان لم تغلقهما Cursor بعد

الفجوة 1: حالة وكيل قابلة للبرمجة وتحت سيطرة العميل. عالجت Cursor قابلية الاستئناف الأساسية: تُحفظ حالة المحادثة إلى أجل غير مسمى افتراضياً، فيما تتبع لقطات VM المُدارة نافذة متجددة مدتها 90 يوماً من عدم النشاط. تنقل Self-Hosted Machines تنفيذ الأدوات، لكن Cursor تظل الجهة التي تشغّل دورة الوكيل وتخزن المحادثة. في المقابل، يتيح Cloudflare Agent حالة مدعومة بـSQLite داخل بيئة تشغيل التطبيق. ويصبح ذلك مهماً عندما يراقب الوكيل الحوادث، أو ينسق عملية ترحيل، أو يحتفظ بحالة العمل عبر مسار إعداد عميل يمتد عدة أيام.

هذه فجوة أضيق من تلك التي كانت قائمة في مايو. تستطيع Cursor استئناف عمليات وكلاء منتجها، لكنها لا تتيح آلة حالات يملكها العميل ويمكن لتطبيقه الاستعلام منها وتوسيعها وتنسيقها بمعزل عن محادثة Cursor.

الفجوة 2: واجهة خطوات دائمة يحددها المطور. لا تعرض وثائق Cloud Agent وSelf-Hosted Machine الحالية لدى Cursor لبنة تطبيقية تماثل خطوة Workflow ذات حالة محفوظة وإعدادات إعادة محاولة مستقلة لكل خطوة. وتوفر Cloudflare ذلك. يظهر أثر هذا الفارق عندما ينتقل وكيل البرمجة إلى الفوترة أو البريد الإلكتروني أو النشر أو أي أثر جانبي خارجي آخر.

نقل استدعاءات الأدوات إلى جهازك لا يغلق هذه الفجوة؛ فهو يغير موقع التنفيذ لا عقد التنسيق. كما أن Cloudflare لا تضمن تنفيذ الآثار الجانبية لمرة واحدة بالضبط؛ إذ يبقى عليك تصميم الخطوة التي تُعاد محاولتها بحيث تكون آمنة عند التكرار.

هذا ليس انتقاصاً من Cursor، بل توضيح للفئة التي ينتمي إليها كل منتج. Cursor منتج برمجة يتيح تنفيذ الأدوات في بيئة مُدارة أو على أنظمة العميل. أما Cloudflare فهي بيئة تشغيل تطبيقات قابلة للبرمجة. ضيّق إصدار سبتمبر فجوة البنية التحتية، لكن الحد الفاصل في الحالة والتنسيق ما زال قائماً.

ما الذي ينبغي للمؤسسين ومديري التقنية فعله هذا الأسبوع؟

ثلاثة أنماط من الفرق، ولكل منها خطوة مختلفة.

إذا كنتم فريق منتج صغيراً يطلق ميزات جديدة، فاستخدموا Cursor Cloud Agents المُدارة متى استطاعت بيئاتها وضوابط الشبكة إعادة إنتاج عملية البناء لديكم. يعالج إصدار بيئات 13 مايو إعداد المستودعات المتعددة وأسرار البناء والتخزين المؤقت وقابلية التدقيق، فيما يمثل إفصاح Cursor عن نسبة تتجاوز 30% من طلبات السحب المدمجة دليلاً علنياً. لا تشغّلوا أسطول عُقد تشغيل ما لم تفرض السياسات ذلك.

إذا كنتم تستخدمون Cloudflare أو Vercel بالفعل لتشغيل عمليات خلفية طويلة العمر، فأبقوا حالة التطبيق الدائمة والتنسيق هناك. تستطيع Cursor Self-Hosted Machines الآن استخدام بنية Cloudflare أو Vercel لتنفيذ الأدوات، لكن Cursor تظل تدير دورة الوكيل. وهناك مثال موازٍ من جانب المستخدم يستحق القراءة حول الطريقة التي تحزم بها Anthropic مكونات مشابهة للشركات الصغيرة والمتوسطة؛ فنمط تقارب المنصات نحو الوكلاء يظهر في كل مكان.

إذا كنتم تخططون لتعميم الاستخدام على مستوى المؤسسة، فابدؤوا بـCloud Agents المُدارة عندما تلبي قوائم السماح أو Tailscale أو AWS PrivateLink أو Cloudflare Tunnel متطلبات الوصول. واستخدموا Team Pools حين يجب أن تظل نسخة العمل وتنفيذ الأدوات والعتاد المخصص أو صورة عُقد التشغيل تحت سيطرتكم. تتطلب Team Pools خطة Enterprise التي يُعرض سعرها بعبارة Custom، فيما تظل ملفات Dockerfile التي تعدّها Cursor في إصدار تجريبي خاص.

ما الذي تغير بعد مايو؟

ثمة إشارتان.

أولاً، توثق Cursor الآن حالة المحادثة بصورة منفصلة عن مساحة عمل بيئة التشغيل. وتُحفظ حالة المحادثة إلى أجل غير مسمى افتراضياً كي يمكن الرجوع إلى عمليات التشغيل واستئنافها؛ أما لقطات VM المُدارة فتنتهي بعد 90 يوماً من عدم النشاط، ما لم يؤدِّ بدء التشغيل أو استئنافه إلى تمديد النافذة. لم تعد قابلية الاستئناف الأساسية فجوة؛ بل أصبحت الملكية وقابلية البرمجة موضع الفرق.

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

هل ألغى إصدار Cursor في 13 مايو الحاجة إلى بنية وكلاء ذاتية الاستضافة؟

لا. توفر Cursor الآن مساراً ذاتي الاستضافة خاصاً بها: My Machines لسير العمل الشخصي وTeam Pools لأساطيل Enterprise. ينقل ذلك تنفيذ الأدوات إلى شبكتكم، لكن Cursor تظل مسؤولة عن دورة الوكيل وتخزين حالة المحادثة. وتبقى الفرق التي تحتاج إلى بيئة تشغيل تطبيقات قابلة للبرمجة أو خطوات Workflow دائمة بحاجة إلى بنية تحتية لهذه الطبقات.

ما سرعة عمليات بناء وكلاء Cursor السحابيين عند استخدام ذاكرة التخزين المؤقت؟

أصبحت عمليات البناء التي تجد نتيجة في ذاكرة التخزين المؤقت أسرع بنسبة 70% بعد ترقية تخزين الطبقات في 13 مايو. وعند العثور على نتيجة مخزنة، لا يُعاد بناء سوى طبقات Dockerfile التي تغيرت.

ماذا تعني نسبة طلبات السحب المدمجة داخلياً لدى Cursor؟

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

هل وكلاء Cursor السحابيون آمنون للشيفرة التي تتعامل مع أسرار الإنتاج؟

يضبط إصدار 13 مايو الاتصالات الصادرة والأسرار لكل بيئة، ويفصل أسرار البناء عن الوكيل أثناء التشغيل، كما يتيح سجل الإصدارات والرجوع إلى إصدار سابق وسجلات التدقيق. وتستطيع Self-Hosted Machines إبقاء نسخة العمل الكاملة وبيانات الاعتماد المحلية للجهاز على عُقدة التشغيل لديكم، لكن محتويات الملفات المطلوبة ومخرجات الأدوات والفروق ولقطات الشاشة ونتائج MCP المحلية قد تستمر في الانتقال إلى Cursor. لذلك تعتمد السلامة على الموافقة على الحدين كليهما.

هل يمكن تشغيل Cloudflare Workers ووكلاء Cursor السحابيين معاً؟

نعم. تدرج Cursor منصة Cloudflare ضمن تكاملات Self-Hosted Machines، ويستخدم قالبها المرجعي Cloudflare Worker بوصفه متحكماً لتشغيل Cloudflare Container واحد لكل طلب تتم المطالبة به. يمكن لـCursor إدارة دورة وكيل البرمجة، بينما تتولى Workers وDurable Objects وWorkflows حالة التطبيق الدائمة والتنسيق. يتداخل المنتجان الآن في تنفيذ الأدوات، لكنهما لا يتداخلان عند الحد الخاص بدورة الوكيل.