كيف تحافظ على موثوقية وكلاء البرمجة عبر المشاريع الطويلة

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

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

المشكلة في الحزام التشغيلي لا في النموذج وحده

يعرّف المقال الوكيل بأنه النموذج مضافاً إليه التعليمات والأدوات وسياسات السياق والخطافات والعزل والوكلاء الفرعيون وآليات المراقبة. ويستشهد بنتيجة عامة من معيار Terminal-Bench 2.0، حيث نقلت LangChain وكيلاً من خارج أفضل 30 إلى أفضل 5 عبر تغيير الحزام التشغيلي فقط، لترتفع النتيجة من 52.8% إلى 66.5%، أي بزيادة 13.7 نقطة، مع إبقاء النموذج نفسه.

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

ستة عناصر لوكيل واحد منضبط

• دستور المشروع: ملف مثل CLAUDE.md أو AGENTS.md يحدد دورة العمل: التخطيط، التوثيق، التنفيذ، الاختبار، المراجعة ثم الالتزام. وينبغي أن يتضمن معايير الجودة وحدود استخدام حزم الموردين، مع إبقائه قصيراً لأنه يُقرأ في كل جلسة.
• حدود الاستقلالية: يُسمح للوكيل بالعمليات القابلة للعكس مثل القراءة والتحرير والاختبار وإنشاء الالتزامات، بينما تتطلب عمليات الدفع والنشر وتطبيق تغييرات البنية التحتية موافقة. ويجب التحقق من دلالات مطابقة الأوامر حتى لا تسمح قواعد واسعة، مثل npm:*، بالنشر عرضاً.
• سياق متعدد المستويات: يضم CONTEXT.md الجذري خريطة المشروع وطريقة تشغيله واختباره، بينما يشرح ملف كل وحدة مسؤوليتها وملفاتها وتبعياتها. ويسجل DECISIONS.md القرارات وأسبابها والبدائل المرفوضة. ويعد السياق القديم خطأ يجب إصلاحه في التغيير نفسه.
• ذاكرة دائمة: تقترح المادة ملفات ذاكرة منفصلة لكل حقيقة، وفهرساً مختصراً، وملف graph.jsonl يربط الوحدات والقرارات بعلاقات مثل يعتمد على أو يستبدل.
• لجنة مراجعة متعددة العدسات: يراجع وكلاء فرعيون التغيير من زوايا المنتج والهندسة والبنية التحتية والأمن والاختبارات. ولا يمنع التغيير إلا العائق أو المشكلة الجسيمة ذات الثقة المرتفعة.
• خطاف بعد التعديل: يعمل PostToolUse بعد كل Edit أو Write أو MultiEdit، ويصدر قائمة تذكّر بتحديث السياق والذاكرة وسجل القرارات في التغيير نفسه، بدلاً من إعادة كتابة الملفات بصمت.

عند تشغيل أسطول من الوكلاء

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

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

لماذا يهم هذا النهج؟

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

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