Perplexity تفتح مصدر SPACE: ما الذي يعلّمنا عزل الوكلاء داخل microVM؟

عندما يُسمح لوكيل ذكاء اصطناعي بتنفيذ كود حقيقي، يصبح السؤال الأهم ليس «ما مدى ذكائه؟» بل «أين يعمل، وماذا يستطيع أن يلمس؟». في 15 أكتوبر 2026 أعلنت Perplexity أنها فتحت مصدر SPACE، المنصة التي تشغّل بها مهام وكيلها Perplexity Computer، تحت رخصة Apache 2.0. وهذا الإعلان يستحق القراءة بعين المطوّر، لأنه يقدّم نموذجاً عملياً لعزل الوكلاء يمكن دراسته والاستفادة منه حتى لو لم تستخدم المنصة نفسها.

ما هو SPACE؟

الاسم اختصار لـ Sandboxed Platform for Agentic Code Execution، أي منصة معزولة لتنفيذ كود الوكلاء. هو أول مكوّن تفتحه الشركة من منصة تشغيل الوكلاء (Agentic Runtime Platform)، وهو مكتوب بلغة Rust، ويأتي مع وثائق وطبقة توافق مع E2B لمن يستخدم هذه الواجهة أصلاً. وبحسب التغطيات المنشورة، يعمل المشروع بحجم إنتاجي يبلغ ملايين البيئات المعزولة يومياً.

كيف يعمل العزل؟

الفكرة المركزية أن كل مهمة وكيل تحصل على جهاز افتراضي صغير خاص بها من نوع Firecracker microVM، وهي التقنية التي بنت عليها خدمات كبيرة أنظمتها. أهم ما في التصميم:

• نواة مستقلة لكل بيئة: لكل sandbox نواة ضيف (guest kernel) خاصة به، فلا يشارك نواة المضيف كما تفعل الحاويات العادية.
• بوابة شبكة لكل بيئة: بوابة على جهاز المضيف تفرض سياسة الخروج (Egress) على كل اتصال صادر، خارج سيطرة الوكيل.
• أسرار لا تدخل البيئة: تُحقن بيانات الاعتماد على مستوى الشبكة، فلا يراها الكود الذي يشغّله الوكيل أصلاً. ويضيف مخزن الاعتماد نطاقات هرمية وحدود معدّل وسجل تدقيق.
• حالة قابلة للإدارة: إيقاف مؤقت وتفرّع (fork) ولقطات واستئناف، وهي مفيدة للمهام الطويلة التي تحتفظ بحالتها.

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

ماذا اختبرت Perplexity؟

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

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

مقارنة سريعة بين مستويات العزل

ماذا يستفيد المطوّر العربي؟

حتى لو لم تكن تشغّل ملايين البيئات، فالدروس قابلة للتطبيق على أي وكيل يكتب أو ينفذ كوداً:

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

أسئلة شائعة

هل يمكنني استخدام SPACE مجاناً؟

المشروع مفتوح المصدر برخصة Apache 2.0 على GitHub ضمن حساب perplexityai. تشغيله بحجم كبير يتطلب بنية تحتية تدعم Firecracker، أي ليس بالضرورة جهازك الشخصي.

هل الحاويات العادية غير كافية للوكلاء؟

تكفي أحياناً للمهام الموثوقة، لكن مشاركة النواة تعني أن ثغرة واحدة قد تفتح المضيف. لذلك يفضّل كثيرون microVM عندما يكون الكود المنفَّذ غير موثوق أو مولّداً آلياً.

هل يعني نجاح الاختبار أن الوكلاء آمنون تماماً؟

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

الخلاصة

فتح Perplexity لـ SPACE خطوة مفيدة للنظام البيئي لأنه ينقل النقاش من «كيف نثق بالوكيل» إلى «كيف نبني بيئة لا تحتاج إلى الثقة». نواة مستقلة، وبوابة شبكة على المضيف، وأسرار لا تدخل الصندوق: ثلاث قواعد يمكن لأي فريق أن يبدأ بها اليوم، سواء اعتمد المنصة أو بنى حلاً خاصاً.

المصادر: MarkTechPost، ExplainX، CellCog، AlphaSignal