وكلاء Cursor في الخلفية: شرح كامل (وما لا يمكنهم فعله)

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

إذا كان فريقك يخلط بالفعل بين بيئات تشغيل متعددة، Claude Code في نافذة طرفية، وCodex في أخرى، ووكيل Gemini على حاسوب أحد الزملاء، فالجواب الصادق أنك تحتاج إلى طبقة تعلو فوقها جميعًا. تلك الطبقة هي Sharkly، منصة موحّدة لإدارة الوكلاء وأوامرهم. سنستعرض أين تتألق وكلاء الخلفية، وأين تتوقف، وكيف تُبقي طبقة محايدة الأسطول بأكمله مرئيًا من الطلب حتى الإصدار.

باختصار

وكلاء الخلفية في Cursor هي وكلاء برمجة مستضافون في السحابة يعملون بشكل غير متزامن في بيئة بعيدة معزولة، تُطلق من محرر Cursor أو من Slack، وتُسلّم عملها على شكل فرع أو طلب سحب. وهي ممتازة عندما يعمل فريقك بأكمله داخل Cursor. لكنها تنسّق وكيل Cursor نفسه، فلا تنسّق Claude Code أو Codex أو Gemini أو الوكلاء العاملين على أجهزة أخرى، ولا تمنح فريقًا يخلط بين بيئات تشغيل متعددة طبقة مراجعة مشتركة. استخدم وكلاء الخلفية عندما يكون Cursor أداتك الوحيدة. واستخدم طبقة محايدة مثل Sharkly عندما يشغّل الفريق عدة بيئات تشغيل ويحتاج إلى إسناد وسياق ومراجعة بشرية مشتركة بينها جميعًا.

ما هي وكلاء الخلفية في Cursor فعليًا

وكيل الخلفية في Cursor هو وكيل برمجة يعمل بشكل غير متزامن في بيئة بعيدة يوفّرها له Cursor، بدلًا من أن يعمل داخل جلسة محررك المحلي. هذه الجملة الواحدة تحمل الفكرة كلها. وكيل Cursor العادي يعمل في محررك، على جهازك، بينما تراقبه. أما وكيل الخلفية فيغادر جهازك، ويستنسخ مستودعك إلى بيئة سحابية معزولة، ويعمل بمفرده بينما تنشغل بشيء آخر.

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

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

ما تجيده وكلاء الخلفية

افترض أفضل صورة لهذه الميزة، فهي ميزة قوية. إليك ما يجعل وكلاء الخلفية يستحقون مكانهم.

توازٍ غير متزامن دون عناء محلي. تشغيل عدة وكلاء في وقت واحد على حاسوبك المحمول يعني التلاعب بتبويبات الطرفية وأشجار عمل git والمعالج. أما وكلاء الخلفية فينقلون هذا العبء إلى سحابة Cursor، فلا يكلفك التوازي شيئًا محليًا. ولمن اعتادوا إعداد هذا الأمر يدويًا، يوضّح دليلنا عن تشغيل عدة وكلاء Claude Code بالتوازي كم يصبح الإعداد اليدوي معقدًا. أما وكلاء الخلفية فيزيلون هذا الإعداد داخل Cursor تمامًا.

بيئات معزولة لكل عملية تشغيل. يحصل كل وكيل خلفية على بيئته الخاصة، فلا يفسد وكيلان يعدّلان ملفات متداخلة حالة أحدهما الآخر. هذا هو مبدأ الأمان نفسه الذي تقوم عليه أشجار عمل git لوكلاء البرمجة، مطبّقًا في السحابة. تهيّئ البيئة مرة واحدة، أوامر التثبيت، والصورة الأساسية، والأسرار، وترثها كل عملية تشغيل لاحقة.

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

تسليم نظيف إلى المراجعة. المخرَج فرع أو طلب سحب، يندرج مباشرة في مسار مراجعة GitHub الذي يثق به فريقك بالفعل. لا مكان جديد تبحث فيه. يظهر فرق الوكيل حيث تظهر الفروق دائمًا.

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

الحدّ الصادق: إنها تنسّق Cursor، لا أدواتك الأخرى

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

