Nvidia تفتح مصدر OpenShell — بيئة آمنة لوكلاء الذكاء الاصطناعي المستقلين

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

لماذا يهم ذلك؟

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

وهذه هي الفجوة التي تحاول Nvidia سدّها عبر OpenShell. فقد نشرت الشركة المشروع بترخيص Apache 2.0، وعرضته في سياق GTC 2026، ودمجته في حزمتها الخاصة بالأنظمة الوكيلية. والفكرة بسيطة: ينبغي ألّا يعتمد الأمان على الموجّهات والقيود الداخلية للنموذج وحدها، بل على طبقة تنفيذ مستقلة تقف بين الوكيل ونظام التشغيل، ولا تتأثر بمدى انضباط الوكيل نفسه.

كيف تعمل بنية OpenShell؟

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

ويجعل هذا النهج OpenShell محايدًا تجاه الوكلاء (agent-agnostic): يمكن تشغيل OpenClaw وClaude Code وCodex وأنظمة أخرى داخله دون إعادة كتابة المنطق ليلائم SDK جديدًا.

• يحدّ صندوق العزل من الوصول إلى نظام الملفات، ولا يسمح للوكيل بتعديل الجهاز المضيف بحرية.
• يضع محرك السياسات قواعد دقيقة للملفات التنفيذية والعناوين الشبكية وطرق HTTP ومسارات الوصول.
• يقرر موجّه الخصوصية (privacy router) وجهة الاستدلال: نموذج محلي أو API خارجي، إذا سمحت السياسة بذلك.
• يسجّل سجلّ التدقيق (audit log) سبب السماح بالإجراء أو حظره أو إعادة توجيهه.

ويقوم النظام على سياسات YAML تصريحية. تُحدَّد القيود الثابتة على نظام الملفات والعمليات عند إنشاء sandbox، بينما يمكن تحديث سياسات الشبكة وسياسات الاستدلال (inference) أثناء التشغيل دون إعادة تشغيل. وتؤكد Nvidia في وثائقها أن OpenShell يستخدم عزلًا على مستوى النواة (kernel-level isolation)، يشمل Landlock لمسارات نظام الملفات وseccomp لحظر استدعاءات النظام الخطرة. كما يوفّر ذلك أثرًا قابلًا للتفسير: فالفريق لا يرى واقعة الحظر فحسب، بل السبب المحدد للقرار.

ماذا يحصل عليه المطوّر؟

الميزة العملية أن OpenShell لا يتطلب إعادة كتابة الوكلاء الموجودين. يستطيع المطوّر تشغيل sandbox بأمر CLI، والاتصال بها عبر الطرفية، ثم فتح الصلاحيات اللازمة بدقة عبر السياسات. وهناك أيضًا وضع بعيد: يمكن تشغيل sandbox محليًا أو على جهاز بعيد أو عنقود GPU، وإدارتها من طرفية عادية. وهذا يجعل المشروع مناسبًا للتطوير المحلي وCI/CD وكذلك لسيناريوهات الإنتاج الأثقل.

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

«الجلسات معزولة، والموارد خاضعة للرقابة، والأذونات تُفحص قبل أي إجراء» — هكذا تصف

Nvidia المنطق الأساسي لـ OpenShell.

ماذا يعني ذلك؟

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