إذا كان وكيل الذكاء الاصطناعي الخاص بك يمكنه كتابة التعليمات البرمجية، فيمكنه كتابة تعليمات برمجية سيئة. إذا كان يمكنه استدعاء الأدوات، فيمكنه استدعاء الأداة الخاطئة بحجج خاطئة. الحل ليس في توجيه ذكي. إنه في وجود حدود عزل بين مخرجات النموذج والجهاز الذي يقوم بتشغيلها. CubeSandbox هو أحد الأنظمة المصممة خصيصًا لتوفير هذه الحدود، ومن المفيد فهم ما يفعله، وكيف يقارن بالأساليب الأخرى، ومكان ملاءمته عندما تبدأ وكلاء الذكاء الاصطناعي في التعامل مع واجهات برمجة التطبيقات (APIs) والبيانات الحقيقية.
خلاصة القول (TL;DR)
CubeSandbox هي خدمة صندوق رمل (sandbox) مفتوحة المصدر ومعزولة بالأجهزة من Tencent Cloud لتشغيل تعليمات برمجية لوكيل الذكاء الاصطناعي. يحصل كل صندوق رمل على نواة نظام تشغيل ضيف خاصة به عبر KVM، ويبدأ في حوالي 60 مللي ثانية، ويستخدم أقل من 5 ميجابايت من الذاكرة الإضافية. مرخص بموجب Apache 2.0 ومتوافق تمامًا مع حزمة تطوير البرامج E2B SDK.
مقدمة
تقوم الأنظمة الوكيلية الآن بكتابة وتنفيذ التعليمات البرمجية في بيئات الإنتاج. يقوم وكيل برمجي بإنشاء وتشغيل نص بايثون (Python). يقوم وكيل بحثي بتصفح صفحة، وتحليلها، وتمرير النتيجة إلى خطوة أخرى. يقوم وكيل بيانات بتحميل ملف CSV وتشغيل تحويلات قررها النموذج أثناء التشغيل. لم تتم مراجعة أي من هذه التعليمات البرمجية بواسطة إنسان قبل تشغيلها. هذه هي المشكلة الأساسية التي يحلها صندوق الرمل للوكلاء: تحتاج إلى تنفيذ تعليمات غير موثوق بها تم إنشاؤها بواسطة النموذج دون منحها وصولاً إلى مضيفك، أو نظام ملفاتك، أو بيانات الاعتماد الخاصة بك، أو شبكتك.
يصبح هذا الأمر أكثر أهمية كلما زاد استقلال الوكلاء. النموذج الذي يخطئ في استعلام SQL مزعج. أما النموذج الذي يخطئ في rm -rf أو يتبع تعليمات محقونة داخل صفحة ويب تم تصفحها، فيمثل حادثًا أمنيًا. يضع صندوق الرمل حدًا صارمًا: يمكن للوكيل أن يفعل ما يشاء داخل بيئة معزولة يمكن التخلص منها، ولا يتسرب أي شيء يفعله خارجها.
هناك مشكلة ثانية، أكثر هدوءًا. لا يقتصر عمل الوكلاء على تشغيل التعليمات البرمجية فحسب؛ بل يستدعون واجهات برمجة التطبيقات (APIs) والأدوات. قبل أن تثق بوكيل لاستدعاء واجهة برمجة تطبيقات الدفع الخاصة بك أو خدماتك الداخلية من داخل صندوق رمل، تحتاج إلى معرفة أن واجهات برمجة التطبيقات هذه تتصرف بشكل صحيح وأن الوكيل يستدعيها بالطريقة التي تتوقعها. هذا هو المكان الذي تكتسب فيه أدوات واجهة برمجة التطبيقات مكانتها جنبًا إلى جنب مع العزل في وقت التشغيل. تتيح لك منصة مثل Apidog محاكاة واختبار نقاط النهاية التي سيستدعيها الوكيل، بحيث تتحقق من العقد قبل أن يبدأ نظام مستقل في تشغيلها ضمن بيئة صندوق رمل. إذا كنت تفكر بالفعل في بنية الوكيل، فإن دليلنا حول هندسة الذكاء الاصطناعي الوكيلية يغطي كيفية تضافر طبقات التنفيذ والأدوات هذه.
يشرح بقية هذه المقالة ماهية CubeSandbox، ولماذا يحتاج الوكلاء إلى صندوق رمل على الإطلاق، وكيف تختلف نماذج العزل، وكيف يرتبط هذا باختبار واجهات برمجة التطبيقات التي يعتمد عليها وكلاؤك.
ما هو CubeSandbox؟
CubeSandbox هو نظام صندوق رمل أمني لتشغيل تعليمات برمجية لوكيل الذكاء الاصطناعي، تم إطلاقه كمصدر مفتوح بواسطة Tencent Cloud بموجب ترخيص Apache 2.0 في أبريل 2026. يصفه شعار GitHub الخاص به بوضوح: "صندوق رمل فوري، متزامن، آمن وخفيف الوزن لوكلاء الذكاء الاصطناعي." إنه ليس مجرد حزمة تطوير برامج (SDK)؛ بل هو مكدس كامل لصندوق الرمل كخدمة (sandbox-as-a-service)، مكتوب في الغالب بلغة Rust، يمكنك نشره بنفسك.
تم بناء البنية على RustVMM و KVM، وهي نفس طبقة المحاكاة الافتراضية لنواة Linux المستخدمة بواسطة العديد من برامج Hypervisor السحابية. وفقًا لوثائق المشروع والإعلان الرسمي، ينقسم النظام إلى عدة مكونات:
- CubeAPI: بوابة REST تعكس واجهة صندوق الرمل E2B.
- CubeMaster: منسق المجموعة الذي يجدول صناديق الرمل عبر العقد.
- CubeHypervisor و CubeShim: طبقة المحاكاة الافتراضية KVM التي تقوم بتشغيل وإدارة كل جهاز ظاهري مصغر (microVM).
- Cubelet و CubeProxy: وكلاء على مستوى العقدة يقومون بتشغيل وتوجيه الاتصالات إلى صناديق الرمل.
- CubeVS: طبقة شبكة مدعومة بتقنية eBPF تفرض عزل الشبكة بين صناديق الرمل على مستوى النواة.
الخاصية الأبرز هي أن كل صندوق رمل يحصل على نواة نظام تشغيل ضيف مخصصة له. هذا نموذج عزل مختلف وأقوى من الحاوية (container)، التي تشارك نواة المضيف. تشير الأرقام المنشورة من Tencent إلى بدء بارد (cold start) يبلغ حوالي 60 مللي ثانية عند التزامن الفردي (بمتوسط 67 مللي ثانية مع P95 حوالي 90 مللي ثانية تحت 50 إنشاءًا متزامنًا)، وأقل من 5 ميجابايت من الذاكرة الإضافية لكل مثيل، والقدرة على تشغيل آلاف صناديق الرمل على مضيف واحد كبير. تشير المواد الصحفية إلى خادم يحتوي على 96 vCPU يدعم أكثر من 2000 صندوق رمل متزامن. تقول Tencent إن CubeSandbox قد تم تشغيله على نطاق واسع داخل بنيتها التحتية الخاصة، وأن MiniMax قد استخدمته لتدريب وكيل التعلم المعزز على نطاق واسع عبر بيئات غير متجانسة.
توصف بعض الميزات المتقدمة، مثل استعادة لقطة على مستوى الحدث (event-level snapshot rollback) لنقاط التحقق واستعادة حالة صندوق الرمل، بأنها لا تزال قيد التطوير. تعامل مع العناصر المستقبلية كخارطة طريق، وليست ضمانات تم شحنها، وتحقق من المستودع (repository) لمعرفة الحالة الحالية. منهجية المعايير العامة التي تتجاوز أرقام البائع نفسه محدودة، لذا تحقق من صحة ادعاءات الأداء مقابل حمل العمل الخاص بك.
للحصول على التفاصيل الرسمية، فإن مصدر الحقيقة هو مستودع GitHub الخاص بـ CubeSandbox وموقع التوثيق الرسمي.
لماذا يحتاج وكلاء الذكاء الاصطناعي إلى صندوق رمل
من المفيد أن نكون محددين بشأن التهديدات، لأن "الأمن" مصطلح غامض جدًا بحيث لا يمكن التصميم ضده. هناك ثلاثة أنماط فشل تدفع الفرق نحو استخدام صناديق الرمل.
تعليمات برمجية خطرة تم إنشاؤها. ينتج النموذج تعليمات برمجية يعتقد أنها صحيحة. أحيانًا لا تكون كذلك. قد تحذف الدليل الخطأ، أو تستنزف الذاكرة في حلقة مفرغة، أو تكتب ملفًا في غير مكانه. لا شيء من هذا خبيث؛ إنه مجرد خطأ، والتعليمات البرمجية الخاطئة مع وصول المضيف خطيرة. الوكيل ليس لديه مفهوم نطاق الضرر ما لم تمنحه واحدًا.
استدعاءات أدوات غير موثوق بها. يستدعي الوكلاء الأدوات وواجهات برمجة التطبيقات بناءً على ما يقرره النموذج في وقت التشغيل. إذا تم توجيه النموذج عن طريق حقن توجيه (prompt injection) مدفون في مستند، أو صفحة ويب، أو استجابة أداة، فقد يستدعي أداة مدمرة، أو يمرر حججًا يتحكم فيها المهاجم، أو يربط الاستدعاءات بطريقة لم تقصدها أبدًا. النموذج ليس جهة موثوق بها هنا؛ إنه مفسر لأي نص يصل إلى نافذة سياقه. نتعمق في هذا في مقالنا حول وكلاء الذكاء الاصطناعي كمستهلكين جدد لواجهات برمجة التطبيقات، والذي يغطي سبب انهيار افتراضات الثقة التقليدية في واجهات برمجة التطبيقات مع المتصلين المستقلين.
تسريب البيانات. هذا هو الأمر الذي يقلل الناس من شأنه. يمكن تحويل الوكيل الذي لديه وصول إلى الشبكة وإلى الأسرار إلى قناة لتسريب البيانات. تعليمات مسمومة تخبر الوكيل بقراءة متغير بيئة يحمل مفتاح API و POSTه إلى نقطة نهاية خارجية. بدون تصفية الصادر (egress filtering) وعزل بيانات الاعتماد، تصبح حدود صندوق الرمل بلا معنى لأن البيانات تخرج من الباب الأمامي. لهذا السبب يجمع CubeSandbox بين العزل على مستوى النواة وتصفية الصادر القائمة على eBPF عبر CubeVS؛ فعزل العملية ليس كافيًا إذا كانت الشبكة مفتوحة على مصراعيها.
القاسم المشترك: لا يمكنك افتراض أن الوكيل سيتصرف بشكل صحيح، لأن سلوك الوكيل يتم التحكم فيه جزئيًا بواسطة أي بيانات غير موثوق بها يتلقاها. يسمح لك صندوق الرمل بالتوقف عن التفكير فيما إذا كان النموذج جديرًا بالثقة والبدء في التفكير في حدود صلبة لا تتأثر. للحصول على نظرة عملية حول فحص هذه السلوكيات قبل أن تصل إلى الإنتاج، راجع كيفية اختبار وكلاء الذكاء الاصطناعي الذين يستدعون واجهات برمجة التطبيقات.
كيف تعمل صناديق رمل الوكلاء: نماذج العزل
لا تقوم جميع صناديق الرمل بالعزل بنفس الطريقة، وتلك الاختلافات مهمة للأمن والأداء على حد سواء. هناك أربعة أساليب رئيسية ستراها في نظام الوكلاء البيئي.
عزل على مستوى العملية (Process-level isolation). يتم تشغيل التعليمات البرمجية كعملية نظام تشغيل مقيدة باستخدام مرشحات seccomp، وإسقاط الصلاحيات، ومساحات الأسماء (namespaces)، ومجموعات التحكم (cgroups). هذا هو الخيار الأخف والأضعف. إنه يشارك نواة المضيف، لذا فإن استغلال النواة يعني اختراق المضيف. مناسب للتعليمات البرمجية التي تثق بها في الغالب؛ لكنه ضعيف لإخراج النموذج العشوائي.
الحاويات (Containers). تضيف الحاويات من نمط Docker مساحات الأسماء وقيود الموارد وهي مألوفة من الناحية التشغيلية. لكن الحاويات تشارك نواة المضيف حسب التصميم. ثغرات الهروب من الحاويات هي فئة حقيقية ومتكررة من الأخطاء، و"التعليمات البرمجية غير الموثوق بها في حاوية بنواة مشتركة" هي نقطة ضعف معروفة. تبدأ العديد من الفرق هنا لأنه سهل، ثم تصل إلى سقف العزل.
الأجهزة الافتراضية المصغرة (MicroVMs). يقوم الجهاز الظاهري المصغر بتشغيل نواة ضيف صغيرة داخل المحاكاة الافتراضية للأجهزة (KVM). يتم تشغيل تعليمات الوكيل البرمجية مقابل نواة خاصة به، لذا فإن استغلالًا على مستوى النواة يقتصر على جهاز افتراضي يمكن التخلص منه، وليس المضيف. لقد عزز Firecracker هذا النموذج لأعباء العمل بلا خادم، ويقع CubeSandbox في هذه الفئة، مستخدمًا RustVMM و KVM مع نواة ضيف لكل صندوق رمل. كانت المقايضة التاريخية هي وقت البدء؛ كانت الأجهزة الافتراضية المصغرة أبطأ في التشغيل من الحاويات. تعالج التطبيقات الحديثة ذلك باستخدام التقاط اللقطات (snapshotting) وتوفير الموارد مسبقًا، وهذا هو السبب في أن CubeSandbox يبلغ عن أوقات بدء أقل من 100 مللي ثانية.
نوى التطبيقات (Application kernels). يسلك gVisor مسارًا مختلفًا: فهو يعترض استدعاءات النظام في مساحة المستخدم وينفذ واجهة شبيهة بـ Linux بنفسه، بحيث لا يتحدث حمل العمل مباشرة إلى نواة المضيف أبدًا. إنها طبقة عزل قوية بدون جهاز ظاهري كامل، مع بعض المقايضات في توافق استدعاءات النظام والأداء.
إليك كيفية مقارنة الأساليب عبر الأبعاد المهمة للوكلاء:
| الأسلوب | قوة العزل | بدء بارد | التكلفة الإضافية | مشاركة النواة | أمثلة |
|---|---|---|---|---|---|
| عملية + seccomp | منخفضة | فورية | أقل قدر | نواة مضيف مشتركة | عملية فرعية مقيدة، nsjail |
| حاويات | متوسطة | ~عشرات مللي ثانية | منخفضة | نواة مضيف مشتركة | Docker, containerd |
| جهاز افتراضي مصغر | عالية | ~50–150 مللي ثانية | منخفضة–متوسطة | نواة ضيف مخصصة | CubeSandbox, Firecracker |
| نواة تطبيق | عالية | ~عشرات مللي ثانية | منخفضة–متوسطة | معترضة في مساحة المستخدم | gVisor |
| واجهة برمجة تطبيقات صندوق رمل مستضافة | عالية (مدارة) | متغيرة | مدارة لك | مدارة لك | E2B، عروض مستضافة |
لا يوجد فائز وحيد. يعتمد الاختيار الصحيح على مدى ثقتك في التعليمات البرمجية، ومدى سرعة البدء البارد الذي تحتاجه، وما إذا كان بإمكانك تشغيل KVM، وما إذا كنت تريد تشغيل البنية التحتية بنفسك أو استهلاكها كخدمة.
CubeSandbox في المشهد التقني
موقع CubeSandbox محدد: عزل على مستوى الأجهزة مع أوقات بدء باردة سريعة بما يكفي لتبدو كحاوية، يتم نشره كشيء تقوم بتشغيله بدلاً من خدمة تستأجرها. وهذا يضعه في مقارنة مفاهيمية مباشرة مع ثلاث نقاط مرجعية.
مقابل الحاويات (containers). تشارك الحاوية نواة المضيف؛ بينما يمنح CubeSandbox كل صندوق رمل نواة خاصة به. بالنسبة للتعليمات البرمجية العشوائية التي ينشئها الوكيل، هذه هي حجة الأمان. التكلفة هي أنك تحتاج إلى مضيف Linux من نوع x86_64 يدعم KVM (خادم معدني خالص، أو جهاز افتراضي سحابي يدعم المحاكاة الافتراضية المتداخلة، أو WSL 2 للعمل المحلي). إذا لم تتمكن منصتك من كشف KVM، فلن يكون العزل القائم على الأجهزة الافتراضية المصغرة متاحًا لك، وقد يكون نهج مساحة المستخدم مثل gVisor أو واجهة برمجة تطبيقات مستضافة أكثر ملاءمة.
مقابل Firecracker. Firecracker هو الجهاز الظاهري المصغر (microVM) المعروف للحوسبة بلا خادم (serverless) وهو بحد ذاته مكون أساسي، وليس منتج صندوق رمل للوكلاء. يعتمد CubeSandbox أيضًا على KVM/RustVMM ولكنه يقدم طبقات أعلى في المكدس: منسق، وبوابة API متوافقة مع E2B، وعزل شبكة eBPF، لذلك أنت تنشر خدمة صندوق رمل للوكلاء بدلاً من تجميعها. إذا كنت تريد المكونات الأساسية، فاختر Firecracker. أما إذا كنت تريد خدمة صندوق رمل بواجهة برمجة تطبيقات مصممة للوكلاء، فإن CubeSandbox يستهدف ذلك.
مقابل E2B وصناديق الرمل المستضافة. يوفر E2B صناديق رمل معزولة كخدمة مُدارة؛ أنت تستدعي واجهة برمجة تطبيقات والبنية التحتية هي مشكلة شخص آخر. يتميز تصميم CubeSandbox بتوافقه مع حزمة تطوير البرامج E2B SDK. تصف الوثائق بأنه بديل جاهز: وجّه E2B_API_URL إلى مثيل Cube المستضاف ذاتيًا وستظل التعليمات البرمجية الحالية تعمل. وهذا يجعل القرار الحقيقي أقل "أي صندوق رمل" وأكثر "خدمة مُدارة مقابل بنية تحتية مستضافة ذاتيًا"، مع عوامل مثل توطين البيانات، والتكلفة عند التوسع، وملكية التشغيل كعوامل حاسمة. كما يدعم أصلاً حزمة تطوير البرامج OpenAI Python SDK وفقًا لإعلان Tencent.
الملخص الصادق: CubeSandbox هو إدخال موثوق به في مجال صناديق رمل الوكلاء مع أطروحة واضحة (عزل قوي، بدايات سريعة، استضافة ذاتية، متوافق مع E2B). إنه جديد أيضًا وموثق إلى حد كبير من قبل بائعه، لذا فإن المعايير المستقلة قليلة. قم بتجربته مقابل حمل عملك وقم بقياس البدء البارد والكثافة وسلوك العزل قبل الالتزام به.
كيف يرتبط هذا باختبار واجهات برمجة التطبيقات والأدوات التي يستدعيها وكلاؤك
يجيب العزل في وقت التشغيل على سؤال "ماذا لو كانت التعليمات البرمجية سيئة؟". لكنه لا يجيب على سؤال "ماذا لو كانت واجهة برمجة التطبيقات التي يستدعيها الوكيل سيئة، أو إذا استدعاها الوكيل بشكل خاطئ؟". هاتان مشكلتان مختلفتان، وتحتاج إلى تغطية كليهما.
تخيل وكيلًا في صندوق رمل يقوم بحجز السفر. التعليمات البرمجية تعمل بأمان داخل CubeSandbox. ولكن الوكيل لا يزال يستدعي واجهة برمجة تطبيقات للرحلات الجوية، وواجهة برمجة تطبيقات للدفع، وخدمة مسار رحلة داخلية. إذا أعاد أي منها استجابة غير صحيحة، فقد يدخل الوكيل في حلقة مفرغة، أو يتوهم استردادًا، أو يمرر بيانات سيئة إلى الأنظمة التالية. إذا استدعى واجهة برمجة تطبيقات الدفع بمفتاح عدم التكرار (idempotency key) الخاطئ، فلن يحميك العزل؛ لا تزال الأموال تتحرك. يحمي صندوق الرمل المضيف من الوكيل. لكنه لا يحمي أنظمتك من وكيل مرتبك يقوم بإجراء مكالمات حقيقية لخدمات حقيقية.
لذلك، فإن سير العمل الذي يصمد يتكون من طبقتين تعملان معًا:
- عزل التنفيذ بحيث لا تتمكن التعليمات البرمجية التي ينشئها النموذج واستدعاءات الأدوات من إلحاق الضرر بالمضيف أو تسريب البيانات. هذه هي طبقة CubeSandbox.
- التحقق من العقد لكل واجهة برمجة تطبيقات وأداة يمكن للوكيل الوصول إليها، قبل وأثناء عمليات التشغيل في صندوق الرمل. هذه هي طبقة أدوات واجهة برمجة التطبيقات.
بالنسبة للطبقة الثانية، قم بمحاكاة التبعيات بحيث يتحدث الوكيل إلى بديل متحكم به أثناء اختبار السلوك، ثم اختبر نقاط النهاية الحقيقية للتأكد من توافق المخطط، ومعالجة الأخطاء، والمصادقة، والحالات الهامشية. باستخدام Apidog، يمكنك بناء خادم وهمي يعيد استجابات حتمية ودقيقة للمخطط، وتوجيه الوكيل الذي يعمل في صندوق رمل إليه، ومشاهدة كيفية تفاعل الوكيل مع مسارات النجاح والفشل دون التأثير على بيئة الإنتاج. عندما تكون جاهزًا، قم بتشغيل نفس السيناريوهات مقابل واجهة برمجة التطبيقات الحية لتأكيد صحة العقد. يغطي دليلنا حول اختبار صندوق الرمل الممارسة العامة للاختبار مقابل بيئات معزولة ومتحكم بها، وهو ما ينطبق مباشرة هنا.
هذا الاقتران مهم لأن الوكلاء يضخمون انحراف العقد. يلاحظ الإنسان عندما تبدو استجابة واجهة برمجة التطبيقات غير طبيعية. غالبًا لا يلاحظ الوكيل ذلك؛ فهو يستوعب الاستجابة ويتصرف بناءً عليها. عقود واجهات برمجة التطبيقات الصارمة، التي يتم ممارستها باستخدام المحاكاة والاختبارات، تمنع المتصل المستقل من تحويل استجابة سيئة واحدة إلى سلسلة من المشاكل. إذا كانت وكلاؤك تتحدث بروتوكول سياق النموذج (Model Context Protocol)، فإن اختبار خوادم MCP باستخدام Apidog يوسع نفس الانضباط إلى طبقة الأدوات. وإذا كنت تصمم واجهات برمجة تطبيقات لمستهلكي الوكلاء، فإن تصميم واجهات برمجة التطبيقات لوكلاء الذكاء الاصطناعي يغطي أنماط العقود التي تجعل الاستدعاءات المستقلة قابلة للتنبؤ.
حالات الاستخدام في العالم الحقيقي
بعض الأنماط التي يُظهر فيها نهج العزل بالإضافة إلى العقد قيمته:
- وكلاء البرمجة ومفسرو التعليمات البرمجية. يكتب النموذج التعليمات البرمجية ويشغلها للإجابة على سؤال، أو تحويل البيانات، أو إنشاء رسم بياني. هذه هي حالة الاستخدام النموذجية لصندوق الرمل وتلك التي تستهدفها واجهات برمجة التطبيقات المتوافقة مع E2B مباشرة. نواة CubeSandbox لكل صندوق رمل مهمة هنا لأن التعليمات البرمجية عشوائية تمامًا وتتغير مع كل تشغيل.
- منصات وكلاء متعددة المستأجرين. إذا كانت وكلاء العديد من العملاء يقومون بتنفيذ التعليمات البرمجية على بنية تحتية مشتركة، فإن العزل على مستوى الحاوية بين المستأجرين محفوف بالمخاطر. يوفر عزل الأجهزة لكل صندوق رمل حدودًا للمستأجرين تحافظ على أمان حتى لو كان وكيل أحد المستأجرين معادياً. الكثافة المبلغ عنها (آلاف صناديق الرمل لكل مضيف) هي ما يجعل هذا الحل قابلاً للتطبيق بدلاً من جهاز افتراضي واحد لكل مستأجر.
- التعلم المعزز الوكيلي وحلقات التدريب. تدريب الوكلاء باستخدام التعلم المعزز يعني تشغيل أعداد هائلة من عمليات النشر القصيرة الأجل وغير الموثوق بها. تستشهد Tencent باستخدام MiniMax لـ CubeSandbox لهذا الغرض بالضبط عبر بيئات غير متجانسة. يعد البدء البارد السريع والتكلفة الإضافية المنخفضة لكل مثيل الفرق بين تشغيل تدريب ممكن وآخر غير ممكن.
- وكلاء البحث والبيانات الذين يستخدمون الأدوات. يقوم الوكيل بجلب محتوى خارجي، وتحليله، واستدعاء واجهات برمجة التطبيقات النهائية. المحتوى الذي تم جلبه غير موثوق به (خطر حقن التوجيه)، لذا فإن التحليل والتعليمات البرمجية التي تم إنشاؤها تنتمي إلى صندوق رمل، بينما يجب اختبار واجهات برمجة التطبيقات النهائية مقابل المحاكيات أولاً. هذا هو المكان الذي يؤتي فيه اقتران العزل مع اختبار عقود واجهة برمجة التطبيقات ثماره القصوى.
- تنفيذ الملحقات أو الإضافات غير الموثوق بها. إذا كان بإمكان المستخدمين توفير أدوات أو تعليمات برمجية يقوم وكيلك بتشغيلها، فأنت تقوم بتنفيذ تعليمات برمجية لطرف ثالث غير موثوق بها بحكم التعريف. حدود الجهاز الظاهري المصغر (microVM) لكل عملية تنفيذ هي الوضع المناسب، وهو نفس المنطق الذي استخدمته منصات الحوسبة بلا خادم عند اعتماد Firecracker.
الخاتمة
توقف استخدام صندوق رمل الوكلاء عن كونه اختياريًا بمجرد أن بدأت الوكلاء في تنفيذ التعليمات البرمجية واستدعاء الأدوات دون مراجعة بشرية. يقدم CubeSandbox إجابة ملموسة ومفتوحة للنصف المتعلق بالعزل من تلك المشكلة.
- CubeSandbox حقيقي ومحدد: صندوق رمل مفتوح المصدر من Tencent Cloud بموجب ترخيص Apache 2.0 لوكلاء الذكاء الاصطناعي، مبني على RustVMM و KVM، مع أنوية ضيف خاصة بكل صندوق رمل.
- نموذج العزل هو الجوهر: نواة مخصصة لكل صندوق رمل أقوى من عزل الحاوية للتعليمات البرمجية العشوائية التي يولدها النموذج، مع أوقات بدء باردة أقل من 100 مللي ثانية وتكلفة إضافية أقل من 5 ميجابايت.
- توافق E2B يقلل تكلفة التبديل: إذا كنت تستخدم E2B، فإن المسار الموثق للتبديل المباشر يعيد صياغة الاختيار على أنه بين خدمة مُدارة مقابل استضافة ذاتية، وليس إعادة كتابة.
- تعامل مع أرقام البائع كنقطة بداية: تأتي ادعاءات الأداء والكثافة بشكل كبير من Tencent؛ قم بإجراء اختبارات مقارنة مقابل حمل عملك، وتحقق من المستودع (repo) لمعرفة الميزات التي تم شحنها مقابل تلك التي لا تزال قيد التطوير.
- العزل ضروري ولكنه غير كافٍ: يحمي صندوق الرمل مضيفك من الوكيل؛ لكنه لا يحمي واجهات برمجة التطبيقات الخاصة بك من وكيل مرتبك يستدعيها.
- اقرن عزل وقت التشغيل باختبار عقود واجهة برمجة التطبيقات: قم بمحاكاة واختبار كل نقطة نهاية يمكن للوكيل الوصول إليها حتى لا تتسبب استجابة سيئة واحدة في سلسلة من المشاكل.
إذا كانت وكلاؤك تستدعي واجهات برمجة تطبيقات (APIs) تملكها أو تعتمد عليها، فقم بإعداد طبقة العقد جنبًا إلى جنب مع طبقة العزل. قم بتنزيل Apidog لمحاكاة الخدمات التي يستدعيها وكلاؤك في صناديق الرمل واختبارها للتأكد من مخططها، ومصادقتها، وسلوك الأخطاء قبل أن يقوم نظام مستقل بتشغيلها في الإنتاج.