Dynamic Workers باختصار: sandbox بحجم tab في المتصفح

الفكرة مش جديدة على Cloudflare، لكن الإعلان الجديد إنها بقت API مفتوحة. بدل ما الـ agent بتاعك يشغّل كود في حاوية منفصلة، هو بيعمل loader.get(...) وبيرجعله isolate جاهز في ميلي ثانية. الـ isolate ده نفس التكنولوجيا اللي Chrome بيستخدمها علشان يفصل الـ tabs عن بعضها.

المشكلة باختصار

AI agents دلوقتي بتعمل حاجة متكرّرة: الـ LLM يولّد كود، و التطبيق لازم ينفّذه بأمان. لو عندك 10 آلاف طلب في الساعة، كل واحد فيهم كود مختلف، الحل الشائع هو حاوية لكل طلب. النتيجة: فاتورة CPU وذاكرة بتطير، وتأخير 1–3 ثواني في كل طلب مجرّد "setup".

ركّز في النقطة دي: المشكلة مش في تنفيذ الكود، المشكلة في كم مرة بتجهّز البيئة في الثانية. ده اللي Dynamic Workers بتحاول تحلّه.

مثال بسيط قبل ما ندخل في الفني

تخيّل إن عندك مطعم. الطريقة الأولى: كل زبون يدخل، تفتحله مطبخ كامل جديد — فرن، ثلاجة، أدوات — يطبخ طلبه، ثم تقفل المطبخ بالكامل. ده الـ Container. مناسب جدًا لو الأكل معقّد، لكن بطيء ومكلف لو كل الزبائن بيطلبوا ساندويتش.

الطريقة التانية: مطبخ واحد مشترك فيه 1000 طاولة تقطيع منفصلة، معزولة عن بعضها بزجاج. كل زبون ياخد طاولة، يحضّر طلبه في ثواني، ويمشي. ده الـ V8 Isolate. أسرع بكتير، بس مينفعش لو الطلب محتاج فرن (يعني OS-level access).

الـ trade-off هنا واضح: كسبت السرعة، خسرت القدرة على عمل أي شيء برّا JavaScript.

V8 Isolate بشكل علمي

V8 Isolate هو instance مستقل من محرّك JavaScript، بحالة heap خاصة و global scope منفصل. كل isolate معزول عن البقية بضمانات الـ runtime نفسه — مش ضمانات الـ kernel زي الحاوية. ده بيخلّيه:

• خفيف جدًا: مفيش kernel processes، مفيش filesystem layers. بس JS heap و WebAssembly memory.
• سريع البدء: V8 بيعمل snapshot للحالة الابتدائية ويعيد استخدامه. النتيجة: cold start ~5ms بدل 200–2000ms للحاوية.
• محدود بـ JavaScript/WebAssembly: مفيش exec()، مفيش syscalls مباشرة، مفيش بنية ملفات حقيقية.

الأرقام اللي أعلنتها Cloudflare: كل isolate بحد أقصى 128MB من الذاكرة (heap + WASM)، ومسموحله بنفس الـ scale اللي Workers بتدعمه — ملايين الطلبات في الثانية.

كود تنفيذي: شغّل كود LLM جوّا Worker

ده مثال بـ TypeScript يستخدم Dynamic Worker Loader. الـ Worker الأساسي بياخد كود من LLM ويشغّله في isolate منفصل:

// worker.ts - الـ Worker الأساسي
import { DynamicWorkerLoader } from "cloudflare:dynamic-workers";

export default {
  async fetch(req: Request, env: Env) {
    const userPrompt = await req.text();

    // 1) اطلب من الـ LLM يولّد كود JS
    const generatedCode = await callLLM(userPrompt, env.AI_API_KEY);

    // 2) حمّل الكود جوّا isolate جديد
    const loader = env.LOADER as DynamicWorkerLoader;
    const worker = await loader.get({
      compatibilityDate: "2026-04-15",
      mainModule: "agent.js",
      modules: {
        "agent.js": generatedCode,
      },
    });

    // 3) نفّذه وأرجع النتيجة
    const result = await worker.fetch(new Request("https://run/"));
    return new Response(await result.text());
  },
};

الإعداد في wrangler.toml:

name = "agent-runner"
main = "src/worker.ts"
compatibility_date = "2026-04-15"

[[dynamic_workers]]
binding = "LOADER"

النتيجة الفعلية: 5ms cold start بدل الـ container spin-up كامل. لو بتشغّل 1000 invocation/دقيقة، الفرق بيبقى في الفاتورة شهريًا ~70–90%.

Code Mode: ليه Cloudflare بتراهن على الفكرة دي

فيه نقطة تانية مهمة. Cloudflare نشرت رقم لافت: تحويل MCP server لـ TypeScript API بيقلل استهلاك tokens بنسبة 81%. ليه؟ لإن الـ LLM لمّا بيكتب كود بيستدعي الـ API عدة مرات، بدل ما يعمل tool call منفصل لكل خطوة، بيوفّر round-trips.

