متطلبات صندوق الرمل للكود المولّد بالذكاء الاصطناعي للتطبيقات الإنتاجية

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

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

عزل صندوق الرمل: العملية، الحاوية، والآلة الافتراضية الصغرى

العزل هو طيف، وكل مستوى يحمل مقايضات مختلفة للأداء، وقابلية النقل، ومدى الثقة التي تمنحها للكود المُولّد.

عزل مستوى العملية يستخدم مبادئ نظام التشغيل — مساحات الأسماء، مجموعات التحكم (cgroups)، seccomp، وملفات تعريف AppArmor أو SELinux — لتقييد ما يمكن للعملية الوصول إليه. إنه سريع ولا يتطلب نواة VM منفصلة، لكن جميع العمليات تشارك نواة المضيف. ثغرة في النواة أو استدعاء نظام مُميّز يتسلل عبر مرشح seccomp يمكن أن يؤثر على أعباء العمل الأخرى على نفس المضيف. عزل العملية هو نقطة انطلاق معقولة لمسارات كود منخفضة المخاطر، قصيرة العمر، وموثوقة، لكنه حدود ضعيفة للكود غير الموثوق المُولّد بالذكاء الاصطناعي الذي قد يحاول استدعاءات نظام، أو إنشاء عمليات فرعية، أو تثبيت حزم.

ما يجب التحقق منه في هذا المستوى:

• أي استدعاءات نظام محظورة، وما هي السياسة الافتراضية عند محاولة استدعاء نظام غير معروف؟
• هل مساحات الأسماء محددة لكل مهمة، لكل مستأجر، أم مشتركة عبر المهام؟
• هل حدود مجموعات التحكم (cgroups) مفروضة على مستوى المهمة أم فقط على مستوى المضيف؟
• هل يقوم صندوق الرمل بتنظيف جميع العمليات، الملفات المؤقتة، المقابس، والذاكرة المشتركة عند الخروج؟

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

ما يجب التحقق منه في هذا المستوى:

• هل صورة الحاوية ضئيلة، مع فقط بيئات التشغيل والأدوات التي يحتاجها عبء العمل فعليًا؟
• هل تم إسقاط القدرات إلى الحد الأدنى المطلوب؟
• هل الحاوية بدون جذر (rootless)، أم تتطلب صلاحيات الجذر وما هي الضوابط حول ذلك؟
• هل مساحة اسم PID للمضيف، وشبكة المضيف، ومقبس Docker مستبعدة صراحةً؟
• هل وحدات التخزين المثبتة محدودة بمسارات محددة صراحةً، وهل نظام الملفات الجذر للقراءة فقط حيثما أمكن؟

عزل الآلة الافتراضية الصغرى (MicroVM) يضع كل عبء عمل داخل جهاز افتراضي خفيف الوزن — مع نواة ضيف خاصة به، وأجهزة افتراضية، وحد KVM بين الضيف والمضيف. تقنيات مثل Firecracker تستخدم نموذج جهاز ضئيل لتقليل سطح الهجوم مع الحفاظ على سرعة البدء كافية للاستخدام التفاعلي. حد MicroVM يعني أن استغلال النواة في الضيف لا يؤثر تلقائيًا على المضيف أو الضيوف الآخرين.

ما يجب التحقق منه في هذا المستوى:

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

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

إدارة جلسات صندوق الرمل المتزامنة

تطبيق إنتاجي يُولّد كودًا لعدة مستخدمين في وقت واحد يحتاج إلى صندوق رمل يتعامل مع التزامن كأمر من الدرجة الأولى، وليس فكرة لاحقة.

الأسئلة الرئيسية هي:

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

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

عدالة الموارد تحت الحمل: عندما تستهلك جلسة واحدة قدرًا غير عادي من وحدة المعالجة المركزية أو الذاكرة، هل الجلسات الأخرى محمية بحدود موارد لكل جلسة، أم يمكن لعبء عمل واحد صاخب أن يُردي المجموعة بأكملها؟

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

إعادة استخدام الجلسة مقابل البيئات الجديدة: تستفيد بعض التطبيقات من إعادة استخدام جلسة طويلة العمر عبر عدة أدوار للوكيل، بينما يحتاج البعض الآخر إلى بيئة نظيفة لكل طلب. تحقق من دعم كلا النمطين وأن إعادة استخدام الجلسة لا تحمل حالة قديمة من محادثة سابقة.

واجهة برمجة دورة الحياة: إنشاء، تنفيذ، إنهاء

