قوالب تسليم مهام وكيل البرمجة: الأدوار والحالات وبوابات المراجعة

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

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

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

ما هو قالب تسليم الوكيل البرمجي

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

هناك عمليتا تسليم تستحقّان القولبة، لأنهما تسيران في اتجاهين متعاكسين وتحملان شيئين متعاكسين:

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

قولبة الاثنين معًا هي المقصد. معظم الفرق تكتب تذكرة تقريبية ولا تقولب شيئًا في طريق العودة، فتتحوّل كل مراجعة إلى استجواب. وإصلاح رحلة العودة هو حيث يُوفَّر الوقت.

نموذج التشغيل الذي يجسّده القالب

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

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

## Assignment handoff
Task ID:        SH-###
Goal:           one sentence, in plain language
In scope:       the specific files, endpoints, or behaviors to touch
Out of scope:   what to leave alone (auth, billing, public contracts)
Definition of done:
  - [ ] observable acceptance criterion 1
  - [ ] observable acceptance criterion 2
Constraints:    frameworks, patterns, or limits to respect
Assignee:       the exact Agent that owns this

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

تسليم المراجعة: ما الذي يعود

قالب العودة هو ما تتخطّاه معظم سير العمل، وهو ما يوفّر عليك بقية يومك. حين ينتهي الوكيل، لا ينبغي أن يبعث لك تنبيهًا بـ"جاهز" ورابطًا فحسب، بل أن يعيد بنية مملوءة:

## Review handoff
Task ID:        SH-###
Summary:        what changed, in 2-3 sentences
Acceptance:     each definition-of-done item, checked with how it was verified
Tests:          typecheck / unit / build results, pasted or linked
Diff:           the PR or worktree branch
Known limits:   what this does NOT cover, and any risky assumption
Open questions: decisions left for a human

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

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

الحالات وبوابات المراجعة: أين يعيش القالب

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

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

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

لنأخذ مهمة واقعية، SH-441: "أضف تصدير CSV إلى صفحة التقارير." راقب كيف تُملأ القوالب، لا الكود.

يفتح شخص المهمة SH-441، ويُكمل وكيل قائد تسليم الإسناد: الهدف ("تمكين المستخدمين من تنزيل التقرير الحالي بصيغة CSV")، النطاق (وحدة تحكّم التقارير ووحدة تصدير جديدة واحدة)، خارج النطاق (المصادقة، استعلامات التقارير القائمة)، وتعريف إنجاز بثلاث بنود قابلة للفحص (زر تنزيل، تهريب صحيح للفواصل وعلامات الاقتباس، اختبار ببيانات تجريبية من 10,000 صف). الشخص المُسنَد إليه هو وكيل خلفي. لا شيء غامض، لأن القالب رفض أن يكون كذلك.

يطالب الوكيل الخلفي بالمهمة، ويعمل في worktree معزول فلا يتصادم أبدًا مع عمل آخر، وينفّذ بنود تعريف الإنجاز كقائمة تحقق خاصة به. وحين تظهر نتائج typecheck واختبارات الوحدة والبناء خضراء، ينقل SH-441 إلى "جاهزة للمراجعة" مع قالب العودة مملوءًا: ملخّص قصير، وكل بند قبول مُفحوصًا بطريقة التحقق منه، وفرق التغييرات، وحدّ معروف واحد ("عمليات التصدير التي تتجاوز 100 ألف صف تُخزَّن في الذاكرة مؤقتًا؛ البثّ غير مُنفَّذ").

الآن ينقلب اتجاه التسليم. يقرأ شخص سجلًّا واحدًا، لا ذاكرة تمرير. فيتأكد من اختبار التهريب، ويزن حدّ الذاكرة مقابل أحجام التقارير الفعلية، ويقبله في الوقت الحالي، وينقل SH-441 إلى "منتهية"، ما يُفعّل الدمج. من التذكرة إلى PR مدموج، مع قالب مملوء عند كل مفصل وسجل بمن ملك كلًّا منها. هذا هو مسار المتطلبات إلى الكود جاعلًا كل خطوة قابلة للتتبّع من البداية إلى النهاية.

متى يكون القالب مبالغة

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

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

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

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

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

هل ينبغي للوكيل أن يعلّم عمله بأنه منتهٍ؟ لا. دع الوكيل ينقل المهمة إلى "جاهزة للمراجعة" وقالب العودة مملوء، واترك النقل إلى "منتهية" وقرار الدمج لشخص. والفصل بين "عُرض" و"قُبل" هو ما يمنع إصدار كود غير مُراجَع.

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

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