سبير تقدّم ثلاث أدوات مفتوحة المصدر لوكلاء الذكاء الاصطناعي وتطبيقات JVM

كتب وكيل ذكاء اصطناعي الكود، لكنه فقد قيود البنية المعمارية. وحدّثت إحدى الخدمات طلبًا ثم تعطلت قبل إرسال الحدث، فلم يعلم النظام المجاور بشيء. يعرض ملخص سبير ثلاث أدوات مفتوحة المصدر لمثل هذه المشكلات الهندسية: HG SDLC وSpring AI GigaChat وSchedulex. وتغطي هذه الأدوات جوانب مختلفة: نقل السياق بين الوكلاء، وربط النموذج بالتطبيق، وتنفيذ المهام الخلفية بعد الأعطال.

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

HG SDLC: تمرير المهمة إلى الوكيل مع سياقها

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

يقترح HG SDLC وصف تسلسل العمل في رسم بياني بصيغة YAML. يضم عُقدًا تحمل مهامّ للوكلاء، وفحوصات آلية، ونقاطًا يتخذ فيها الإنسان القرار. ويحتفظ المنسّق (orchestrator) بالسياق والمخرجات وسجل التنفيذ، ويدير الانتقالات، ويتيح إعادة العمل إلى مرحلة سابقة.

وبحسب وصف الفريق، يعمل الأداة فوق وكلاء البرمجة المتوافقين مع Agent Client Protocol. وللتشغيل المحلي يلزم Java 21 وNode.js 22 وPostgreSQL ووكيل متوافق. وهذا مكوّن مستقل في البنية التحتية سيتعيّن إعداده وصيانته أيضًا.

يقدّر المؤلفون الزيادة في كفاءة التطوير الناتجة عن الجمع بين الوكلاء والتطوير القائم على المواصفات وHG SDLC بنسبة 16–30%. ولا يستطيعون عزل مساهمة المنسّق نفسه. لذا فإن اعتبار هذا الرقم وعدًا بتسريع عمل فريقك سابق لأوانه. وأول ما يجب اختباره: كم من عمليات تمرير السياق اليدوية تختفي فعلًا.

Spring AI GigaChat: دمج النموذج في تطبيق قائم

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

صُمّم Spring AI GigaChat كـ Spring Boot Starter، ويربط واجهة GigaChat API بواجهات Spring AI. يتعامل التطبيق مع النموذج عبر ChatClient، وتساعد المكونات المرتبطة في المنظومة على تنظيم العمل مع المستندات وسجل الرسائل والأدوات.

ومن السيناريوهات الواضحة مساعد للوثائق الداخلية يجيب الموظف ويستدعي عند الحاجة دالة من التطبيق. تبقى منطق الأعمال كود Java، ويمر التكامل مع النموذج عبر Spring AI. كما يصف المقال الوسم @GigaTool لتعريف الدوال المتاحة للنموذج.

قبل الربط يجب التحقق من توافق إصدارات الـ Starter وSpring Boot وSpring AI. ويشير المؤلفون بشكل منفصل إلى تأثير تغييرات الواجهة البرمجية على التكامل. كما أن المكتبة المفتوحة لا تُغني عن إعداد الوصول إلى GigaChat API والثقة بشهادات الخادم.

Schedulex: النجاة من إعادة التشغيل والحفاظ على اتساق البيانات

تعالج الأداة الثالثة العمل الخلفي على JVM. المثال الرئيسي: تغيّر الخدمة حالة الطلب وتنشئ مهمة إرسال الحدث في معاملة واحدة ضمن قاعدة بيانات مشتركة. وعند التراجع لا يُحفظ أي من التغييرين. وبعد إتمام الالتزام (commit) بنجاح يبقى سجل المهمة في القاعدة حتى لو أُعيد تشغيل التطبيق.

يقدّم Schedulex مهامّ منفردة، ورسومًا بيانية للعمليات، وCodeFlow، وهو وصف للعملية بكود عادي مع شروط وانتظارات وفروع متوازية. وبحسب المؤلفين، تعتمد استعادة CodeFlow على سجل نتائج الخطوات وعلى الحالة المخزنة في القاعدة. وعند تحديث التطبيق يجب مراعاة توافق الكود الجديد مع السجل المحفوظ.

حدّ الضمان جوهري: معاملة القاعدة لا تجعل استدعاء HTTP خارجيًا ذريًا. فإذا عالج المستلم الطلب ولم يتمكن المرسل من تسجيل النجاح، فقد تؤدي إعادة المحاولة إلى تكرار. ولذلك تحتاج العمليات الخارجية إلى خاصية العودية الآمنة (idempotency)، أي المعالجة الآمنة للطلب المكرر.

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

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