بيئة تشغيل العميل 2026: Cloudflare تراهن ضد الحاويات (Containers)

في سطر واحد: بيئة تشغيل العميل (agent runtime) هي طبقة التنفيذ التي تحدد المكان الذي يتم فيه تشغيل كود العميل فعلياً. في 3 أغسطس 2026، أطلقت Cloudflare @cloudflare/computer، وهي بيئة تشغيل تمنح العميل نظام ملفات واحد وتسمح له بالاختيار لكل أمر بين عازل (isolate) خفيف الوزن وحاوية Linux كاملة.

ملخص

افتتحت Cloudflare أسبوع العملاء (Agents Week) الثاني لعام 2026 في 2 أغسطس، بعد ثلاثة أشهر ونصف من إغلاق الأسبوع الأول.¹² وكان الإصدار الرئيسي في اليوم الثاني هو @cloudflare/computer، وهي بيئة تشغيل عملاء مفتوحة المصدر في مرحلة المعاينة الأولية، بُنيت على فرضية صرحت بها الشركة بوضوح: أن منح كل عميل حاوية خاصة به لن يكون قابلاً للتوسع.³

يمنح هذا التصميم العميل نظام ملفات افتراضي واحد مدعوم بـ SQLite، يعيش داخل Durable Object، بالإضافة إلى خلفيتين تنفيذيتين قابلتين للتبديل — عازل (isolate) وحاوية (container) — تعملان على نفس الملفات.³ ويختار العميل أيهما يستخدم لكل أمر.

هدف Cloudflare المعلن هو أن ينتهي الأمر بالحاجة إلى حاوية في أقل من 10% من عمل العميل.³ هذا الرقم هو الجزء القابل للاختبار من الإعلان، وهو الرقم الذي يستحق المتابعة.

بقية المنافسين يختلفون حول الوسيلة الأساسية، وليس حول المشكلة. حيث يقوم E2B و Vercel Sandbox بعزل كود العميل في Firecracker microVMs؛ بينما يستخدم Modal أداة gVisor.⁴⁵ وتعتبر Cloudflare حالة استثنائية في مراهنتها على أن معظم أعمال العملاء لا تحتاج أبداً إلى نواة (kernel) خاصة بها.

ما ستتعلمه

• ما هي بيئة تشغيل العميل، وكيف تختلف عن إطار عمل العميل (agent framework)
• ما الذي أطلقته Cloudflare في اليوم الثاني من أسبوع العملاء 2026
• لماذا أصبحت الحاويات هي عنق الزجاجة في توسع حوسبة العملاء
• كيف يقوم @cloudflare/computer بتقسيم العمل بين العوازل والحاويات
• كيف تتقارب خيارات العزل عبر E2B و Modal و Vercel و Cloudflare
• أي الادعاءات هنا تم التحقق منها، وأيها لا تزال مجرد أهداف

ما الذي أطلقته Cloudflare في اليوم الثاني

افتتحت Cloudflare أسبوع العملاء الثاني من العام في 2 أغسطس 2026 بمنشور تمهيدي من Rita Kozlov لم يذكر أي منتجات على الإطلاق.¹ وكان أسبوع العملاء الأول قد أقيم في الفترة من 13 إلى 17 أبريل 2026 وقدم مجموعة أوسع بكثير من الإصدارات، بما في ذلك وصول Sandboxes إلى مرحلة التوفر العام.²

يضع المنشور الافتتاحي مساراً لمدة خمسة أيام وفرضية حول من بُنيت السحابة من أجلهم: "إن السحابة التي لدينا اليوم، والويب الذي تقوم عليه، قد بُنيا من أجل البشر. كل طبقة تفترض أن هناك بشراً يراقبون."¹

شهد اليوم الثاني، 3 أغسطس، خمسة منشورات مرتبطة بالأسبوع. كانت أربعة منها تتعلق بالبنية التحتية للمنصة: دعم inbound TCP و gRPC لـ Workers والحاويات، ونظام محاسبة للاستخدام (Billable Usage) API مبني حول مواصفات FOCUS، وعمل Workers RPC عبر Python و JavaScript، ومنشور هندسي حول تقديم نماذج Kimi و GLM بتكلفة أقل.⁶

