تشغيل Codex أو وكيل برمجة في صندوق رمل آمن

قم بتشغيل وكيل برمجة في صندوق رمل (sandbox) بمنحه مساحة عمل مستودع محددة النطاق، ومسار تنفيذ طرفي مُتحكم فيه، وصلاحيات ملفات صريحة، وسياسات شبكة وتثبيت حزم، وأسرار معزولة، وسجلات أوامر، وملفات مُخرجة، ومسار موافقة واضح للتغييرات عالية المخاطر قبل الدمج أو النشر. يعمل هذا النمط سواء كان الوكيل من نمط Codex، أو متصلًا ببيئة التطوير (IDE)، أو مُشغلًا من خلال CI، أو مدمجًا في منصة المطورين الخاصة بك: يمكن للنموذج التخطيط والتحرير، لكن الصندوق الرملي هو الذي يقرر ما يمكنه لمسه، وما يمكنه تشغيله، وما يمكنه جلبه، وما الأدلة التي سيتلقاها المراجع.

ما هو صندوق رمل وكيل البرمجة؟

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

التحول المهم هو أن الصندوق الرملي ليس مجرد غلاف محادثة (chat wrapper) حول النموذج. إنه الحدود التشغيلية للعمل. يقترح النموذج الإجراءات؛ يفرض الصندوق الرملي مساحة العمل، والأدوات، والأذونات، ومسار الأدلة.

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

• مساحة عمل مخصصة لكل مهمة أو جلسة.
• حالة مستودع وفرع معروفان.
• واجهة تنفيذ أوامر مع موافقات للعمليات الخطرة.
• سياسة تثبيت حزم لـ npm وpip وcargo وapt والأدوات المشابهة.
• قواعد اتصال شبكة صادرة للسجلات (registries)، والمستندات، وواجهات API، ووصول المعاينات.
• أسرار محددة نطاق المهمة ومخفية عن السجلات قدر الإمكان.
• التقاط stdout، stderr، رموز الخروج، تغييرات الملفات، الملفات المُنشأة، وعناوين URL للمعاينات.
• بوابة مراجعة قبل الدمج أو النشر أو الإصدار الخارجي.

لهذا السبب يجب فهم “تشغيل Codex في صندوق رمل” على أنه نمط بنية تحتية، وليس مجرد علامة سطر أوامر واحدة أو تكامل مع بائع واحد. تم توثيق Codex CLI نفسه كوكيل برمجة يعمل محليًا على جهاز الكمبيوتر الخاص بك، وتوثيق OpenAI’s Codex يصف سير عمل موجهًا للطرفية (terminal). إذا كنت تدير هذا النوع من الوكلاء لفريق، أو نظام CI، أو سير عمل منتج، فإن بيئة التشغيل المحيطة تصبح مستوى التحكم.

بنية صندوق رمل وكيل البرمجة

أفضل بنية تفصل حلقة النموذج عن حدود التنفيذ:

الطبقة	المسؤولية	الأسئلة التي تحتاج إجابة
واجهة الوكيل (Agent interface)	تحويل نية المستخدم إلى خطط، تحريرات ملفات، استدعاءات أدوات، وملخصات مراجعة	ما النموذج أو وكيل البرمجة المستخدم؟ كيف تتم إدارة الاستفسارات (prompts) والسياق ومخططات الأدوات؟
مدير مساحة العمل (Workspace manager)	إنشاء الصندوق الرملي، سحب المستودع، تعيين الفرع، وتحميل الملفات المسموح بها	هل كل مهمة معزولة؟ هل الالتزام الأساسي (base commit) معروف؟ هل يمكن إعادة تعيين مساحة العمل؟
مشغل الأوامر الطرفية (Terminal runner)	تنفيذ الأوامر المعتمدة وإعادة النتائج إلى الوكيل	ما الأوامر التي تعمل تلقائيًا، تتطلب موافقة، أو محظورة؟
طبقة السياسات (Policy layer)	التحكم في نطاق نظام الملفات، الأسرار، الاتصال الصادر للشبكة، تثبيت الحزم، حدود وقت التشغيل، والتنظيف	هل يمكن للوكيل جلب الحزم؟ هل يمكنه الاتصال بالإنترنت العام؟ هل يمكنه قراءة بيانات الاعتماد؟
طبقة الأدلة (Evidence layer)	تخزين السجلات، الفروق (diffs)، نتائج الاختبارات، المعاينات، والملفات المُخرجة	هل يمكن للمراجع إعادة بناء ما حدث دون الثقة في ملخص النموذج؟
بوابة المراجعة (Review gate)	تتطلب خطوة موافقة بشرية أو أتمتة موثوقة قبل الدمج أو النشر أو الإصدار	من يوافق على التغييرات الخطرة؟ ما الفحوصات التي يجب أن تنجح أولاً؟

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

