وكلاء Cursor ذاتية الاستضافة: أدواتك تبقى داخل شبكتك

تشرح هذه المقالة كيف تُبقي وكلاء Cursor تنفيذ الأدوات داخل شبكتك، وما الذي يظل في سحابة Cursor، ومتطلبات التشغيل والتكلفة والعزل قبل اعتمادها.

Thursday, September 3, 2026Omid Saffari
Tools
وكلاء Cursor ذاتية الاستضافة: أدواتك تبقى داخل شبكتك

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

كيف تعمل وكلاء Cursor ذاتية الاستضافة؟ نموذج تشغيل منقسم

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

تفصل Cursor Self-Hosted Machines بين هذين النصفين. تحتفظ Cursor بالحلقة والاستدلال والتخطيط والواجهة وتنسيق الجلسة، بينما ينفّذ عامل تديره أنت الأدوات.

قائمة Run on في Cursor ولوحة مجموعة Self-Hosted Machines
Cursor Self-Hosted Machines

قد يكون هذا العامل حاسوبًا محمولًا، أو جهازًا افتراضيًا، أو جهاز Mac، أو حاوية Kubernetes، أو بيئة معزولة يوفرها شريك تكامل. يفتح العامل اتصال HTTPS صادرًا إلى Cursor، ويتلقى استدعاءات الأدوات، وينفذها محليًا، ثم يعيد النتائج. ولا تحتاج Cursor إلى منفذ وارد أو عنوان IP عام على العامل.

فيما يلي توزيع المسؤوليات التشغيلية.

الطبقةCloud Agent تديره CursorSelf-Hosted Machine
حلقة الوكيل والنموذج والتخطيطتشغّلها Cursorتظل Cursor هي من يشغّلها
تعديل الملفات والأوامر وإجراءات المتصفح وMCP المحليجهاز افتراضي معزول تديره Cursorالعامل التابع لك
دورة حياة المضيف وعزلهCursorأنت أو مزود البنية التحتية لديك
سعة التنفيذمشمولة في بيئة التشغيل المُدارةتحدد حجمها وتدفع تكلفتها أنت
استخدام النموذجتسعير النموذج المحددتسعير النموذج المحدد نفسه

تقدم Cursor نمطين للعامل. يربط My Machines جهازًا بحساب شخص واحد، وهو مناسب لبيئة تطوير أو لسير عمل شخصي محدود. أما Team Pools فهي طوابير مسماة لفرق Enterprise. ينتظر الطلب داخل المجموعة إلى أن يتسلمه عامل متاح، ولا يعالج كل عامل في المجموعة سوى جلسة Cloud Agent واحدة في كل مرة.

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

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

ما الذي يبقى داخل شبكتك، وما الذي يخرج منها؟

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

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

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

وهذه أول نتيجة عملية على مستوى الأعمال. بات من الممكن في مراجعة الأمان اعتماد موقع التنفيذ بمعزل عن معالجة النموذج، لكن لا بد من اعتماد كليهما.

من يمكنه استخدام هذه الميزة، وما الذي سيتغير؟

فريق خلفية مؤسسي يعتمد على خدمات داخلية

قد يحتاج فريق خلفية إلى سجل حزم خاص، وقاعدة بيانات مرحلية، ونقاط نهاية لخدمات لا يمكن الوصول إليها من جهاز افتراضي مُدار. يمكن وضع Team Pool داخل الشبكة الخاضعة للضبط نفسها وتشغيل عملية البناء من دون فتح مسار وارد من Cursor.

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

فريق iOS مرتبط بأجهزة Mac

تعمل Cursor-managed Cloud Agents على أجهزة Ubuntu افتراضية. ويمكن لفريق يحتاج إلى أجهزة Mac لأعمال iOS تسجيلها كعوامل، وإضافة أذونات التحكم بالحاسوب المطلوبة، ثم السماح للوكيل بالنقر والكتابة والتقاط صور الشاشة أو التحكم في المتصفح على ذلك الجهاز.

الميزة هي أن الوكيل البعيد يستطيع استخدام فئة الأجهزة نفسها التي تُجرى عليها عملية البناء. أما التكلفة التشغيلية فهي مألوفة لكل من يدير أسطول بناء من أجهزة Mac: يظل اختلاف صور الأنظمة والأذونات ووقت التشغيل والتنظيف والاستبدال مسؤوليتك.