الخامس هو الذي يحمل حجة. "عميلك يحتاج إلى كمبيوتر، وليس حاوية (container)" يقدم @cloudflare/computer، الذي كتبه Matt Carey و Aron Carroll.³

يتم طرحه كمعاينة أولية ومكتبة مفتوحة المصدر، يمكن تثبيتها باستخدام npm install @cloudflare/computer.³ إن وجود أسبوعي ابتكار حول نفس الموضوع في أقل من أربعة أشهر هو في حد ذاته إشارة إلى مدى سرعة تحرك هذه الطبقة.

لماذا أصبحت الحاويات هي عنق الزجاجة

يبدأ المنشور بملاحظة حول كيفية تحول بنية العملاء (agent architecture) خلال عام 2026. في بداية العام، كان المعتاد هو تشغيل حاوية وتشغيل العميل بداخلها.³

مؤخراً، انتقلت هياكل العملاء إلى تقديم تنفيذ كود معزول (sandboxed code execution) كـ أداة بدلاً من ذلك. تصف Cloudflare هذا بأنه فصل "اليدين (البيئة المعزولة حيث يتم العمل) عن الدماغ (حلقة تكرار العميل)."³

هذا الفصل أصبح الآن شائعاً في جميع أنحاء الصناعة. الخلاف هو حول المادة التي يجب أن تُصنع منها هذه "اليدين".

حجة Cloudflare ضد الحاويات هي حجة سعة، وقد صرحت بها دون تردد: "عبر جميع السحابات، وجميع مزودي الخدمات العملاقة (hyperscalers)، لا يوجد قدر كافٍ من الحوسبة في العالم لتعطي كل شركة لكل عميل من مستخدميها بيئة حوسبة حاوية خاصة به."³

تربط الشركة هذا مباشرة بحالة السوق التي سيتعرف عليها المطورون من فواتيرهم: "هذا هو السبب في وجود طلب صناعي يائس ومذعور على حوسبة CPU، وليس فقط حوسبة GPU."³

هذا التأطير يستحق التوقف عنده. معظم التغطيات لأزمة حوسبة العملاء تركز على GPUs. تجادل Cloudflare بأن جانب CPU هو المكان الذي ينهار فيه التوسع لكل عميل فعلياً — وهي نقطة تتفق مع ما بدأت تقيسه معايير استدلال العملاء (agentic inference benchmarks) الجديدة في بداية هذا العام.

الرهان الذي دخلته Cloudflare بالفعل

حجة العزل (isolate argument) ليست جديدة بالنسبة لـ Cloudflare، والمنشور صريح في أن هذا الموقف يعود إلى ما يقرب من عقد من الزمن وليس فكرة حديثة.

قدمت Cloudflare خدمة Workers في 29 سبتمبر 2017، و Durable Objects في سبتمبر 2020.⁷⁸ وجاءت الحاويات في وقت لاحق بكثير، حيث وصلت إلى النسخة التجريبية العامة في يونيو 2025.⁹

السبب المعلن لتفضيل العزل (isolates) هو التوسع الأفقي. فهي تعمل وتتوقف بسرعة، ويمكنها السبات بينما يكون العميل خاملاً، ويمكنها الاحتفاظ بحالة العميل الخاصة، ويمكنها تشغيل عزلات إضافية لتشغيل كود غير موثوق.³

بنية Cloudflare كانت تشغل هيكل العميل في Durable Object وتستدعي حاوية مرتبطة بها عند الطلب كأداة منذ وصول الحاويات.³ @cloudflare/computer هي محاولة لوقف جعل المطورين يقومون بربط هذا الانقسام بأنفسهم.

كيف يعمل @cloudflare/computer

الجزء المركزي هو مساحة العمل (workspace): نظام ملفات افتراضي مدعوم بـ SQLite، يتم ملؤه من التخزين السحابي، أو أنظمة التحكم في الإصدارات، أو ملفات عشوائية، ويتم إنشاؤه على أي Durable Object.³

ترتبط بيئات تشغيل التنفيذ بنظام الملفات هذا. جميعها توفر نفس الواجهة، exec(string, options)، وهناك اثنان متاحان بشكل افتراضي.³