وكيل الخلفية لا يشغّل Claude Code أو Codex أو Gemini أو OpenCode. بل يشغّل وكيل Cursor. وإذا انتقل نصف فريقك إلى Claude Code في الطرفية لأنه يناسب سير عملهم، فإن تلك العمليات تعيش في عالم منفصل تمامًا. لا يوجد خط زمني مشترك يجلس فيه عمل وكيل خلفية من Cursor وعملية تشغيل Claude Code جنبًا إلى جنب.

وكيل الخلفية لا يمنحك طبقة مراجعة واحدة عبر الأدوات. يعود عمله إلى طلب سحب على GitHub، وهذا جيد، حتى تصبح لديك أيضًا وكلاء يعملون في مكان آخر لا تصل تقدّمهم ومعوقاتهم ونتائجهم إلى المكان نفسه أبدًا. وهنا يصبح "مصدر الحقيقة الواحد" لديك ثلاثة مصادر للحقيقة.

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

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

ثنائية القرار: تنسيق أحادي المزوّد أم طبقة محايدة

الخيار ليس "أداة جيدة مقابل أداة سيئة." بل "أي شكل من التنسيق يناسب فريقك." وإليك ثنائية القرار الصادقة.

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

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

هذا هو التفريع نفسه الذي يصطدم به المطوّرون عندما يتجاوزون لوحة محلية، وقد تناولناه في دليل بدائل Vibe Kanban. التنسيق أحادي المزوّد مريح حتى يتوقف المزوّد عن أن يكون القصة كاملة.

أين تقع Sharkly: الطبقة المحايدة حول كل بيئة تشغيل

Sharkly ليست بديلًا عن Cursor أو Claude Code أو Codex أو غيرها من أدوات التنفيذ. إنها تضيف المهمة المشتركة، والحاسوب، والسياق، والتحكم، وطبقة المراجعة حول الأدوات التي يستخدمها فريقك بالفعل. هذه الجملة تلخّص العلاقة كلها، فاقرأها مرتين. تحتفظ بـ Cursor. وتحتفظ بوكلائه الخلفيين حيث تناسب. أما Sharkly فهي ما ينسّق الأسطول حين يصبح الأسطول أكبر من مزوّد واحد.

تقسيم العمل واضح. Cursor وClaude Code وCodex والأدوات المشابهة تنفّذ. أما Sharkly فتدير الإسناد على مستوى الفريق، والحواسيب المتصلة، وسياق المهمة، والتقدّم، والمعوقات، والنتائج، والمراجعة البشرية عبر تلك الأدوات. يبحث الوكلاء وينفّذون ويختبرون ويقدّمون التقارير. أما البشر فيحدّدون الاتجاه، ويمنحون الصلاحية، ويقبلون النتيجة. وتتوقف الأتمتة عند النقطة التي يستلزم فيها الأمر حكم الفريق.

وعمليًا، المهمة في Sharkly هي وحدة العمل الأساسية، وهي تحمل كل ما يتعلق بجزء من العمل في مكان واحد. تُسندها إلى وكيل يعمل على حاسوب تتحكم به، وببيئة التشغيل التي تختارها. وتعود عمليات التنفيذ والمعوقات والنتائج والنقاش اللاحق إلى الخط الزمني للمهمة، بدلًا من أن تتشتت بين طرفيات خاصة، وسحابة مزوّد واحد، ومحادثة على Slack. يبقى الهدف، والفرق، والنقاش، ومراجعة كل عملية تشغيل معًا، سواء استخدمت تلك العملية Claude Code أو Codex أو أداة تتبناها العام المقبل.

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

مثال تطبيقي

لنفترض أن فريقك يتلقى التذكرة SH-312: "أضف تحديد معدل الطلبات إلى الـ API العام وغطِّه بالاختبارات." لاحظ كيف يتعامل الشكلان معها.

بوكلاء الخلفية وحدها، يطلق مستخدم Cursor وكيل خلفية، فيعمل في سحابة Cursor، ويعود إليك طلب سحب. جيد، ما دام ذلك المستخدم هو من يقوم بالعمل. لكن قائد فريق الواجهة الخلفية لديك يستخدم Claude Code ويريد تولي الجزء المعقد من الوسيط (middleware). الآن أصبحت SH-312 موزّعة بين طلب سحب من Cursor وجلسة Claude Code منفصلة بلا موطن مشترك. وعلى من يراجع أن يجمع الاثنين معًا من الذاكرة.