فريق منصة يواجه طلبًا متقلبًا على الوكلاء

يمكن لفريق المنصة وضع Cloudflare Containers خلف Team Pool. ينشئ القالب المرجعي حاوية معزولة واحدة لكل جلسة يجري تسلمها، ويستخدم Durable Object لامتلاك تلك الحاوية، ويمكنه تخزين لقطات المستودعات مؤقتًا في R2.

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

مطور فردي لديه بيئة تطوير تحتفظ بحالتها

يناسب My Machines مطورًا يعتمد مشروعه على أدوات أو حالة محلية يصعب إعادة إنشائها كل مرة. ويمكن لعدة وكلاء مشاركة الجهاز نفسه؛ وهذه ميزة مريحة لجهاز شخصي، لكنها إشارة تحذير عند التعامل مع أعمال حساسة.

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

إعداد Cloudflare قابل للتشغيل

يُعد مسار Cloudflare مفيدًا لأنه يُظهر بوضوح حدود الملكية الجديدة. وهو يتطلب Cursor Enterprise، ومفتاح حساب خدمة للفريق بصلاحية agent، وحساب Cloudflare Workers Paid يدعم Containers وR2، وNode.js 20 أو أحدث، وDocker.

  1. تسجيل Team Pool

    ثبّت Cursor CLI، وتأكد من عمله، ثم صِل عاملًا محليًا مؤقتًا حتى تظهر المجموعة في Cursor.

    Bash
    curl https://cursor.com/install -fsS | bash
    agent --version
    export CURSOR_API_KEY="<team service-account API key>"
    CURSOR_API_KEY="$CURSOR_API_KEY" agent worker --pool cloudflare-test start

    أوقف ذلك العامل باستخدام Ctrl+C بعد ظهور المجموعة، ثم شغّل unset CURSOR_API_KEY. أبقِ العامل المحلي متوقفًا أثناء اختبار Cloudflare حتى لا يتسلم الطلب أولًا.

  2. نشر القالب المرجعي من Cursor

    استنسخ القالب وثبّت اعتمادات المشروع وسجّل الدخول إلى Cloudflare وأنشئ حاوية اللقطات الاختيارية.

    Bash
    git clone https://github.com/anysphere/cloudflare-workers.git
    cd cloudflare-workers
    npm install
    npx wrangler login
    npx wrangler r2 bucket create cursor-pool-worker-snapshots
  3. تخزين بيانات الاعتماد

    ضع مفتاح حساب خدمة Cursor في أسرار Worker. ولا تضف بيانات اعتماد Git إلا إذا كانت الحاويات تحتاج إلى مستودعات خاصة.

    Bash
    npx wrangler secret put CURSOR_API_KEY
    npx wrangler secret put GIT_USERNAME
    npx wrangler secret put GIT_TOKEN

    لا يصلح مفتاح Cursor API شخصي للاستخدام مع Team Pool. وهذا هو خطأ الإعداد الأكثر قابلية لأن يبدو كعطل في البنية التحتية، لأن المتحكم يعيد 401.

  4. ضبط المجموعة والسعة

    في wrangler.jsonc، غيّر CURSOR_POOL إلى cloudflare-test. واضبط containers[].max_instances على أكبر عدد من الجلسات المتزامنة التي أنت مستعد لتشغيلها، لا على عدد المطورين في الفريق.

    يستخدم الملف المرجعي افتراضيًا قيمة max_instances قدرها 10 وحاوية standard-1 تضم 0.5 vCPU وذاكرة بسعة 4 GiB وقرصًا بسعة 8 GB. وقد تحتاج عمليات البناء الفعلية إلى فئة أكبر.

  5. النشر ومراقبة أول عملية تشغيل

    انشر المشروع، ثم أبقِ واجهتي المتحكم والحاويات مفتوحتين أثناء تشغيل Cloud Agent واختيار المجموعة ذاتية الاستضافة.

    Bash
    npx wrangler deploy
    npx wrangler tail
    npx wrangler containers list

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

التكلفة انتقلت ولم تختفِ

تتضمن Cursor-managed Cloud Agents بنية التنفيذ التحتية. أما Self-Hosted Machines فتواصل استخدام النموذج المحدد وفق تسعير Cursor، ثم تضيف إليها فاتورة العامل لديك. وتتطلب Team Pools أيضًا عقد Enterprise بسعر مخصص.