يستخدم نظام الـ isolate الخلفي just-bash لتحويل أكواد shell إلى JavaScript، حيث يعمل داخل worker ديناميكي مع توفر نظام الملفات مباشرة عبر worker bindings.³

يستخدم نظام الـ container الخلفي Cloudflare Containers لتوفير بيئة Linux كاملة، مع توفير نظام الملفات من خلال FUSE mount بحيث يتم مزامنة التغييرات مرة أخرى إلى المصدر الأساسي.³

كلاهما يعمل على نفس الملفات. هذا التصميم القائم على الحالة المشتركة هو ما يجعل التبديل بينهما لكل أمر عملية متسقة بدلاً من كونها عملية نقل بيانات.

بالنسبة للعملاء البرمجيين (agents)، توفر Cloudflare مجموعة أدوات متوافقة مع AI SDK توفر عمليات القراءة، والكتابة، والتعديل، و ls و exec.³ جميع العمليات تخضع للرقابة والتدقيق والمراقبة، وهو أمر مهم بالنظر إلى أن جزءاً كبيراً من عمل احتواء العملاء البرمجيين في العام الماضي كان يتمحور حول معرفة ما فعله العميل البرمجي فعلياً.

أداة exec هي الأداة المثيرة للاهتمام. فهي تأخذ وسيط backend، وقد كُتب وصف الأداة لتوجيه النموذج نحو بيئة التشغيل المناسبة — سواء كانت worker سريعة ورخيصة، أو container كاملة الميزات.

تدعي Cloudflare أن هذا يعمل: "في اختباراتنا، كانت النماذج الرائدة جيدة جداً في اتخاذ القرار الصحيح واللجوء إلى استخدام الحاويات (containers) فقط عند الحاجة."³ هذا ادعاء من المورد حول اختباراته الخاصة، دون وجود معيار قياس (benchmark) منشور مرفق به.

المثال الموثق يعمل على @cf/zai-org/glm-5.2، وهو نموذج البرمجة الوكيل الخاص بـ Z.ai على Workers AI، مقترناً بـ @cloudflare/think.³

هدف أقل من 10%

الادعاء الملموس والقابل للتحقق في الإعلان بأكمله هو هذا: هدف Cloudflare هو بيئة تشغيل "حيث تكون الحاوية (container) مطلوبة لأقل من 10% من عملها"، مع معالجة مهام البرمجة، ومعالجة الصوت والفيديو، وإنشاء المستندات جميعها بواسطة isolates.³

لاحظ صيغة الفعل. هذا هدف، وليس نتيجة مقاسة — Cloudflare لا تنشر رقماً حالياً يثبت ذلك.

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

كيف يقارن المجال

سوق صناديق الرمل (sandbox) للعملاء البرمجيين لم ينتظر Cloudflare. تغطي المقارنة أدناه بدائية العزل التي يستخدمها كل مزود، وهي الفرق الجوهري بينهم.

النمط واضح. انتقل المزودون الرئيسيون الآخرون نحو عزل أقوى على مستوى النواة (kernel-level)، لأن الحاوية ذات النواة المشتركة تعد حدودًا ضعيفة للأكواد غير الموثوقة التي تولدها النماذج.

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

يمكن أن يكون كلا الأمرين صحيحين. V8 isolate هو حدود على مستوى اللغة، وليس على مستوى الأجهزة، وهذه المقايضة هي الجزء الذي يجب على المطورين تقديره — خاصة أي شخص تابع عمليات الهروب من الـ sandbox التي تم الكشف عنها هذا الصيف.

ما هو الجديد فعليًا، وما ليس كذلك

من الجدير بالفصل بينهما، لأن صياغة الأمر هنا تلعب دورًا في التوجيه.

ليس جديدًا: عبارة "امنح وكيلك جهاز كمبيوتر". منشور Cloudflare في أبريل الذي أعلن عن الإطلاق العام لـ Sandboxes كان بعنوان "الوكلاء لديهم أجهزة كمبيوتر خاصة بهم مع الإطلاق العام لـ Sandboxes".¹⁰ واستخدمت Vercel لغة مطابقة تقريبًا عندما أطلقت Sandbox الخاص بها في يناير.⁵ هذه الصياغة تسبق هذا الإصدار من كلا الجانبين.

