مجلد agents/ في نواة لينكس: حين تصبح مهارات الوكلاء جزءاً من شجرة الشيفرة

حين يقترح مهندس يشارك في صيانة فروع الاستقرار طويلة الأمد في نواة لينكس أن يكون للوكلاء الذكية مجلد خاص داخل شجرة الشيفرة نفسها، فالخبر ليس عن أداة جديدة، بل عن اعتراف مؤسسي بأن مساعدي البرمجة صاروا جزءاً من سير العمل اليومي، وأن الأفضل تنظيمهم بدل تجاهلهم. المقترح الذي طرحه ساشا ليفين (Sasha Levin) على قوائم المراسلة الخاصة بسير العمل وقمة المطوّرين يضيف مجلداً باسم agents/ يضم مهارات وأوامر وموارد موجّهة لمساعدي البرمجة. في هذا المقال نشرح ما الذي يقترحه بالضبط، ولماذا بدأ بمهارة صغيرة جداً، وما الذي يمكن أن يتعلمه أي فريق من هذه الخطوة.

ما الذي يقترحه ليفين بالضبط؟

المقترح عبارة عن سلسلة من رقعتين (patches). الرقعة الأولى تضيف المجلد الجديد وتسجّل له مدخلاً في ملف MAINTAINERS حتى يكون له مسؤول واضح. الرقعة الثانية تعدّل وثيقة المساعدين البرمجيين الموجودة أصلاً في النواة، وتضيف قسماً يطلب من المساعد أن يتبع الدليل المناسب قبل أن يعتمد إصلاح خطأ أو رسالة الإيداع (commit message)، وعند مراجعة وسم موجود.

بنية المجلد

• لكل مهارة مجلد مستقل تحت agents/skills/.
• ملف SKILL.md هو نقطة الدخول، ويُكتب بصيغة المهارات المعروفة (Agent Skills).
• يمكن لاحقاً إضافة نصوص مساعدة وأمثلة بجانب الملف نفسه.

الفكرة أن تكون المعرفة التي كانت مبعثرة في ملاحظات شخصية وأوامر مخصصة لكل مطوّر موثّقة في مكان واحد، ويراجعها المشرفون كما يراجعون أي شيفرة أخرى.

المهارة الأولى: find-fixes

اختار ليفين أن يبدأ بمهارة ضيقة ومحدّدة بدل مهارة طموحة. تساعد find-fixes المساعد على التحقق من الإيداع الذي أدخل الخطأ فعلاً قبل أن يكتب وسم Fixes:. وهذه مشكلة حقيقية؛ فبحسب تقدير نقله المطوّر هانيس رينيكه (Hannes Reinecke) تكون نسبة 15 إلى 20 في المئة من هذه الوسوم خاطئة.

ما تفعله المهارة	ما لا تفعله
تحلّل تاريخ Git وتفرّق بين الإيداع الذي أضاف الشيفرة والإيداع الذي جعلها معيبة	لا تكتب رسالة الإيداع
تتعامل مع عمليات الدمج والنقل إلى فروع أقدم (backports)	لا تطبّق الوسم بنفسها
لا تعيد وسماً إذا كانت الأدلة غير كافية	لا تقرر هل يستحق الإصلاح الدخول إلى الفرع المستقر

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

المهارة الجيدة لا تحاول أن تفعل كل شيء، بل تحدّد بدقة ما تتركه للإنسان.

لماذا مجلد مستقل وليس ملف توجيه واحد؟

سبق أن اقترح ليفين ملف AGENTS.md للنواة، وواجه اعتراضات كان أبرزها استهلاك الرموز (tokens): إذا طُلب من الوكيل قراءة كل الوثائق في كل مرة فسيكلّف ذلك وقتاً ومالاً وسياقاً. المهارات تعالج ذلك بنمط التحميل عند الحاجة؛ يقرأ الوكيل وصف المهارة أولاً، ولا يفتح التعليمات التفصيلية إلا إذا كانت المهمة تحتاجها. وللتوسع في فكرة ملفات التوجيه يمكنك مراجعة مقالنا عن معيار AGENTS.md.

سؤال لم يُحسم: أين يوضع المجلد؟

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

ماذا يعني هذا لفريقك؟

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

1. ابدأ بمهمة واحدة ضيقة يتكرر فيها الخطأ البشري، مثل ربط الإصلاح بالإيداع المسبب.
2. اجعل المهارة تحت إشراف المراجعة نفسه الذي تخضع له الشيفرة، مع مسؤول معروف عنها.
3. اكتب حدود المهارة صراحة: ما الذي لا تفعله، ومتى تمتنع عن الإجابة.
4. قِس الأثر: قارن نسبة الأخطاء قبل المهارة وبعدها بدل الاعتماد على الانطباع.
5. أبقِ التعليمات قصيرة حتى لا تستهلك سياق الوكيل في كل تشغيل.

محاذير يجب ألا تتجاهلها

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

لماذا الآن؟ خلفية القرار

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

الفرق بين الوثيقة والمهارة

الوثيقة تُقرأ مرة وتُنسى، أما المهارة فهي إجراء قابل للتنفيذ يستدعيه الوكيل عند الحاجة، ومعه شروط واضحة لبدء العمل ولإيقافه. ولهذا تبدو مهارة مثل find-fixes أقرب إلى قائمة تحقق ذكية منها إلى دليل نظري.

ما الذي يجعل البداية الصغيرة ذكية؟

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

بهذا الأسلوب تُبنى الثقة تدريجياً، ويُترك لكل مهارة جديدة أن تثبت نفسها قبل التوسع.

أسئلة شائعة

هل اعتُمد المقترح رسمياً في نواة لينكس؟

لا. هو سلسلة رقع مقترحة على القوائم البريدية، والنقاش حول الموقع والشكل النهائي لم ينتهِ بعد.

هل ستكتب الوكلاء شيفرة النواة بدلاً من المشرفين؟

لا يقول المقترح ذلك. المهارة الأولى تساعد على التحقق من التاريخ فقط، ولا تكتب الرسائل ولا تطبّق الوسوم ولا تقرر ما يدخل الفروع المستقرة.

كيف أطبق الفكرة في مشروعي؟

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

الخلاصة

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

المصادر: It's FOSS، Phoronix