يوضح Cloudflare شكل البند الإضافي في الفاتورة. تعمل خدمة Containers ضمن خطة Workers Paid الشهرية البالغة $5. وتشمل الخطة 25 GiB-hours من الذاكرة، و375 vCPU-minutes، و200 GB-hours من القرص. وبعد استهلاك ذلك، تبلغ تكلفة الذاكرة $0.0000025 لكل GiB-second، وتكلفة وحدة المعالجة النشطة $0.000020 لكل vCPU-second، وتكلفة القرص المحجوز $0.00000007 لكل GB-second.

إذا استخدمنا فئة standard-1 في القالب المرجعي ونمذجنا 100 جلسة تعمل كل منها ساعة واحدة، وتستهلك كامل وحدة المعالجة المتاحة أثناء النشاط، ثم تنتظر خلال نافذة الخمول البالغة خمس دقائق في القالب، تصبح تكلفة الحاويات بعد الاستهلاك المشمول نحو $12 للشهر:

$5 plan + $3.15 CPU + $3.675 memory + $0.168 disk = $11.993

هذا مثال توضيحي لتكلفة البنية التحتية، وليس إجمالي فاتورة Cursor. فهو لا يشمل استخدام Worker وDurable Object، أو السجلات، أو نقل البيانات الصادر، أو R2، أو عقد Enterprise، أو استخدام النموذج، أو الأشخاص الذين يديرون الأسطول. ويفترض كذلك أن أصغر فئة في القالب كافية، في حين قد يفرض مستودع كثيف التجميع استخدام حاوية أكبر.

غالبًا لا يكون سعر الثانية الواحدة هو القرار الأعلى تكلفة، بل سياسة السعة الجاهزة. يستخدم عامل المجموعة العام في Cursor افتراضيًا نافذة إعادة اتصال مدتها 3,600 ثانية، بينما يخفضها قالب Cloudflare إلى 300 ثانية. تجعل النافذة الأطول مطالبات المتابعة أسرع، لكنها تواصل احتساب الذاكرة والقرص المحجوزين. وتوفر النافذة الأقصر إنفاق وقت الخمول مقابل المزيد من مرات البدء البارد.

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

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

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

ما الخطوة المناسبة الآن؟

تحرك هذا الأسبوع إذا كان Cloud Agent يحتاج إلى عتاد مخصص، أو صورة مخصصة، أو وصول إلى أدوات لا تستطيع الشبكات المُدارة توفيره. ابدأ بمجموعة محدودة ومستودع منخفض المخاطر. وأبقِ معالجة النموذج وبيانات الأدوات المعادة ضمن مراجعة الأمان، لأن نقل التنفيذ لا يلغيها.

انتظر إذا كان مطلبك الوحيد هو الوصول إلى شيفرة مصدر خاصة أو خدمة داخلية. توصي Cursor بتجربة البيئات المُدارة، أو ضوابط الشبكة، أو Tailscale، أو AWS PrivateLink، أو Cloudflare Tunnel قبل تحمل مسؤولية أسطول من العوامل. فهذه المسارات تُبقي دورة حياة المضيف وعزله لدى Cursor.

لن تتأثر إذا كانت Cloud Agents المُدارة تجتاز سياساتك بالفعل وتعيد إنتاج عملية البناء لديك. فالاستضافة الذاتية لا تضيف قدرات جديدة للنموذج، بل تغيّر موقع التنفيذ والجهة المسؤولة عن تشغيله.

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

احصل على التحليل التالي لسير عمل الذكاء الاصطناعي بمستوى تشغيلي عبر النشرة البريدية.

آخر تحديث

3 سبتمبر 2026

التصنيفExplained

فضّل هذا الموقع في Google

إضافة omidsaffari.com كمصدر مفضّل في بحث Google

اجعل omidsaffari.com مصدرًا مفضّلًا، وسيرفعه Google لك في Top Stories وAI Overviews وAI Mode.

المزيد من Explained

عرض كل مقالات Explained
النشرة البريدية

رسالة واحدة، كل يوم أحد. أنظمة تعمل، لا آراء ساخنة.

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

أسبوعية. بلا إزعاج. يمكنك إلغاء الاشتراك متى شئت.