تشغيل متعدد وكلاء البرمجة بالذكاء الاصطناعي بالتوازي باستخدام Container-Use من Dagger
تُعدّ وكلاء البرمجة القائمة على الذكاء الاصطناعي من المساعدين الأساسيين في تطوير البرمجيات. فهذه الأدوات الذاتية أو شبه الذاتية قادرة على كتابة، واختبار، وإعادة هيكلة التعليمات البرمجية، مما يُسرّع بشكل كبير من دورة التطوير. ومع ذلك، مع زيادة عدد الوكلاء العاملين على قاعدة بيانات برمجية واحدة، تزداد التحديات أيضًا، مثل: تعارضات التبعيات، وتسرب الحالة بين الوكلاء، وصعوبة تتبع إجراءات كل وكيل. يُعالج مشروع Container-Use من Dagger هذه التحديات من خلال توفير بيئات مُحَوَّاة (Containerized) مُصممة خصيصًا لوكلاء البرمجة.
عزل البيئات وتشغيل متعدد الوكلاء
من خلال عزل كل وكيل في حاوياته الخاصة، يمكن للمطورين تشغيل عدة وكلاء في وقت واحد دون أي تداخل، ومراقبة أنشطتهم في الوقت الفعلي، والتدخل مباشرةً عند الضرورة. تقليديًا، عندما يُنفذ وكيل برمجة مهام مثل تثبيت التبعيات، أو تشغيل نصوص البناء، أو تشغيل الخوادم، فإنه يفعل ذلك ضمن بيئة المطور المحلية. يؤدي هذا النهج بسرعة إلى حدوث تعارضات: فقد يقوم وكيل واحد بترقية مكتبة مُشتركة تُسبب تعطيل سير عمل وكيل آخر، أو قد يُخلّف نص خاطئ آثارًا تُعيق عمليات التشغيل اللاحقة. تحل الحاويات هذه المشاكل بشكل أنيق من خلال تغليف بيئة كل وكيل. بدلاً من رعاية الوكلاء واحداً تلو الآخر، يمكنك إنشاء بيئات جديدة تمامًا، والتجربة بأمان، والتخلص من حالات الفشل على الفور، مع الحفاظ على الرؤية لما قام كل وكيل بتنفيذه.
التكامل مع أدوات العمل الحالية
علاوة على ذلك، نظرًا لإمكانية إدارة الحاويات من خلال أدوات مألوفة مثل Docker و Git وأدوات سطر الأوامر القياسية، فإن Container-Use يتكامل بسلاسة مع سير العمل الحالي. بدلاً من الاعتماد على حلول خاصة، يمكن للفرق الاستفادة من مجموعة أدواتهم المفضلة، سواء كانت بيئات افتراضية Python أو سلاسل أدوات Node.js أو حزم مستوى النظام. النتيجة هي بنية مرنة تُمكّن المطورين من الاستفادة من الإمكانات الكاملة لوكلاء البرمجة، دون التضحية بالتحكم أو الشفافية.
التثبيت والإعداد
يُعدّ البدء باستخدام Container-Use أمرًا بسيطًا. يُوفر المشروع أداة سطر أوامر قائمة على Go، “cu”، والتي يمكنك بناؤها وتثبيتها عبر أمر “make” بسيط. بشكل افتراضي، تستهدف عملية البناء النظام الأساسي الحالي، ولكن يُدعم التجميع المتقاطع من خلال متغيرات بيئة “TARGETPLATFORM” القياسية.
# بناء أداة سطر الأوامر
make
# (اختياري) التثبيت في PATH
make install && hash -rبعد تشغيل هذه الأوامر، تصبح الملف التنفيذي “cu” متاحًا في محيطك، وجاهزًا لبدء جلسات محتوية لأي وكيل متوافق مع MCP. إذا كنت بحاجة إلى التجميع لنظام أساسي مختلف، مثل ARM64 لجهاز Raspberry Pi، فقم ببساطة بإضافة النظام الأساسي الهدف قبل عملية البناء:
TARGETPLATFORM=linux/arm64 makeتضمن هذه المرونة أنه سواء كنت تقوم بالتطوير على macOS، أو نظام Windows الفرعي لنظام Linux، أو أي نوع من أنظمة Linux، يمكنك إنشاء ملف ثنائي محدد للبيئة بسهولة.
التكامل مع وكلائك المفضلين
تتمثل إحدى نقاط قوة Container-Use في توافقه مع أي وكيل يتحدث بروتوكول سياق النموذج (MCP). يُوفر المشروع تكاملات نموذجية لأدوات شائعة مثل Claude Code و Cursor و GitHub Copilot و Goose. يتضمن التكامل عادةً إضافة “Container-Use” كخادم MCP في تكوين وكيلك وتمكينه:
- Claude Code: يستخدم مساعد NPM لتسجيل الخادم. يمكنك دمج تعليمات Dagger المُوصى بها في ملف “CLAUDE.md” الخاص بك بحيث يُنشئ تشغيل “claude” تلقائيًا وكلاء في حاويات معزولة.
npx @anthropic-ai/claude-code mcp add container-use -- $(which cu) stdio
curl -o CLAUDE.md https://raw.githubusercontent.com/dagger/container-use/main/rules/agent.md- Goose: يقرأ إطار عمل الوكيل المستند إلى المتصفح من “~/.config/goose/config.yaml”. يُوجّه إضافة قسم “Container-Use” هناك Goose إلى تشغيل كل وكيل تصفح داخل حاوياته الخاصة.
extensions:
container-use:
name: container-use
type: stdio
enabled: true
cmd: cu
args:
- stdio
envs: {}-
Cursor: يمكن توصيل مساعد ترميز الذكاء الاصطناعي عن طريق إسقاط ملف القواعد في مشروعك. باستخدام “curl”، يمكنك جلب القاعدة المُوصى بها ووضعها في “.cursor/rules/container-use.mdc”. يمكن لمستخدمي VSCode و GitHub Copilot تحديث “settings.json” و “.github/copilot-instructions.md” على التوالي، مشيرين إلى أمر “cu” كخادم MCP. ثم يُنفذ Copilot عمليات إكمال التعليمات البرمجية الخاصة به داخل البيئة المُغلّفة.
-
Kilo Code: يتكامل من خلال ملف إعدادات قائم على JSON، مما يسمح لك بتحديد أمر “cu” وأي وسيطات مطلوبة ضمن “mcpServers”.
يضمن كل من هذه التكاملات، بغض النظر عن المساعد الذي تختاره، أن تعمل وكلائك في بيئاتها الرملية، وبالتالي إزالة خطر التلوث المتبادل وتبسيط التنظيف بعد كل تشغيل.
أمثلة عملية
لتوضيح كيف يمكن لـ Container-Use أن يُحدث ثورة في سير عمل التطوير لديك، يتضمن مستودع Dagger العديد من الأمثلة الجاهزة للتشغيل. تُوضح هذه الأمثلة حالات الاستخدام النموذجية وتُبرز مرونة الأداة:
-
Hello World: في هذا المثال البسيط، يُنشئ وكيل خادم HTTP بسيط، مثل استخدام Flask أو وحدة “http” الخاصة بـ Node، ويُشغله داخل حاوياته. يمكنك الضغط على “localhost” في متصفحك للتأكد من أن التعليمات البرمجية التي تم إنشاؤها بواسطة الوكيل تعمل كما هو متوقع، معزولة تمامًا عن نظامك المضيف.
-
التطوير المتوازي: هنا، يُنشئ وكيلان متغيرين مختلفين لنفس التطبيق، أحدهما يستخدم Flask والآخر يستخدم FastAPI، كل منهما في حاوياته الخاصة وعلى منافذ منفصلة. يُوضح هذا السيناريو كيفية تقييم نهجين متجاورين دون القلق بشأن تصادمات المنافذ أو تعارضات التبعيات.
-
فحص الأمان: في هذا المسار، يُجري وكيل صيانة روتينية، ويُحدّث التبعيات الضعيفة، ويعيد تشغيل عملية البناء للتأكد من عدم حدوث أي أعطال، ويُنشئ ملف تصحيح يُغطي جميع التغييرات. تتطور العملية بأكملها داخل حاوية مؤقتة، تاركة مستودعك في حالته الأصلية ما لم تقرر دمج التصحيحات.
تشغيل هذه الأمثلة بسيط مثل تمرير ملف المثال إلى أمر الوكيل. على سبيل المثال، مع Claude Code:
cat examples/hello_world.md | claudeأو مع Goose:
goose run -i examples/hello_world.md -sبعد التنفيذ، سترى كل وكيل يُلتزم بعمله في فرع git مخصص يُمثّل حاوياته. يسمح لك فحص هذه الفروع عبر “git checkout” بمراجعة التغييرات أو اختبارها أو دمجها حسب شروطك.
مراقبة وتسجيل الأحداث
يُعدّ أحد المخاوف الشائعة عند تفويض المهام إلى الوكلاء معرفة ما فعلوه، وليس فقط ما يدّعونه. يُعالج Container-Use هذا من خلال واجهة تسجيل موحّدة. عندما تبدأ جلسة، تُسجّل الأداة كل أمر، وإخراج، وتغيير ملف في محفوظات “.git” لمشروعك ضمن وحدة تحكم خاصة تسمى “Container-Use”. يمكنك متابعة عملية تشغيل الحاوية، وتشغيل الوكيل للأوامر، وتطور البيئة. إذا واجه وكيل خطأً أو خرج عن المسار، فلا داعي لمشاهدة السجلات في نافذة منفصلة. يُتيح لك أمر بسيط عرضًا تفاعليًا:
cu watchيُظهر لك هذا العرض المباشر فرع الحاوية النشط، والمخرجات الأخيرة، وحتى يُتيح لك إمكانية الدخول إلى محيط عمل الوكيل. من هناك، يمكنك تصحيح الأخطاء يدويًا: فحص متغيرات البيئة، وتشغيل أوامرك الخاصة، أو تحرير الملفات أثناء التنفيذ. تضمن هذه القدرة على التدخل المباشر أن يظل الوكلاء متعاونين بدلاً من أن يكونوا صناديق سوداء غير مفهومة.
تخصيص حاويات Docker
بينما تُغطي صور الحاويات الافتراضية التي يوفرها Container-Use العديد من حالات استخدام node و Python ومستوى النظام، فقد تكون لديك احتياجات خاصة، مثل مُجمّعات مخصصة أو مكتبات خاصة. لحسن الحظ، يمكنك التحكم في ملف Dockerfile الذي يُشكل أساس كل حاوية. من خلال وضع “Containerfile” (أو “Dockerfile”) في جذر مشروعك، ستقوم واجهة سطر الأوامر “cu” ببناء صورة مُخصصة قبل تشغيل الوكيل. يُمكنك هذا النهج من تثبيت حزم مستوى النظام مسبقًا، واستنساخ المستودعات الخاصة، أو تكوين سلاسل أدوات معقدة، وكل ذلك دون التأثير على بيئة المضيف الخاصة بك.
قد يبدأ ملف Dockerfile مُخصص نموذجي من قاعدة رسمية، ويضيف حزمًا على مستوى نظام التشغيل، ويُعيّن متغيرات بيئة، ويُثبت تبعيات محددة للغة:
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y git build-essential
WORKDIR /workspace
COPY requirements.txt .
RUN pip install -r requirements.txtبمجرد تعريف حاويتك، سيعمل أي وكيل تقوم باستدعائه ضمن هذا السياق افتراضيًا، ويرث جميع الأدوات والمكتبات المُعدّة مسبقًا التي تحتاجها.
الخلاصة
في الختام، مع قيام وكلاء الذكاء الاصطناعي بمهام تطوير أكثر تعقيدًا، تزداد الحاجة إلى العزل والشفافية القوية بالتوازي. يُقدم Container-Use من Dagger حلاً عمليًا: بيئات مُحَوَّاة تضمن الموثوقية، وإمكانية التكرار، والرؤية في الوقت الفعلي. من خلال الاعتماد على الأدوات القياسية، بما في ذلك Docker و Git ونصوص shell، وتقديم تكاملات سلسة مع وكلاء MCP الشائعة، فإنه يُقلل من حاجز الوصول إلى سير عمل متعدد الوكلاء آمن وقابل للتطوير.
اترك تعليقاً