ليس جديدًا: تشغيل كود الوكيل في sandbox كأداة. هذا التحول حدث في جميع أنحاء المجال خلال النصف الأول من عام 2026.

أيضًا ليس جديدًا: الواجهات الخلفية للتنفيذ القابلة للتوصيل (pluggable execution backends). إن بيئات تشغيل الوكلاء المدارة التي أطلقتها AWS و Google و Alibaba هذا العام توفر بالفعل بيئات معزولة لكل جلسة خلف API واحد، كما توفر أطر عمل الوكلاء أهداف sandbox قابلة للتبديل منذ فترة.

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

غير مثبت: أن النماذج الرائدة تختار بشكل صحيح وموثوق، وأن هدف الـ 10% يظل صامدًا في أعباء العمل الحقيقية. كلاهما مجرد ادعاءات من Cloudflare اليوم.

ما الذي يغيره هذا إذا كنت تبني وكلاء

إذا كنت تستخدم Cloudflare بالفعل، فإن هذا يحل مشكلة الربط التي كنت تعالجها في مساحة المستخدم (userspace). نظام الملفات، وأدوات git، والـ shell، وسجل التدقيق تأتي جميعها كحزمة واحدة بدلاً من ثلاث حزم.

إذا لم تكن كذلك، فإن الفائدة الحقيقية تكمن في السؤال وليس في المنتج. بالنسبة لمزيج الأوامر الفعلي لعميلك (agent)، ما هو الجزء الذي يحتاج حقاً إلى Linux userland؟

معظم الفرق لم تقم بقياس ذلك أبداً. لقد اختاروا مزود sandbox، ومنحوا كل عميل بيئة كاملة، وتحملوا التكلفة. إذا كانت إجابتك أقل بكثير من النصف، فأنت تدفع أسعار microVM من أجل cat و grep و git.

الاعتبار المقابل هو الوضع الأمني. Firecracker و gVisor موجودان لأن الكود الذي يولده النموذج هو مدخل غير موثوق، وقد اتجهت الصناعة في هذا المسار عمداً. إن الاعتماد على isolate-first كخيار افتراضي هو تحسين للتكلفة يقلل من نطاق الضرر (blast radius) بشكل أقل مما يفعله microVM.

لقد قامت Cloudflare الآن بنقل هذه الطبقة مرتين في أقل من أربعة أشهر، وهي ليست الوحيدة التي تتحرك. اقرأ هذا جنباً إلى جنب مع ما قدمته AWS و Google و Alibaba — حيث تبيع الشركات العملاقة (hyperscalers) حلقة العميل (agent loop) كبنية تحتية مدارة، بينما تجادل Cloudflare حول ما يجب أن تعمل عليه هذه الحلقة.

الخلاصة

العنوان الرئيسي هو استفزاز، لكن الحجة الكامنة تحته هي ادعاء حول القدرة الاستيعابية: لا توجد حوسبة كافية في العالم لمنح مليار عميل متزامن حاوية لكل منهم، لذا يجب التنازل عن شيء ما في الإعدادات الافتراضية.

إجابة Cloudflare هي جعل الحاوية استثناءً وترك النموذج يقرر متى تكون هناك حاجة إليها. هذا موقف معماري حقيقي، وهو يتعارض مع التوجه الذي سلكته E2B و Modal و Vercel.

ما ينقصنا هو الدليل. رقم "أقل من 10%" هو هدف، والادعاء حول دقة توجيه النموذج لم يتم اختباره علناً، والأمر برمته لا يزال في مرحلة المعاينة المبكرة.

راقب رقمين خلال الربع القادم: معدل استخدام الحاويات المقاس على أعباء عمل حقيقية، وأي تقييم مستقل لمدى جودة اختيار النماذج الرائدة (frontier models) لواجهتها الخلفية. وحتى يحدث ذلك، يظل هذا رهاناً مدعوماً بحجج جيدة وليس نتيجة محسومة.