أعادت Cloudflare بناء Containers للوكلاء: بدء التشغيل أسرع بـ 6 مرات

أعادت Cloudflare تصميم البنية التحتية لخدمة Containers لتلائم الحمل الذي تولّده وكلاء الذكاء الاصطناعي: إذ تظهر بيئات sandbox عند الطلب، لكل مهمة على حدة، ويجب أن تكون جاهزة فورًا. في اختبار ComputeSDK المستقل، انخفض متوسط زمن البدء من 4.049 ثانية إلى 648 ملي ثانية (بمعدل 6.2 مرة)، وفي اختبار تجريبي أجرته الشركة بنفسها شغّل حساب واحد 100 000 حاوية في 5.387 ثانية عبر ست مواقع. وصدر معها اختيار الـ image والموارد مباشرة من الكود، ولقطات نظام الملفات (snapshots) في نسخة بيتا عامة.

الكود يختار الـ image والعتاد، لا عملية النشر

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

كان النموذج القديم يتطلب تطبيقًا منفصلًا لكل تركيبة من الـ image ونوع الـ instance، مع مساحة أسماء Durable Objects خاصة به وتوجيه في Worker. وهكذا كانت بيئة Node.js صغيرة وبيئة Python كبيرة للبناء تعنيان نشرين اثنين. أما سياسة الجدولة الجديدة `durable_object` فتحوّل ذلك إلى شرط `if`: تُعلَن الـ images المتاحة (مثل node وpython) في إعدادات wrangler، ثم يمرّر Durable Object عند البدء إلى `ctx.container.start()` الـ image ونوع الـ instance (مثل standard-1 أو standard-2) وعلامة السماح بالوصول إلى الإنترنت. وبذلك تظهر البيئة الجديدة بتعديل الكود، لا بنشر جديد.

وينطبق الأمر نفسه على طرح التحديثات. فلم يعد هناك grace-periods ولا تقسيمات بالنسبة المئوية ولا استدعاءات لواجهة API الإعدادات: تعمل الحاوية على الـ image الذي بدأت به إلى أن يوقفها الكود، ويعتمد التشغيل التالي الـ image الذي يختاره الكود. ومن هذا ينتج إطلاق تدريجي (canary) على 5% من بيئات sandbox الجديدة بحسب hash معرّف Durable Object، وتثبيت المشاريع النشطة على الـ image الحالي، والترحيل عند نقطة تحقق (checkpoint)، والتراجع بمجرد تغيير الـ image للتشغيلات المقبلة.

لماذا تُنفَّذ أول أمر أسرع

كان تشغيل الحاوية في السابق يمر عبر مستوى تحكم عالمي: يحلّل إعدادات التطبيق، ويبحث عن السعة، وينسّق التوزيع. أما الآن فينشأ الطلب على مستوى Durable Object. تبحث البنية التحتية أولًا عن مكان على الجهاز نفسه، ثم توسّع البحث ضمن الموقع، وتمنح الأولوية للمضيفين الذين يوجد عليهم الـ image أو الـ snapshot محليًا.

وبعد الوصول إلى المضيف حُذف كل ما هو زائد أيضًا: فبدلًا من إقلاع آلة افتراضية من الصفر، تستعيد بيئة التشغيل آلة افتراضية مُعدّة مسبقًا وغير مخصصة بعد، وتعيد استخدام إعدادات الشبكة ونظام الملفات، وتجمّع العمليات المتكررة، ولا تنتظر الخدمات التي لا يحتاجها أول أمر. نتائج اختبار Burst TTI (100 بيئة sandbox متزامنة، والقياس من جهة العميل):

• المتوسط: 4.049 ث ← 648 مل ث (أسرع بـ 6.2 مرة)؛ • المئين 95: 5.839 ث ← 910 مل ث (بمعدل 6.4 مرة)؛ • المئين 99: 6.717 ث ← 1129 مل ث (بمعدل 5.9 مرة).