كيف يجب أن يعمل الوصول إلى الطرفية في صندوق رمل وكيل البرمجة؟

الطرفية (terminal) هي المكان الذي يصبح فيه وكيل البرمجة مفيدًا تشغيليًا وخطيرًا تشغيليًا. يمكنه تشغيل الاختبارات، بناء الأصول، فحص الملفات المُنشأة، تشغيل الخوادم المحلية، وتشخيص الأعطال. يمكنه أيضًا حذف الملفات، تسريب متغيرات البيئة، تشغيل نصوص تثبيت غير متوقعة، أو استهلاك موارد حاسوبية كبيرة.

يحتوي النموذج الجيد للطرفية على ثلاثة أجزاء.

أولاً، حدد فئات الأوامر. الأوامر الآمنة للقراءة فقط مثل ls وsed وrg وgit diff وأوامر حالة الاختبار يمكن تشغيلها تلقائيًا غالبًا. أوامر البناء والاختبار مثل npm test وpytest وcargo test وnpm run build يمكن السماح بها مع مهلة زمنية. الأوامر التدميرية أو ذات التأثير الخارجي مثل rm -rf وgit push وgh pr merge وواجهات CLI للنشر ونشر الحزم وترحيل قواعد البيانات (database migration) أو تغيير موارد السحابة يجب أن تتطلب موافقة صريحة أو تكون محظورة تمامًا.

ثانيًا، قم ببث النتائج بهيكل. يجب أن يرى الوكيل والمراجع الأمر، دليل العمل، وقت البدء، رمز الخروج، stdout، stderr، حالة المهلة، وسياسة الإخراج المقتطع (truncated-output). لقطة شاشة للطرفية ليست كافية؛ يجب على النظام الحفاظ على سجلات قابلة للقراءة آليًا.

ثالثًا، تعامل مع الجلسات الطويلة عن قصد. غالبًا ما يحتاج وكلاء البرمجة إلى خادم تطوير خلفي (dev server)، ومشرف (watcher)، وعملية أتمتة متصفح، أو مجموعة اختبار تكامل. تعامل مع العمليات الطويلة كموارد بمقابض (handles): ابدأها، بث السجلات، اعرض فقط منفذ المعاينة المطلوب، وأوقفها أثناء التنظيف. لا تدع عملية خلفية تصبح أثرًا جانبيًا غير متتبع لجلسة محادثة.

عزل المستودع والتحكم في الفرع لتغييرات الوكيل

حالة المستودع هي العمود الفقري لسير عمل وكيل برمجة قابل للمراجعة. يجب ألا يعمل الوكيل في مجلد غامض مع تعديلات محلية غير معروفة ما لم يختر المستخدم هذا الوضع صراحة.

لسير عمل الفريق، ابدأ كل مهمة من عنوان URL معروف للمستودع، وفرع أساسي، وSHA التزام. أنشئ فرع مهمة أو مساحة عمل منفصلة (detached). حافظ على فصل تغييرات المستخدم عن تغييرات الوكيل، والتقط الفرق (diff) الدقيق قبل المراجعة. إذا كان الصندوق الرملي يدعم الجلسات المستمرة، فاحتفظ بمساحة العمل عن قصد؛ لا تعتمد على حالة عملية عرضية.

يبدو النمط الافتراضي كما يلي:

1. إنشاء مساحة عمل معزولة للمهمة task-123.
2. سحب المستودع على main@<base_sha>.
3. إنشاء فرع agent/task-123.
4. تشغيل تثبيت التبعيات وفقًا للسياسة.
5. السماح للوكيل بالفحص والتحرير والاختبار والتكرار.
6. التقاط git diff، مخرجات الاختبار، الملفات المُنشأة، وعنوان URL المعاينة.
7. فتح طلب سحب (pull request) أو تسليم التصحيح إلى مراجع بشري.
8. تفكيك أو أرشفة مساحة العمل وفقًا لسياسة الاحتفاظ.

التفصيل الرئيسي هو الخطوة 6. الوكيل البرمجي المفيد لا يقول فقط "لقد أصلحته." إنه يعيد الملفات التي تم تغييرها، لماذا يوجد كل تغيير، ما التحقق الذي تم تشغيله، ما فشل، وما بقي غير موثوق.

