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

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

يزداد الغموض سوءًا بمجرد تشغيل أكثر من وكيل واحد. أسند خطأً برمجيًا إلى Claude Code وآخر إلى Codex، وستجد نفسك أمام فرعين وملخّصين، دون إجابة مشتركة عن سؤال بسيط: باسم مَن سيُسجَّل كلٌّ منهما عند الدمج؟ الملكية التي تعيش في سجل الطرفية ليست ملكية، بل تخمين يصمد حتى أمر git log التالي.

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

الخلاصة السريعة

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

من يملك العمل الذي ينتجه الوكيل

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

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

نموذج التشغيل: الإسناد، التشغيل، المراجعة، القبول

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

التفصيل المهم يكمن في الصف الأول والأخير: الشخص نفسه يملك الإسناد والقبول. وهكذا تُغلق الحلقة، فمن قرّر أن العمل يستحق التنفيذ هو من يؤكد إنجازه. ويدعم Sharkly ذلك عبر الاحتفاظ بخانتَي إسناد على المهمة في آنٍ واحد: مكلَّف بشري ومكلَّف من الوكلاء، بحيث تُسجَّل المسؤولية والتنفيذ كواقعين منفصلين بدلًا من عبارة غامضة واحدة «مُسند إلى». ولمعرفة كيف يصل العمل إلى الوكيل، راجع دليلنا عن إسناد عمل الوكلاء وتتبعه ومراجعته في مكان واحد.

الحالات والبوابات: الوكلاء يصلون إلى «جاهزة للمراجعة» والبشر ينقلون العمل إلى «منتهية»

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

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

من التذكرة إلى طلب دمج مدمج: مثال عملي كامل

إليك النموذج وهو يعمل من البداية إلى النهاية على مهمة واحدة، SH-312، «إضافة تحديد معدّل الطلبات إلى نقطة نهاية البحث العامة».

1. الإسناد. تكتب مهندسة المهمة: نقطة النهاية، والحدّ المستهدف، ومعايير القبول (استجابة 429 عند تجاوز الحد، ونجاح الاختبارات الحالية، واختبار جديد للحدّ). تحدّد نفسها مكلَّفًا بشريًا وتختار مكلَّف الوكيل. تبقى المهمة في قائمة الأعمال المتراكمة، ولا شيء يعمل بعد.
2. التشغيل. تنقل SH-312 إلى حالة «جاهزة للعمل». تغيير الحالة هذا هو ما يبدأ التشغيل. يستلم الوكيل المهمة، ويجهّز شجرة عمل جديدة حتى لا يتعارض هذا العمل مع أي شيء آخر، ويقرأ الوصف والتعليقات الأخيرة، ويعدّل نقطة النهاية، ويضيف الاختبار، ويشغّل مجموعة الاختبارات.
3. التقرير. يفتح الوكيل طلب دمج وينشر تعليقًا على المهمة يتضمن: ملخّص التغيير، والاختبارات التي شغّلها ونتائجها، وملاحظة صادقة واحدة بأنه لم يُجرِ اختبار حمل للحدّ في ظروف حركة مرور حقيقية. وينقل SH-312 إلى «جاهزة للمراجعة» ويتوقف عند هذا الحد؛ فلا يمكنه المضي أبعد.
4. المراجعة. تصل إشارة انتظار المراجعة إلى صندوق وارد المهندسة. تقرأ بالترتيب: معايير القبول، ثم تعليق الوكيل، ثم سجل التنفيذ، ثم الفرق. يُظهر السجل سبب انتظار التشغيل في الطابور وما استدعاءات الأدوات التي أجراها، فتراجع التغيير نفسه لا حكاية عنه. ثغرة اختبار الحمل حقيقية، فتنشر تعليقًا تطلب فيه اختبارًا عند السقف الموثّق. وهذا التعليق يضع تشغيلًا لاحقًا في الطابور للوكيل نفسه، دون أن تفتح مهمة ثانية.
5. القبول. يضيف الوكيل الاختبار، ويقدّم تقريره مرة أخرى، ويعيد المهمة إلى «جاهزة للمراجعة». هذه المرة تطابق الأدلةُ المعايير، فتدمج طلب الدمج وتنقل SH-312 إلى «منتهية»: إجراءان مقصودان من الشخص الذي ملك العمل منذ البداية.

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

حيث تنكسر الملكية بصمت

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

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

الخاتمة

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

إذا كنت تشغّل بالفعل عدة وكلاء برمجة، يمنحك Sharkly مكانًا واحدًا لإسناد عملهم ومتابعة تشغيله وتسجيل من راجع كل نتيجة وقبلها. يمكنك تجميع هذا النموذج يدويًا بأشجار العمل وجدول بيانات، أو تنزيل Sharkly وترك المهمة تحمله عنك. ولمعرفة الشكل الكامل لهذه الطبقة، ابدأ بـإدارة وكلاء البرمجة فوق Claude Code و Codex.

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

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

هل يمكن للوكيل وسم عمله بالانتهاء؟ لا. يستطيع الوكيل نقل المهمة إلى «جاهزة للمراجعة»، لكن سير عمل المهمة لا يمنحه حالة «مقبولة». يقرأ شخص الأدلة وينقل المهمة إلى «منتهية».

هل يعني دمج طلب الدمج قبول المهمة؟ لا. دمج طلب دمج مرتبط بالمهمة حدث في Git ولا يغيّر حالة المهمة في Sharkly. القبول تغيير حالة منفصل يقوم به المالك البشري بعد المراجعة.

من ينبغي أن يملك مهمة الوكيل؟ الشخص الذي قرّر أن العمل يستحق التنفيذ. يحتفظ Sharkly بخانة مكلَّف بشري إلى جانب مكلَّف الوكيل، لتصل إشارة المراجعة إلى ذلك الشخص ويقبلها هو.

ماذا يحدث إذا لم يُكلَّف أي إنسان؟ تحصل على تنفيذ بلا مسؤولية. والقاعدة الآمنة أن تحدّد كل مهمة وكيل مالكًا بشريًا، حتى يكون لتشغيل منتهٍ دائمًا شخص مسؤول عنه.