تواجه مشاريع المصدر المفتوح واقعاً جديداً مع وصول طلبات سحب كتب وكلاء الذكاء الاصطناعي إلى قوائم الانتظار. وبدلاً من إغلاق الباب أمام هذه المساهمات بالكامل، تعتمد AutoGPT على تعليمات محلية وبوابات آلية تحدد ما يمكن قبوله وكيفية مراجعته، مع إبقاء القرار النهائي بيد المشرفين على المشروع.
يروي مقال منشور على مدونة GitHub تجربة Nicholas Tindle، المهندس المؤسس للذكاء الاصطناعي في AutoGPT، الذي تحدث عن إدارة المشروع خلال مقابلة أجريت في مايو ضمن فعالية Maintainer Month. وفي ذلك الوقت، كان مستودع AutoGPT يضم أكثر من 180 ألف نجمة ونحو 150 طلب سحب مفتوحاً، وكان جزء كبير منها مكتوباً بواسطة وكلاء، من بينهم Copilot وOpenClaw وأدوات AutoGPT الداخلية.
ضع التعليمات حيث يعمل الوكيل
بدأت AutoGPT بتحسين إرشادات المساهمين والوثائق، بل أنشأت ويكي مخصصة للعمل مع المستودع، لكن ذلك لم يغير سلوك الأدوات كثيراً. فالوكيل لا يذهب بالضرورة إلى الوثائق بحثاً عن السياق؛ بل يقرأ ما هو موجود أمامه في مستوى المجلد الذي يعمل فيه.
لذلك وضعت AutoGPT التعليمات بالقرب من الشيفرة المعنية. استخدمت في البداية ملفات CLAUDE.md بعدما كانت طلبات السحب التي ينتجها Claude تفتقر إلى سياق خاص بالمستودع. لكن هذه المقاربة لم تكن مناسبة لوكلاء آخرين مثل Copilot وCodex، فجرى توحيد التعليمات في ملف AGENTS.md، مع توجيه ملفات Claude إليه.
ويشير المقال إلى أن ملف AGENTS.md يرتبط بنطاق مجلد محدد، بينما يمكن اكتشاف المهارة من خارج ذلك النطاق. والمهارة هي ملف تعليمات يتضمن وصفاً يحدد متى ينبغي للوكيل تحميله. وبذلك يستطيع الوكيل اكتشاف إرشادات متخصصة عند توافق المهمة مع الوصف، حتى إذا لم يكن يعرف مكان ملف AGENTS.md ذي الصلة.
ومن الأمثلة على ذلك أن مهندس الواجهة الأمامية في AutoGPT أنشأ مهارة تعالج طلبات الاختبار المتكررة في Storybook. ويتضمن وصف المهارة عبارات تشغيل تشير إلى ضرورة كتابة اختبار Storybook عندما تكون المكونات في مجلدات معينة. أما في الواجهة الخلفية، فتُفرض تغطية اختبار تبلغ 80% قبل السماح بفتح طلب السحب.
بوابات عملية لطلبات السحب
تعتمد AutoGPT مجموعة من الضوابط التي تجعل طلب السحب قابلاً للفحص قبل أن يستهلك وقت المشرفين:
- فرض قالب طلب السحب: تُغلق الطلبات التي لا تلتزم بالقالب تلقائياً. ووفق التجربة المذكورة، أدى مجرد توضيح هذا الشرط إلى تغيير سلوك الوكلاء قبل الحاجة إلى تشغيل أداة الإغلاق الآلي. ويرى Tindle أن منح المساهم البشري مساحة أكبر عند عدم الالتزام بالقالب قد يكون مناسباً، لأن التمييز بين أنماط المساهمة يساعد في التعامل معها.
- إضافة خطة اختبار: يتطلب القالب خطة اختبار، وتتضمن صياغته عبارة تؤدي إلى تشغيل مهارة باسم test PR. وتثبت هذه المهارة وكيل المتصفح بعد الحصول على الإذن، وتشغل التطبيق وتنفذ التغيير، ما يحول خانة في القالب إلى خطوة فعلية للتحقق من الشيفرة.
- جعل التكامل المستمر حاجزاً: تُعد حدود التغطية من الفحوص المطلوبة. فإذا فتح الوكيل طلب السحب وفشل الفحص، يمكنه تحميل مهارة الاختبار وكتابة الاختبارات اللازمة قبل الدمج.
- استخدام اتفاقية ترخيص المساهمين كحاجز بشري: يتطلب توقيع الاتفاقية متصفحاً وتدفق OAuth من GitHub على نطاق منفصل، وهي خطوة لا تتعامل معها الوكلاء بسهولة حالياً. وإذا لم تُوقّع الاتفاقية خلال أسبوع، يُغلق طلب السحب مع تعليق يطلب توقيعها وإعادة فتح الطلب لاحقاً. ويذكر المقال أن مربع تأكيد مدونة السلوك قد يؤدي وظيفة مشابهة.
- طلب معرّف الالتزام قبل إغلاق سلسلة المراجعة: تستخدم AutoGPT مهارة باسم pr-address تفرض التسلسل التالي: إصلاح المشكلة، ثم الالتزام بالتغيير، ثم الدفع، ثم الرد، وبعد ذلك حل سلسلة المراجعة. ويجب أن يتضمن الرد رابطاً إلى الالتزام المُصلح باستخدام SHA كاملاً مستخرجاً من الأمر git rev-parse HEAD.
ليس كل تشغيل آلي مفيداً
جربت AutoGPT تشغيل وكيل داخل GitHub Actions لقراءة نتائج الفحوص والتعليق على أسباب الفشل. استُخدم Claude Code في النسخة الأولى، ثم ظهر أن تشغيل Copilot داخل سير العمل يمكن أن يقدم النتيجة نفسها. لكن الفريق أوقف التعليقات الآلية في النهاية، لأن فشل التكامل المستمر كان متكرراً، وأصبح سيل التعليقات عبئاً إضافياً بدلاً من تخفيف العبء.
الدرس هنا ليس إضافة أكبر عدد ممكن من الوكلاء، بل الاحتفاظ بما يقلل عمل المشرفين وإيقاف ما يتحول إلى ضجيج. فطلبات السحب التي تصل إلى AutoGPT باتت تعمل في الغالب، لكن المشكلة انتقلت إلى طلبات لا تنسجم مع خارطة الطريق، وهي مشكلة يعتبرها المقال أفضل من استقبال تغييرات لا تعمل.
تحذيرات قبل التوسع
- قد يكون ملف AGENTS.md سيئاً أسوأ من عدم وجوده، إذ يؤدي انتشار الملفات إلى تلويث السياق وصرف انتباه الوكيل عن الملفات المهمة.
- يمكن أن تفرض واجهة GraphQL حداً لمعدل الطلبات عندما تستخدم الأدوات واجهة CLI كمستخدمين منفصلين. وتقترح التجربة إنشاء GitHub App ومصادقة CLI من خلاله.
- أدوات المراجعة الثقيلة تستهلك أموالاً حقيقية. فاختبار طلب السحب في AutoGPT ينسخ الفرع، ويشغل ثمانية وكلاء بمهام مختلفة، وينفذ الحزمة كاملة ويرفع لقطات شاشة؛ لذلك بات تشغيله مقتصراً على طلبات السحب الصغيرة جداً أو الكبيرة جداً.
- ينبغي تدقيق التطبيقات المصرح لها بالوصول. فكل أداة جرى اختبارها ثم التخلي عنها قد تترك تفويضاً قائماً، ولهذا يجب إزالة التطبيق من قائمة التطبيقات المصرح لها بعد التوقف عن استخدامه.
حدود المساهمة يحددها المشرفون
لا تعني أتمتة استقبال المساهمات ضرورة قبول كل طلب سحب. فدمج ناتج نموذج لغوي يحمّل المشروع أعمال الصيانة المستقبلية، وقد يكون إغلاق الطلب وإعادة بناء الإصلاح داخلياً خياراً مشروعاً. ويمكن للمشروع تعطيل طلبات السحب بالكامل، أو قصر إنشاء القضايا على المتعاونين، أو اشتراط التواصل قبل بدء العمل. ويقدم المقال SQLite مثالاً على مشروع لا يقبل مساهمات شيفرة خارجية، لكنه يستقبل تقارير الأخطاء.
وعندما يقرر المشرف إعادة بناء التغيير بنفسه، يقترح المقال إضافة المساهم كمؤلف مشارك إذا كان ذلك مناسباً. وتضم AutoGPT نحو 800 مساهم، لكن الفكرة الأوسع هي الاعتراف بمن ساعد في تحديد المشكلة، حتى إن لم يُدمج طلب السحب الأصلي.
تخلص التجربة إلى أن التعليمات الموضوعة بجوار الشيفرة تمثل خطوة إضافية نحو جعل التعاون صريحاً وقابلاً للفهم من البشر والوكلاء معاً. ولا تقدم AutoGPT صيغة نهائية؛ فقد وصلت إلى نسختها الثالثة بعد نشر إصدارات غير جيدة ومراقبة سلوك الوكلاء معها. لكن المبدأ ثابت: يظل المشرفون هم من يقرر ما يدخل المشروع، ويحددون مستوى الجودة، ويضعون الحدود، بينما تساعد القواعد المحلية والبوابات الآلية على تطبيق هذا الحكم قبل أن تتراكم طلبات السحب.