بيئات تشغيل وكلاء AI: السحابة MicroVMs مقابل المحلي

عند منح وكيل ذكاء اصطناعي (AI Agent) صلاحية تنفيذ أوامر الطرفية (Shell)، أو ترجمة الكود، أو تشغيل اختبارات الوحدات تلقائياً، يواجه مهندسو البنية التحتية سؤالاً مباشراً: أين يجب أن يُنفَّذ هذا الكود فعلياً؟

في بيئات الإنتاج الحالية، ينقسم التصميم المعماري لبيئات التشغيل (Execution Harnesses) إلى مسارين رئيسيين:

• 1. البيئات السحابية المعزولة (Cloud MicroVM Sandboxes): مثل E2B وModal المبنية فوق محرك AWS Firecracker، حيث تُنفَّذ كل مهمة داخل آلة افتراضية مصغرة مستقلة بنواتها الخاصة، وتُدمَّر فور انتهاء التنفيذ.
• 2. بيئات التشغيل المحلية (Local Workstation Harnesses): مثل Claude Code المقترنة بـ Git Worktrees وأدوات العزل على مستوى نظام التشغيل (bubblewrap وLandlock على لينكس)، حيث يعمل الوكيل مباشرة على أقراص NVMe المحلية للوصول الفوري إلى المستودعات البرمجية الضخمة.

تزداد حساسية هذا القرار عند ربط الوكيل بواجهات المراسلة الفورية مثل تيليجرام (Telegram) أو تطبيقات الدردشة؛ إذ إن ربط بيئة تشغيل محلية غير محصنة ببوت محادثة يحوّل جهاز المطور الشخصي إلى هدف مباشر لتنفيذ الأوامر عن بُعد (RCE) عبر هجمات حقن التعليمات غير المباشرة (Indirect Prompt Injection).

1. المقارنة المعمارية: احتواء المخاطر مقابل سرعة الإدخال والإخراج (I/O)

• العزل والأمان (Blast Radius Containment): تتفوق البيئات السحابية بفضل العزل العتادي عبر KVM؛ فإذا تعرض الوكيل لخداع عبر نص خارجي وحاول قراءة مفاتيح ~/.ssh أو تنفيذ أمر تدميري، فإنه يصطدم بآلة افتراضية مؤقتة معزولة تماماً عن جهاز المطور وشبكته المحلية.
• سرعة التطوير المحلية (Local I/O Velocity): تتفوق البيئات المحلية في سرعة القراءة المباشرة من القرص (تصل إلى 4,800 ميجابايت/ثانية على أقراص NVMe مقارنة بـ 55–120 ميجابايت/ثانية عبر الشبكة)، مع إمكانية إنشاء فرع عمل معزول عبر أمر git worktree add خلال 42 مللي ثانية فقط دون الحاجة لرفع جيجابايتات من الكود إلى السحابة.

2. إشكالية بوتات المراسلة: تيليجرام مقابل الأنظمة المحلية

تختلف تطبيقات المراسلة في بنيتها التحتية وطريقة تخزينها للبيانات، وهو ما يفرض نمط تشغيل مختلفاً لكل منها:

1. النموذج السحابي (مثل Telegram): يعتمد بروتوكول MTProto على مزامنة سحابية مركزية وواجهات Bot API مفتوحة، وغالباً ما يعمل البوت داخل مجموعات عامة غير موثوقة. لذلك فإن الربط الآمن يتطلب بيئة سحابية معزولة 100% (Cloud MicroVM) مع سياسة حظر افتراضي للاتصالات الصادرة (Default-Deny Egress Filter) عبر eBPF لمنع تسريب أي بيانات.
2. النموذج المحلي الخصوصي (مثل WeChat الشخصي): تُخزَّن المحادثات والملفات محلياً في قواعد بيانات SQLite مشفرة على جهاز المستخدم. هنا يناسبها النمط الهجين المحلي أولاً (Local-First Hybrid)، حيث تُعالَج الملفات الحساسة محلياً داخل مسار عمل مقيد، بينما تُرسَل المهام الحسابية الثقيلة أو جلب الروابط الخارجية إلى حاوية سحابية مؤقتة لا تحتوي على أي بيانات شخصية.

3. التصميم الهجين الموصى به (Secure Hybrid IM Gateway)

لجمع مزايا السرعة المحلية مع الأمان السحابي عند التحكم بالوكيل عبر الهاتف، يعتمد المهندسون بنية البوابة الهجينة المكونة من ثلاث طبقات:

1. بوابة فحص وتصنيف مبدئية (Cloud Triage Gateway): تستقبل رسائل الـ Webhook، وتفحص هوية المرسل ونوع القناة؛ فإذا كانت الرسالة قادمة من مجموعة عامة، تُحوَّل إجبارياً إلى آلة Firecracker سحابية مؤقتة.
2. نفق شبكي مشفر (WireGuard / Tailscale Mesh): يتصل بجهاز العمل المحلي دون فتح أي منافذ عامة (Inbound Ports) على الراوتر.
3. بوابة موافقة تفاعلية (HMAC Inline Approval Gate): عند طلب تنفيذ أمر حساس محلياً، يرسل البوت زر موافقة تفاعلياً موقعاً رقمياً بـ HMAC إلى هاتف المطور مع صلاحية زمنية قصيرة (TTL 5 دقائق) قبل السماح بالتنفيذ داخل Git Worktree محلي.

4. المراجع والأكواد المصدرية

للاطلاع على الكود المصدري الكامل بلغة بايثون لتطبيق البوابة الهجينة (SecureHybridIMGateway)، وجداول القياس المرجعية (Benchmarks) على اختبارات SWE-bench وBIPIA، يمكنكم مراجعة المقالة التفصيلية باللغة العربية على:

🔗 مقارنة بيئات تشغيل وكلاء الذكاء الاصطناعي السحابية والمحلية — AgDex.ai

أدوات ومشاريع ذات صلة تمت تجربتها في هذا التحليل:

• E2B Sandbox: لتشغيل جلسات الكود داخل آلات Firecracker المصغرة.
• Modal: لتشغيل الحاويات المعزولة عبر gVisor وتوسيع المهام المتوازية.
• Claude Code: وكيل البرمجة الطرفي للعمل المباشر على المستودعات المحلية.
• OpenHands: إطار العمل مفتوح المصدر الذي يدعم التبديل بين العزل المحلي والسحابي.

كلمات دليلية: أمن_سيبراني برمجة ذكاء_اصطناعي