Dynamic Workers هي الطبقة اللي بتخلّي الفكرة دي عملية في الإنتاج: تدّي الـ agent API، يكتب كود يستدعيها، تشغّله في sandbox آمن في 5ms.

التسعير: ابعد عن المفاجآت

• متاحة حاليًا على Workers Paid plan فقط (5$ شهريًا كحد أدنى).
• السعر المُعلَن: $0.002 لكل Worker بيتحمّل. المقصود بـ "Worker بيتحمّل" إن كل مرة بتعمل loader.get() بـ كود مختلف، ده حساب جديد.
• الـ requests والـ CPU بتحسب من خطة Workers العادية (10 مليون طلب شهريًا مشمولين في الخطة المدفوعة).
• مهم: رسوم الـ Workers اليومية مش مفعّلة لسه أثناء الـ beta. ده هيتغيّر.

الحسبة السريعة: agent بيخدم 100K طلب/يوم بكود مختلف في كل طلب = 3M Worker loads شهريًا = $6,000. مش رخيصة، بس قارنها بحاويات شغّالة 24/7 على AWS ECS Fargate بنفس الحمل، هتلاقيها أوفر 3–5×.

الـ trade-offs بصراحة

كل قرار معاه ثمن. هنا الأتمنة:

1. مقيد بـ JavaScript/TypeScript/WebAssembly. لو الـ agent بيحتاج يشغّل Python فيه pandas، أو scripts شيل، Dynamic Workers مش هيقدر. تقدر تستخدم Pyodide عبر WASM لكن بحد أقصى 128MB وبدون NumPy native.
2. الذاكرة سقفها 128MB. لو الـ agent بيعالج PDF كبير أو صور خام، الحاوية لسه أنسب.
3. العزل runtime مش kernel. لو عندك متطلبات أمنية صارمة (تشغيل كود untrusted من مستخدمين مش معروفين)، ده فرق مهم. V8 sandbox escape نادر لكن موجود تاريخيًا.
4. Vendor lock-in حقيقي. الـ API تابع لـ Cloudflare. مفيش مكافئ ناضج عند AWS أو GCP حاليًا. لو هتنقل، هتعيد كتابة طبقة الـ loader.

سيناريو واقعي: agent بيولّد تقارير من قاعدة بيانات

فرضية: عندك SaaS بيخدم 500 شركة، كل شركة بتطلب تقارير مخصّصة يوميًا. الـ agent بيكتب SQL + TypeScript post-processing لكل تقرير.

قبل (حاوية لكل طلب): 500 تقرير × 1.2s cold start = 10 دقائق setup يوميًا مجرّد انتظار. التكلفة الشهرية ~$800 على ECS Fargate.

بعد (Dynamic Workers): 500 × 5ms = 2.5 ثواني إجماليًا. التكلفة ~$30/شهر (500 × 30 × $0.002).

الفرق: 96% توفير. بشرط إن التقارير مش محتاجة مكتبات Python.

متى لا تستخدم Dynamic Workers

• لو الـ agent بيحتاج أدوات OS-level (ffmpeg، imagemagick، shell scripts).
• لو بتشغّل كود untrusted من مستخدمين نهائيين مجهولين — استخدم gVisor أو Firecracker VMs بدل isolate.
• لو workload طويل (>30s لكل طلب) ومستهلك رام كبير — الحاوية أوفر لإنها بتشتغل طول عمر الطلب بكامل الموارد.
• لو بتعتمد على كتابة/قراءة ملفات فعلية من نظام الملفات — الـ isolate مش بيشوف filesystem.

الخطوة التالية

لو عندك agent شغّال على حاويات حاليًا، اعمل proof-of-concept في يوم واحد:

1. فعّل Workers Paid plan لو لسه ما فعّلتهاش.
2. انسخ agent واحد بسيط (مثال: تلخيص مقال، تحليل JSON) وحوّله لـ Dynamic Worker.
3. قِس latency قبل وبعد بـ console.time() داخل الكود نفسه.
4. لو الفرق >50× في cold start، ابدأ تخطّط لنقل 20% من الـ workload كمرحلة أولى.

لو الـ cold start عندك أقل من 200ms بالفعل (يعني حاويات warm-pool)، الفرق هيكون أقل والقرار محتاج رقم ذو مصداقية قبل النقل.

المصادر

• Cloudflare Blog — Sandboxing AI agents, 100x faster (إعلان البيتا الرسمي)
• Cloudflare Agents Week 2026 — Updates and announcements
• InfoQ — Cloudflare Launches Dynamic Workers Open Beta
• VentureBeat — Dynamic Workers ditch containers to run AI agent code 100x faster
• InfoWorld — Cloudflare launches Dynamic Workers for AI agent execution
• Cloudflare Docs — Dynamic Workers Pricing
• HotHardware — Dynamic Workers Promise A 100x Faster Sandbox