وكيل برمجي يستطيع فتح طلب سحب هو أداة مفيدة. أما وكيل برمجي يستطيع دمجه بينما لا يراقبه أحد فهو مصدر خطر يملك صلاحيات الكتابة إلى المستودع. والفجوة بين الجملتين هاتين هي المشكلة بأكملها. فبمجرد أن يصبح الوكيل قادرًا على الدفع إلى فرع، وتشغيل الاختبارات، والنقر على زر الدمج، لم يعد السؤال «هل يستطيع إنجاز العمل؟» بل «أين تنتهي صلاحياته؟».
معظم الفرق تجيب عن هذا السؤال بالمصادفة. يملك الوكيل ما مُنح له من صلاحيات في بيئة تشغيله، وتجري المراجعة في أي طرفية بدأ فيها التشغيل، وسجل من وافق على ماذا يبقى في سجل التمرير الخاص بشخص واحد. وهذا الحال يصمد حتى تصبح تشغّل ثلاثة وكلاء عبر مستودعين، فينشر إصدار يوم الجمعة شيئًا لم يقرأه أحد. بوابة الموافقة هي الحل، لكن بشرط أن تكون نقطة تفتيش حقيقية في نظام مشترك، لا مجرد عادة تأمل أن يلتزم بها الجميع.
هذا النظام المشترك هو ما تقدّمه Sharkly. أنت تملك وكلاء برمجيين بالفعل؛ و Sharkly تحوّل تشغيلاتهم إلى مهام (Tasks) لها حالات ومكلَّفون بها وخطوة مراجعة يجب أن ينفذها إنسان عن قصد. تستعرض هذه المقالة نموذج التشغيل الذي يقوم عليه ذلك: من يُسند العمل، ومن ينفذه، ومن يراجعه، ومن يقبله، وأين يقع موضع التوقف بالضبط حتى لا يدمج الوكيل تغييرًا خاصًا به دون مراجعة.
ما هي بوابة الموافقة فعليًا
بوابة الموافقة هي نقطة في دورة حياة المهمة يتوقف عندها التنفيذ الآلي في انتظار قرار إنسان بالخطوة التالية. ليست تحذيرًا، وليست سطرًا في السجل يمكن تجاوزه بالتمرير، بل حالة يبقى فيها العمل ريثما يحرّكه إنسان.
أهم تمييز هنا هو بين وكيل يقترح تغييرًا ووكيل يُدخله إلى الفرع. فتح طلب سحب اقتراح، أما دمجه فهو قرار يخص بيئة الإنتاج. هذان فعلان مختلفان من حيث الصلاحية، والفعل الثاني هو ما يجب أن يبقى بيد حكم الفريق. وتجعل Sharkly هذا الحد صريحًا: حتى مع ربط GitHub، لا يغيّر دمج طلب السحب حالة المهمة. يبقى الدمج إجراءً بشريًا مسجّلًا، لا أثرًا جانبيًا يحرّكه الوكيل بمجرد انتهائه.
تذكّر هذا الحد جيدًا، لأن معظم حكايات «الوكيل عطّل بيئة الإنتاج» هي في حقيقتها حكايات عن بوابة غائبة بين الاقتراح والإدخال.
نموذج التشغيل: الإسناد، والتنفيذ، والمراجعة، والقبول
تقسم Sharkly المهمة إلى أربعة أدوار، لكل دور مهمة واحدة. والعقد واضح: الوكلاء يبحثون وينفذون ويختبرون ويقدّمون التقارير؛ والبشر يحددون الاتجاه ويمنحون الصلاحية ويقبلون النتيجة.
- الإسناد. يصف إنسان الحاجة ويحدد المكلَّف. وتحمل المهمة إسنادين منفصلين: الأشخاص المشاركون فيها، والمكلَّف الواحد بالتنفيذ، وهو الوكيل أو الـ Crew الذي ينفذ العمل. وتغيير أحدهما لا يغيّر الآخر.
- التنفيذ. يقوم المكلَّف بالتنفيذ بالعمل داخل worktree معزول في git، فلا تلامس التشغيلات المتوازية ملفات بعضها. وتعود التطورات والعوائق والنتائج إلى المهمة.
- المراجعة. عندما ينتهي الوكيل، يترك المهمة في انتظار مراجعة بشرية بدلًا من إغلاقها. ويُرفق الفرق (diff) ومخرجات الاختبارات وملخص التغيير بالمهمة، لا بطرفية.
- القبول. يقرأ إنسان الأدلة ويقرر: طلب تعديلات، أو القبول والدمج. والقبول هو الخطوة النهائية، ولا يتخذها إلا إنسان.
القيمة هنا ليست في أن Sharkly تشغّل الوكيل، بل في أن الأدوار الأربعة تبقى مرئية في مكان واحد بدل أن تتلاشى في أي طرفية صادف أنها كانت مفتوحة. وللنسخة المعمّقة من نصف المراجعة، راجع وكلاء البرمجة بمشاركة بشرية في الحلقة.
اجعل البوابة حالةً في النظام، لا عادة
البوابة التي عليك أن تتذكرها هي بوابة ستتجاوزها عاجلًا أو آجلًا. لذا ضمّنها في دورة حياة المهمة.
تحمل حالات Sharkly معنى نظاميًا من خلال تصنيفاتها. فـ Backlog حالة انتظار: المهمة الموجودة فيها لا تُنفّذ حتى لو كان لها وكيل مكلَّف. ونقلها إلى تصنيف «جاهز للعمل» هو ما يسمح ببدء التنفيذ. أما Completed فهي حالة نهائية، والوصول إليها خطوة بشرية، لا شيء يمنحه الوكيل لنفسه.
حالة المهمة منفصلة عن قصد عن حالة عمل الوكيل. فبينما تقرأ حالة دورة الحياة In Progress، قد يكون الوكيل في الأسفل يعمل، أو ينتظر ردًا بشريًا، أو ينتظر مراجعة بشرية، أو يبلّغ عن خطأ. وهذا الفصل هو البوابة نفسها: يستطيع الوكيل إنهاء تشغيله وإظهار «بانتظار مراجعة بشرية» دون أن تعبر المهمة أبدًا إلى حالة توحي بأنها نُشرت. يعود العمل إلى المهمة ويتوقف هناك حتى يقبله أحد.
وهذا أيضًا ما يجعل تشغيل عدة وكلاء في آن واحد آمنًا. فعندما تصل خمسة وكلاء متوازيين في worktrees معزولة إلى عمود المراجعة نفسه، تصبح لديك بؤرة واحدة لفرزها بدل خمس طرفيات تراقبها.
مثال تطبيقي: من التذكرة إلى طلب سحب مدمج
لنتتبع مهمة واحدة خطوة بخطوة، باستخدام صيغة المعرّف SH-312 في Sharkly.
- أنشئها. ينشئ إنسان
SH-312، وهي مهمة خلل: «البحث يعيد نتائج قديمة بعد تغيير الفلتر». يحمل الوصف الهدف، وخطوات إعادة إنتاج المشكلة، ومعايير القبول. المكلَّف: وكيل Claude Code مرتبط بمستودع البحث. - حدّد شكلها. يبحث الوكيل في قاعدة الشيفرة وسجلها المتصل، ويؤكد النطاق، وينشر خطته في المهمة. يقرأ الإنسان الخطة وينقل
SH-312من Backlog إلى حالة جاهزية، وهي إشارة الانطلاق. - نفّذها. يستحوذ الوكيل على المهمة ويعمل في worktree جديد. يكتب الإصلاح، ويشغّل فحص الأنواع ومجموعة الاختبارات، ويفتح طلب سحب يحمل عنوانه
SH-312حتى تربط Sharkly طلب السحب بالمهمة. - التوقف عند البوابة. لا يدمج الوكيل التغيير. بل يرفق ملخص التغيير، ومخرجات الاختبارات الناجحة، وأي قيود معروفة، ثم يترك
SH-312بانتظار مراجعة بشرية. وهكذا عاد العمل إلى المهمة. - المراجعة. يفتح إنسان
SH-312، ويقرأ الفرق والأدلة في عرض واحد، فيلاحظ أن الإصلاح لامس دالة استعلام مشتركة. يترك تعليقًا يطلب تغييرًا أضيق نطاقًا. وفي مهمة لها وكيل مكلَّف جاهز، يعيد هذا التعليق التشغيل إلى قائمة الانتظار، فتبقى حلقة طلب التعديلات موثّقة بدل أن تبدأ من جديد في محادثة خاصة. - القبول والدمج. ينجح التشغيل الثاني في المراجعة. يوافق الإنسان على طلب السحب ويدمجه وينقل
SH-312إلى Completed. ولأن الدمج لا يغلق المهمة تلقائيًا، يبقى القبول والدمج قرارين بشريين مسجّلين، لا سلسلة تلقائية واحدة.
يمكن تفتيش كل خطوة في هذه السلسلة لاحقًا، وهذا هو جوهر سير عمل قابل للتتبع من المتطلبات إلى الشيفرة: تستطيع الإجابة عن سؤال «من وافق على هذا، وبناءً على أي دليل» دون تنقيب أثري في سجل تمرير أحدهم.
أين لا ينبغي وضع البوابة
المزيد من البوابات ليس أكثر أمانًا بالضرورة؛ فهي تضيف احتكاكًا يدرّب الناس على النقر والتجاوز. ضع البوابة حيث تكون تكلفة الدمج الخاطئ حقيقية. فبالنسبة لتغيير صغير محدد جيدًا ومنخفض المخاطر مُسند إلى وكيل واحد، تكفي نقطة التوقف قبل الدمج، ولا حاجة إلى Crew أو خطوات موافقة إضافية فوقها. وأضف مراجعة أثقل عندما يكون نطاق التأثير واسعًا: الشيفرة المشتركة، والترحيلات (migrations)، وأي شيء يلامس المصادقة أو الفوترة.
البوابة الوحيدة التي لا تُزيلها أبدًا هي بوابة الدمج. يمكن للوكيل أن يبحث ويكتب ويختبر ويقترح طوال اليوم، لكن ما إذا كان تغييره سيصل إلى فرعك الرئيسي قرار بشري، ويجب أن يبقى كذلك حتى لو كان الوكيل محقًا في معظم الأحيان. اقرن مراجعة المهام في Sharkly بحماية الفروع الموجودة لديك لتفرض المنصة ما يهدف إليه سير العمل، واحتفظ بالأدوات التي يستخدمها فريقك بالفعل: اربط GitHub وأسند التذكرة إلى وكيل ذكاء اصطناعي دون إعادة بناء عملياتك.
إذا كنت تشغّل بالفعل عدة وكلاء برمجيين وتفقد القدرة على تتبع أيّهم انتهى، وأيّهم فشل، وأيّهم ينتظرك، فعمود المراجعة هذا هو السبب لِتجربة Sharkly. شغّل وكلاءك الحاليين من خلالها وأبقِ قرار الدمج في مكانه الصحيح.
الأسئلة الشائعة
هل تستطيع Sharkly منع الوكيل من الدمج بمفرده؟ نعم. فدمج طلب السحب لا يغيّر حالة المهمة في Sharkly، ولذلك ينتهي التشغيل عند «بانتظار مراجعة بشرية» بدل إدخال تغيير إلى الفرع. واقرن ذلك بحماية الفروع في GitHub لفرض المراجعات المطلوبة على مستوى المستودع.
ما الفرق بين حالة المهمة وحالة الوكيل؟ حالة المهمة هي تصنيف دورة الحياة (Backlog، وStarted، وCompleted، وما إلى ذلك). أما حالة الوكيل فهي ما يفعله التشغيل الآن: يعمل، أو ينتظر ردًا بشريًا، أو ينتظر المراجعة، أو وقع في خطأ. ويمكن أن تبقى المهمة In Progress بينما ينتظرك الوكيل.
هل أحتاج إلى Crew لكل مهمة تخضع للمراجعة؟ لا. بالنسبة للعمل الصغير المحدد النطاق، أسند المهمة إلى وكيل واحد واستخدم بوابة المراجعة قبل الدمج. واحتفظ بالـ Crew للهدف الذي يحتاج إلى وكيل قائد ينسّق بين عدة أعضاء.
