دليل Vercel Sandbox Drives لمساحات عمل الوكلاء الدائمة

الخلاصة السريعة

أنشئ Drive مرة واحدة باستخدام Drive.getOrCreate()، ثم مرّره إلى Sandbox.create() تحت مسار تثبيت مطلق مثل /data، واحفظ كل ملف مطلوب على المدى الطويل داخل ذلك المسار. أوقف sandbox الأول قبل أن يطلب sandbox آخر صلاحية القراءة والكتابة. أما بيئات الاختبار أو المراجعة المتوازية، فاستخدم معها drive.snapshot(). سيحصل كل قارئ على صورة مجمّدة ولن تصله الكتابات اللاحقة.

من الأنسب تصور Drive كغرفة مشروع قابلة للنقل، لا كقرص أكبر داخل جهاز واحد. الـsandbox هو فريق العمل وورشته المؤقتة، أما Drive فهو غرفة التخزين المقفلة التي تبقى بعد مغادرة الفريق ويمكن وصلها بالورشة التالية.

تضع Vercel ضمن الاستخدامات المقصودة لـDrives مساحات عمل الوكلاء، والذاكرة المحفوظة على القرص، وأشجار الاعتماديات، ومجموعات البيانات، والنماذج، ومخرجات البناء. كما ذكر أحد المستخدمين الأوائل أن تخصيص Drive لكل وكيل أتاح تجاوز إعادة تثبيت الاعتماديات عند استعادة الاتصال. هذه هي الفائدة التي تستحق القياس: تقليل أعمال الإعداد، لا مجرد زيادة سعة التخزين.

إعداد مساحة عمل دائمة باستخدام Vercel Sandbox Drives

ابدأ بمشروع على Vercel ومصادقة محلية. توصي Vercel باستخدام رمز OIDC للتطوير المحلي؛ إذ يكتب vercel env pull رمز التطوير في .env.local، وتنتهي صلاحيته بعد 12 ساعة. ويمكن لنظام CI خارجي استخدام معرّف الفريق ومعرّف المشروع ورمز وصول بدلًا من ذلك.

الإصدار المستقر من حزمة npm وقت النشر هو @vercel/sandbox 3.5.0. لا تزال بعض الصفحات القديمة من وثائق Vercel SDK تصفه بأنه إصدار تجريبي خاص وتقترح قناة beta، لكن صفحة مفهوم Drive الحالية وإعلان الإطلاق في 23 سبتمبر تؤكدان أن الإصدار التجريبي العام متاح في الخطط الثلاث.

npm install @vercel/sandbox@3.5.0
npx vercel link
npx vercel env pull

أنشئ الآن Drive، وثبّته، واكتب ملف علامة وذاكرة مؤقتة صغيرة، ثم أوقف ذلك الـsandbox واقرأ الملفين من sandbox جديد:

import { Drive, Sandbox } from '@vercel/sandbox';

const workspace = await Drive.getOrCreate({
  name: 'agent-workspace',
  region: 'iad1',
});

const first = await Sandbox.create({
  persistent: false,
  region: 'iad1',
  mounts: { '/data': workspace },
});

await first.runCommand('bash', [
  '-lc',
  "mkdir -p /data/.cache/demo && printf 'ready\\n' > /data/marker.txt && printf 'cached\\n' > /data/.cache/demo/package.txt",
]);
await first.stop();

const next = await Sandbox.create({
  persistent: false,
  region: 'iad1',
  mounts: { '/data': workspace },
});

const check = await next.runCommand('bash', [
  '-lc',
  'cat /data/marker.txt /data/.cache/demo/package.txt',
]);
console.log(await check.stdout());
await next.stop();

يحصر persistent: false هذا المثال في Drive. فالـsandbox الدائم يملك آلية استئناف خاصة به تعتمد على snapshot، بينما يبقى Drive دليلًا مستقلًا يمكن نقله بين بيئات sandbox مختلفة. ويمكن الجمع بين الاثنين عند الحاجة إلى بيئة أساسية قابلة لإعادة الاستخدام، إلى جانب مجلد مشروع منفصل يتطور بمرور الوقت.

نفّذ الاختبارات الأربعة الحاسمة

