- ما هي البيئة الآمنة لوكيل البرمجة؟
- بنية البيئة الآمنة لوكيل البرمجة
- كيف يجب أن يعمل الوصول إلى الطرفية في بيئة آمنة لوكيل البرمجة؟
- عزل المستودع والتحكم في الفرع لتغييرات الوكيل
- سياسات الأوامر والحزم والشبكة لوكلاء البرمجة في البيئة الآمنة
- الأسرار والسجلات ومسارات التدقيق لمساحات عمل الوكيل
- الفروق والمعاينات وبوابات المراجعة قبل الدمج
- استراتيجية التنظيف وإعادة التعيين لجلسات الوكيل الطويلة
- أين تتناسب بيئة Novita Agent Sandbox مع سير العمل هذا
- قائمة فحص تنفيذ البيئة الآمنة لوكيل البرمجة
- الأسئلة الشائعة
قم بتشغيل وكيل برمجة في بيئة آمنة (sandbox) من خلال منحه مساحة عمل مستودع محددة النطاق، مسار تنفيذ طرفية مُتحكم به، صلاحيات ملفات صريحة، سياسات الشبكة وتثبيت الحزم، أسرار معزولة، سجلات الأوامر، القطع الأثرية، ومسار موافقة واضح للتغييرات عالية المخاطر قبل الدمج أو النشر. يعمل هذا النمط سواء كان الوكيل من نمط Codex، متصلًا بـ IDE، مُشغلًا من CI، أو مضمّنًا في منصة المطورين الخاصة بك: يمكن للنموذج التخطيط والتحرير، لكن البيئة الآمنة هي التي تقرر ما يمكنه لمسه، وما يمكنه تشغيله، وما يمكنه جلبه، وما الأدلة التي يتلقاها المراجع.
ما هي البيئة الآمنة لوكيل البرمجة؟
البيئة الآمنة لوكيل البرمجة هي بيئة تشغيل معزولة حيث يمكن للنظام الذكي فحص الكود، تحرير الملفات، تشغيل أوامر الطرفية، تثبيت التبعيات عندما تسمح السياسة بذلك، تنفيذ الاختبارات، بدء خوادم المعاينة، وإرجاع فرق قابل للمراجعة دون الحصول على وصول واسع إلى جهاز المطور أو بيئة الإنتاج.
التحول المهم هو أن البيئة الآمنة ليست مجرد غلاف محادثة حول النموذج. إنها الحدود التشغيلية للعمل. يقترح النموذج الإجراءات؛ تفرض البيئة الآمنة مساحة العمل، والأدوات، والأذونات، ومسار الأدلة.
بالنسبة لمساعد برمجة بسيط، قد يكون السحب المحلي والنسخ واللصق اليدوي كافيين. بالنسبة لوكيل يمكنه تشغيل الأوامر أو الاستمرار لعدة خطوات، فأنت بحاجة إلى حدود أقوى:
- مساحة عمل مخصصة لكل مهمة أو جلسة.
- حالة مستودع وفرع معروفان.
- واجهة تنفيذ أوامر مع موافقات للعمليات الخطرة.
- سياسة تثبيت حزم لـ
npm،pip،cargo،apt، وأدوات مماثلة. - قواعد الخروج من الشبكة للسجلات، الوثائق، واجهات API، ووصول المعاينة.
- أسرار محددة النطاق للمهمة ومخفية من السجلات حيثما أمكن.
- التقاط stdout، stderr، رموز الخروج، تغييرات الملفات، القطع الأثرية المُنشأة، وعناوين URL للمعاينة.
- بوابة مراجعة قبل الدمج أو النشر أو الإصدار الخارجي.
لهذا السبب يجب فهم “تشغيل Codex في بيئة آمنة” على أنه نمط بنية تحتية، وليس علامة CLI واحدة أو تكامل بائع واحد. Codex CLI نفسه موثق كعامل برمجة يعمل محليًا على جهاز الكمبيوتر الخاص بك، وتصف وثائق Codex من OpenAI سير عمل موجهًا نحو الطرفية. إذا كنت تشغل هذا النوع من الوكيل لفريق أو نظام CI أو سير عمل منتج، فإن بيئة التنفيذ المحيطة تصبح لوحة التحكم.
بنية البيئة الآمنة لوكيل البرمجة
أفضل بنية تفصل حلقة النموذج عن حدود التنفيذ:
| الطبقة | المسؤولية | الأسئلة التي يجب الإجابة عليها |
|---|---|---|
| واجهة الوكيل | تحويل نية المستخدم إلى خطط، تحرير ملفات، استدعاءات أدوات، وملخصات مراجعة | أي نموذج أو وكيل برمجة يُستخدم؟ كيف تتم إدارة المطالبات والسياق ومخططات الأدوات؟ |
| مدير مساحة العمل | إنشاء البيئة الآمنة، سحب المستودع، تعيين الفرع، وتحميل الملفات المسموح بها | هل كل مهمة معزولة؟ هل الالتزام الأساسي معروف؟ هل يمكن إعادة تعيين مساحة العمل؟ |
| مشغل الطرفية | تنفيذ الأوامر المعتمدة وبث النتائج مرة أخرى إلى الوكيل | أي الأوامر مسموح بها تلقائيًا، تتطلب موافقة، أو محظورة؟ |
| طبقة السياسة | التحكم في نطاق نظام الملفات، الأسرار، الخروج من الشبكة، تثبيت الحزم، حدود وقت التشغيل، والتنظيف | هل يمكن للوكيل جلب الحزم؟ هل يمكنه الاتصال بالإنترنت العام؟ هل يمكنه قراءة بيانات الاعتماد؟ |
| طبقة الأدلة | تخزين السجلات، الفروق، نتائج الاختبار، المعاينات، والقطع الأثرية | هل يمكن للمراجع إعادة بناء ما حدث دون الوثوق بملخص النموذج؟ |
| بوابة المراجعة | تتطلب خطوة بشرية أو أتمتة موثوقة قبل الدمج أو النشر أو الإصدار | من يوافق على التغييرات الخطرة؟ ما الشيكات التي يجب أن تمر أولاً؟ |
في الممارسة العملية، قد تجمع منصة واحدة عدة طبقات من هذه الطبقات. لا تزال البنية مهمة لأنها تحافظ على صدق اختيارات المنتج. إذا أعطت أداة وكيلًا طرفية لكنها لا تستطيع عرض سجلات الأوامر أو فروق الملفات أو سياسة الخروج، فقد تكون مناسبة للنماذج الأولية لكنها ضعيفة للمراجعة الإنتاجية.
كيف يجب أن يعمل الوصول إلى الطرفية في بيئة آمنة لوكيل البرمجة؟
الطرفية هي المكان الذي يصبح فيه وكيل البرمجة مفيدًا تشغيليًا وخطيرًا تشغيليًا. يمكنه تشغيل الاختبارات، بناء الأصول، فحص الملفات المُنشأة، بدء الخوادم المحلية، وتشخيص الأعطال. يمكنه أيضًا حذف الملفات، تسريب متغيرات البيئة، تشغيل سكريبتات تثبيت غير متوقعة، أو استهلاك موارد حاسوبية كبيرة.
نموذج الطرفية الجيد يتكون من ثلاثة أجزاء.
أولاً، حدد فئات الأوامر. يمكن غالبًا تشغيل الأوامر الآمنة للقراءة فقط مثل ls، sed، rg، git diff، وأوامر حالة الاختبار تلقائيًا. قد تكون أوامر البناء والاختبار مثل npm test، pytest، cargo test، و npm run build مسموحًا بها مع مهلات زمنية. يجب أن تتطلب الأوامر التدميرية أو ذات التأثير الخارجي مثل rm -rf، git push، gh pr merge، أدوات CLI للنشر، نشر الحزمة، ترحيل قاعدة البيانات، أو تحويل موارد السحابة موافقة صريحة أو تكون محظورة تمامًا.
ثانيًا، بث النتائج بهيكل. يجب أن يرى الوكيل والمراجع الأمر، دليل العمل، وقت البدء، رمز الخروج، stdout، stderr، حالة المهلة الزمنية، وسياسة الإخراج المقتطع. لقطة شاشة للطرفية ليست كافية؛ يجب على النظام الاحتفاظ بسجلات قابلة للقراءة آليًا.
ثالثًا، تعامل مع الجلسات الطويلة عن عمد. غالبًا ما يحتاج وكلاء البرمجة إلى خادم تطوير خلفي، مراقب، عملية أتمتة متصفح، أو مكدس اختبار تكامل. تعامل مع العمليات طويلة الأمد كموارد بمقابض: ابدأها، تدفق السجلات، فضح منفذ المعاينة المطلوب فقط، وأوقفها أثناء التنظيف. لا تدع عملية خلفية تصبح أثرًا جانبيًا غير متتبع لجلسة محادثة.
عزل المستودع والتحكم في الفرع لتغييرات الوكيل
حالة المستودع هي العمود الفقري لسير عمل وكيل برمجة قابل للمراجعة. لا يجب أن يعمل الوكيل في مجلد غامض مع تعديلات محلية غير معروفة ما لم يختر المستخدم هذا الوضع صراحة.
بالنسبة لسير عمل الفريق، ابدأ كل مهمة من عنوان URL معروف للمستودع، فرع أساسي، وSHA التزام. أنشئ فرع مهمة أو مساحة عمل منفصلة. حافظ على تغييرات المستخدم منفصلة عن تغييرات الوكيل، والتقط الفرق الدقيق قبل المراجعة. إذا كانت البيئة الآمنة تدعم الجلسات المستمرة، فاحتفظ بمساحة العمل عن قصد؛ لا تعتمد على حالة عملية عرضية.
النمط الافتراضي يبدو كالتالي:
1. إنشاء مساحة عمل معزولة للمهمة-123.
2. سحب المستودع عند main@<base_sha>.
3. إنشاء فرع agent/task-123.
4. تشغيل تثبيت التبعيات وفقًا للسياسة.
5. السماح للوكيل بفحص الملفات وتحريرها واختبارها والتكرار.
6. التقاط git diff، مخرجات الاختبار، القطع الأثرية المُنشأة، وعنوان URL للمعاينة.
7. فتح طلب سحب أو تسليم التصحيح إلى مراجع بشري.
8. هدم أو أرشفة مساحة العمل وفقًا لسياسة الاحتفاظ.
التفصيل الرئيسي هو الخطوة 6. وكيل البرمجة المفيد لا يقول فقط “لقد أصلحت الأمر.” يعيد الملفات التي تم تغييرها، سبب وجود كل تغيير، أي تحقق تم تشغيله، ما فشل، وما تبقى غير مؤكد.
سياسات الأوامر والحزم والشبكة لوكلاء البرمجة في البيئة الآمنة
تثبيت الحزم هو أحد أصعب أجزاء عزل وكيل البرمجة. العديد من المهام الحقيقية تحتاج إلى تبعيات. تبدأ العديد من حوادث سلسلة التوريد أيضًا بجلب التبعيات أو نصوص ما بعد التثبيت أو الثنائيات المعتمة.
السياسة العملية ليست “لا تقم أبدًا بتثبيت الحزم.” إنها “قم بتثبيت الحزم فقط من خلال مسارات معروفة، مع تسجيل ونطاق.”
| التحكم | التنفيذ العملي |
|---|---|
| مدراء الحزم | قرر أي مدراء الحزم متاحون حسب اللغة ونوع المستودع. |
| الوصول إلى السجل | السماح بسجلات معتمدة؛ منع مصادر الحزم التعسفية عندما لا تحتاجها المهمة. |
| ملفات القفل | تفضيل ملفات القفل الحالية وأوامر التثبيت القابلة للتكرار. |
| نصوص ما بعد التثبيت | قرر ما إذا كانت نصوص دورة الحياة يمكن تشغيلها تلقائيًا أو تتطلب موافقة. |
| حزم النظام | تعامل مع apt، brew، وتثبيت حزم نظام التشغيل على أنها عالية المخاطر أكثر من تثبيت تبعيات المشروع. |
| ذاكرات التخزين المؤقت | استخدم ذاكرات تخزين مؤقتة للحزم مُتحكم بها عندما تحتاج إلى السرعة وقابلية التكرار. |
| التسجيل | تخزين أسماء الحزم، الإصدارات، عناوين URL للسجل، المجاميع الاختبارية عندما تكون متاحة، ومخرجات التثبيت. |
يجب أن تكون سياسة الشبكة صريحة بالمثل. قد يحتاج وكيل البرمجة إلى قراءة الوثائق العامة، استدعاء واجهة API لبيئة اختبارية، تنزيل حزمة، أو فضح معاينة محلية. هذه مختلفة عن الوصول غير المقيد إلى الإنترنت. افصل جلب الحزم الخارجية، تصفح الويب، استدعاءات API، تسليم webhook، ووصول المعاينة الواردة. إذا كان منتجك يتعامل مع كود أو بيانات حساسة، اسأل عما إذا كانت DNS وسجلات الوكيل ومرايا السجل مشمولة بنفس سياسة حركة مرور HTTP.
الأسرار والسجلات ومسارات التدقيق لمساحات عمل الوكيل
يجب أن تكون الأسرار محددة النطاق لأصغر سطح مفيد. وكيل البرمجة لا يحتاج عادةً إلى بيانات اعتماد الإنتاج. قد يحتاج إلى رمز Git للقراءة فقط، رمز سجل حزم، مفتاح API لبيئة اختبارية، أو رمز نشر معاينة. يجب أن يكون كل منها محدود النطاق للمهمة، محدود الوقت حيثما أمكن، وغير متاح للأوامر التي لا تتطلبه.
تجنب وضع الأسرار في ملفات يمكن للوكيل قراءتها ما لم تتطلب المهمة ذلك حقًا. فضل الوصول الوسيط: يمكن للبيئة الآمنة تنفيذ عملية، لكن النموذج لا يرى بيانات الاعتماد الخام. عندما تكون متغيرات البيئة ضرورية، يجب على السجلات إخفاء أنماط الأسرار المعروفة، ولا يجب أن تتضمن القطع الأثرية للمراجع تفريغات كاملة للبيئة.
بالنسبة لمسارات التدقيق، قم بتخزين أكثر من التصحيح النهائي:
- طلب المستخدم وبيانات المهمة.
- عنوان URL للمستودع، الالتزام الأساسي، الفرع، والالتزام النهائي أو الفرق.
- الأوامر المطلوبة، المعتمدة، المحظورة، والمنفذة.
- مخرجات الأوامر، رموز الخروج، والمهل الزمنية.
- قراءة وكتابة الملفات عندما تستطيع المنصة التقاطها.
- سجلات جلب الشبكة والحزم على المستوى الذي تدعمه سياستك.
- عناوين URL للمعاينة ومسارات القطع الأثرية المُنشأة.
- الموافقات البشرية وقرارات الدمج.
هذه ليست بيروقراطية. إنها كيف يميز المراجع بين إصلاح حقيقي وقصة معقولة.
الفروق والمعاينات وبوابات المراجعة قبل الدمج
أكثر مخرجات مفيدة من وكيل البرمجة هي مجموعة تغييرات قابلة للمراجعة. هذا يعني أن البيئة الآمنة يجب أن تنتج نفس القطع الأثرية التي يتوقعها مهندس دقيق من طلب سحب:
- فرق مركز.
- اختبارات أو أوامر بناء تم تشغيلها.
- الإخفاقات المتبقية.
- لقطات شاشة، عناوين URL للمعاينة، أو ملفات قابلة للتنزيل عندما تغيرت واجهة المستخدم أو الأصول المُنشأة.
- شرح قصير لتغيير السلوك المقصود.
احتفظ بالدمج النهائي أو النشر خلف بوابة يتحكم فيها الإنسان ما لم تكن مؤسستك قد بنت سياسة أتمتة موثوقة منفصلة لهذا المستودع بالضبط ومستوى المخاطرة. المراجعة البشرية مهمة بشكل خاص عندما تمس التغييرات المصادقة، الفوترة، الوصول إلى البيانات، استدعاءات الشبكة، البنية التحتية، إصدارات التبعيات، الترحيلات المُنشأة، أو المحتوى المرئي للمستخدم.
معالجة المعاينة تستحق قاعدتها الخاصة: فضح فقط الخدمة والمنفذ المطلوبين للمراجعة. البيئة الآمنة التي تبدأ تطبيق ويب يجب أن تعطي المراجعين عنوان URL معاينة محدود النطاق، وليس وصولاً واسعًا للشبكة إلى مساحة العمل.
استراتيجية التنظيف وإعادة التعيين لجلسات الوكيل الطويلة
كل بيئة آمنة تحتاج إلى دورة حياة. بدونها، تصبح بنية وكيل البرمجة طويلة الأمد كومة من مساحات العمل القديمة والسجلات المسربة والعمليات التي لا تزال تعمل.
بالنسبة للمهام القصيرة، يعمل النموذج المؤقت بشكل جيد: أنشئ بيئة آمنة، قم بتشغيل المهمة، استخرج القطع الأثرية، ثم دمرها. بالنسبة للمهام الأكبر، يمكن أن تكون الاستمرارية قيمة: قد يحتاج الوكيل إلى التوقف مؤقتًا، انتظار المراجعة، الاستئناف من نفس الفرع، أو الحفاظ على خادم تطوير قيد التشغيل أثناء جلسة المراجعة. يجب أن تكون الاستمرارية ميزة منتج صريحة مع تاريخ انتهاء، مالك، وقواعد احتفاظ.
حدد التنظيف من أجل:
- العمليات الخلفية والمنافذ المفتوحة.
- الملفات المؤقتة ومخرجات البناء.
- ذاكرات التخزين المؤقت للحزم والأرشيفات التي تم تنزيلها.
- الأسرار المحددة للمهمة.
- السجلات والقطع الأثرية.
- الفروع أو أشجار العمل التي تم استبدالها.
إعادة التعيين مهمة بنفس القدر. يجب أن يكون المراجع قادرًا على إعادة تشغيل تحقق الوكيل من الالتزام الأساسي أو الفرع النهائي. إذا كانت النتيجة تعمل فقط بسبب حالة غير مرئية داخل جلسة طويلة الأمد، فمن الصعب الوثوق بسير العمل.
أين تتناسب بيئة Novita Agent Sandbox مع سير العمل هذا
Novita Agent Sandbox مصمم لبنية الوكيل حيث يحتاج تنفيذ الكود، أتمتة المتصفح، سير العمل من نمط استخدام الكمبيوتر، تحليل البيانات، التقييمات، وسير عمل الوكيل الأطول تشغيلًا إلى بيئة تشغيل معزولة. تصف وثائق Novita Agent Sandbox المنتج كبيئة ذات حالة لتشغيل أعباء عمل الوكيل، مع مسارات SDK و CLI للعمل مع دورة حياة البيئة الآمنة، الملفات، الأوامر، جلسات المتصفح، والبدائيات ذات الصلة بسير العمل.
بالنسبة للفرق التي تستخدم بالفعل واجهات برمجة تطبيقات نموذج Novita AI، يمكن لطبقة البيئة الآمنة تقليل الفجوة بين استدلال النموذج وتنفيذ الإجراء. يمكن للنموذج التفكير واستدعاء الأدوات وتخطيط تغييرات الكود؛ يمكن للبيئة الآمنة توفير مساحة العمل المعزولة حيث يتم تنفيذ تلك الإجراءات وتسجيلها ومعاينتها ومراجعتها.
استخدم حدود منتج محافظة عند تصميم سير العمل الخاص بك:
- تعامل مع Novita Agent Sandbox كبيئة تنفيذ، وليس ضمان أمان شامل.
- حافظ على الأسرار وتثبيت الحزم والخروج والإجراءات النشر خلف سياستك الخاصة.
- تحقق من SDK الحالي و CLI والتسعير وتفاصيل حد الحساب من وثائق Novita قبل ترميزها بشكل ثابت في أتمتة الإنتاج.
- قم بتقييم حدود العزل وتوافق الوكيل الخارجي ومتطلبات الامتثال مقابل سياستك الخاصة قبل الاعتماد على أي بيئة آمنة في الإنتاج.
يحافظ هذا الفصل على فائدة إرشادات التنفيذ حتى عندما تتغير طبقة الوكيل. يمكنك استخدام وكلاء من نمط Codex، وكلاء برمجة داخلية، وكلاء متصفح، أو عمال تقييم مع الحفاظ على نفس أسئلة التحكم في البيئة الآمنة.
قائمة فحص تنفيذ البيئة الآمنة لوكيل البرمجة
استخدم قائمة الفحص هذه قبل نقل بيئة آمنة لوكيل البرمجة إلى ما بعد النموذج الأولي.
| المجال | سؤال الإنتاج الأدنى |
|---|---|
| مساحة العمل | هل تحصل كل مهمة على نظام ملفات محدد النطاق والتزام قاعدة مستودع معروف؟ |
| التفرع | هل تغييرات الوكيل معزولة على فرع أو تصحيح يمكن للمراجعين فحصه؟ |
| الطرفية | هل الأوامر مسجلة مع دليل العمل والمخرجات ورمز الخروج والمهلة الزمنية؟ |
| الموافقة | أي الأوامر تعمل تلقائيًا، تتطلب موافقة، أو محظورة؟ |
| الحزم | هل تثبيت التبعيات قابل للتكرار ومسجل؟ |
| الشبكة | هل الخروج مقسم حسب جلب الحزم، تصفح الوثائق، استدعاءات API، ووصول المعاينة؟ |
| الأسرار | هل بيانات الاعتماد محددة النطاق للمهمة ومخفية من السجلات؟ |
| المعاينات | هل منافذ المعاينة صريحة وسهلة الإغلاق؟ |
| القطع الأثرية | هل الملفات المُنشأة ولقطات الشاشة والتقارير والسجقات مرفقة بالمراجعة؟ |
| الاستمرارية | هل إيقاف/استئناف الجلسة مقصود، مع مالك وتاريخ انتهاء؟ |
| التنظيف | هل تتم إزالة العمليات والمنافذ والملفات المؤقتة والأسرار ومساحات العمل القديمة؟ |
| المراجعة | هل يوافق الإنسان على الدمج أو النشر أو النشر للتغييرات الخطرة؟ |
إذا كان إعدادك الحالي لا يستطيع الإجابة على عدة من هذه الأسئلة، حافظ على سير العمل في مسار نموذج أولي. قد لا يزال الوكيل مفيدًا، لكن لا يجب أن يحصل على وصول واسع للمستودع أو الشبكة أو بيانات الاعتماد.
الأسئلة الشائعة
هل يمكنني تشغيل Codex نفسه داخل بيئة آمنة سحابية؟
من الناحية المفاهيمية، نعم: يمكن تشغيل وكيل برمجة طرفي داخل مساحة عمل معزولة إذا كانت البيئة تدعم نظام التشغيل ومسار المصادقة وإدخال/إخراج الطرفية والوصول إلى نظام الملفات والوصول إلى الشبكة التي يتطلبها الوكيل. لا تفترض وجود تكامل رسمي أو توافق كامل ما لم يوثق موفر البيئة الآمنة وموفر الوكيل ذلك لإعدادك المحدد.
هل Docker كافٍ لبيئة آمنة لوكيل البرمجة؟
يمكن أن يكون Docker مفيدًا للتطوير المحلي ووظائف CI والبيئات القابلة للتكرار، لكن “كافٍ” يعتمد على نموذج التهديد الخاص بك. اسأل ما الذي يشارك النواة، وما هي تركيبات الملفات الموجودة، وكيف يتم التحكم في خروج الشبكة، وما إذا كانت الأسرار مكشوفة للحاوية، وكيف سيتم التعامل مع عمليات الهروب أو اختراق التبعيات. بالنسبة لأعباء العمل الحساسة، غالبًا ما تقوم فرق الأمان بتقييم حدود عزل أقوى وضوابط خروج أكثر صرامة.
هل يجب أن يكون لوكيل البرمجة وصول إلى الإنترنت؟
فقط عندما تحتاج المهمة إلى ذلك، وفقط من خلال سياسة يمكنك شرحها. البحث في الوثائق، الوصول إلى سجل الحزم، استدعاءات واجهة API لبيئة اختبارية، والتصفح التعسفي هي أذونات مختلفة. سجل ما جلبه الوكيل، حافظ على تثبيت الحزم قابلاً للتكرار، وتجنب إعطاء وصول إلى شبكة الإنتاج لجلسة برمجة عامة.
ما الذي يجب أن ينظر إليه المراجع قبل دمج الكود المُنشأ من قبل الوكيل؟
راجع الفرق، الأوامر التي تم تشغيلها، مخرجات الاختبار/البناء، تغييرات التبعيات، القطع الأثرية المُنشأة، سلوك المعاينة، وأي تحقق تم تخطيه. انتبه بشكل إضافي للمصادقة، الأذونات، معالجة البيانات، استدعاءات الشبكة، الترحيلات، سكريبتات التثبيت، والأسرار.
كيف تساعد Novita في البيئات الآمنة لوكلاء البرمجة؟
توفر Novita Agent Sandbox بيئة تشغيل وكيل معزولة لأعباء العمل مثل تنفيذ الكود، أتمتة المتصفح، مهام من نمط استخدام الكمبيوتر، تحليل البيانات، التقييمات، وسير العمل الأطول. قم بإقرانها بسياسات صريحة للمستودع والأوامر والحزمة والشبكة والأسرار والمراجعة عند بناء سير عمل وكيل برمجة.
المقالات الموصى بها