سياسات الأوامر والحزم والشبكة لوكلاء البرمجة في الصندوق الرملي

تثبيت الحزم هو أحد أصعب أجزاء عزل وكيل البرمجة. تحتاج العديد من المهام الحقيقية إلى تبعيات. تبدأ العديد من حوادث سلسلة التوريد (supply-chain) أيضًا بجلب التبعيات أو نصوص ما بعد التثبيت أو الملفات الثنائية غير الشفافة.

السياسة العملية ليست “لا تقم أبدًا بتثبيت الحزم.” إنها “قم بتثبيت الحزم فقط من خلال مسارات معروفة، مع تسجيل ونطاق.”

التحكم	التنفيذ العملي
مديرو الحزم	حدد مديري الحزم المتاحين حسب اللغة ونوع المستودع.
الوصول إلى السجلات (registries)	اسمح بالسجلات المعتمدة؛ احظر مصادر الحزم العشوائية عندما لا تحتاج المهمة إليها.
ملفات القفل (Lockfiles)	فضّل ملفات القفل الحالية وأوامر التثبيت القابلة للتكرار.
نصوص ما بعد التثبيت	قرر ما إذا كانت نصوص دورة الحياة (lifecycle scripts) يمكن تشغيلها تلقائيًا أو تتطلب موافقة.
حزم النظام	تعامل مع apt وbrew وتثبيت حزم نظام التشغيل كمخاطر أعلى من تثبيت تبعيات المشروع.
ذاكرات التخزين المؤقت (Caches)	استخدم ذاكرات تخزين مؤقت محكومة للحزم عندما تحتاج إلى سرعة وقابلية تكرار.
التسجيل	قم بتخزين أسماء الحزم، الإصدارات، عناوين URL للسجلات، المجاميع الاختبارية (checksums) عند توفرها، ومخرجات التثبيت.

يجب أن تكون سياسة الشبكة واضحة بالمثل. قد يحتاج وكيل البرمجة إلى قراءة الوثائق العامة، أو استدعاء واجهة API للتطوير (staging API)، أو تنزيل حزمة، أو عرض معاينة محلية. هذه مختلفة عن الوصول غير المقيد إلى الإنترنت. افصل جلب الحزم الصادر، وتصفح الويب، واستدعاءات API، وتسليم webhook، ومدخل المعاينة. إذا كان منتجك يتعامل مع كود أو بيانات حساسة، اسأل ما إذا كانت DNS وسجلات الوكيل (proxy logs) ومرايا السجلات (registry mirrors) مشمولة بنفس سياسة حركة مرور HTTP.

الأسرار والسجلات ومسارات التدقيق لمساحات عمل الوكيل

يجب أن تكون الأسرار محددة لأصغر سطح مفيد. لا يحتاج وكيل البرمجة عادةً إلى بيانات اعتماد الإنتاج. قد يحتاج إلى رمز Git للقراءة فقط، أو رمز سجل حزم، أو مفتاح API للتطوير، أو رمز نشر معاينة. يجب أن يكون كل محددًا لنطاق المهمة، محدد الوقت قدر الإمكان، وغير متاح للأوامر التي لا تتطلبه.

تجنب وضع الأسرار في ملفات يمكن للوكيل قراءتها ما لم تتطلب المهمة ذلك حقًا. فضّل الوصول الوسيط (brokered access): يمكن للصندوق الرملي تنفيذ عملية، لكن النموذج لا يرى بيانات الاعتماد الخام. عندما تكون متغيرات البيئة ضرورية، يجب على السجلات تحرير (redact) أنماط الأسرار المعروفة، ويجب ألا تتضمن ملفات المراجعة تفريغات كاملة للبيئة.

بالنسبة لمسارات التدقيق، قم بتخزين أكثر من مجرد التصحيح النهائي:

• طلب المستخدم وبيانات المهمة التعريفية.
• عنوان URL المستودع، الالتزام الأساسي، الفرع، والالتزام النهائي أو الفرق (diff).
• الأوامر المطلوبة والمعتمدة والمحظورة والمنفذة.
• مخرجات الأوامر، رموز الخروج، والمهل الزمنية.
• قراءات وكتابات الملفات عندما يمكن للمنصة التقاطها.
• سجلات الشبكة وجلب الحزم على المستوى الذي تدعمه سياستك.
• عناوين URL المعاينة ومسارات الملفات المُنشأة.
• الموافقات البشرية وقرارات الدمج.