يثبت المسار المثالي بقاء الملفات. أما الاختبارات الأربعة التالية فتثبت أن التصميم سيتصرف كما ينبغي عندما تتعامل عدة مهام مع مساحة العمل نفسها.

1. تأكد من بقاء مساحة العمل في sandbox جديد

اكتب ملف علامة وذاكرة مؤقتة تحت /data، ثم أوقف الكاتب وأنشئ sandbox مختلفًا يستخدم Drive نفسه. اقرأ الملفين من /data. وجود ملفات في موضع آخر داخل الـsandbox الأول لا يثبت استمرارية Drive.

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

2. تأكد من بقاء القارئ القديم على نسخته القديمة

اكتب علامة أولية، وأوقف الكاتب، ثم أنشئ قارئًا باستخدام mounts: { '/data': workspace.snapshot() }. أبقِ هذا القارئ قيد التشغيل. ثبّت Drive بصلاحية القراءة والكتابة في sandbox آخر، واستبدل العلامة، ثم أوقف الكاتب. يفترض أن يعيد القارئ الحالي العلامة الأصلية لأن نسخته ثُبتت لحظة التركيب. أنشئ قارئ snapshot جديدًا كي يرى القيمة البديلة.

النموذج الذهني الصحيح هنا هو صورة ثابتة، لا مرآة حية. يحدد استدعاء snapshot() تركيبًا للقراءة فقط، وتُنشأ نسخة النقطة الزمنية عندما يثبّتها sandbox القارئ. ويجب أيضًا أن تُكتب بيانات إلى Drive مرة واحدة على الأقل قبل تثبيت snapshot؛ إذ يعيد Drive غير المكتوب إليه الخطأ drive_not_initialized.

3. تأكد من رفض الكاتب الثاني

أبقِ sandbox واحدًا للقراءة والكتابة قيد التشغيل، وحاول إنشاء sandbox آخر بصلاحية القراءة والكتابة على Drive نفسه. لا تسمح Vercel إلا بتركيب واحد للقراءة والكتابة في الوقت ذاته. لا تحوّل الفشل المتوقع إلى سيل من محاولات الإعادة؛ ضع آلية lease أو طابورًا أمام الكتّاب، وأوقف المالك بصورة سليمة، واستخدم Drive.list() أو currentSandboxName عندما تحتاج إلى معرفة موضع الاتصال الحالي.

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

4. تأكد من تطابق المنطقة الرئيسية

أنشئ Drive في iad1، ثم حاول تثبيته في sandbox منطقته الرئيسية sfo1. توثّق Vercel خطأ عدم التطابق هذا باسم drive_region_mismatch. لا يمكن تغيير منطقة Drive بعد إنشائه، كما أن طلب getOrCreate() بالاسم نفسه مع منطقة أو حجم أقصى مختلفين يؤدي إلى خطأ conflict.

حدد المنطقة صراحة في الكائنين حتى إن كانت iad1 هي المنطقة الافتراضية. يمنع هذا الإعداد الواضح أي تغيير لاحق في القيمة الافتراضية للمشروع من تحويل إعادة تشغيل عادية إلى فشل سببه المنطقة.

بعد اختبار مؤقت، أوقف كل كاتب وقارئ، وتأكد عبر Drive.list() أو currentSandboxName من فصل Drive، ثم استدعِ await workspace.delete(). يحذف ذلك الملفات نهائيًا، وترفض Vercel تنفيذ الحذف ما دام أي sandbox متصلًا.

الفاتورة تتكوّن من أربعة بنود مستقلة

لا يحل تخزين Drive محل حوسبة الـsandbox، بل يضيف ثلاثة مقاييس تخزين إلى مقياس الحوسبة القائم. الأسعار المنشورة حاليًا في iad1 هي:

تختلف الأسعار بحسب المنطقة. تنزيلات الإنترنت، مثل حزم npm ومستودعات Git، مجانية، لكن CPU والذاكرة المحجوزة المستخدمين في تثبيتها يظلان ضمن الفاتورة. ولهذا قد تكون ذاكرة الاعتماديات المؤقتة مجدية: فهي تلغي تكرار الإعداد، لا رسوم نقل التنزيل.

