وكلاء البرمجة بالذكاء الاصطناعي: تشغيل عدة وكلاء بالتوازي

بيئة تطوير الوكلاء (ADE، اختصارًا لـ Agent Development Environment) مساحة عمل لتشغيل عدد من وكلاء البرمجة بالذكاء الاصطناعي في الوقت نفسه. يحصل كل وكيل على مهمته الخاصة ونسخة معزولة من الكود وحالة ظاهرة للعيان، بينما يتولى الإنسان تقسيم العمل ومتابعة التقدم ومراجعة كل تغيير قبل دمجه.

01أبرز النقاط

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

02ما وكلاء البرمجة بالذكاء الاصطناعي؟

وكيل البرمجة بالذكاء الاصطناعي أداة يقودها نموذج ذكاء اصطناعي، تستطيع قراءة المستودع (repository) وتعديل الملفات وتشغيل الأوامر والاختبارات لإنجاز مهمة موصوفة، بدلًا من الاكتفاء باقتراح الكود أثناء الكتابة. ومن أمثلتها وكلاء سطر الأوامر مثل Claude Code وCodex CLI وGemini CLI، وأوضاع الوكيل (agent mode) في محررات الكود، والوكلاء المستضافون الذين يعملون في بيئة معزولة (sandbox) على السحابة ثم يعيدون إليكم طلب دمج (pull request).

03ما هي بيئة تطوير الوكلاء (ADE)؟

بيئة التطوير المتكاملة (IDE) التقليدية مصممة حول شخص واحد يحرر نسخة عمل واحدة، وقد باتت محررات كثيرة تضيف ميزات الوكلاء الخاصة بها. لكن ما إن يعمل عدة وكلاء في آن واحد حتى يصبح التنسيق، لا التحرير، محور يومكم. ويصف هذا المصطلح، الذي يُكتب أحيانًا «بيئة التطوير الوكيلية» (agentic development environment)، المكان الذي تطوّرون فيه البرمجيات مستعينين بوكلاء البرمجة بالذكاء الاصطناعي، لا أدوات بناء وكلاء الذكاء الاصطناعي.

لا تحل بيئة تطوير الوكلاء محل محرركم ولا محل الوكلاء أنفسهم؛ إنها طبقة التنسيق (orchestration) التي تعلوهم، وتتولى العمل الذي يتضاعف مع كل وكيل جديد:

• عزل مساحات العمل: مجلد عمل وفرع منفصلان لكل وكيل، دون إدارة يدوية لـ git.
• تتبع المهام: وصف المهمة الذي أُعطي لكل وكيل، ظاهرًا أمامكم دائمًا.
• الحالة المباشرة: أي الوكلاء يعمل، وأيها ينتظر مدخلات، وأيها انتهى أو أخفق.
• واجهة المراجعة: فروق كل وكيل والأوامر التي نفّذها ونتائج اختباراته في مكان واحد.
• الدمج: مسار مضبوط يعيد فرع كل وكيل إلى الفرع الرئيسي.

04لماذا تشغّلون عدة وكلاء برمجة بالذكاء الاصطناعي بالتوازي؟

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

عمليًا، تغطي ثلاثة أنماط معظم العمل المتوازي:

• التوزيع (fan-out): عدة مهام مستقلة من قائمة العمل نفسها، لكل منها وكيل، وتُدمج كل واحدة على حدة.
• المحاولات المتنافسة: في المشكلات الملتبسة، تُسند المهمة نفسها إلى وكيلين، أو تُنفَّذ مرتين بتعليمات مختلفة، ثم تحتفظون بالنتيجة الأفضل.
• خط الإنتاج (pipeline): وكيل ينفّذ، وثانٍ يراجع النتيجة أو يكتب اختبارات لها، ويتخذ الإنسان القرار النهائي.

05ما الطرق المتاحة لتشغيل وكلاء البرمجة بالذكاء الاصطناعي بالتوازي؟

تعتمد معظم الفرق على واحد من أربعة إعدادات، ويجمع كثير منها بين أكثر من إعداد:

• علامات تبويب في الطرفية أو نوافذ tmux، لكل وكيل واحدة ومعها git worktree خاص به: لا أدوات جديدة، لكنكم تتابعون حالة كل وكيل بأنفسكم.
• ميزات تعدد الوكلاء المدمجة في المحرر: مريحة حين يعمل الفريق كله أصلًا في ذلك المحرر.
• وكلاء سحابيون أو وكلاء يعملون في الخلفية داخل بيئة معزولة مستضافة ثم يعيدون طلب دمج: لا شيء يعمل على أجهزتكم، وكل ما عليكم مراجعة طلب الدمج (PR).
• بيئة تطوير وكلاء مخصصة: الحالة والفروق والمراجعة لكل وكيل في مكان واحد.

