مراجعة طلبات السحب باستخدام وكلاء الذكاء الاصطناعي: دليل الإعداد في 6 خطوات

إجابة سريعة: لمراجعة طلبات السحب (Pull Requests) بواسطة وكلاء الذكاء الاصطناعي، أوكل مهمة المراجعة إلى وكيل ثانٍ بتعليمات مستقلة، وبيئة فحص خاصة، ونموذج ذكاء اصطناعي مختلف إن أمكن. واحرص على تشغيله تلقائيًا بمجرد وصول المهمة إلى مرحلة المراجعة، ليتولى تشغيل الاختبارات وإصدار قرار بالقبول (PASS) أو طلب التعديلات (CHANGES REQUIRED)، وإعادة النتائج غير الناجحة إلى الوكيل المُطوِّر. ويبقى قرار الدمج النهائي دائمًا بيد المطور البشري.

لماذا ينبغي لوكلاء الذكاء الاصطناعي مراجعة طلبات السحب قبلك؟

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

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

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

لماذا لا يستطيع الوكيل مراجعة الكود الذي كتبه بنفسه؟

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

يتجلى هذا بوضوح في الاختبارات؛ فالوكيل المُطوِّر الذي يعجز عن اجتياز اختبار معين قد يُضعف شروط التحقق (assertions) ويزعم إنجاز المهمة. وقد استعرضنا هذه الأنماط بالتفصيل في مقالنا حول كيفية كشف تحايل وكلاء البرمجة على الاختبارات. في المقابل، يقرأ المراجع المستقل - الذي ليس لديه أي مصلحة في النتيجة - التغييرات بحيادية تامة ويطرح سؤالاً مختلفاً: هل يُحقق هذا التعديل المطلوب من المهمة بدقة، دون أي زيادة أو نقصان؟

وقد خلُص المقال التصميمي لفريق DeepSeek Harness حول الوكلاء الفائقين (super-agents) إلى فصل مماثل: حيث يرتبط عدة وكلاء فرعيين (Workers) بطلب السحب نفسه، ويتابعون أحداثه معًا ويسوون التعارضات فيما بينهم. ورغم أن المقال يصف تصميمًا تجريبيًا وليس منتجًا نهائيًا، إلا أن الفكرة تثبت صحتها عمليًا؛ فالمراجعة تكون أكثر فاعلية عندما يتولاها طرف مستقل.

الخطوة 1: الفصل بين الوكيل المُطوِّر والوكيل المُراجِع

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

لا يحتوي الوكيل في Sharkly على أداة لاختيار النموذج، بل يتحدد هدف تنفيذه من خلال جهاز (Computer) وبيئة تشغيل (Runtime) يتم اكتشافها على هذا الجهاز. وبالتالي، فإن عبارة «استخدام نموذج مختلف» تعني ربط الوكيل المُراجع ببيئة تشغيل مختلفة، وهو ما يضفي منظورًا وأسلوبًا جديدين على فحص التعديلات. وتُحسب تكلفة كل عملية تشغيل وفقًا للخطة المربوطة بتلك البيئة، نظراً لأن Sharkly لا تبيع الرموز (tokens) بشكل مباشر.

اضبط دليل العمل الخاص بالوكيل المُراجع على الوضع المؤقت (Temporary mode). وتوضح وثائق الأجهزة (Computers docs) كيف يحصل كل تشغيل على دليل معزول تمامًا، مع إمكانية إعداد شجرة عمل Git (Git worktree) جديدة عند تشغيل المستودعات. وبهذا، يستخرج المُراجع فرع طلب السحب في نسخته المستقلة دون التعارض مع ملفات الوكيل المُطوِّر أو الكتابة فوقها. ويوضح مقالنا حول الوكلاء المتوازيين في أشجار عمل معزولة أهمية ذلك عند مشاركة عدة وكلاء في مستودع واحد.

الخطوة 2: صياغة تعليمات الوكيل المُراجِع

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

You are the code reviewer for this Space. You never push, merge or edit files.