إليك مثالًا تخطيطيًا مفيدًا لخطة Pro أو Enterprise، وليس اختبار أداء. تخزين شجرة اعتماديات بحجم 10 GB لشهر كامل يكلف $0.50. وقراءة الشجرة كاملة في 100 تشغيل تعني 1,000 GB من القراءات المنطقية، أي $1.50. أما كتابة 10 GB مرة واحدة فتكلف $0.04. وبذلك تبلغ حصة Drive وحده $2.04، قبل الحوسبة والذاكرة والنقل وأي كتابات لاحقة.

يقدّر مثال التسعير الذي تنشره Vercel تكلفة تشغيل للتحقق من شفرة AI مدته خمس دقائق ويستخدم 2-vCPU و4 GB بنحو $0.03 في iad1 عند استخدام CPU بنسبة 100%. لا تفترض أن Drive يوفر هذا المبلغ كاملًا. قِس جزء التثبيت الذي يزيله فعليًا، ثم قارن ما وفرته من الحوسبة ووقت الانتظار البشري بفاتورة التخزين والقراءة والكتابة في Drive.

تتضمن Hobby سعة تخزين Drive قدرها 15 GB، إلى جانب 30 GB شهريًا لكل من القراءة والكتابة. وبصورة منفصلة، يكون الحد الأقصى الافتراضي لكل Drive في Hobby هو 1 GiB. لا تفرض Hobby رسوم تجاوز؛ بل يتوقف إنشاء sandbox جديد بعد تخطي الحصة. وفي الخطط المدفوعة، يكون الحد الأقصى الافتراضي لـDrive هو 1 TiB عند حذف maxSize، ويمكن ضبط الحصة الافتراضية حتى 16 TiB.

سبع حالات استخدام مرتبة حسب المستفيد الأكبر

1. منتج وكيل برمجة لمشاريع يعود إليها المستخدم

خصص لكل مساحة عمل وكيل Drive مستقلًا، واحفظ المستودع والملفات المنشأة وملاحظات المهام وذاكرة الحزم المؤقتة تحت مسار التثبيت، ثم صِله بـsandbox جديد في الجولة التالية. يتجنب فريق المنتج إعادة بناء مساحة العمل نفسها بعد كل حدث في دورة حياة الـsandbox، ويحصل المستخدم على الاستمرارية من دون إبقاء الحوسبة عاملة.

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

2. فريق بناء يكرر تثبيت الاعتماديات نفسها

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

3. مسار مراجعة متعدد الوكلاء

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

4. فريق بيانات يعيد استخدام مجموعة بيانات مجهزة

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

5. وكيل بحث يجمع الملفات عبر جلسات متعددة

احفظ المراجع والنصوص المستخرجة والجداول الوسيطة وفهرس البحث المحلي على Drive. يستطيع sandbox جديد متابعة العمل من ذلك المجلد بدلًا من جمع المصادر وفهرستها مرة أخرى. المكسب هو مواد عمل قابلة لإعادة الإنتاج؛ أما الخطر فهو التعامل مع الملفات بوصفها حقيقة دائمة من دون نظام مستقل للنسخ الاحتياطي أو تتبع المصدر.

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

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

7. منصة تدريب بمشاريع طلابية قابلة للاستئناف

خصص Drive لكل مشروع، وثبّته في sandbox جديد عند بدء الجلسة، ثم افصله عند انتهائها. يحتفظ الطلاب بملفاتهم بينما تحرر المنصة موارد الحوسبة. يساعد قيد الكاتب الواحد على منع جلستين نشطتين من تعديل المشروع نفسه، لكن المنتج يظل بحاجة إلى قواعد مستقلة للهوية والنسخ الاحتياطي والاحتفاظ.

فكرتان لمنتجين يستحقان البناء

حجم البحث مؤشر إلى الطلب، لا توقعًا للإيرادات. السؤال المفيد هو: هل تزيل هذه الإمكانية مهمة مؤلمة عن فئة تبحث أصلًا عن حل؟

الخيار الأقوى: وسيط lease لمساحات عمل الوكلاء

ابنِ طبقة تحكم صغيرة تربط كل وكيل أو مشروع مستخدم بـDrive، وتمنح lease مؤقتًا لكاتب واحد، وتنشئ بيئات sandbox لقراء مجمدين مخصصين للاختبارات والمعاينات، وتعرض المنطقة وحالة الاتصال والحذف. ستدفع فرق بناء وكلاء البرمجة مقابل طبقة التنسيق لأن أداة التخزين الأولية لا تقرر من يملك حق الكتابة.