06ما المهام التي تناسب وكلاء البرمجة المتوازيين؟

اختبروا كل مهمة مرشحة بأربعة أسئلة: هل هي مستقلة عن المهام الأخرى الجارية؟ هل يمكن وصفها في تكليف قصير؟ هل يمكن التحقق منها عبر الاختبارات أو فحص الأنواع (type check) أو البناء (build) أو معيار قبول واضح؟ هل تمس جزءًا مختلفًا من قاعدة الكود؟

مهام مناسبة

• إضافة اختبارات لوحدات تفتقر إلى التغطية.
• إصلاح أخطاء قائمة بذاتها مع خطوات واضحة لإعادة إنتاجها.
• ميزات معزولة خلف واجهة محددة جيدًا، مثل نقطة نهاية (endpoint) جديدة في واجهة برمجة التطبيقات أو مكوّن جديد في واجهة المستخدم.
• عمليات ترحيل (migration) آلية تنقسم بوضوح حسب المجلد أو الحزمة.
• التوثيق وتحسينات الأنواع (typing) وإصلاحات أدوات الفحص (lint) في أجزاء لا يعدّلها أحد آخر.

مهام غير مناسبة

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

07كيف تشغّلون عدة وكلاء برمجة بالذكاء الاصطناعي؟ خطوة بخطوة

1. 1قسّموا العمل إلى مهام مستقلة.
2. 2اعزلوا كل وكيل في git worktree وفرع خاصين به.
3. 3اكتبوا وصف مهمة يستطيع كل وكيل تنفيذه.
4. 4راقبوا، وأزيلوا العوائق، وتدخّلوا عند الحاجة.
5. 5راجعوا الفروع وادمجوها واحدًا تلو الآخر.

الخطوة 1: قسّموا العمل إلى مهام مستقلة

ابدؤوا من النتيجة المطلوبة، لا من الوكلاء. جزّئوا الهدف إلى مهام يمكن إنجاز كل منها والتحقق منها ودمجها على حدة. وإذا كانت مهمتان ستعدّلان الملفات نفسها، فاجمعوهما في مهمة واحدة أو شغّلوهما بالتتابع. وملاحظة قصيرة عن الاعتماديات، مثل «تحتاج إلى المخطط الجديد من المهمة 2»، تجنّبكم معظم مفاجآت الدمج.

الخطوة 2: اعزلوا كل وكيل باستخدام git worktree

وكيلان في مجلد العمل نفسه قد يكتب أحدهما فوق تغييرات الآخر، ويُربك كلٌّ منهما تشغيل اختبارات الآخر. وأبسط طريقة موثوقة للعزل هي git worktree: مجلد عمل إضافي مرتبط بالمستودع نفسه، وعلى فرع خاص به.

# One worktree and one branch per agent
git worktree add -b agent/auth-refactor ../app-agent-auth
git worktree add -b agent/billing-tests ../app-agent-tests

# See what is checked out where
git worktree list

# Clean up once the branch has been merged locally (use -D after a squash merge)
git worktree remove ../app-agent-auth
git branch -d agent/auth-refactor

افتراضيًا، لا يسمح git بسحب (check out) الفرع نفسه في مجلدي عمل في آن واحد، وهذه بالضبط الحماية التي تريدونها. وعند التنظيف، يرفض الأمر git worktree remove حذف مجلد عمل يحتوي على ملفات معدّلة أو غير متتبَّعة؛ فاعتمدوها (commit) أو تخلّصوا منها أولًا، أو أضيفوا --force حين تكونون متأكدين. غير أن مجلدات العمل تعزل الملفات، لا كل شيء. لذا خطّطوا لما تتشاركه:

• التبعيات ومخرجات البناء: يحتاج كل worktree عادةً إلى حزمه المثبتة الخاصة (node_modules أو البيئات الافتراضية) ومخرجات بناء خاصة به.
• المنافذ (ports): لا يمكن لخادمي تطوير أن يستخدما المنفذ نفسه، لذا خصّصوا منفذًا لكل وكيل.
• قواعد البيانات: استخدموا قواعد بيانات أو مخططات محلية منفصلة، ولا تستخدموا أبدًا بيئة staging المشتركة.
• ملفات البيئة: انسخوا فقط الإعدادات غير السرية التي يحتاجها كل وكيل.