واجهة برمجة دورة الحياة هي الواجهة بين تطبيقك وبيئة تشغيل صندوق الرمل. يجب أن تُتيح واجهة برمجة إنتاجية على الأقل:

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

تنفيذ: إرسال كود أو أمر للتنفيذ. يجب أن يكون هذا استدعاءً غير متزامن يُعيد معرف تنفيذ. يجب أن تدعم API تحديد دليل عمل، تجاوزات بيئة للاستدعاء، ومهلة زمنية.

دفق الإخراج: استرداد stdout و stderr كدفق، وليس فقط كنتيجة نهائية بعد اكتمال التنفيذ. البث مهم للمهام طويلة الأمد، وخطوات الوكيل التي تستغرق عدة ثوان، وأي تجربة مستخدم تُظهر للمستخدم تقدمًا تدريجيًا.

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

تنظيف: تدمير الجلسة وتحرير جميع الموارد المرتبطة — نظام الملفات، الذاكرة، فتحات العمليات، حالة الشبكة، وأي بيانات اعتماد محتفظ بها. يجب أن يكون هذا الاستدعاء غير قابل للتغيير (idempotent) بحيث لا تؤدي إعادة المحاولة بعد خطأ في الشبكة إلى أخطاء.

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

قدرات إضافية تستحق التحقق منها للاستخدام الإنتاجي:

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

قابلية المراقبة: السجلات، المقاييس، والتتبعات

لا يمكنك تصحيح الأخطاء أو تدقيق ما لا يمكنك رؤيته. تحتاج صناديق الرمل الإنتاجية إلى قابلية مراقبة مبنية من الداخل، وليست مُلحقة من الخارج.

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

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

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

تتبع الأخطاء: عندما يفشل صندوق الرمل في البدء أو التنفيذ أو التنظيف، يجب أن يكون سطح الخطأ منظمًا: رمز الخطأ، الرسالة، معرف الجلسة، وسياق كافٍ للتمييز بين خطأ المستخدم (كود سيئ، حزمة مفقودة) وخطأ المنصة (تجاوز الحصة، فشل داخلي).

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

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

حدود وحدة المعالجة المركزية، الذاكرة، والمهلة الزمنية

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

يجب على صندوق الرمل الإنتاجي فرض الحدود على مستوى الجلسة، وليس فقط على مستوى المضيف:

وحدة المعالجة المركزية (CPU): حدد مقدار وقت وحدة المعالجة المركزية الذي يمكن أن تستهلكه جلسة واحدة. الجلسة التي تُنشئ حلقة لا نهائية يجب ألا تُردي الجلسات الأخرى على نفس المضيف. تحقق مما إذا كان الحد صارمًا (يتم خنق العملية أو قتلها) أم حدًا مرنًا (تتنافس مع عمليات أخرى على وحدة المعالجة المركزية المتاحة).

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

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

استخدام القرص: قد يكتب الكود المُولّد ملفات مخرجات كبيرة، أو يُثبّت حزمًا كبيرة، أو يملأ دليل العمل. حصة قرص على دليل عمل الجلسة تمنع الكتابة الجامحة.

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

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

سياسات تثبيت الحزم

يطلب الكود المُولّد بالذكاء الاصطناعي بشكل متكرر تثبيت حزم — pip install، npm install، apt-get، استنساخ Git، جلب URL مباشر. كل من هذه العمليات تسحب كودًا خارجيًا إلى صندوق الرمل في وقت التشغيل، وهي واحدة من أعلى العمليات خطرًا التي يحتاج صندوق الرمل إلى حوكمتها.

يجب أن تغطي سياسة الحزم الإنتاجية ما يلي:

قوائم السماح للسجلات: أي سجلات الحزم مسموح بها؟ PyPI و npm هما الافتراضيان، لكن العديد من الفرق تريد خيار التقييد بمرايا داخلية، أو سجلات منسقة، أو مصادر معتمدة صراحةً.

تخزين مؤقت للتثبيت: عندما تُثبّت العديد من الجلسات نفس الحزم الشائعة، فإن ذاكرة تخزين مؤقت للطبقة أو وكيل سحب (pull-through) يتجنب التنزيلات المكررة، ويُقلل زمن استجابة البدء، ويمنحك نقطة لفحص ما يتم جلبه.

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

التحقق من التجزئة وملفات القفل: عندما يُسمح بالحزم، فإن الإصدارات المثبتة والتجزئة المؤكدة تُقلل من خطر تسوية السجل الذي يُغير الكود الذي يعمل داخل صندوق الرمل.

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

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