هذه ليست بيروقراطية. إنها كيف يميز المراجع بين إصلاح حقيقي وقصة معقولة.

الفروق (diffs) والمعاينات وبوابات المراجعة قبل الدمج

الناتج الأكثر فائدة من وكيل البرمجة هو مجموعة تغييرات قابلة للمراجعة. يعني ذلك أن الصندوق الرملي يجب أن ينتج نفس الملفات التي يتوقعها مهندس دقيق من طلب سحب (pull request):

• فرق مركز.
• اختبارات أو أوامر بناء تم تشغيلها.
• الإخفاقات التي لا تزال قائمة.
• لقطات شاشة، عناوين URL معاينة، أو ملفات قابلة للتنزيل عندما تتغير واجهة المستخدم أو الأصول المُنشأة.
• شرح موجز لتغيير السلوك المقصود.

احتفظ بخطوة الدمج أو النشر النهائي خلف بوابة بشرية ما لم تكن مؤسستك قد بنت سياسة أتمتة موثوقة منفصلة لذلك المستودع ومستوى المخاطرة بالضبط. المراجعة البشرية مهمة بشكل خاص عندما تلمس التغييرات المصادقة (authentication) أو الفوترة (billing) أو الوصول إلى البيانات أو استدعاءات الشبكة أو البنية التحتية أو إصدارات التبعيات أو الترحيلات المُنشأة (generated migrations) أو المحتوى المرئي للمستخدم.

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

استراتيجية التنظيف وإعادة التعيين لجلسات الوكيل الطويلة

كل صندوق رمل يحتاج إلى دورة حياة. بدونها، تصبح بنية وكيل البرمجة طويلة الأمد كومة من مساحات العمل القديمة والسجلات المسربة والعمليات التي لا تزال قيد التشغيل.

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

حدد التنظيف من أجل:

• العمليات الخلفية والمنافذ المفتوحة.
• الملفات المؤقتة ومخرجات البناء.
• ذاكرات التخزين المؤقت للحزم والأرشيفات التي تم تنزيلها.
• الأسرار الخاصة بالمهمة.
• السجلات والملفات المُخرجة.
• الفروع أو أشجار العمل (worktrees) التي تم استبدالها.

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

أين يتناسب Novita Agent Sandbox مع سير العمل هذا

Novita Agent Sandbox مصمم للبنية التحتية للوكلاء حيث تحتاج تنفيذ الكود، أتمتة المتصفح، سير العمل من نمط استخدام الكمبيوتر (computer-use)، تحليل البيانات، التقييمات، وسير عمل الوكيل الأطول إلى بيئة تشغيل معزولة. يصف توثيق Novita Agent Sandbox المنتج كبيئة ذات حالة (stateful environment) لتشغيل أعباء عمل الوكيل، مع مسارات SDK وCLI للعمل مع دورة حياة الصندوق الرملي والملفات والأوامر وجلسات المتصفح وعناصر سير العمل ذات الصلة.

للفرق التي تستخدم بالفعل واجهات برمجة تطبيقات نموذج Novita AI، يمكن لطبقة الصندوق الرملي تقليل الفجوة بين استدلال النموذج وتنفيذ الإجراء. يمكن للنموذج التفكير واستدعاء الأدوات والتخطيط لتغييرات الكود؛ يمكن للصندوق الرملي توفير مساحة العمل المعزولة حيث يتم تنفيذ تلك الإجراءات وتسجيلها ومعاينتها ومراجعتها.

استخدم حدود منتج محافظة عند تصميم سير عملك:

• تعامل مع Novita Agent Sandbox كبيئة تنفيذ، وليس ضمانًا أمنيًا شاملاً.
• احتفظ بالأسرار وتثبيت الحزم والاتصال الصادر وإجراءات النشر خلف سياستك الخاصة.
• تحقق من تفاصيل SDK الحالية وCLI والتسعير وحدود الحساب من توثيق Novita قبل ترميزها في أتمتة الإنتاج.
• قيم حدود العزل وتوافق وكلاء الطرف الثالث ومتطلبات الامتثال مقابل سياستك الخاصة قبل الاعتماد على أي صندوق رمل في الإنتاج.

هذا الفصل يحافظ على فائدة إرشادات التنفيذ حتى عندما تتغير طبقة الوكيل. يمكنك استخدام وكلاء من نمط Codex أو وكلاء برمجة داخليين أو وكلاء متصفح أو عمال تقييم مع الاحتفاظ بنفس أسئلة التحكم في الصندوق الرملي.

