حزمة «كوبايلوت» لجافا تفتح مساراً مباشراً لبناء الوكلاء داخل تطبيقات المؤسسات

في تطبيقات المؤسسات، لا يبدأ سؤال الذكاء الاصطناعي من النموذج وحده، بل من المكان الذي يعيش فيه التطبيق أصلاً. لهذا تبدو حزمة GitHub Copilot SDK for Java محاولة لتغيير نقطة الدخول: بدلاً من أن يتعامل مطور جافا مع الذكاء الاصطناعي عبر إطار عمل مفروض عليه، تقول GitHub إن الحزمة تتيح تشغيل جلسات الوكيل، وتسجيل الأدوات، وإرسال المطالبات، واستقبال الاستجابات المهيكلة من داخل كود جافا على الخادم.

الحزمة متاحة كاعتمادية Maven بإصدار معاينة 1.0.7-preview.1. وتعرض GitHub مثالاً مبنياً على Jakarta EE 11، حيث يعالج وكيل مستقل كل استفسار عقاري ضمن مسار يضم التحقق والبحث وكتابة التقرير. المثال ليس إعلاناً عن منتج عقاري، بل وسيلة لإظهار كيف يمكن لجلسات منفصلة أن تعمل بالتوازي على خيوط افتراضية، بينما يدفع الخادم تحديثات الحالة إلى المتصفح عبر Jakarta WebSocket.

جافا لا تغادر بيئتها المعتادة تصف GitHub واجهة الحزمة بأنها قريبة من أساليب جافا المألوفة، مثل CompletableFuture والتعليقات التوضيحية والدوال اللامبدا والخيوط الافتراضية. وفي المثال، يستطيع المطور تعريف أداة يستدعيها النموذج عبر التعليمة البرمجية @CopilotTool، ثم تصف @CopilotToolParam الوسائط التي تقبلها الأداة. وتقول GitHub إن الحزمة تتولى توليد مخطط JSON وتحليل الوسائط وتمرير الاستدعاء، بينما يكتب المطور طريقة جافا عادية.

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

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

المرونة لا تعني فتح كل الأبواب تؤكد GitHub أن الحزمة يمكن استخدامها مع مزودي نماذج مباشرين، منهم OpenAI وAzure وAnthropic ونقاط نهاية متوافقة مع OpenAI، عبر إعداد مزود ومفتاح خاص بالمطور. كما تعرض تشغيل العميل في وضع خال من تكامل بيئة التطوير، بحيث يتواصل مباشرة مع Copilot CLI. لكن المثال نفسه يضع حداً مهماً: إعداد قائمة الأدوات المتاحة للجلسة يسمح بإتاحة الأدوات المخصصة، واختيار web_fetch فقط من الأدوات المدمجة، بدلاً من كشف كل ما قد يشمل الوصول إلى الملفات أو تنفيذ أوامر الصدفة.

وتذكر GitHub أن إعداد APPROVE_ALL مناسب للعرض والتطوير فقط، أما الإنتاج فيحتاج إلى سياسة صلاحيات حقيقية تتحقق من الأدوات المسموح للوكيل باستدعائها. هنا تكمن القيمة العملية للخبر: الحزمة لا تقدم «ذكاءً» مجرداً لجافا، بل ترسم نقاطاً صريحة ينبغي أن يقرر فيها فريق التطبيق ما الذي يراه الوكيل، وما الذي يستطيع فعله، وأين تنفذ استدعاءاته.

سياق الخادم جزء من التصميم في نموذج Jakarta EE، تستخدم GitHub مصنع خيوط تديره الحاوية مع خاصية الخيوط الافتراضية، ثم تمرر منفذاً إلى الحزمة. الهدف، وفق الشرح، هو أن تحمل ردود استدعاء الأدوات سياق الحاوية، بما فيه CDI وJNDI والمعاملات. لذلك يمكن لطريقة أداة أن تحقن مستودع JPA وتنفذ استعلاماً ضمن السياق الصحيح، بدلاً من أن تصبح طبقة الوكيل جزيرة منفصلة عن التطبيق المؤسسي. وتورد GitHub كذلك استخدام CDI للعميل الوحيد، وJakarta Data لاستعلامات البيانات، وJakarta Faces لتحديثات الواجهة.

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