- لماذا نستخدم صندوق الرمل لوكلاء الذكاء الاصطناعي
- نماذج عزل صندوق الرمل
- الخروج من صندوق الرمل وسياسة الشبكة
- الوصول إلى الملفات ونظام ملفات المضيف
- حالة الجلسة والاستمرارية
- تثبيت الحزم والتبعيات في وقت التشغيل
- التعامل مع الأسرار وبيانات الاعتماد
- سجلات التدقيق والمراقبة
- الامتثال والمراجعة الأمنية
- تسعير صندوق الرمل ومحركات التكلفة
- الاستضافة الذاتية مقابل صندوق رمل وكيل الذكاء الاصطناعي المُدار
- تشغيل الكود غير الموثوق بأمان
- مقالات موصى بها
تجيب هذه الأسئلة الشائعة حول صندوق رمل وكلاء الذكاء الاصطناعي على أسئلة الأمان العملية التي يطرحها المطورون قبل تشغيل الكود الذي يولده الوكيل: كيف يعمل العزل، وما هو وصول الشبكة للوكلاء، وأين تذهب الملفات وحالة الجلسة، وكيفية التعامل مع الأسرار وسجلات التدقيق والامتثال والتكلفة. إذا كنت جديدًا في صناديق الرمل، ابدأ بـ ما هو صندوق رمل وكيل الذكاء الاصطناعي؟ للحصول على أساس حول نماذج العزل والخروج والتصوير اللحظي. إذا كنت تختار مزودًا، فراجع أفضل صناديق رمل وكلاء الذكاء الاصطناعي في 2026 أو دليل تقييم E2B مقابل Daytona.
لماذا نستخدم صندوق الرمل لوكلاء الذكاء الاصطناعي
لماذا تستخدم الفرق صندوق رمل مخصص لوكلاء الذكاء الاصطناعي؟
يختلف وكلاء الذكاء الاصطناعي عن البرامج التقليدية في جانب جوهري واحد: الكود الذي يشغلونه ليس مكتوبًا بواسطة إنسان ولا تتم مراجعته قبل التنفيذ. يولد LLM تعليمات، ويختار أدوات، ويُثبّت حزمًا، ويقوم باستدعاءات API بشكل ديناميكي - غالبًا بطرق لم يحددها مطور التطبيق مسبقًا. يمنحك صندوق الرمل طبقة إنفاذ وقت التشغيل تحتوي على عواقب هذه الإجراءات دون الحاجة إلى الموافقة المسبقة على كل إجراء محتمل. بدون صندوق رمل، يمكن لوكيل سيء السلوك أو تم التلاعب به أن يؤثر على النظام المضيف أو أحمال العمل المجاورة أو البنية التحتية الخارجية. مع صندوق الرمل، يقتصر نصف قطر الانفجار الأسوأ على البيئة المعزولة، والتي يمكن التخلص منها بعد الجلسة.
ما هو تنفيذ كود وكيل الذكاء الاصطناعي؟
تنفيذ كود وكيل الذكاء الاصطناعي هو مرحلة وقت التشغيل حيث تصبح قرارات LLM تعليمات فعلية يقوم الكمبيوتر بتنفيذها. يتلقى الوكيل مهمة، ويحللها، ويولد كودًا أو استدعاءات أدوات، وتقوم طبقة التنفيذ بتشغيل تلك الإجراءات وإرجاع النتائج إلى الوكيل. صندوق الرمل هو طبقة البنية التحتية القياسية لهذه المرحلة التنفيذية: فهو يوفر بيئة الحوسبة ونظام الملفات والشبكة التي يحتاجها الوكيل، مع الحفاظ على تلك البيئة معزولة عن كل شيء آخر. تتكرر دورة “يفكر النموذج ← تشغل طبقة التنفيذ ← تغذي النتائج النموذج” حتى يكمل الوكيل المهمة.
كيف يختلف العزل باستخدام صندوق الرمل عن مجرد تشغيل وكيل في حاوية؟
تضيف الحاوية فصلًا لنظام الملفات ومساحة اسم الشبكة، لكن جميع الحاويات على نفس المضيف تشترك في نواة نظام التشغيل. بالنسبة لوكلاء الذكاء الاصطناعي الذين يشغلون كودًا مولّدًا من LLM من مدخلات غير موثوقة، يمكن أن يؤثر اختراق على مستوى النواة من خلال ثغرة مشتركة على أحمال العمل المجاورة. يضيف صندوق رمل مخصص لوكلاء الذكاء الاصطناعي عادةً حدود آلة افتراضية صغيرة (microVM): يعمل كود الوكيل داخل آلة افتراضية خفيفة الوزن مع نواة ضيف خاصة بها، لذلك حتى اختراق على مستوى النواة في الضيف لا يؤثر على المضيف. المفاضلة العملية هي تكلفة إضافية صغيرة في وقت بدء التشغيل البارد (عادةً أقل من 500 مللي ثانية للمنصات القائمة على Firecracker). راجع قسم نماذج العزل للحصول على مقارنة كاملة.
نماذج عزل صندوق الرمل
ماذا يعني “العزل” في صندوق رمل وكيل الذكاء الاصطناعي؟
العزل يعني أن كود الوكيل، وملفاته، وعملياته، ووصوله إلى الشبكة محصورة في بيئة محدودة لا يمكنها التأثير على النظام المضيف أو المستأجرين الآخرين. من الناحية العملية، العزل هو طيف: يستخدم العزل على مستوى العملية بدائيات OS (مساحات الأسماء، cgroups، seccomp) لتقييد استدعاءات النظام والوصول إلى الموارد؛ يضيف عزل الحاوية حدودًا لنظام الملفات ومساحة اسم الشبكة؛ ويغلف عزل microVM حمل العمل في آلة افتراضية خفيفة الوزن مع نواة ضيف خاصة بها. كل خطوة للأعلى في المكدس تزيد من قوة الحدود على حساب بعض الحمل الزائد في بدء التشغيل والتعقيد التشغيلي. للحصول على نظرة عامة شاملة لجميع أبعاد العزل، راجع ما هو صندوق رمل وكيل الذكاء الاصطناعي؟. راجع Firecracker لصناديق رمل وكلاء الذكاء الاصطناعي للحصول على إطار تقييم مفصل.
هل Docker كافٍ لتشغيل كود يولده الوكيل؟
تمنحك الحاويات صورًا قابلة للتكرار وتحكمًا جيدًا في الموارد، لكن جميع الحاويات على نفس المضيف تشترك في نواة المضيف. يمكن لثغرة في النواة، أو استدعاء نظام ينزلق عبر مرشح seccomp، أن تؤثر على أحمال العمل الأخرى. بالنسبة للمهام منخفضة المخاطر وقصيرة العمر التي تشغل كودًا موثوقًا أو شبه موثوق، غالبًا ما تكون الحاويات كافية عند تقويتها بشكل صحيح - لا وضع مميز، أقل قدر من الإمكانيات، لا يتم تحميل مقبس Docker، نظام ملفات جذر للقراءة فقط حيثما أمكن. بالنسبة للكود غير الموثوق الذي يولده الذكاء الاصطناعي والذي قد يُثبّت حزمًا أو ينتج عمليات فرعية أو يستدعي أوامر شل عشوائية، فإن الحدود الأقوى تستحق التقييم. تعتمد الإجابة على نموذج التهديد الفعلي الخاص بك. راجع صندوق رمل الكود المولد بالذكاء الاصطناعي: متطلبات تطبيقات الإنتاج للحصول على قائمة التحقق عند كل مستوى عزل.
ما الفرق بين عزل الحاوية وعزل microVM؟
الفرق الرئيسي هو حدود النواة. تشترك الحاويات في نواة المضيف؛ كل microVM يشغل نواة ضيف داخل آلة افتراضية خفيفة الوزن، مدعومة بالمحاكاة الافتراضية للأجهزة (KVM). يوفر صندوق الرمل القائم على microVM باستخدام تقنية مثل Firecracker حدودًا على غرار VM دون الحمل الزائد الكامل لجهاز VM تقليدي: زمن بدء التشغيل مصمم ليكون سريعًا، ونموذج الجهاز ضئيل لتقليل سطح الهجوم، والضيف معزول عن نواة المضيف بطبيعته. التأثير العملي هو أن اختراق النواة في الضيف لا يؤثر تلقائيًا على المضيف أو الضيوف الآخرين، بينما في نموذج الحاوية ذات النواة المشتركة قد يحدث ذلك. راجع Firecracker لصناديق رمل وكلاء الذكاء الاصطناعي لمعرفة أين تساعد حدود microVM وأين لا تحل المشكلة بأكملها.
هل يوجد صندوق رمل واحد لكل وكيل، أو لكل مستخدم، أو لكل مهمة؟
يعتمد ذلك على النظام الأساسي وكيفية تصميم التطبيق. النمط الأكثر أمانًا للتطبيقات متعددة المستأجرين هو بيئة صندوق رمل معزولة واحدة لكل تشغيل وكيل أو لكل مهمة - مما يعني أن جلسة كل مستخدم لها شجرة العمليات الخاصة بها، ونظام الملفات، ومساحة اسم الشبكة، ونطاق بيانات الاعتماد الخاصة بها. مشاركة صندوق الرمل عبر المستخدمين أو عبر المهام غير المرتبطة هي المصدر الأكثر شيوعًا لتسرب الحالة في تطبيقات الوكيل في الإنتاج. عند تقييم نظام أساسي، تحقق من أن الجلسات المتزامنة معزولة على مستوى نظام الملفات والعملية والشبكة، وليس فقط على مستوى توجيه API. راجع صندوق رمل الكود المولد بالذكاء الاصطناعي: متطلبات تطبيقات الإنتاج للحصول على قائمة التحقق لعزل كل جلسة.
الخروج من صندوق الرمل وسياسة الشبكة
هل يمكن لوكيل الذكاء الاصطناعي إجراء استدعاءات شبكة صادرة من صندوق الرمل؟
يعتمد ذلك على سياسة الخروج الخاصة بصندوق الرمل. بشكل افتراضي، تسمح العديد من صناديق الرمل بالاتصالات الصادرة، وهو أمر مناسب للبحث على الويب واستدعاءات API وتثبيت الحزم. بالنسبة لأحمال عمل الإنتاج التي تشغل كودًا غير موثوق، فإن الخروج المفتوح افتراضيًا هو خطر: يمكن لوكيل مخترق أو سيء السلوك تسريب البيانات، أو الوصول إلى خدمات البيانات الوصفية الداخلية، أو سحب كود غير متوقع من عناوين URL عشوائية. وضع إنتاج أقوى هو رفض الخروج افتراضيًا مع قائمة سماح صريحة للوجهات المسموح بها. مهما كانت السياسة التي تختارها، يجب أن تكون صريحة ومسجلة. راجع Firecracker لصناديق رمل وكلاء الذكاء الاصطناعي لمعرفة كيفية تقييم عناصر التحكم في الشبكة.
كيف يتم التحكم في DNS داخل صندوق الرمل؟
DNS هو فجوة شائعة في سياسة الخروج: قائمة السماح لوجهات HTTP لا تقيد تلقائيًا تحليل DNS. الوكيل الذي يمكنه تحليل أسماء النطاقات العشوائية يمكنه استنتاج طوبولوجيا الشبكة، واختبار الأسماء الداخلية، أو استخدام DNS كقناة جانبية حتى عند حظر HTTP. للحصول على سياسة خروج متماسكة، يجب معالجة تحليل DNS بشكل متسق - إما عن طريق التوجيه إلى محلل داخلي يحترم قائمة السماح، أو تقييد التحليل للنطاقات المعتمدة. تحقق مع مزود صندوق الرمل الخاص بك كيف يتم تحديد نطاق DNS بالنسبة لسياسة الخروج الأوسع.
كيف يتم التحكم في جلب الحزم أثناء الجلسات المقيدة الشبكة؟
تثبيتات الحزم هي عمليات شبكة. إذا كان الخروج مقيدًا بقائمة سماح، فيجب أن تتضمن قائمة السماح سجلات الحزم التي يحتاجها الوكيل بشكل مشروع، أو يجب أن يوفر صندوق الرمل ذاكرة تخزين مؤقت للسحب عبر (pull-through cache) داخل الشبكة الموثوقة. لذاكرة التخزين المؤقت للسحب عبر فائدة إضافية تتمثل في العمل كنقطة تفتيش: يمكنك رؤية أي الحزم تم جلبها، واكتشاف التبعيات غير المتوقعة، وتقليل الخروج الزائد عن الحاجة. تستخدم بعض الفرق قوالب صندوق رمل مُعدّة مسبقًا لأحمال العمل حيث تكون قابلية التكرار أكثر أهمية من المرونة، مما يلغي جلب الحزم في وقت التشغيل تمامًا. راجع قسم تثبيت الحزم للحصول على مزيد من المعلومات حول حوكمة التثبيتات في وقت التشغيل.
الوصول إلى الملفات ونظام ملفات المضيف
ما هو وصول الملفات الذي يمتلكه الوكيل المعزول؟
يجب أن يكون للوكيل المعزول وصول فقط إلى الملفات المثبتة صراحةً في مساحة العمل الخاصة به. بالنسبة لوكيل البرمجة، قد يكون ذلك مستودعًا تم سحبه ودليل عمل للقطع الأثرية المنشأة. بالنسبة لوكيل تحليل البيانات، قد يكون ذلك ملف CSV تم رفعه ومجلد إخراج. يجب ألا يتمكن الوكيل من الوصول إلى نظام ملفات المضيف، أو مساحات عمل المستأجرين الآخرين، أو أسرار خادم التطبيق، أو أدلة النظام خارج مساراته المثبتة. الممارسة الجيدة هي تثبيت المواد المصدر للقراءة فقط وتوفير دليل إخراج منفصل للقراءة والكتابة للقطع الأثرية المنشأة. راجع صندوق رمل خادم MCP: خوادم MCP معزولة مع عناصر تحكم في نظام الملفات والأسرار والشبكة لمعرفة كيفية تحديد نطاق تركيبات نظام الملفات لكل أداة.
هل نظام ملفات المضيف قابل للوصول من داخل صندوق الرمل؟
لا ينبغي أن يكون كذلك. صندوق الرمل المهيأ بشكل صحيح - حاوية أو microVM - يقيد رؤية الوكيل لنظام الملفات الخاص بالضيف فقط. الوصول إلى نظام ملفات المضيف من داخل صندوق الرمل هو فشل في التكوين، وليس سلوكًا متوقعًا. تشمل الأخطاء الشائعة التي تكسر هذه الحدود تثبيت أدلة واسعة (مثل دليل المنزل للمطور أو /)، أو استخدام الوضع المميز في الحاويات، أو تثبيت مقبس Docker في صندوق الرمل. عند تقييم نظام أساسي أو بناء نظام خاص بك، تحقق مما هو مثبت، وما هي أذونات نظام ملفات الجذر، وما إذا كان بإمكان عمليات الهروب عبر الروابط الرمزية أو حيل استخراج الأرشيف الوصول إلى مسارات خارج مساحة العمل المقصودة.
ماذا يحدث للملفات بعد انتهاء الجلسة؟
بالنسبة للجلسات المؤقتة، يتم تدمير دليل العمل وجميع الملفات المنشأة عند انتهاء الجلسة. هذا هو الإعداد الافتراضي الصحيح لإكمال الكود، وتشغيلات التقييم، وأي مهمة حيث تكون قابلية التكرار أكثر أهمية من الاستمرارية. بالنسبة لمساحات العمل الدائمة (وكلاء البرمجة طويلة المدى، جلسات التطوير التكرارية)، يمكن أن تبقى الملفات عبر استدعاءات التنفيذ داخل الجلسة ويمكن الاحتفاظ بها بعد انتهاء الجلسة إذا كان النظام الأساسي يدعم استمرارية مساحة العمل أو اللقطات. الأسئلة الرئيسية التي يجب الإجابة عليها هي: من يملك مساحة العمل المحتجزة، ومتى يتم تنظيفها، وهل يمكن أن تتسرب مساحة عمل أحد المستخدمين إلى آخر؟ راجع صندوق رمل الكود المولد بالذكاء الاصطناعي: متطلبات تطبيقات الإنتاج للحصول على قائمة التحقق لنموذج الاستمرارية.
حالة الجلسة والاستمرارية
هل جلسة صندوق الرمل ذات حالة أم مؤقتة؟
كلا النمطين موجودان ويخدمان أحمال عمل مختلفة. تبدأ الجلسات المؤقتة من خط أساس نظيف لكل مهمة - لا توجد حزم أو ملفات أو تاريخ متراكم. يسهل التفكير فيها وهي مثالية لتشغيلات التقييم أو تنفيذ الكود لمرة واحدة. تحافظ الجلسات ذات الحالة على الملفات والحزم المثبتة وتاريخ الشل وحالة البيئة عبر استدعاءات تنفيذ متعددة، وهو أمر ضروري لوكلاء البرمجة متعددي الخطوات، وتحليل البيانات التفاعلي، وسير العمل الطويل. تدعم معظم المنصات الإنتاجية كليهما. المفاضلة هي أن الجلسات ذات الحالة تتطلب سياسات تنظيف صريحة وعزلًا أكثر دقة للمستأجرين.
كم من الوقت تستمر الحالة في صندوق رمل مُدار؟
تختلف مدة الجلسة حسب النظام الأساسي والخطة. يحدد بعض المزودين مهلة جلسة افتراضية (شائعة من 60 دقيقة إلى 24 ساعة)، وبعدها يتم إنهاء الجلسة وتفقد الحالة ما لم يتم الاحتفاظ بها في لقطة أو تخزين خارجي. سير عمل الوكيل الطويل - الجلسات التي قد تتوقف بين استدعاءات LLM لدقائق أو ساعات - تحتاج إلى نظام أساسي يدعم إيقاف الجلسة مؤقتًا واستئنافها أو الإيقاف التلقائي لتجنب الفوترة لوقت الخمول مع الحفاظ على الحالة. تحقق من الحد الأقصى لطول الجلسة وما يحدث للحالة قيد التشغيل عند حدوث مهلة. يدعم Novita Agent Sandbox جلسات تصل إلى 24 ساعة ويوثق قدرة الإيقاف المؤقت/الاستئناف التلقائي لإدارة وقت الخمول. راجع Novita Sandbox: بديل فعال من حيث التكلفة لـ E2B Pro مع توافق سلس لمقارنة الميزات.
هل يمكن إيقاف الجلسات مؤقتًا واستئنافها؟
تدعم بعض المنصات الإيقاف المؤقت والاستئناف، حيث يتم تعليق الجلسة على القرص ويمكن إعادة تشغيلها لاحقًا من نفس الحالة. هذا مفيد للوكلاء الذين ينتظرون ردود LLM بين الخطوات، للحد من أحمال العمل باهظة الثمن، وللجلسات التي تمتد عبر تفاعلات مستخدم متعددة بمرور الوقت. الأمور الرئيسية التي يجب التحقق منها هي: كم من الوقت يمكن أن تبقى الجلسة الموقوفة معلقة، وماذا يحدث لاتصالات الشبكة المحتجزة أثناء الإيقاف المؤقت، وما إذا كانت بيانات الاعتماد المحقونة في بداية الجلسة تظل صالحة بعد الاستئناف أو تحتاج إلى تحديث.
هل يمكن أخذ لقطة لحالة صندوق الرمل وإعادة استخدامها؟
القوالب واللقطات مرتبطة لكنها متميزة. القالب هو بيئة أساسية مبنية مسبقًا - بيئات تشغيل، أدوات، حزم معتمدة - تبدأ منها الجلسات الجديدة. اللقطة تلتقط الحالة الحالية لجلسة قيد التشغيل وتستخدمها كنقطة بداية للجلسات المستقبلية. تقلل القوالب من الحمل الزائد لبدء التشغيل لكل جلسة وتضمن أن جميع الوكلاء يبدأون من خط أساس متسق وخاضع للحوكمة. اللقطات مفيدة للحفاظ على العمل الجزئي أو بدء المهام التكرارية بشكل دافئ. كلاهما يحتاج إلى حوكمة: من يمكنه إنشاؤها، ومن يمكنه قراءتها، وأي مستأجر تنتمي إليه، وكيف يتم إدارة إصداراتها.
تثبيت الحزم والتبعيات في وقت التشغيل
هل يمكن للوكلاء تثبيت الحزم في وقت التشغيل؟
تسمح معظم بيئات صندوق الرمل بتثبيت الحزم في وقت التشغيل (pip install، npm install، apt-get، إلخ) بشكل افتراضي لأن العديد من أعباء عمل الوكيل تحتاج إليها. السؤال ليس ما إذا كان التثبيت مسموحًا به، بل ما إذا كان كل تثبيت خاضعًا للحوكمة. تثبيتات الحزم غير الخاضعة للحوكمة هي واحدة من أعلى العمليات خطورة في صندوق الرمل: فهي تسحب كودًا خارجيًا إلى بيئة التنفيذ في وقت التشغيل، ويمكن أن تتضمن نصوصًا بعد التثبيت تنفذ أوامر عشوائية، وقد تقدم مخاطر سلسلة التوريد.
ما السياسات التي تحكم تثبيت الحزم في وقت التشغيل؟
تتضمن سياسة الحزم في الإنتاج عادةً مجموعة من السماح بسجل الحزم (الجلب فقط من سجلات الحزم أو المرايا المعتمدة)، وذاكرة التخزين المؤقت للسحب عبر (فحص ما يدخل قبل تنفيذه)، وتسجيل التثبيت (تسجيل اسم الحزمة، الإصدار، المصدر، والنتيجة لكل تثبيت)، ووضع عدم الاتصال الاختياري (تثبيت التبعيات مسبقًا في القالب ومنع تثبيتات وقت التشغيل لخطوط أنابيب التقييم حيث تكون قابلية التكرار مهمة). تعتمد السياسة الصحيحة على عبء العمل: قد يحتاج وكيل البرمجة الذي يساعد مطورًا في تصحيح الكود إلى وصول مرن للحزم؛ يجب أن يعمل خط أنابيب التقييم الآلي من بيئة مجمدة على الأرجح. راجع بناء محلل بيانات ذكي باستخدام Python في صندوق رمل مع وصول محكوم للحزم للحصول على مثال تنفيذي عملي.
التعامل مع الأسرار وبيانات الاعتماد
كيف يتم التعامل مع الأسرار وبيانات الاعتماد في صندوق الرمل؟
يجب حقن الأسرار بشكل ضيق - فقط بيانات الاعتماد التي تحتاجها مهمة محددة، لمدة تلك الجلسة. النمط المعاكس الشائع هو تثبيت ملف بيئة واسع يحتوي على جميع مفاتيح API في كل جلسة؛ وهذا يعني أن أي جلسة، إذا تم اختراقها، يمكنها الوصول إلى كل بيانات الاعتماد في هذا الملف. يُفضل استخدام الرموز قصيرة العمر المقتصرة على المهمة، ويُفضل آليات الحقن (متغيرات البيئة أو الملفات المثبتة) على الترميز الثابت. بالنسبة لبيانات الاعتماد الأكثر حساسية، توفر API أسرار وقت التشغيل التي توفر القيم فقط لعملية مصرح بها صراحةً عزلًا أقوى من متغير بيئة مسطح متاح لجميع العمليات.
هل يمكن للنموذج رؤية متغيرات البيئة المحقونة في صندوق الرمل؟
نعم، إذا تم حقن متغير البيئة في العملية التي يعمل فيها كود النموذج. تكون متغيرات البيئة مرئية لجميع العمليات في نفس الجلسة بشكل افتراضي. لا يمكن للنموذج قراءتها مباشرة من نافذة السياق الخاصة به، ولكن الكود المولد الذي يتم تنفيذه داخل صندوق الرمل يمكنه قراءتها باستخدام os.environ، أو process.env، أو ما يعادله. لهذا السبب يهم النطاق الضيق: حقن فقط بيانات الاعتماد التي تتطلبها المهمة، ويفضل استخدام الرموز قصيرة العمر بحيث يكون لبيانات الاعتماد المسربة نافذة محدودة من الفائدة. التنقية هي مسؤولية التطبيق: لا تقم بتسجيل الإخراج الكامل لـ stdout بشكل افتراضي إذا كانت الأسرار قد تظهر في رسائل الخطأ أو عبارات الطباعة.
ماذا يحدث للأسرار عند انتهاء الجلسة؟
يجب تنظيف متغيرات البيئة وملفات الأسرار المثبتة كجزء من تفكيك الجلسة. إذا كان النظام الأساسي يحافظ على الحالة عبر الجلسات (اللقطات، وحدات التخزين الدائمة)، تحقق من أن بيانات الاعتماد المكتوبة على نظام الملفات أو المخزنة مؤقتًا بواسطة موفر بيانات الاعتماد يتم تنظيفها أو تدويرها أيضًا. بيانات الاعتماد القديمة في لقطة قابلة للاستئناف تشكل خطرًا - بعد تفكيك الجلسة، يجب ألا تحتفظ اللقطة بالرموز التي كانت صالحة فقط لمدة الجلسة الأصلية.
سجلات التدقيق والمراقبة
ما الأحداث التي يتم تسجيلها في صندوق الرمل؟
تشمل سجلات التدقيق المفيدة لصندوق الرمل إنشاء الجلسة وإنهاءها (معرف الجلسة، المستأجر، إصدار القالب، تخصيص الموارد، المدة)، أحداث التنفيذ (أي كود أو فئة أمر تم تشغيله، وقت البدء/الانتهاء، حالة الخروج)، تثبيتات الحزم (الاسم، الإصدار، المصدر، النتيجة)، جهات الاتصال الشبكية الصادرة (النطاقات، عناوين IP، المنافذ)، الملفات المقروءة أو المكتوبة من مسارات محددة، ونتيجة التنظيف. الهدف هو جعل سلوك الوكيل قابلاً لإعادة البناء بعد وقوع الحدث دون تحويل سجل التدقيق إلى مخزن أسرار ثانوي. بشكل عام، لا تنتمي ملفات العملاء الأولية، ومخرجات الأوامر الكاملة، والطلبات الكاملة إلى سجلات التدقيق ما لم تكن سياسات الاحتفاظ والوصول الخاصة بك مصممة خصيصًا لتلك البيانات.
من يمكنه الوصول إلى سجلات التدقيق؟
يجب أن تكون ضوابط الوصول على سجلات التدقيق مقتصرة على المشغل، وحيثما كان ذلك مناسبًا، المستأجر. في المنصات متعددة المستأجرين، يجب ألا تكون سجلات التدقيق الخاصة بمستأجر مرئية للمستأجرين الآخرين. بالنسبة للنشر الحساس للامتثال، يجب أن يكون مسار التدقيق مقاومًا للتلاعب، ومحتفظًا به للفترة المطلوبة، ويمكن الوصول إليه من قبل المراجعين المصرح لهم (فريق الأمان، مسؤول الامتثال) عند الطلب. اسأل مزود صندوق الرمل الخاص بك عن فترة الاحتفاظ بالسجلات المقدمة افتراضيًا، وما إذا كان يمكن تصدير السجلات إلى SIEM أو تخزين خاص بك، وما هي ضوابط الوصول التي تحمي بيانات السجل.
الامتثال والمراجعة الأمنية
ما مراجعة الامتثال المطلوبة قبل استخدام صندوق الرمل في الإنتاج؟
تعتمد المتطلبات المحددة على صناعتك وولايتك القضائية، لكن الأسئلة القياسية لأي نظام وكيل في الإنتاج تشمل: ما البيانات التي تدخل صندوق الرمل (وهل تخضع تلك البيانات لـ GDPR أو HIPAA أو SOC 2 أو أطر أخرى)، وأين يتم استضافة صندوق الرمل وهل يفي ذلك بمتطلبات إقامة البيانات، وما هو نموذج العزل وهل يمكنك توثيقه لمدقق، وكيف تتم إدارة بيانات الاعتماد وتدويرها، وكيف يبدو مسار التدقيق؟ ستسأل معظم المراجعات الأمنية أيضًا عما إذا كان الكود المولد يمكنه الوصول إلى قواعد بيانات الإنتاج أو أسطح الإدارة الداخلية أو بيانات العملاء خارج النطاق المقصود. هذه ضوابط معمارية، وليست مجرد شهادات بائعين.
ما الأسئلة التي يجب أن تطرحها فرق الأمان عند تقييم صندوق رمل وكيل الذكاء الاصطناعي؟
قائمة تحقق تقييم عملية للمراجعة الأمنية:
- العزل: ما هي الحدود - عملية، حاوية، أم microVM؟ هل كل جلسة وكيل معزولة على مستوى نظام الملفات والعملية والشبكة؟
- الخروج: ما هي سياسة الخروج الافتراضية؟ هل يمكن السماح للوجهات الصادرة بقائمة؟ كيف يتم التحكم في DNS؟
- الأسرار: كيف يتم حقن بيانات الاعتماد؟ هل هي مقتصرة على المهمة؟ هل يتم تنظيفها عند تفكيك الجلسة؟
- التدقيق: ما الأحداث التي يتم تسجيلها؟ من يمكنه الوصول إلى السجلات؟ ما فترة الاحتفاظ؟
- إقامة البيانات: أين يتم استضافة صناديق الرمل؟ هل يمكن تحديد النشر لمنطقة سحابية أو حساب معين؟
- وضع الامتثال: هل يحمل المزود الشهادات ذات الصلة (SOC 2، ISO 27001)؟ ما هو نموذج المسؤولية المشتركة؟
- مدى وصول الشبكة: هل يمكن لصندوق الرمل الوصول إلى خدمات البيانات الوصفية الداخلية أو واجهات API الخاصة أو موارد المستأجرين الآخرين؟ كيف يتم منع الحركة الجانبية؟
صغ هذه كأسئلة للتقييم وليس كمتطلبات يفي بها أي بائع واحد تلقائيًا. يجب التحقق من ادعاءات الأمان والامتثال في وثائق البائع مقابل وثائق المنتج الحالية، وليس أخذها على ظاهرها. بالنسبة للفرق ذات المتطلبات التنظيمية أو التعاقدية، اطلب من فريق الأمان إكمال المراجعة قبل النشر في الإنتاج، وليس بعده.
متى يكون النشر بـ BYOC (اجلب سحابتك الخاصة) أو VPC ذا صلة؟
تعد متطلبات إقامة البيانات أو سياسات أمان الشبكة أو القيود التنظيمية التي تحظر مغادرة البيانات لحساب سحابي محدد الأسباب الرئيسية التي تدفع الفرق لاختيار نشر BYOC أو VPC بدلاً من خدمة مدارة مشتركة. تشغيل صناديق الرمل داخل VPC الخاص بك على AWS أو GCP يعني أن بيئة التنفيذ ضمن محيط شبكتك، وتنطبق ضوابط الوصول لحسابك السحابي، ويمكن التحكم في الخروج من صندوق الرمل بواسطة سياسات الشبكة الحالية لديك. المفاضلة هي المسؤولية التشغيلية: أنت تمتلك إدارة البنية التحتية، والتصحيح، والتوسع. يوثق Novita Agent Sandbox نشر BYOC داخل حسابات AWS أو GCP كخاصية للفرق التي لديها هذه المتطلبات. تحقق من التوفر الحالي وخيارات التكوين في وثائق Novita Agent Sandbox.
تسعير صندوق الرمل ومحركات التكلفة
ما الذي يحرك تكاليف صندوق الرمل؟
تكاليف صندوق الرمل عادة ما تكون مزيجًا من وقت الحوسبة (vCPU والذاكرة يتم الفوترة بالثانية أو الدقيقة)، والنفقات العامة للجلسة (رسوم بدء تشغيل لكل جلسة على بعض المنصات)، والتخزين الدائم فوق المستوى المجاني المضمن، ونقل البيانات الصادرة (الخروج). يعتمد الوزن النسبي لكل منها على عبء العمل الخاص بك: مترجم الكود قصير الجلسة هو في الغالب حوسبة؛ وكيل أتمتة المتصفح الذي يقوم بتنزيل ملفات كبيرة قد يولد خروجًا كبيرًا؛ مساحة عمل برمجة دائمة ستتراكم عليها مساحة تخزين. التعامل مع وقت الخمول هو عامل تمييز رئيسي - المنصات ذات الإيقاف التلقائي تتوقف عن الفوترة عندما ينتظر صندوق الرمل ردًا من LLM، مما يمكن أن يقلل التكاليف بشكل كبير لسير العمل التفاعلي. راجع نماذج تسعير صندوق رمل وكيل الذكاء الاصطناعي: لكل جلسة، حوسبة، تخزين، وخروج للحصول على تحليل مفصل لكل محور تسعير.
كيف تتفاعل مدة الجلسة والحوسبة والخروج في التكلفة؟
بالنسبة لمعظم أحمال العمل، تهيمن تكلفة الحوسبة. جلسة برمجة مدتها 10 دقائق على 1 vCPU تكلف أكثر من 1 جيجابايت من الخروج بالمعدلات النموذجية. لكن التفاعل مهم لأحمال عمل محددة: وكيل بيانات يقوم بتنزيل مجموعة بيانات تدريب كبيرة سيولد رسوم خروج تفوق تكلفة الحوسبة. وكيل متصفح يحتفظ بجلسات مفتوحة بين أدوار LLM سيتراكم عليه وقت خمول حسابي إذا لم يتم تمكين الإيقاف التلقائي. النهج العملي هو تقدير كل بُعد مقابل ملف عبء العمل الفعلي الخاص بك قبل الالتزام بنظام أساسي. يقوم Novita Agent Sandbox بالفوترة بالثانية بناءً على استخدام vCPU والذاكرة الفعلي بدون رسوم بدء تشغيل لكل جلسة؛ اعتبارًا من منتصف 2026، سعر 1 vCPU هو $0.0000098/ثانية. (المصدر: صفحة تسعير Novita AI، تم التحقق منه في الوثائق المنشورة. تحقق دائمًا من الأسعار الحالية قبل تخطيط الميزانية.)
الاستضافة الذاتية مقابل صندوق رمل وكيل الذكاء الاصطناعي المُدار
متى يجب على الفرق الاستضافة الذاتية بدلاً من استخدام صندوق رمل مُدار؟
الاستضافة الذاتية (تشغيل البنية التحتية الخاصة بصندوق الرمل، غالبًا على Firecracker أو طبقة microVM مماثلة) منطقية عندما: تمنع متطلبات إقامة البيانات أو سياسة الشبكة استخدام خدمة مدارة من طرف ثالث، أو يكون حجم عبء العمل مرتفعًا بما يكفي لتتجاوز تكلفة الخدمة المدارة التكلفة التشغيلية لتشغيل البنية التحتية الخاصة بك، أو أن الفريق لديه قدرة هندسة منصة موجودة ويريد السيطرة الكاملة على نموذج العزل، وحوكمة الصور، وسياسة الشبكة. الاستضافة الذاتية أصعب مما تبدو: إدارة النوى، وأنظمة ملفات الجذر، والصور، واللقطات، ومحددات المعدل، والمقاييس، والتنظيف، وعزل متعدد المستأجرين هو عمل حقيقي. راجع Firecracker لصناديق رمل وكلاء الذكاء الاصطناعي لمعرفة ما يبدو عليه النطاق التشغيلي.
متى يكون صندوق الرمل المُدار أكثر منطقية؟
بالنسبة لمعظم الفرق التي تبني وكلاء برمجة، أدوات تحليل البيانات، سير عمل أتمتة المتصفح، أو خطوط أنابيب التقييم، فإن صندوق الرمل المُدار هو الطريق الأسرع للإنتاج. يتعامل النظام الأساسي مع توفير البنية التحتية، وتقوية الأمان، وتحديثات الصور، والتوسع، وإدارة دورة الحياة. تركز الفريق على هندسة الوكيل، وليس التفاصيل الداخلية لصندوق الرمل. مقارنة التكلفة ليست مجرد أسعار حوسبة سحابية: ضع في اعتبارك الوقت الهندسي لبناء طبقة العزل وصيانتها، وعمل الامتثال لتوثيقها، والاستجابة للحوادث عند حدوث شيء غير متوقع. بالنسبة للفرق التي ليس لديها قدرة هندسة منصة مخصصة، تصل الخدمات المدارة عادةً إلى الإنتاج بشكل أسرع وتحافظ على تكلفة إجمالية أقل للملكية. راجع نماذج تسعير صندوق رمل وكيل الذكاء الاصطناعي للحصول على إطار لمقارنة التكلفة الإجمالية المُدارة مقابل المستضافة ذاتيًا.
ما الأسئلة التي يجب أن تطرحها الفرق عند تقييم مزودي صناديق الرمل المُدارة؟
أسئلة تقييم عملية تتجاوز التسعير الرئيسي:
- ما هو نموذج العزل لكل جلسة (microVM، حاوية، عملية)؟
- ما هي سياسة الخروج الافتراضية والقابلة للتكوين؟
- ما هي خيارات حوكمة تثبيت الحزم؟
- كيف يتم حقن الأسرار وتنظيفها؟
- ما بيانات سجل التدقيق المتاحة وكيف يتم الوصول إليها؟
- ما هي حدود طول الجلسة والتزامن في المستوى المطلوب؟
- هل يدعم المزود النشر بـ BYOC أو VPC؟
- ما هو سلوك الإيقاف المؤقت/الاستئناف وكيف يؤثر على الفوترة؟
- كيف يتصرف زمن بدء التشغيل عند التوسع (تجمع دافئ، لقطة، تمهيد بارد)؟
تشغيل الكود غير الموثوق بأمان
كيف يمكنني تشغيل الكود المولد بالذكاء الاصطناعي بأمان في الإنتاج؟
الأساس هو: لا تقم بتشغيل الكود المولد من LLM على مضيفك. قم بتوجيه كل التنفيذ من خلال صندوق رمل يوفر عزل نظام الملفات والعملية والشبكة. إلى جانب ذلك، خمس ممارسات تحدث فرقًا ذا معنى: (1) تعيين سياسة الخروج صراحةً - الرفض افتراضيًا مع قائمة سماح أكثر أمانًا من الفتح افتراضيًا؛ (2) نطاق الأسرار بشكل ضيق - حقن فقط بيانات الاعتماد التي تحتاجها المهمة الحالية؛ (3) حوكمة تثبيتات الحزم - السماح بالتثبيت من السجلات المعتمدة، أو استخدام الصور المعدة مسبقًا لأحمال العمل القابلة للتكرار؛ (4) التسجيل على مستوى النواة أو برنامج Hypervisor بدلاً من الوثوق بسجلات طبقة التطبيق؛ (5) تعيين حدود الموارد - CPU، الذاكرة، القرص، ومهلة زمن الحائط - بحيث لا يمكن لوكيل هارب أن يؤثر على الجلسات المجاورة. راجع ما مدى أمان صندوق رمل الذكاء الاصطناعي لتنفيذ الكود؟ للحصول على قائمة تحقق كاملة.
هل يوجد صندوق رمل وكيل ذكاء اصطناعي مفتوح المصدر؟
نعم. Daytona هو مفتوح المصدر بموجب ترخيص AGPL ويدعم النشر المستضاف ذاتيًا. حزمة SDK الأساسية لـ E2B هي مفتوحة المصدر، على الرغم من أن البنية التحتية المدارة لوقت التشغيل ليست كذلك. إذا كنت ترغب في بناء صندوق الرمل الخاص بك من الصفر، فإن النهج الأكثر شيوعًا هو Firecracker (مطور من AWS، مرخص بموجب Apache 2.0) كبيئة تشغيل microVM، بالإضافة إلى إدارة الصور الخاصة بك، والتنسيق، والتحكم في دورة الحياة. الاستضافة الذاتية تعني تحمل النطاق التشغيلي الذي تستبعده الخدمة المُدارة: إدارة النواة، وحوكمة نظام ملفات الجذر، وتحديد المعدل، وتخزين اللقطات، وسياسات التنظيف، والعزل متعدد المستأجرين. راجع Firecracker لصناديق رمل وكلاء الذكاء الاصطناعي لمعرفة كيف يبدو هذا النطاق عمليًا.
ما هي منصة صندوق رمل وكيل الذكاء الاصطناعي المُدارة؟
منصة صندوق رمل وكيل الذكاء الاصطناعي المُدارة هي خدمة سحابية توفر البنية التحتية لصندوق الرمل كـ API: تقوم باستدعاء SDK، يتم توفير صندوق رمل وإعادته في حالة جاهزة، وتتعامل المنصة مع الحوسبة الأساسية والشبكات وإدارة الصور ودورة الحياة. Novita Agent Sandbox و E2B ووضع Daytona المُدار هي أمثلة. البديل هو الاستضافة الذاتية، حيث تقوم بتوفير وتشغيل البنية التحتية لصندوق الرمل بنفسك. الأسئلة الرئيسية لأي منصة مُدارة هي: ما نموذج العزل الذي تستخدمه، وما سياسة الخروج القابلة للتكوين، وما إذا كان نشر BYOC أو VPC متاحًا، وما هو التسعير بالثانية لعبء العمل المتوقع الخاص بك. راجع أفضل صناديق رمل وكلاء الذكاء الاصطناعي في 2026 للحصول على مقارنة منظمة.
ما هو صندوق رمل وكيل الذكاء الاصطناعي للاستخدام المؤسسي؟
عادةً ما تمتد متطلبات صندوق رمل وكيل الذكاء الاصطناعي للمؤسسات إلى أبعد مما توفره الخدمة المُدارة التي تركز على المطورين بشكل افتراضي. تشمل المتطلبات الشائعة: نشر BYOC أو VPC (يعمل صندوق الرمل داخل حسابك السحابي، وليس في مستأجر طرف ثالث مشترك)؛ شهادة SOC 2 أو ISO 27001؛ سياسة خروج قابلة للتكوين وتصدير سجل التدقيق إلى SIEM؛ نطاق بيانات اعتماد على مستوى الجلسة مع رموز قصيرة العمر؛ وضوابط إقامة البيانات التي تقيد مكان تنفيذ أعباء عمل الوكيل. يدعم Novita Agent Sandbox نشر BYOC في VPC الخاص بك على AWS أو GCP، مما يعالج متطلبات إقامة البيانات وعزل الشبكة الأكثر شيوعًا للمؤسسات. تحقق من الشهادات الحالية للامتثال وخيارات التكوين المتاحة في وثائق المنتج قبل اتخاذ قرارات الهندسة المعمارية.