1. Read the triggering task. If it is not a code task in this Space, reply "not mine" and stop.
2. Find the linked pull request (the task ID appears in its title, description or branch).
3. Check out the PR branch in your worktree. Run the test command from the repo README.
4. Compare the diff to the task's acceptance criteria.
5. Post one verdict comment on the task in the format below. Nothing else.

الخطوة الأولى أهم بكثير مما تبدو عليه؛ إذ إن مشغلات تغيير الحالة والتعليقات تعمل على نطاق المنظمة بأكملها حاليًا، لذا يتعين على التعليمات التحقق من ملاءمة المهمة قبل الشروع في أي إجراء، وهو ما تنص عليه صراحةً وثائق الأتمتة (Automations docs).

الخطوة 3: تحديد آلية التشغيل التلقائي (Trigger)

تجمع الأتمتة في Sharkly بين التعليمات، والوكيل (Agent) أو فريق العمل (Crew)، ومُشغّل واحد أو أكثر. ولمراجعة طلبات السحب، هناك خياران مناسبان للتشغيل.

تغيير حالة المهمة (Task status change): أضف حالة مثل In Review إلى مسار عمل مساحتك (Space). يقوم الوكيل المُطوِّر بنقل مهمته إلى هذه الحالة بعد فتح طلب السحب، ليبدأ الوكيل المُراجع عمله فورًا. ويُنشئ التشغيل القائم على تغيير الحالة محادثة مرتبطة بتلك المهمة، مما يحافظ على ربط القرار النهائي واستهلاك الرموز (tokens) بسياق العمل الأصلي.

تُظهر لقطة الشاشة أعلاه البوابة البرمجية التي تعتمدها هذه المدونة لمراجعة مسوداتها الخاصة؛ حيث تصل المهمة إلى مرحلة Ready for Release فيتولى وكيل المراجعة فحصها. والنمط نفسه ينطبق تمامًا على مراجعة الأكواد البرمجية.

خطافات الويب (Webhook): إذا كانت طلبات السحب تُفتح خارج لوحة المهام الخاصة بك، فيمكنك توجيه pull_request webhook الخاص بـ GitHub إلى عنوان URL للـ webhook في الأتمتة. وعند تفعيل التحقق من التوقيع، تقبل Sharkly ترويسة X-Hub-Signature-256 الخاصة بـ GitHub، حيث تلصق سر التوقيع في حقل Secret في GitHub. وبما أن عمليات التشغيل عبر الـ webhook لا تكون مرتبطة بمهمة محددة، ينشر الوكيل المُراجع قراره مباشرة على طلب السحب نفسه باستخدام GitHub CLI.

اختبر أيًا من المسارين باستخدام خيار Run now قبل الاعتماد عليه كليًا.

الخطوة 4: تزويد الوكيل المُراجِع بقائمة تدقيق

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

1. هل تعمل الاختبارات وتجتاز بنجاح؟ يقوم المُراجع بتشغيلها بنفسه ولا يعتمد إطلاقًا على ملخص الوكيل المُطوِّر.
2. هل تم الالتزام بنطاق المهمة؟ أي ملفات تم تعديلها خارج إطار المهمة تُعد مخالفة، حتى لو بدا التغيير غير ضار.
3. هل هناك أي بيانات سرية مكشوفة؟ مثل الرموز (tokens)، والمفاتيح (keys)، وقيم ملفات .env في الفروقات أو سجلات التشغيل.
4. هل طرأ أي كسر في توافقية التوابع والمستدعين (Callers)؟ كتعديل تواقيع الدوال، أو حذف نقاط النهاية (endpoints)، أو ترحيل قواعد البيانات دون خطة تراجع (rollback).
5. هل تم إضعاف الاختبارات؟ كحذف شروط التحقق (assertions)، أو إضافة تخطيات جديدة (skips)، أو التساهل في القيم المتوقعة.

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

الخطوة 5: تثبيت هيكل تقرير القرار

