OpenAI تضيف بيئة تنفيذ معزولة (sandbox) إلى Agents SDK لتحكم أفضل وتشغيل آمن لوكلاء الذكاء الاصطناعي

تسعى OpenAI إلى سدّ إحدى أكثر الثغرات إيلامًا في وكلاء الذكاء الاصطناعي المؤسسيين: كيف تمنح النموذج صلاحية الوصول إلى الملفات والشيفرة وبيئة العمل دون أن يتحول ذلك إلى خطر غير خاضع للسيطرة على الشركة. يضيف التحديث الجديد لحزمة Agents SDK تنفيذًا أصليًا داخل بيئة sandbox، أي طبقة تنفيذ معزولة يستطيع فيها الوكيل قراءة الملفات وكتابتها وتشغيل الأوامر والتعامل مع التبعيات (dependencies)، دون أن يحصل على وصول مباشر إلى البنية التحتية الحساسة. وبالنسبة إلى الفرق التي تجاوزت مرحلة العروض التجريبية وتحاول تشغيل مسارات عمل الوكلاء في بيئة الإنتاج، فهذا ليس تحديثًا شكليًا، بل محاولة لمعالجة ثلاث مشكلات دفعة واحدة: الحوكمة (governance) والموثوقية وتكلفة عمليات التشغيل الطويلة.

حتى الآن كان أمام المطورين خيار صعب. فالأطر المحايدة تجاه النماذج (model-agnostic) منحتهم الحرية وجنّبتهم الارتباط بمزوّد واحد، لكنها غالبًا لم تستثمر إمكانات النماذج الرائدة (frontier) بالكامل. أما حزم SDK الصادرة عن المزوّدين أنفسهم فكانت أقرب إلى النموذج، لكنها لم توفر دائمًا الشفافية المطلوبة في حلقة التحكم. وسهّلت واجهات managed agent API عملية الإطلاق، لكنها قيّدت بشدة المكان الذي يعمل فيه الوكيل وطريقة وصوله إلى بيانات المؤسسة.

تحاول OpenAI رفع هذا التنازل عبر ما تسميه model-native harness، وهي طبقة تحكم أكثر انسجامًا مع الطريقة التي تعمل بها النماذج فعليًا في المهام الطويلة متعددة الخطوات. وتضمّ الحزمة المحدّثة ذاكرة قابلة للضبط، وتنسيقًا (orchestration) يراعي بيئة sandbox، وأدوات للتعامل مع نظام الملفات على غرار Codex، ودعمًا لـ MCP وAGENTS.md وshell وapply patch.

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

ولتسهيل الربط ببيئة المؤسسة، أضافت OpenAI أيضًا تجريدًا (abstraction) باسم Manifest. وهو يصف مساحة عمل الوكيل: أي الملفات المحلية يمكن ربطها (mount)، وأين تُكتب النتائج، ومن أي مخازن تُجلب البيانات. وتشمل المخازن المدعومة AWS S3 وAzure Blob Storage وGoogle Cloud Storage وCloudflare R2.

يتركز التحديث أساسًا على الأمان. فتنطلق OpenAI من افتراض أن أي وكيل يقرأ محتوى خارجيًا أو ينفّذ شيفرة مولَّدة سيواجه عاجلًا أم آجلًا هجمات prompt injection ومحاولات تسريب البيانات (exfiltration). لذلك تفصل الشركة بين control harness وطبقة الحوسبة (compute layer). وتبقى بيانات الاعتماد وحلقة التحكم الرئيسية خارج البيئة التي تُنفَّذ فيها الشيفرة التي ينتجها النموذج. ويقلل ذلك احتمال أن تتمكن تعليمات خبيثة مخبأة داخل مستند أو طلب من الوصول إلى المفاتيح أو واجهات API الداخلية أو الأنظمة المجاورة.

وتُعالَج بشكل منفصل مشكلة موثوقية عمليات التشغيل الطويلة: فإذا انهارت الحاوية عند الخطوة التاسعة عشرة من عشرين، فلا حاجة إلى بدء التشغيل من الصفر. إذ يحفظ SDK الحالة في طبقة خارجية، ويستطيع إنشاء snapshot ثم إعادة تهيئة الحالة (rehydration)، ثم متابعة المهمة من آخر نقطة تحقق (checkpoint) داخل حاوية جديدة. وتقلل هذه البنية النفقات السحابية وتسهّل التوسع في الوقت نفسه: إذ يمكن توزيع عمليات التشغيل على عدة بيئات sandbox، وعزل الوكلاء الفرعيين (subagents)، وتوزيع الحمل (workload) بالتوازي.

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

الإمكانات الجديدة متاحة بالفعل عبر API وفق نموذج التسعير القياسي، لكن لبيئة Python أولًا، بينما أُعلن عن دعم TypeScript لاحقًا. وتبدو الخطوات التالية المنطقية هي code mode والوكلاء الفرعيين وتكاملًا أوثق مع الأدوات الداخلية للشركات، أي كل ما يلزم لينتقل الوكيل من مرحلة التجربة إلى مسار عمل خاضع للإدارة.