الخطوة 3: اكتبوا وصف مهمة يستطيع كل وكيل تنفيذه

يملأ الوكلاء كل فجوة في وصف المهمة بافتراضاتهم الخاصة. والوصف الجيد قصير لكنه مكتمل:

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

أما التعليمات الدائمة للمشروع، في ملف يقرؤه الوكيل عند بدء التشغيل مثل AGENTS.md أو CLAUDE.md بحسب الوكيل، فتغنيكم عن تكرار أعراف المشروع في كل وصف مهمة.

الخطوة 4: راقبوا، وأزيلوا العوائق، وتدخّلوا

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

الخطوة 5: راجعوا الفروع وادمجوها واحدًا تلو الآخر

ادمجوا الفروع وفق ترتيب الاعتماديات، فرعًا واحدًا في كل مرة. وبعد كل دمج، نفّذوا rebase للفروع المتبقية على الفرع الرئيسي المحدَّث وأعيدوا تشغيل فحوصها. والتعارضات في هذه المرحلة معلومة مفيدة: فهي تكشف مهام كانت أقل استقلالًا مما بدت عليه.

08كيف تمنعون التعارضات بين وكلاء الذكاء الاصطناعي؟

تنشأ معظم التعارضات بين الوكلاء المتوازيين من عدد قليل من النقاط الساخنة المشتركة:

• ملفات القفل (lockfiles) وملفات التبعيات: اسمحوا لوكيل واحد فقط في كل جولة بإضافة التبعيات أو ترقيتها.
• ترحيلات قاعدة البيانات: شغّلوها بالتتابع، لأن الترحيلات المولَّدة بالتوازي قد تتصادم في ترتيبها أو في حالة المخطط.
• السجلات المشتركة مثل ملفات التوجيه والإعدادات: اجعلوا لكل ملف مالكًا واحدًا، أو أجروا التغيير بأنفسكم أولًا.
• الكود المولَّد آليًا: أعيدوا توليده بعد الدمج بدلًا من دمج ملفات مولَّدة من عدة فروع.
• تغييرات التنسيق غير الضرورية: اطلبوا من الوكلاء ألا يعيدوا تنسيق ملفات لم يغيّروها لسبب آخر.

والنصف الآخر من الحل هو الفروع قصيرة العمر: فالمهام الصغيرة التي تُدمج خلال ساعات تتعارض أقل بكثير من فروع تبتعد عن الفرع الرئيسي أيامًا.

09كيف تراقبون ما يفعله كل وكيل برمجة بالذكاء الاصطناعي؟

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

• على ماذا يعمل، وما وصف المهمة الذي أُعطي له؟
• ما حالته: يعمل، أم ينتظر مدخلات أو إذنًا، أم متوقف بسبب خطأ، أم انتهى؟
• ما الذي غيّره حتى الآن، في صورة فروق مقارنةً بفرعه الأساسي؟
• ما الأوامر التي نفّذها، وهل نجحت الاختبارات والفحوص؟
• منذ متى يعمل، وكم استهلك من حصة الاستخدام؟

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

10ما تكلفة تشغيل عدة وكلاء برمجة بالذكاء الاصطناعي؟

للتكلفة شقّان: استخدام النموذج ووقت البشر. يزداد استخدام النموذج بزيادة عدد الوكلاء وطول جلساتهم وحجم السياق الذي يقرؤونه. وسواء كنتم تدفعون مقابل كل رمز (token) أو تعملون ضمن حدود اشتراك، فإن الوكلاء المتوازيين يستهلكون تلك الميزانية أسرع، والمحاولات المتنافسة تنفقها عمدًا على عمل ستتخلصون منه.

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

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

11لماذا تظل المراجعة البشرية للكود المولَّد بالذكاء الاصطناعي ضرورية؟

وكلاء البرمجة بالذكاء الاصطناعي أكفاء، لكنهم لا يتحملون المسؤولية. فقد يسيئون فهم أحد المتطلبات، أو يكتبون اختبارات تؤكد السلوك الخطأ، أو يُسكتون خطأً بدلًا من إصلاحه، أو يُبلغون بأن فحصًا ما نجح وهو لم يُشغَّل أصلًا. والكود الذي يكتبه البشر يُراجَع للأسباب نفسها؛ كل ما في الأمر أن الوكلاء المتوازيين ينتجون تغييرات أكثر وبسرعة أكبر.

