وكلاء البرمجة بالتدخل البشري: سير عمل المراجعة

عادةً ما يُوصف وكلاء البرمجة الذين يعملون بمشاركة الإنسان (human-in-the-loop) بأنهم إعداد: الوضع الذي يسأل فيه الوكيل قبل أن يُجري تعديلًا. هذه حلقة واحدة، وهي الأصغر. تعمل داخل طرفية مطوّر واحد، لجلسة واحدة، وتتلاشى عند انتهاء الجلسة. والفريق الذي يظن أن لديه إشرافًا بشريًا لأن الجميع تركوا Claude Code في وضع Manual لديه إشراف على ضغطات المفاتيح، لا على النتائج.

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

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

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

البوابة 1: وضع الإذن داخل بيئة التشغيل

كل وكيل برمجة جاد يأتي مزوّدًا بآلية موافقة. تتدرّج أوضاع الإذن في Claude Code من default، الموسوم Manual، الذي يسأل قبل التعديلات وأوامر shell والوصول إلى الشبكة، مرورًا بـ acceptEdits وplan وauto، حيث يراجع نموذج ثانٍ يُسمى المصنّف الإجراءات بدلًا منك، وصولًا إلى bypassPermissions للحاويات المعزولة فقط. يمكن التبديل باستخدام Shift+Tab أو --permission-mode. ويكشف Codex الفكرة نفسها عبر أمر /permissions، الذي يحدد متى يجوز له تحرير الملفات أو تشغيل الأوامر دون سؤال.

هذه البوابة ضرورية لكنها غير كافية. فهي لكل جلسة ولكل مطوّر، وتحمي الجهاز لا المتطلب، ولا تترك أي سجل يستطيع زميل في الفريق قراءته. في خطط Pro وMax وTeam، يبدأ Claude Code الآن في وضع auto افتراضيًا، وهو خيار معقول تحديدًا لأن المصنّف أسرع وأكثر اتساقًا من إنسان متعب يضغط على «نعم». الدرس ليس محاربة هذه الآلية، بل التوقف عن اعتبارها هي المراجعة.

البوابة 2: تأكيد الخطة

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

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

البوابة 3: حد التنفيذ

لا تبدأ مهمة مسندة إلى وكيل وهي في Backlog. نقلها إلى حالة تنتمي إلى فئة جاهزة للعمل هو ما يبدأ التشغيل، ولا تبدأ فئات completed وcanceled وduplicate أبدًا تشغيلًا أوليًا. لذلك فإن فئة الحالة بوابة يُشغّلها شخص عن قصد، وهي ظاهرة على اللوحة.

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

البوابة 4: إشارة الانتباه

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

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

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

البوابة 5: القبول على السجل

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

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

سير العمل في جدول واحد

متى تفتح البوابات على نطاق أوسع

ليست كل مهمة تستحق خمس محطات، والتظاهر بغير ذلك هو ما يحوّل المراجعة إلى مسرح. العمل للقراءة فقط، مثل تدقيق مستودع، يحتاج البوابة 1 والبوابة 5. العمل القابل للعكس في worktree معزول، مثل ترقية تبعية مع اختبارات، يمكنه تخطي تأكيد الخطة. يجب أن تنص تعليمات الأتمتة التي تعمل وفق جدول زمني على متى يجب أن يراجع شخص أو يقرر، وينبغي تشغيلها يدويًا وفحصها قبل أن يعتمد أي شخص على الجدول؛ دليلنا إلى الأتمتة في Sharkly يغطي ذلك.

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

ما الذي لا يعنيه human-in-the-loop

إنه ليس شخصًا يراقب طرفية. وليس مطالبة إذن يقف خلفها مراجع منهك. وليس حالة تقول Completed. تتوقف الأتمتة حيث يلزم تقدير الفريق، وتعيد تسليمًا بسياق كامل وأدلة قابلة للفحص. تلك الجملة هي سير العمل كله؛ والبوابات ليست سوى المواضع التي يُفرض فيها. Sharkly ليس بديلًا عن Claude Code أو Codex أو أدوات التنفيذ الأخرى؛ إنه الطبقة التي تكتب هذه القرارات.

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

هل يزيل وضع auto في Claude Code البشر من الحلقة؟ إنه يزيل البشر من مطالبة الإذن. يراجع المصنّف الإجراءات مقابل طلبك؛ لكنه لا يراجع ما إذا كانت النتيجة قد لبّت المتطلب. لا تزال البوابات من 2 إلى 5 من مسؤولية البشر.

كيف أوقف وكيلًا أثناء التشغيل؟ يمكن إلغاء تنفيذ في قائمة الانتظار أو قيد التشغيل. كما أن نقل مهمة إلى حالة Canceled أو Duplicate يوقف عمليات التشغيل النشطة؛ أما نقلها إلى Completed فلا يفعل ذلك، لذا ألغِ أولًا إذا كان الوكيل لا يزال يعمل.

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

هل يمكن أن تعود ملاحظات المراجعة إلى الوكيل دون مهمة جديدة؟ نعم. يمكن لتعليق على المهمة أن يضع تشغيلًا لاحقًا في قائمة الانتظار للوكيل المسنَد، ويتم دمج التعليقات السريعة حتى لا تُنشئ عمليات تشغيل مكررة.