تُظهر بيانات الكلمات المفتاحية في الولايات المتحدة نحو 8,100 عملية بحث شهرية عن “ai powered coding agent”، مع نية تجارية. والسوق المجاور يتقبل أصلًا فاتورة منصة؛ إذ تعرض E2B خطة Pro بسعر $150 شهريًا إضافة إلى الاستخدام، بينما تندرج الجلسات الدائمة لعدة أيام ضمن فئة Enterprise المخصصة. ليست هذه مقارنة أسعار مباشرة، لكنها مؤشر واقعي إلى الميزانية لدى الفرق التي تشتري بنية الوكلاء التحتية.

يحتاج أصغر إصدار قابل للبيع إلى ربط كل مساحة عمل بـDrive، وطابور كتّاب بمدة صلاحية، وإنشاء قراء snapshot، وشاشة للاستخدام، وتنظيف آمن. التحدي هو بناء حاجز تنافسي حقيقي؛ إذ تستطيع Vercel أو إحدى أطر الوكلاء استيعاب غلاف بسيط، لذلك يحتاج المنتج إلى سياسات تشغيلية وسجل تدقيق واستعادة وقابلية نقل بين المزوّدين، لا مجرد زر أجمل لـgetOrCreate().

طبقة بدء دافئ لبيئات التطوير السحابية

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

تُظهر بيانات الكلمات المفتاحية في الولايات المتحدة نحو 1,900 عملية بحث شهرية عن “cloud integrated development environment”، مع CPC يبلغ $9.03. تشير قيمة البحث المدفوع هذه إلى تنافس المورّدين على هذا الجمهور. يمكن أن يبدأ MVP بنطاق ضيق: Node وpnpm أولًا، ومنطقة واحدة، وسياسة واحدة للذاكرة المؤقتة، ولوحة تفصل بين التخزين والقراءة والكتابة وActive CPU والذاكرة.

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

قيود ينبغي أن تغيّر تصميمك

• كاتب واحد يعني مالكًا واحدًا. نفّذ التغييرات بالتتابع. قراء snapshot مخصصون لتوزيع العمل، لا للتحرير التعاوني.
• القراء مجمدون. لا يتلقى القارئ العامل أي كتابة لاحقة. أعد إنشاءه باستخدام snapshot جديد.
• أول snapshot يحتاج إلى كتابة. هيئ Drive قبل تشغيل بيئات sandbox القارئة.
• يجب أن تتطابق المنطقة الرئيسية. يبقى Drive في منطقة واحدة ولا يمكن نقله. حدد المنطقة صراحة.
• يحصل sandbox على أربعة مسارات تثبيت. يجب أن يكون كل مسار مطلقًا، ولا يجوز أن تتداخل مسارات التثبيت.
• Drive ليس الجهاز كاملًا. استخدم snapshot للـsandbox إذا كنت تريد بيئة كاملة، واستخدم Drive لدليل ينبغي أن يتطور بصورة مستقلة.
• قد تكون القراءات الباردة أبطأ. تعمل قراءات إصابة الذاكرة المؤقتة والكتابات بسرعة NVMe، خلافًا لحالات الفقد التي تستدعي التخزين الدائم.
• الحذف نهائي. تصف Vercel استدعاء drive.delete() بأنه دائم، لذلك يجب ألا يكون Drive نسختك الاحتياطية الوحيدة.

ثمة تعارض قائم في الوثائق أيضًا. يقول إعلان 23 سبتمبر إن بيئات sandbox التي تثبّت Drives لا تستطيع استخدام مناطق failover، بينما تقول صفحة المناطق المؤرخة في 22 سبتمبر إن failover يستطيع تحميل Drive عبر المناطق مع زمن قراءة أعلى. إلى أن توحّد Vercel هذين الوصفين، تعامل في تصميمك مع failover الخاص بـDrive بوصفه غير مدعوم، واختبره مجددًا قبل الاعتماد عليه.

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

ما ينبغي فعله يوم الاثنين

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

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