أطلقت هذا الصباح ثلاثة وكلاء برمجة (coding agents). أحدهم يعيد هيكلة وحدة المصادقة، والآخر يكتب اختبارات، والثالث يتعقب مشكلة عشوائية في مهام التكامل المستمر (flaky CI job). بعد ساعة، تجد أمامك خمس نوافذ طرفية مفتوحة، وجلستي tmux منفصلتين، وشعوراً ملحاً بأن أحدهم على الأقل قد توقف منذ فترة وظل خاملاً دون أن تنتبه. تبدّل بين النوافذ عبر Alt-Tab، وتمرر عبر السجلات، وتخمّن ما يجري.
هذا التخمين هو التكلفة الحقيقية لتشغيل عدة وكلاء بالتوازي. فإطلاق عدة وكلاء برمجة في الوقت نفسه بات أمراً سهلاً اليوم، لكن معرفة أي منهم يحتاج تدخلك، وأيهم عالق، وأيهم أنهى مهمته في صمت، هو ما يبتلع ساعات يومك. تعني مراقبة وكلاء البرمجة المتوازيين الإجابة عن أربعة أسئلة فورية دون فتح خمس نوافذ: ماذا يفعل كل وكيل الآن؟ إلى أي مرحلة وصل؟ ما الذي يعيقه؟ وما المخرجات التي تحتاج إلى مراجعة؟
يستعرض هذا الدليل أولاً إعدادات المراقبة اليدوية (DIY)، ويحدد نقاط الفشل المحتملة في كل خطوة، ثم يوضح أين تتوقف هذه الطريقة عن التوسع وما تضيفه طبقة المهام المشتركة. هذه الطبقة المشتركة هي Sharkly: فإذا كنت تستخدم بالفعل وكلاء برمجة، فإن Sharkly يحولهم إلى فريق متكامل عبر إبقاء تقدم كل وكيل، وعوائقه، ونتائجه مرئية في مكان واحد بدلاً من تشتتها عبر الطرفيات. يمكنك بناء معظم آليات المراقبة بنفسك، والهدف من استعراض كلا النهجين هو معرفة متى يبدأ الحل اليدوي في استنزاف وقت وجهد يفوق ما يوفره.
الإشارات الأربع التي تستحق المراقبة
المراقبة ليست مفهوماً واحداً بسيطاً؛ فعندما يقول المطورون إن تشغيل الوكيل "يبدو على ما يرام"، فهم يقصدون عادةً واحدة من أربع إشارات منفصلة، ولكل منها نمط فشل مختلف.
- الحالة (State): هل العملية قيد التشغيل، أم تنتظر مدخلات، أم اكتملت، أم توقفت نهائياً؟ الوكيل الذي أنهى عمله والوكيل العالق كلاهما لا ينتج أي مخرجات جديدة، وبالتالي فإن الصمت وحده لا يكشف لك أي شيء.
- التقدم (Progress): ما هو القدر المنجز من المهمة؟ بنود خطة تم شطبها، ملفات تم تعديلها، واختبارات اجتازت بنجاح. التقدم هو المؤشر الذي يخبرك بأن الوكيل قيد التشغيل يتقدم فعلياً ولا يدور في حلقة مفرغة.
- العوائق (Blockers): ما الذي ينتظره الوكيل؟ طلب إذن صلاحية، متغير بيئة مفقود، تعارض في الدمج (merge conflict)، أو سؤال طرحه ولم يُجب عليه أحد.
- مخرجات بحاجة إلى مراجعة (Output needing review): ما الذي أنتجه الوكيل ويتطلب الآن من الإنسان قبوله أو رفضه؟ فارق التغييرات (diff)، أو طلب سحب (PR)، أو ملخص بالتعديلات.
إذا راقبت الحالة وحدها، فستفوتك رؤية الوكيل الذي يعمل لكنه عالق في حلقة إعادة محاولة لا نهائية. وإذا راقبت التقدم وحده، فستفوتك معرفة أن وكيلاً قد أنهى مهمته منذ عشرين دقيقة. يجب أن يبرز نظام المراقبة هذه الإشارات الأربع معاً، لكل وكيل، بلمحة واحدة سريعة.
الخطوة 1: المراقبة بالطريقة اليدوية (DIY)، ومواطن القصور في كل مرحلة
يعتمد الإعداد اليدوي على أدوات تملكها وتستخدمها بالفعل. إليك نظرة واقعية وصريحة عليه، مع توضيح الفجوة التي تتركها كل خطوة دون معالجة.
معرفة ما هو قيد التشغيل: إذا كان كل وكيل يعمل داخل مساحة عمل منفصلة git worktree، فيمكنك عرضها وفروعها عبر:
git worktree list
tmux ls # if each agent runs in a tmux session
نمط الفشل: يخبرك هذا الأمر بوجود الجلسة فقط، ولا يبين ما إذا كان الوكيل داخلها يعمل بنشاط أم ينتظر تدخلاً. فلوحة tmux العالقة عند موجه تأكيد Continue? (y/n) تبدو مطابقة تماماً للوحة تعمل بنشاط وسط المهمة؛ ولن تكتشف ذلك إلا بعد الاتصال بالجلسة (attach).
متابعة التقدم: تتبّع مخرجات كل وكيل واستطلع مساحة عمله لرصد التغييرات:
tail -f /path/to/agent-1.log
watch -n 5 'git -C ../wt-auth status --short'
نمط الفشل: تتزايد صعوبة هذه الطريقة طردياً مع عدد الوكلاء؛ فمتابعة ثلاثة سجلات أمر ممكن، لكن متابعة ستة سجلات تتداخل مخرجاتها تصبح مستحيلة، كما أن حلقات watch تظهر لك وتيرة تعديل الملفات دون إعطائها أي معنى، إذ يمكنك رؤية الملفات تتغير دون أدنى فكرة عما إذا كان التغيير صحيحاً أم أن الوكيل يكرر أفعاله بلا جدوى.
التقاط انتهاء المهام: غلّف أمر تشغيل كل وكيل بحيث يرسل إشعاراً فور انتهاء العملية:
your-agent-command "$TASK"; \
curl -s -X POST "$WEBHOOK_URL" -d "agent-1 exited $?"
نمط الفشل: يشير رمز الخروج 0 (exit code 0) إلى انتهاء العملية البرمجية فقط، وليس إلى أن العمل متقن أو حتى مكتمل. فالعديد من الوكلاء ينهون عملهم بنجاح بعد طرح سؤال لم تره قط. هذا الإشعار بـ "الانتهاء" يجعلك تعتمد على إشارة مضللة لا تعني الإنجاز الفعلي.
رصد التعارضات: عندما يتشارك عدة وكلاء مستودعاً واحداً، تفصل شجرات العمل (worktrees) أدلة العمل الخاصة بكل منهم، إلا أن تعديل وكيلين للملف ذاته على فرعين مختلفين سيؤدي إلى تصادم حتمي وقت الدمج.
git worktree list --porcelain | grep branch
نمط الفشل: لن تكتشف هذا التداخل إلا عند محاولة الدمج، وهي اللحظة الأكثر كلفة وتأخيراً لاكتشافه.
كل ما سبق ليس خاطئاً في حد ذاته؛ فعند تشغيل وكيلين أو ثلاثة على مهام غير مترابطة، فإن نافذتي tmux وحلقة watch تشكل أسلوب مراقبة معقولاً ومناسباً، ولا داعي للجوء إلى حلول أكثر تعقيداً. أبقِ الأمور بسيطة قدر الإمكان إلى أن تصطدم بالجدار.
أين تتوقف المراقبة اليدوية عن التوسع والفعالية؟
يظهر هذا الحاجز عادةً عندما تدير عدداً من الوكلاء لا تتسع له شاشة واحدة، وهنا تتفاقم ثلاثة إخفاقات رئيسية:
الاستطلاع يوضح الحالة، لا السبب: يكشف لك أمرا git status ومتابعة السجلات عبر tail أن شيئاً ما قد تغير أو أن المخرجات توقفت، لكنهما يعجزان عن توضيح ما إذا كان الوكيل عالقاً أمام طلب إدخال، أو تعيقه حزمة مفقودة، أو أنه قد أتم عمله بالفعل. فينتهي بك الأمر بالدخول إلى الجلسات واحدة تلو الأخرى لتشخيص المشكلة، وهو عين التنقل المرهق بين النوافذ الطرفية الذي كان من المفترض بالعمل الموازي أن يعفيك منه.
غياب الحالة المشتركة: تقتصر مراقبتك على حاسوبك المحمول، وخادم tmux، وسجل سطر الأوامر الخاص بك. ولا يستطيع زميلك في الفريق معرفة أي وكيل يتولى أي مهمة، كما تفقد أنت نفسك هذه الرؤية بمجرد إغلاق غطاء حاسوبك. وعندما يعمل وكيل على جهاز بعيد، فإن أسلوب تتبع السجلات محلياً يسقط تماماً.
تتحول المراجعة إلى عنق زجاجة: هذه هي النقطة التي يغفل عنها الكثيرون؛ إذ لا جدوى من تشغيل الوكلاء بالتوازي إذا كانت مراجعة مخرجاتهم ستعود أدراجها لتصطف في طابور فردي متعاقب. فوجود خمسة فروق تغييرات (diffs) مكتملة دون مساحة مشتركة لتتبع حالات "تمت المراجعة / طُلبت تعديلات / تم الدمج" يتحول إلى خمس علامات تبويب في المتصفح وملاحظات ذهنية مشتتة؛ وبذلك يصبح الوكلاء أسرع، بينما يصبح الإنسان أبطأ.
عند تلك النقطة، لست بحاجة إلى المزيد من النوافذ الطرفية، بل ينقصك سجل مشترك للمهام.
ما الذي توفره لوحة المهام: عودة كل النتائج إلى مكان واحد
تغير طبقة المهام وحدة المراقبة من "عملية في لوحة طرفية" إلى "مهمة لها حالة محددة". هذا هو التحول الأساسي الذي صُممت منصة Sharkly حوله، وهو ما يرتبط مباشرة بالإشارات الأربع للمراقبة.
يرتبط كل تشغيل لوكيل بمهمة معينة، وتصب الحالة، والتقدم، والعوائق، والنتائج كلها في الخط الزمني لتلك المهمة بدلاً من بقائها حبيسة سجل لا يراه أحد سواك. وبدلاً من الاستطلاع اليدوي المستمر، تراقب لوحة واضحة: ما هي المهام الجارية، وما هي العالقة، وما هي المكتملة التي تنتظر قرارك. ويعتبر صندوق وارد Sharkly (Inbox) المكان الذي تبرز فيه عمليات التشغيل التي تحتاج إلى تدخل بشري؛ ومن ثم لم يعد السؤال: "هل انتهى أي شيء؟"، بل أصبح: "إليك ما يحتاج إلى قرارك الآن". يتولى الوكلاء البحث والتنفيذ والاختبار وإعداد التقارير، بينما يتولى البشر تحديد الاتجاه، ومنح الصلاحيات، واعتماد النتائج؛ فالأتمتة تتوقف أينما تطلب الأمر حكماً وتقديرياً بشرياً.
هذا الحد الفاصل مهم للغاية هنا، لتجنب أي لبس: فمنصة Sharkly لا تشغل الوكلاء بنفسها ولا تكتب الكود، بل تظل بيئات التشغيل التي تستخدمها بالفعل—مثل Claude Code وCodex وغيرها—هي المسؤولة عن التنفيذ. يضيف Sharkly طبقة مشتركة للمهام، وأجهزة التشغيل، والسياق، والمراجعة من حولها؛ وبذلك يظهر تقدم كل تشغيل وفارق التغييرات الخاص به في مكان يراه الفريق بأكمله بدءاً من الطلب وحتى الإطلاق. كما أنه يُبقي كل تشغيل في مساحة worktree معزولة، مما يتيح احتواء تعارض الملفات المتزامنة وحصره لكل مهمة على حدة بدلاً من مفاجأتك به عند الدمج.
القاعدة الصريحة لاتخاذ القرار هي: إذا كنت تشغل وكيلاً أو وكيلين في مهام غير مترابطة دون الحاجة لتسليم العمل لأي شخص آخر، فإن أسلوب المراقبة اليدوي كافٍ تماماً، وستكون الاستعانة بـ Sharkly عبئاً إضافياً غير مبرر. لكن المعادلة تختلف جذرياً عندما يفوق عدد الوكلاء سعة شاشاتك، أو عند تشغيل المهام على أجهزة لا تجلس أمامها، أو عندما يحتاج أعضاء الفريق إلى رؤية اللوحة نفسها. وإذا كنت ترغب في الاستمرار باستخدام عدة وكلاء برمجة بدلاً من التقيد بمنظومة واحدة، فإن تقديم هذه الرؤية الموحدة المشتركة هو التحدي الذي صُممت Sharkly لحله. ولأخذ فكرة أشمل عما يجب أن تحتويه تلك اللوحة، راجع ما يجب أن تعرضه لوحة تحكم وكلاء البرمجة المدعومة بالذكاء الاصطناعي بالفعل.
قائمة مراجعة للمراقبة يمكنك تطبيقها اليوم
سواء واصلت الاعتماد على الإعداد اليدوي أو انتقلت إلى طبقة مشتركة، ينبغي لنظام مراقبة الوكلاء المتوازيين أن يجيب عن هذه النقاط دون أن تضطر للاتصال بجلسة طرفية واحدة:
- ربط كل وكيل بمهمة محددة الاسم: لا تترك أسماء مبهمة مثل "agent-3"؛ إذ يجب أن تعرف بوضوح الغرض من كل وكيل.
- رؤية الحالة بلمحة واحدة: التمييز الفوري بين كونه قيد التشغيل، أو ينتظر مدخلات، أو انتهى، أو فشل، دون محاولة استنتاج ذلك من مجرد التوقف عن إخراج النصوص.
- الوكلاء المتعثرون يطلبون التدخل: إظهار أي موجه ينتظر موافقة
y/n، أو مفتاح سري مفقود، أو سؤال دون إجابة، بدلاً من التوقف في صمت تام. - الاكتمال يعني الجاهزية للمراجعة وليس مجرد انتهاء العملية: تشغيل منتهٍ يشير بوضوح إلى فارق التغييرات (diff) أو طلب سحب (PR)، وليس مجرد رمز خروج للعملية.
- تتبع مراحل المراجعة بوضوح: تتبع حالات "تمت المراجعة"، و"طُلبت تعديلات"، و"تم الدمج"، حتى لا يتحول العمل المتوازي إلى طابور مراجعة فردي وبطيء.
- استمرار الرؤية حتى عند إغلاق الحاسوب مع إمكانية مشاركتها: حفظ الحالة في مكان دائم بدلاً من اقتصارها على سجل سطر الأوامر (shell history).
- عزل الأعمال على نفس المستودع: امتلاك كل وكيل لـ worktree مستقلة به، ورصد تداخل الملفات مسبقاً قبل الدمج وليس أثناءه.
قارن إعدادك الحالي بهذه القائمة؛ فالبنود التي تعجز عن تحقيقها اليوم هي ذاتها التي ستكلفك ساعات طويلة من يومك لاحقاً. وإذا كنت تدير بالفعل عدة وكلاء، فإن Sharkly يوفر لك مقراً موحداً لإدارة مهامهم ونتائجهم. يمكنك أيضاً تشغيل وكلاء البرمجة الحاليين لديك عبر Sharkly مع الاحتفاظ ببيئات التشغيل التي اعتدت عليها.