تتكون حلقة المراجعة العملية من ثلاث طبقات: يتحقق الوكيل من عمله بنفسه مقابل تعريف الاكتمال؛ ثم، اختياريًا، يراجع وكيل ثانٍ الفروق بسياق جديد؛ ثم يقرأ إنسان الفروق ويقرر ما إذا كان سيدمجها. الطبقات الآلية تقلل الضجيج، لكنها لا تحل محل هذا القرار.

قائمة مراجعة للتغييرات التي يكتبها الوكلاء

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

12أخطاء شائعة عند تشغيل عدة وكلاء ذكاء اصطناعي

• تشغيل وكيلين في مجلد العمل نفسه وخسارة العمل بسبب ملفات كُتب فوقها.
• ترك فروع الوكلاء مفتوحة أيامًا حتى يتعذر دمجها بسلاسة.
• منح الوكلاء بيانات اعتماد بيئة الإنتاج أو أذونات لا يحتاجونها.
• عدّ الوكلاء الذين يعملون بدلًا من عدّ التغييرات التي دُمجت وتعمل فعلًا.

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

ما الفرق بين بيئة التطوير المتكاملة (IDE) وبيئة تطوير الوكلاء؟

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

كم وكيلًا للبرمجة بالذكاء الاصطناعي أشغّل في الوقت نفسه؟

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

هل أحتاج إلى git worktree لتشغيل الوكلاء بالتوازي؟

تحتاجون إلى شكل من أشكال العزل، وgit worktree أخف الخيارات: يحصل كل وكيل على مجلده وفرعه الخاصين داخل مستودع مشترك واحد. أما النسخ المستقلة من المستودع (clones) أو الحاويات (containers) فتوفر عزلًا أقوى، لكنها تستهلك مساحة تخزين أكبر وتتطلب إعدادًا أكثر. والبيئات المعزولة المستضافة التي تعيد طلب دمج تنقل العزل خارج أجهزتكم، لكنها لا تُعفيكم من المراجعة. ولا تسمحوا أبدًا لوكيلين بتعديل مجلد العمل نفسه في آن واحد.

هل يمكن لوكلاء البرمجة بالذكاء الاصطناعي مراجعة كود بعضهم بعضًا؟

نعم، وهي طبقة إضافية مفيدة. فالوكيل الثاني الذي يُعطى وصف مهمة المراجِع وسياقًا جديدًا كثيرًا ما يلتقط اختبارات ناقصة وحالات حدّية لم تُعالَج وتضخمًا في النطاق. لكن لا ينبغي أن يكون البوابة الأخيرة: فقد يشترك الوكلاء في النقاط العمياء نفسها، لذا يجب أن يقرأ إنسانٌ الفروق ويقرر الدمج في كل ما يصل إلى بيئة الإنتاج.

هل من الآمن السماح لوكلاء البرمجة بالذكاء الاصطناعي بتشغيل أوامر على جهازي؟

قد يكون كذلك، مع وجود ضوابط. امنحوا الوكلاء أقل الصلاحيات التي يحتاجونها، وأبقوا بيانات اعتماد الإنتاج خارج بيئتهم، واشترطوا الموافقة على الأوامر المدمِّرة أو التي تتصل بالشبكة. وتعاملوا مع كل ما يقرؤه الوكيل من خارج قاعدة الكود، مثل البلاغات (issues) وصفحات الويب وملفات الأطراف الثالثة، على أنه غير موثوق، لأنه قد يحتوي على تعليمات مصممة لتضليل الوكيل، وهو خطر يُعرف بحقن الأوامر (prompt injection). وتضيف الحاويات طبقة حماية إضافية.

14نهج Neptay في تطوير الوكلاء

نصمّم وكلاء الذكاء الاصطناعي وحلول الأتمتة ضمن خدماتنا للعملاء، ونبني منتجاتنا التقنية الخاصة تحت علامة Anlato. وAnlato Space، المنتج الرئيسي في عائلة Anlato، هي بيئة تطوير الوكلاء الخاصة بنا: عدد كبير من وكلاء البرمجة بالذكاء الاصطناعي جنبًا إلى جنب في نافذة أصلية (native) واحدة، لكل منها مهمته وحالته، وكل تغيير ينتظر مراجعتكم. وهي قادمة قريبًا. وإذا كنتم تصممون سير عمل للوكلاء لفريقكم، أو تريدون متابعة Anlato Space، فراسلونا على hello@neptay.com.