Amp من Sourcegraph يتعلّم متابعة طلبات PR الخاصة به: التعليقات والمراجعات وCI في سلسلة محادثة واحدة

لم يعد Amp، وكيل البرمجة من Sourcegraph، يترك pull request بعد فتحه مباشرة. فهو يشترك الآن في التعليقات والمراجعات ونتائج CI المتعلقة بآخر commit في طلب PR الخاص به. إذا فشل أحد الفحوص أو طرح المراجع سؤالاً، يصل الحدث إلى سلسلة المحادثة نفسها التي كتب فيها الوكيل الكود. سياق المهمة متوفر لديه أصلاً، ولا حاجة إلى شرح أي شيء. صدر التحديث في 12 أكتوبر 2026، ويستند إلى تكامل جديد مع GitHub Webhooks.

كيف يعمل الاشتراك

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

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

orb جديد لكل issue أو PR

السيناريو الثاني مصمَّم لتدفق المهام الواردة. تطلبون من Amp تشغيل orb منفصل لكل issue أو PR جديد في المستودع. ومن أمثلة الإعلان: كل issue جديد في المستودع acme/website. ويمكن تضييق الانتقاء ليقتصر على ما يُفتح مع label معيّن.

يقرأ كل orb من هذه الـ orb الـ issue أو الـ PR الخاص به، وحين تفتحون السلسلة يكون ملخص موجز في انتظاركم. وتصل التعليقات اللاحقة إلى السلسلة نفسها، فلا يتشتت النقاش بين عدة جلسات.

أبرز معالم التحديث:

• ثلاثة أنواع من الإشارات المرتبطة بآخر commit في PR: التعليقات والمراجعات وCI؛
• وضعان للتوجيه: إلى orb واحد قائم أو إلى orb جديد لكل حدث؛
• التصفية حسب label للـ orb التي تُشغَّل تلقائياً؛
• إدارة الاشتراكات في Settings → MCP & Integrations → GitHub: التعديل والإيقاف المؤقت وقائمة الـ orb المشغَّلة لكل اشتراك؛
• في لقطة الشاشة لجدول GitHub Event Subscriptions يظهر اثنان من orb spawner واشتراك واحد في PR.

كيف تستفيدون من ذلك

يُستحسن أن تبدؤوا بتثبيت Amp GitHub App على المستودع المطلوب. بعد ذلك يكفي أن تطلبوا من الوكيل في سلسلة محادثة عادية أن يشترك في طلب PR الذي فتحه، أو أن يشغّل orb لكل issue جديد. ومن خلال جدول الاشتراكات في الإعدادات يسهل التحقق مما هو مشغَّل فعلاً وإيقاف ما لا حاجة إليه مؤقتاً.

تتضمن الوثائق سيناريوهات أخرى. فيمكن متابعة CI بعد push إلى main، أو الاشتراك في issue أو PR موجود أصلاً، أو سؤال Puck عمّا تتابعه Amp حالياً.

عملياً، تكمن الفائدة في اختصار الدورة التي تبدأ بفتح PR، ثم فشل CI، ثم ملاحظة الإنسان لذلك، ثم عودته إلى الوكيل. فالوكيل يتفاعل مع CI الأحمر ومع الملاحظات ضمن السياق نفسه الذي كتب فيه الكود. ومع ذلك يستحق المُشغِّل التلقائي (spawner) شيئاً من الحذر: ففي مستودع نشط ينشئ orb لكل issue أو PR، لذا يُستحسن ضبط فلتر الـ label منذ البداية. ولا يكشف الإعلان عن حدود عدد الـ orb ولا عن شروط التسعير، لذلك ينبغي الرجوع إلى وثائق Amp بشأنها.