يمكن للمطورين الآن تشغيل عدة جلسات لوكلاء البرمجة في وقت واحد دون خوف من الكتابة فوق ملفات الحالة أو حدوث تضاربات في الملفات المخفية. يعمل نمط "عدم المشاركة" (share-nothing) الاستشاري على عزل مساحة عمل كل وكيل ويحذر من التعارضات المحتملة. يستبدل هذا النهج الأقفال الصارمة بسجل خفيف الوزن يحدد الأعمال المتداخلة قبل حدوثها، مما يحافظ على استمرار مسارات العمل حتى عند تعطل إحدى الجلسات.
لماذا تسبب الوكلاء المتوازية المشاكل
إن تشغيل أكثر من مساعد برمجة مؤتمت في مستودع واحد يسرع من عملية توليد الكود أو اختباره أو إعادة هيكلته (refactoring). ولكن من الناحية العملية، تظهر مشكلتان على الفور:
- فساد الحالة (State corruption) – يقوم وكيلان بالكتابة في ملف الحالة نفسه؛ فتؤدي عملية الكتابة اللاحقة إلى الكتابة فوق العملية السابقة، مما يؤدي إلى مسح التقدم المحرز.
- تصادم الملفات (File collision) – يقوم وكيلان بتعديل نفس ملف المصدر دون علم كل منهما بالآخر. ويظهر التعارض لاحقاً عندما يظهر الفرق (diff) تغييرات متباعدة.
تؤدي كلتا المشكلتين إلى إضاعة وقت المطور ويمكن أن تتسببا في أخطاء يصعب تتبعها.
قاعدة "عدم المشاركة"
الفكرة الأساسية بسيطة: يحصل كل وكيل على مساحة عمل مؤقتة خاصة به على القرص، ويكتب فقط في الملفات التابعة لتلك الجلسة. يُسمح بملف واحد فقط مشترك عمداً لكل فرع، ويتبع قاعدة "آخر من يكتب هو من يربح" (last-writer-wins)؛ حيث يحدد الوكيل الذي يكتب آخراً المحتوى النهائي.
تتتبع طبقة التواجد (presence layer) كل جلسة نشطة:
- اسم الفرع
- قائمة الملفات التي يتم التعامل معها
- الطابع الزمني لآخر نشاط
عند بدء جلسة جديدة، يتم استشارة السجل. إذا كانت هناك جلسة أخرى تتعامل بالفعل مع أي من الملفات نفسها، يتلقى المطور تحذيراً قبل بدء أي عمل.
الأقفال الاستشارية مقابل الأقفال الحاجزة
تعمل ملفات الأقفال التقليدية مثل طريق مسدود: بمجرد أخذ القفل، تنتظر أي عملية أخرى حتى يتم تحريره. وإذا تعطلت الجلسة المالكة للقفل، فقد يظل القفل عالقاً إلى أجل غير مسمى، مما يضطر المطور للبحث يدوياً عن ملفات الأقفال القديمة.
أما النموذج الاستشاري فهو أكثر مرونة؛ حيث يصدر تحذيراً عند اكتشاف تعارض محتمل ولكنه لا يوقف الجلسة الجديدة. وإذا كان إدخال السجل قديماً — أي أن العملية التي أنشأته لم تعد موجودة — فإن النظام يكتفي بالتحذير فقط، تاركاً للمطور قرار المتابعة من عدمها.
كيفية تنفيذ هذا النمط
- تقسيم الحالة حسب الكاتب – امنح كل وكيل دليلاً (directory) خاصاً به للملفات المؤقتة والحالة. خصص الملفات المشتركة للبيانات العالمية حقاً وطبق قاعدة "آخر من يكتب هو من يربح" هناك فقط.
- حقن الوعي عند الإطلاق – قبل أن يبدأ الوكيل، اقرأ سجل التواجد وقارن قائمة الملفات المطلوبة بالإدخالات الموجودة. أوقف العملية أو حذر في حال وجود تداخل.
- التحقق من الحيوية عند القراءة – عند استشارة إدخال في السجل، تحقق مما إذا كان معرف العملية (process ID) المسجل لا يزال يعمل في نظام التشغيل. تخلص من الإدخالات التابعة لعمليات متوقفة.
- تفضيل الأقفال الاستشارية على الحاجزة – اترك للمطورين حق التحكم. التحذير يسمح لهم بالمتابعة أو التوقف أو الإلغاء، مما يتجنب حالة الاستعصاء (deadlock).
- تتبع حالات الانتظار – عندما يكون العديد من الوكلاء نشطين، يصبح انتباه المطور هو عنق الزجاجة. اعرض الوكلاء الذين ينتظرون مدخلات بشرية حتى يمكن إعادة ترتيب أولويات العمل.
يمكن بناء كل هذا باستخدام مجلد بسيط من ملفات JSON؛ ولا حاجة لقاعدة بيانات خارجية أو ناقل رسائل (message bus). يجعل تنسيق التخزين البسيط النظام سهل التدقيق وقابلاً للنقل عبر البيئات المختلفة.
المخاطر والآراء المعارضة
قد تجادل بعض الفرق بأن القفل الصارم يضمن السلامة: فلا يمكن لوكيلين الكتابة في نفس الملف أبداً. لكن المقابل هو انخفاض القدرة على التعافي — فالجلسات المتعطلة تترك أقفالاً يتيمة تعطل سير العمل بالكامل.
ما يجب مراقبته
إذا كنت تدير عدة مساعدات برمجة مدعومة بالذكاء الاصطناعي، فإن نمط "عدم المشاركة" الاستشاري يوفر مساراً عملياً لمنعها من التداخل في عمل بعضها البعض. من خلال عزل الحالة، والكشف المبكر عن النوايا، وترك القرار للبشر، يوازن هذا الأسلوب بين الأمان والمرونة التي تتطلبها مسارات التطوير الحديثة.