Spring AI وBedrock AgentCore: وكيل Java في بيئة الإنتاج بتعليق توضيحي واحد ونقطتي وصول

إذا كان لديكم فريق مؤسسي يعمل بلغة Java، فإن قصة الوكلاء تبدو عادةً على هذا النحو: يبني أحدهم عرضاً تجريبياً بلغة Python، فيعجب الجميع، ثم يتبيّن أنه لا يتلاءم مع خط CI/CD ولا مع المراقبة ولا مع نموذج الوصول لديكم. في تحليل جديد، تقترح AWS مساراً آخر: عدم تغيير التقنيات المستخدمة، بل ربط الوكلاء عبر Spring AI وBedrock AgentCore.

ما الفرق بين الوكيل واستدعاء النموذج

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

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

كيف يبدو ذلك في الشيفرة

AgentCore منصة مُدارة من AWS غير مرتبطة بإطار عمل أو بنموذج بعينه. تتطلب بيئة التشغيل من خدمتكم نقطتي وصول فقط: POST /invocations للطلبات (JSON أو SSE بالبث) وGET /ping لفحص الحالة. وإذا كانت المهمة طويلة، فعلى الخدمة أن تردّ بـ HealthyBusy، وإلا فقد تقلّص بيئة التشغيل حجمها.

يُخفي Spring AI AgentCore SDK هذا العقد خلف التعليق التوضيحي @AgentCoreInvocation: فهو ينشئ نقطتي الوصول بنفسه، ويُسلسل JSON، ويُنسّق SSE. ويمكن للخدمة نفسها تقديم REST لواجهة React، فلا حاجة إلى واجهة خلفية منفصلة للوكيل.

وتُربط الأدوات بالأسلوب نفسه المعتاد في Spring. تضعون @Tool مع وصف على الدالة، وتسجّلونها في ChatClient عبر defaultTools، ويقرر النموذج بنفسه متى يستدعيها. وللحصول على إجابة مهيكلة تطلبون Java record، وللمستندات ترفقون الملف برسالة المستخدم. وتُربط الذاكرة عبر advisors: وهي معترضات تضيف السياق إلى الـ prompt قبل التوجّه إلى النموذج. الجزء الخاص بالذاكرة مقطوع في النص الأصلي، لذا ارجعوا إلى المصدر للاطلاع على التفاصيل.

من وكيل واحد إلى عدة وكلاء

المثال الثاني نظام لمعالجة المستندات بخمسة متخصصين: محامٍ، ورهن عقاري، وتأمين، وضرائب، ووكيل عام. يحدد المصنّف نوع المستند ويمرّره إلى المتخصص المناسب، الذي يعيد JSON مهيكلاً مع تقدير للثقة. ثم تقرر قواعد SpEL من ملف application.yml ما يجب فعله: إرسال ALERT، أو الحظر، أو إرسال المستند إلى مراجعة يدوية.

هناك ثلاثة أنماط: الموجّه (توزيع فقط دون منطق مجالي)، والمقيِّم (قواعد أعمال فوق الإجابات)، والتوزيع المتوازي (fan-out). ولم يُنفَّذ الأخير في الحل الأساسي: إذ تجري المعالجة الدفعية بالتتابع. ولو أُضيف fan-out لتحدّد زمن التحليل بأبطأ وكيل، لا بمجموع جميع الاستدعاءات.

القيود

أولاً: هذه مادة من AWS، وهي مصمّمة لمنظومة AWS. فـ Bedrock Converse API وAgentCore وGraviton ووحدات Terraform كلها في حزمة واحدة. ولا يناقش المقال إمكانية النقل إلى سحابات أخرى.

ثانياً: جرى اختبار المخرجات المهيكلة في Java record على Claude Sonnet 4.5. يضيف Spring AI المخطط إلى الـ prompt ويحلّل الإجابة، لكن النموذج يعيد أحياناً بيانات لا تطابق المخطط. وللصرامة يلزم مزوّد يتحكم أصلاً بالمخطط، أو تحقق مع إعادة الطلب.

ثالثاً: عند استدعاء الأدوات بعدة معاملات، ينصح المؤلفون بجمع الإجابة عبر call() الحاجب، ثم تقطيعها إلى chunks ليكون ربط المعاملات موثوقاً. وهذا يقلّل من فائدة البث الحقيقي.

ما العمل

إذا كانت منظومتكم قائمة على Java وكنتم بالفعل على AWS، فابدؤوا بمساعد السفر: وكيل واحد وأدوات وذاكرة. تحققوا من سلوك نموذجكم في المخرجات المهيكلة، ثم أضيفوا الموجّه والقواعد. والمتطلبات صارمة: JDK 21 وSpring Boot 4.1 مع Spring AI 2.0 وTerraform 1.5+ وDocker مع Buildx لصورة ARM64. تأكدوا مسبقاً من أن مشروعكم سيتحمّل هذه الترقية.