وأصدرت Cloudflare بشكل منفصل image باسم `cloudflare/debian-trixie` يضم Debian Trixie Slim وNode.js 24.20.0 LTS. يستطيع الوكيل تشغيل بيئة Linux sandbox دون Dockerfile ودون بناء الـ image أو دفعه (push)، ثم يستنسخ مستودعًا ويثبّت الحزم عبر `exec()`. ولأن Cloudflare نفسها تتحكم في هذا الـ image، فهي توزّعه مسبقًا على المضيفين المناسبين، فلا يُنزَّل شيء ولا يُفكّ ضغطه عند التشغيل.

اللقطات (Snapshots): حفظ مساحة العمل والعودة إليها

حتى البدء السريع لا يلغي الحاجة إلى التهيئة: فاستنساخ المستودعات وتثبيت الاعتماديات وإعداد سلسلة الأدوات تستغرق غالبًا وقتًا أطول من تشغيل الحاوية نفسها. ولهذا صدرت لقطات نظام الملفات الأصلية (native) في نسخة بيتا عامة. تحفظ الدالة `snapshotContainer()` مساحة العمل، وتستعيدها `start()` مع المعامل `containerSnapshot`.

اللقطات غير قابلة للتعديل وقابلة لإعادة الاستخدام، ولذلك تعمل في سيناريوهين. الأول: استمرار مساحة عمل واحدة بين الجلسات. يحفظ وكيل البرمجة المستودع والاعتماديات وذاكرة البناء المؤقتة والتعديلات عندما يغادر المستخدم، ويستعيدها في اليوم التالي. الثاني: نقطة تحقق مشتركة لعدد كبير من بيئات sandbox. وهذا مفيد في تقييم الوكلاء، حين تُشغَّل المهمة نفسها بـ system prompts أو مهارات أو نماذج أو إصدارات وكيل مختلفة، بينما يجب أن يبقى كل ما عدا ذلك ثابتًا. تشغّل لقطة واحدة بيئات معزولة كثيرة بأساس متطابق، وتزيل انحراف البيئة (environment drift) من النتائج. كما تعمل السلسلة أيضًا: يبدأ الوكيل من debian-trixie، ويهيّئ البيئة عبر `exec()`، ويحفظ النتيجة كلقطة.

لمن يفيد هذا

السيناريوهات التي أُعيد تصميم المنصة من أجلها: وكلاء البرمجة التي تتعامل مع المستودعات ومديري الحزم والمترجمات وخوادم التطوير (dev-servers)؛ وعمليات التقييم (evals) ذات الحالة الابتدائية المعروفة؛ وأنظمة التعلم المعزز (RL) التي تنشئ عددًا كبيرًا من البيئات وتقيّمها وتعيد ضبطها؛ والمهام الطويلة التي يلزم فيها حفظ الملفات.

تبني منتجاتها على Containers بالفعل Base44 (بيئة تطوير معزولة لكل تطبيق مع معاينة حية) وKilo Code (بيئة منفصلة لكل جلسة سحابية للوكيل). وتوجد تكاملات مع Cursor Cloud Agents وDevin Outposts وOpenAI Agents API وClaude Managed Agents. وينتقل النموذج نفسه إلى Sandbox SDK 1.0، وتُضاف إمكانيات أكثر إلى واجهة `ctx.container` الأصلية كي يدير Durable Object الحاوية دون صنف مغلِّف (wrapper class).

أما الخلاصة العملية للفرق التي تبني منتجات الوكلاء فهي التالية: إذا كنتم تُبقون تطبيقات منفصلة لكل stack، فيمكن دمجها في صنف Durable Object واحد يختار الـ image أثناء التشغيل (runtime). وفي التقييم والتعلم المعزز يُستحسن إعداد لقطة مرجعية وإطلاق تشغيلات متوازية منها. وللجلسات طويلة الأمد يناسب الزوج «لقطة عند الإيقاف المؤقت، واستعادة عند العودة». أما أرقام الـ 100 000 حاوية فهي أولية، ولذلك من الأفضل اختبار الحمل الفعلي على ملف الاستخدام الخاص بكم.