السؤال الذي يجب طرحه على بائع صندوق الرمل ليس “هل يمكن للمستخدمين تثبيت الحزم؟” بل “كيف يتم تدقيق كل تثبيت، وما هي السجلات المسموح بها افتراضيًا، وهل يمكنني تكوين سياسة أكثر صرامة لأعباء العمل الحساسة؟”

ضوابط الشبكة والخروج

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

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

الوجهات المسموح بها: لوكلاء البرمجة، قد تشمل الوجهات المسموح بها النموذجية سجلات الحزم، مجموعة محددة من واجهات برمجة التطبيقات العامة التي بُني الوكيل لاستدعائها، ولا شيء غير ذلك. لوكلاء تحليل البيانات، قد تشمل القائمة مصادر بيانات محددة. تحقق مما إذا كانت المنصة تدعم قوائم السماح للوجهات لكل جلسة أو لكل مستأجر.

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

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

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

تسجيل الاتصالات الصادرة: حتى عندما يُسمح بالخروج، فإن تسجيل النطاقات وعناوين IP التي اتصلت بها الجلسة مفيد للتحقيق في الحوادث. لا توفر جميع منصات صندوق الرمل هذا بشكل أصلي؛ تحقق مما ستحصل عليه.

الأسرار وحقن بيانات الاعتماد

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

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

بيانات اعتماد قصيرة العمر: حيث تدعم الخلفية ذلك، فضّل الرموز قصيرة العمر مع TTL محدود بنطاق الجلسة. هذا يحد من النافذة التي تكون خلالها بيانات الاعتماد المسربة مفيدة.

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

التنقيح: يجب ألا يُعيد صندوق الرمل الأسرار من خلال stdout، stderr، سجلات التنفيذ، رسائل الخطأ، أو استجابات الأدوات المرئية للنموذج. التنقيح هو مسؤولية طبقة التطبيق، لكن صندوق الرمل الذي يدعم تنظيف السجلات القابل للتكوين يُقلل من نصف قطر الانفجار للتعرض العرضي.

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

تخزين الملفات المؤقت مقابل الدائم

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

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

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

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

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

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

التكامل الخلفي: REST، WebSocket، SDK

صندوق الرمل مفيد فقط إذا اندمج بسلاسة في الخلفية التطبيقية. أنماط التكامل الثلاثة الرئيسية هي REST و WebSocket و SDK.

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

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

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

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

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

استرداد الفشل والتنظيف

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

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

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

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

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

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

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

Novita Agent Sandbox

Novita Agent Sandbox هي منصة صندوق رمل مُدارة مبنية لأعباء عمل الوكيل. تستهدف وكلاء البرمجة، وكلاء تحليل البيانات، وسير عمل الموجهة للمتصفح، وجلسات الوكيل الأطول حيث يحتاج الكود المُولّد إلى العمل في بيئة معزولة وقابلة للمراقبة دون الهبوط على خوادم التطبيق أو البنية التحتية المشتركة.

بالنسبة للفرق التي تستخدم بالفعل واجهات برمجة نموذج Novita AI، يمكن أن يكون Agent Sandbox جزءًا من بنية وكيل أوسع: النموذج يخطط ويُولد الكود، صندوق الرمل يُوفّر تنفيذًا معزولًا مع دورة حياة قابلة للبرمجة، وطبقة التطبيق تمتلك التفويض، وبوابات الموافقة، ومعالجة النتائج.

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

عند تقييم Novita Agent Sandbox مقابل المتطلبات في هذا الدليل، طبق قائمة المراجعة نفسها كما مع أي بائع آخر: حدود العزل لكل جلسة، واكتمال واجهة برمجة دورة الحياة، سطح قابلية المراقبة، حدود الموارد القابلة للتكوين، خيارات سياسة الحزم، ضوابط الخروج، معالجة الأسرار، نموذج الاستمرارية، ودعم التكامل الخلفي.

الأسئلة الشائعة

ما نموذج العزل الذي يجب أن أختاره للكود المُولّد بالذكاء الاصطناعي؟

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

كيف أتعامل مع تثبيتات الحزم في صندوق رمل إنتاجي؟

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

ما الذي يجب أن تُتيحه واجهة برمجة دورة الحياة كحد أدنى؟

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

كيف أمنع تسرب الأسرار عبر صندوق الرمل؟

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

---

مقالات مُوصى بها

• Firecracker لصناديق رمل وكيل الذكاء الاصطناعي: الفوائد، الحدود، وأسئلة التقييم
• خوادم MCP في صناديق رمل معزولة: مقايضات نظام الملفات، الأسرار، والشبكة
• بناء محلل بيانات ذكاء اصطناعي مع Python مُعزَل ووصول محكوم للحزم