التقرير الواضح الذي يستطيع المطور قراءته وفهمه في عشر ثوانٍ يتفوق بمراحل على تقرير مفصل يتجاهله تمامًا. استخدم تنسيقًا ثابتًا:

VERDICT: CHANGES REQUIRED

Tests: 41 passed, 2 failed (test_refund_rounding, test_refund_zero)
Scope: OK, 3 files, all under billing/
Secrets: none found
Breaking changes: refund() now raises on amount=0; two callers in api/ not updated
Weakened tests: none

Required:
1. Handle amount=0 in refund() or update both callers.
2. Fix the rounding in test_refund_rounding; do not change the expected value.

ويتضمن قرار القبول (PASS) الحقول ذاتها ولكن مع قائمة فارغة للتعديلات المطلوبة (Required). كما تتيح الحقول الثابتة قياس القرارات وإحصاءها؛ مما يمكّنك من معرفة معدل فشل كل فحص، وتعديل تعليمات الوكيل المُطوِّر وفقًا لذلك.

الخطوة 6: إغلاق حلقة التغذية الراجعة مع المُطوِّر

ينبغي لقرار طلب التعديلات (CHANGES REQUIRED) أن يُعيد تشغيل الوكيل المُطوِّر تلقائيًا دون تدخل يدوي منك لنقل الملاحظات. أنشئ أتمتة ثانية مخصصة للوكيل المُطوِّر، مع مُشغّل تعليقات يعتمد على عبارة مميزة.

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

ضع حدًا أقصى للحلقة: جولتان من المراجعة والإصلاحات تكفيان، وبعدها يُحيل الوكيل المُراجع المهمة إلى مطور بشري مرفقة بآخر تقرير قرار.

ما يبقى من مسؤولية المطور البشري

يبقى قرار الدمج دائمًا بيدك أنت. ففي تكامل GitHub الخاص بـ Sharkly، يقوم معرّف المهمة في عنوان طلب السحب بربط الطلب بالمهمة، كما أن عملية الدمج لا تغير حالة المهمة تلقائيًا؛ فلا شيء يُنشر بمجرد أن يقرر الوكيل القبول (PASS).

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

خاتمة

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

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

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

هل يستطيع وكيل الذكاء الاصطناعي مراجعة طلب السحب الخاص به؟

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

هل ينبغي للوكيل المُراجع استخدام نموذج مختلف عن الوكيل المُطوِّر؟

نعم، كلما أمكن ذلك. في Sharkly، يرتبط النموذج ببيئة التشغيل (Runtime)، لذا اربط الوكيل المُراجع ببيئة تشغيل مختلفة عن تلك الخاصة بالمُطوِّر، كأن يتولى Codex مراجعة عمل Claude Code على سبيل المثال.

ما الذي يجب أن يتحقق منه مراجع الكود بالذكاء الاصطناعي أولاً؟

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

هل يمكن للوكيل المُراجع الموافقة على طلب السحب ودمجه؟

لا تسمح له بذلك؛ واحتفظ بصلاحيات الدمج للمطورين البشريين من خلال حماية الفروع (Branch protection). يقتصر دور الوكيل المُراجع على كتابة تعليق بالقرار النهائي، بينما القرار الفعلي يعود للبشر.

كيف أمنع حلقة المراجعة من الاستمرار إلى ما لا نهاية؟

حدد سقفًا لا يتجاوز جولتين في تعليمات الوكيل المُراجع، واستخدم عبارة تعليق يمتنع الوكيل المُطوِّر عن تكرارها. وبعد بلوغ هذا الحد، يُحيل المُراجع المهمة إلى مطور بشري.

هل تعمل هذه الآلية مع طلبات سحب GitHub المفتوحة خارج Sharkly؟

نعم. يمكنك ربط webhook الخاص بـ GitHub بمُشغّل الـ webhook في الأتمتة. وتقبل Sharkly ترويسة التوقيع الخاصة بـ GitHub عند تفعيل خيار التحقق.