قائمة التحقق لتنفيذ صندوق رمل وكيل البرمجة

استخدم قائمة التحقق هذه قبل نقل صندوق رمل وكيل البرمجة إلى ما بعد النموذج الأولي.

المجال	سؤال الإنتاج الأدنى
مساحة العمل	هل تحصل كل مهمة على نظام ملفات محدد ونطاق والتزام قاعدة مستودع معروف؟
الفروع (Branching)	هل تغييرات الوكيل معزولة على فرع أو تصحيح يمكن للمراجعين فحصه؟
الطرفية	هل يتم تسجيل الأوامر مع دليل العمل والمخرجات ورمز الخروج والمهلة الزمنية؟
الموافقة	ما الأوامر التي تعمل تلقائيًا، تتطلب موافقة، أو محظورة؟
الحزم	هل تثبيت التبعيات قابل للتكرار ومسجل؟
الشبكة	هل الاتصال الصادر مفصول بين جلب الحزم وتصفح الوثائق واستدعاءات API ووصول المعاينة؟
الأسرار	هل بيانات الاعتماد محددة نطاق المهمة ومحررة من السجلات؟
المعاينات	هل منافذ المعاينة صريحة وسهلة الإغلاق؟
الملفات المُخرجة	هل الملفات المُنشأة ولقطات الشاشة والتقارير والسجلات مرفقة بالمراجعة؟
الثبات	هل إيقاف الجلسة مؤقتًا/استئنافها مقصود، مع مالك وتاريخ انتهاء؟
التنظيف	هل تتم إزالة العمليات والمنافذ والملفات المؤقتة والأسرار ومساحات العمل القديمة؟
المراجعة	هل يوافق إنسان على الدمج أو النشر أو الإصدار للتغييرات الخطرة؟

إذا كان إعدادك الحالي لا يستطيع الإجابة على عدة من هذه الأسئلة، أبقِ سير العمل في مسار نموذج أولي. قد يظل الوكيل مفيدًا، لكن لا ينبغي أن يحصل على وصول واسع للمستودع أو الشبكة أو بيانات الاعتماد.

الأسئلة الشائعة

هل يمكنني تشغيل Codex نفسه داخل صندوق رمل سحابي؟

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

هل Docker كافٍ لصندوق رمل وكيل برمجة؟

يمكن أن يكون Docker مفيدًا للتطوير المحلي ومهام CI والبيئات القابلة للتكرار، لكن “كافٍ” يعتمد على نموذج التهديد الخاص بك. اسأل ما الذي يشارك kernel، وما هي وصلات الملفات الموجودة، وكيف يتم التحكم في الاتصال الصادر للشبكة، وما إذا كانت الأسرار مكشوفة للحاوية، وكيف سيتم التعامل مع عمليات الهروب (escapes) أو اختراق التبعيات. لأعباء العمل الحساسة، غالبًا ما تقوم فرق الأمن بتقييم حدود عزل أقوى وضوابط اتصال صادر أكثر صرامة.

هل يجب أن يكون لوكيل البرمجة وصول إلى الإنترنت؟

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

ما الذي يجب أن ينظر إليه المراجع قبل دمج الكود الذي يولده الوكيل؟

راجع الفرق (diff)، الأوامر التي تم تشغيلها، مخرجات الاختبار/البناء، تغييرات التبعيات، الملفات المُنشأة، سلوك المعاينة، وأي تحقق تم تخطيه. انتبه بشكل إضافي للمصادقة، الأذونات، معالجة البيانات، استدعاءات الشبكة، الترحيلات، نصوص التثبيت، والأسرار.

كيف تساعد Novita في صناديق رمل وكيل البرمجة؟

يوفر Novita Agent Sandbox بيئة تشغيل وكيل معزولة لأعباء العمل مثل تنفيذ الكود وأتمتة المتصفح ومهام من نمط استخدام الكمبيوتر وتحليل البيانات والتقييمات وسير العمل الأطول. قم بإقرانها بسياسات صريحة للمستودع والأوامر والحزم والشبكة والأسرار والمراجعة عند بناء سير عمل وكيل برمجة.

المقالات الموصى بها

• بناء وكيل برمجة مع Novita’s Agent Sandbox
• كيف تدعم صناديق الرمل للوكلاء الابتكار الآمن والقابل للتوسع في AI
• كيفية استخدام Codex مع نماذج Novita AI