GitAgent يقترح صيغة موحّدة لوكلاء الذكاء الاصطناعي عبر LangChain وAutoGen وClaude Code

قُدِّم GitAgent بوصفه صيغة مفتوحة المصدر (open-source) لوكلاء الذكاء الاصطناعي، تهدف إلى إنهاء الارتباط بإطار عمل بعينه. تقوم الفكرة على وصف الوكيل مرة واحدة في مستودع Git، ثم تصديره إلى LangChain وAutoGen وClaude Code وOpenAI Assistants وCrewAI دون إعادة كتابة منطقه الأساسي.

لماذا السوق مجزّأ

يعمل مطورو وكلاء الذكاء الاصطناعي اليوم في عالم من الأنظمة غير المتوافقة. فلكل من LangChain وAutoGen وCrewAI وOpenAI Assistants وClaude Code أسلوبه الخاص في وصف دور الوكيل وتخزين الذاكرة وربط الأدوات وإدارة تنفيذ المهام. وعمليًا تنتج عن ذلك مشكلة بسيطة لكنها مكلفة: فبمجرد أن يختار الفريق منظومة واحدة، يتحول الانتقال إلى منظومة أخرى في الغالب إلى إعادة بناء النظام من الصفر، أو إلى طبقة معقّدة من الحلول الترقيعية فوق الشيفرة القديمة.

يحاول GitAgent نقل «شخصية» الوكيل وبنيته من بيئة تشغيل (runtime) محددة إلى طبقة مستقلة. فبدلًا من إبقاء التعليمات والقواعد والذاكرة ومجموعة المهارات داخل إطار عمل واحد، يقترح المشروع جمعها في بنية ملفات موحّدة داخل مستودع Git. ويقارن مطورو المشروع هذا النهج صراحةً بـ Docker: تصف الكيان أولًا بصيغة مشتركة، ثم تقرر لاحقًا أين وكيف تشغّله.

كيف يعمل GitAgent

لا يقوم GitAgent على محرك تنسيق (orchestration engine) جديد، بل على مواصفة قائمة على الملفات وأداة سطر أوامر (CLI). يُوصَف الوكيل بوصفه مجلدًا من الملفات المقروءة للبشر، يتولى كل منها طبقة مستقلة من السلوك. ومن شأن ذلك تسهيل الصيانة والعمل الجماعي وتدقيق التغييرات والانتقال بين الأدوات المختلفة.

• agent.yaml — ملف البيان الرئيسي، ويتضمن النموذج والإصدارات والتبعيات وإعدادات البيئة
• SOUL.md — هوية الوكيل: الدور والنبرة والأسلوب والتعليمات الأساسية
• DUTIES.md — المهام والقيود، بما في ذلك فصل الأدوار
• skills/ وtools/ — المهارات والأدوات التي ينفّذ الوكيل إجراءاته من خلالها
• memory/ — الذاكرة في ملفات مقروءة مثل context.md وdailylog.md

الفكرة المحورية أن حالة الوكيل لم تعد مخفية في صيغة داخلية خاصة بمكتبة ما، أو في قاعدة بيانات مبهمة. فإذا حدّث الوكيل ذاكرته أو غيّر قواعده أو اكتسب مهارة جديدة، أمكن الاطلاع على هذه التغييرات كاختلاف (diff) عادي في Git. وبذلك يحصل الفريق على آليات التطوير المألوفة: الفروع وطلبات الدمج (pull request) والمراجعة وسجل التعديلات، إضافة إلى التراجع السريع عبر git revert إذا انحرف السلوك عن المسار المطلوب أو بدأ الوكيل يبتعد عن دوره الأصلي.

التصدير والرقابة

أبرز ميزة عملية في GitAgent هي الأمر export، الذي يحوّل المواصفة نفسها إلى صيغة المنظومة المطلوبة. وتذكر المادة خمس وجهات: OpenAI Assistants وClaude Code وLangChain أو LangGraph وCrewAI وAutoGen. أي أن بإمكان المطوّر، من الناحية النظرية، الاحتفاظ بمنطق العمل الخاص بالوكيل وتغيير طبقة التنفيذ فقط بحسب المهمة، بدلًا من إعادة كتابة الذاكرة والتعليمات والأدوات لكل منظومة على حدة.

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

ويولي المشروع اهتمامًا خاصًا بالامتثال (compliance) في القطاعات الخاضعة للتنظيم. إذ يدعم GitAgent نموذج فصل المهام (Segregation of Duties)، الذي يتيح الفصل الصريح بين أدوار maker وchecker وexecutor. وقبل النشر، يُفترض أن يتحقق الأمر validate مما إذا كان وكيل واحد قد حصل على صلاحيات مفرطة. ويكتسب هذا أهمية خاصة في السيناريوهات المالية والقانونية، حيث لا ينبغي أن يبادر المنفّذ نفسه إلى إجراء حرج ويصادق عليه دون فحص إضافي.

ماذا يعني ذلك

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