مع Sharkly، تصبح SH-312 مهمة واحدة. يعمل وكيل الوسيط على حاسوب القائد تحت Claude Code، ويعمل وكيل تغطية الاختبارات تحت بيئة تشغيل مختلفة، ويعيد كلاهما عمله إلى المهمة نفسها. يفتح المراجع مكانًا واحدًا ويرى الصورة كاملة: ما فعله كل وكيل، وما هو معطّل، وما اجتاز فحص الأنواع والاختبارات، وما ينتظر قرارًا بشريًا. تتحرك الواجهة الأمامية والخلفية وتغطية الاختبارات في الوقت نفسه، وهو نمط التطوير المتوازي الذي وصفناه في ما يعنيه البرمجة الوكيلية حقًا. أما الشخص فيقبل، أو يطلب تعديلات، أو يقرر الدمج. بقيت بيئات التشغيل كما هي تمامًا. والتنسيق هو ما أُضيف.

أخطاء شائعة يجب تجنّبها

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

وكلاء الخلفية في Cursor مقابل طبقة تنسيق محايدة

اقرأ هذا كتقسيم للعمل، لا كلوحة نتائج.

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

أهم الخلاصات

• وكلاء الخلفية في Cursor هي وكلاء برمجة غير متزامنين مستضافون في السحابة، تُطلق من المحرر أو من Slack، وتُسلّم العمل على شكل فرع أو طلب سحب.
• وهي تجيد ذلك: توازٍ غير متزامن بلا تكلفة محلية، وبيئات معزولة لكل عملية تشغيل، وواجهة إطلاق قليلة الاحتكاك، وتسليم نظيف إلى مراجعة GitHub.
• حدّها مقصود بالتصميم: فهي تنسّق وكيل Cursor، لا Claude Code أو Codex أو Gemini، ولا تمنح فريقًا مختلط بيئات التشغيل طبقة مراجعة مشتركة واحدة.
• استخدم وكلاء الخلفية عندما يعيش فريقك كله داخل Cursor. واستخدم طبقة محايدة عندما تشغّل عدة بيئات وتحتاج إسنادًا وسياقًا ومراجعة مشتركة.
• تعمل Sharkly جنبًا إلى جنب مع Cursor لا بدلًا منه: احتفظ بأدواتك، وجِلب اشتراكك الخاص، ودع كل عملية تشغيل تعود إلى مهمة واحدة من الطلب حتى الإصدار.

الخطوة التالية صغيرة عن قصد. اربط حاسوبًا واحدًا، وأنشئ وكيلًا واحدًا، وأسند إليه شيئًا روتينيًا. وتغطي الوثائق كل مفهوم بمزيد من العمق على docs.sharkly.ai.

الأسئلة الشائعة

ما هو وكيل الخلفية في Cursor في جملة واحدة؟ هو وكيل برمجة يعمل بشكل غير متزامن في بيئة بعيدة يوفّرها Cursor، يُطلق من المحرر أو من Slack، ويستنسخ مستودعك، ويجري تعديلات، وينفّذ أوامر، ويعيد عمله على شكل فرع أو طلب سحب.

كيف يختلف وكلاء الخلفية عن وكيل Cursor العادي؟ وكيل Cursor العادي يعمل في جلسة محررك المحلي بينما تراقبه. أما وكيل الخلفية فيترك جهازك ويعمل بمفرده في السحابة، فتبقى غير متوقف ويمكنك تشغيل عدة وكلاء في وقت واحد.

هل يمكن لوكلاء الخلفية في Cursor تشغيل Claude Code أو Codex؟ لا. يشغّل وكلاء الخلفية وكيل Cursor نفسه. وإذا كان فريقك يستخدم Claude Code أو Codex، فتجري تلك العمليات بشكل منفصل، ولهذا يحتاج الفريق المختلط بيئات التشغيل إلى طبقة محايدة فوق كل أداة. راجع دليلنا عن تشغيل عدة وكلاء Claude Code لمعرفة ذلك الجانب من الأسطول.

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

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

هل تغيّر Sharkly طريقة دفعي مقابل النماذج؟ لا. أنت تجلب اشتراكك الخاص. يستمر استخدام النماذج عبر الاشتراكات أو مفاتيح API المهيّأة في أدواتك المتصلة، وتعتمد حصة النموذج على الخطط وحسابات API التي يربطها فريقك.

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