إذا كنت تلاحظ أن AgentCore Runtime يعامل كل طلب كأنه يبدأ جلسة جديدة، فهذه ليست مشكلة في إعدادك، بل هو الطريقة التي يعمل بها النظام حسب الوثائق.
عندما تستخدم وضعية بلا حالة (stateless) عبر بروتوكول MCP، فإن AgentCore يقوم تلقائياً بإنشاء معرف جلسة فريد (Mcp-Session-Id) في كل مرة يصل طلب جديد بدون معرف مسبق. يتم توجيه الطلبات إلى MicroVM بناءً على هذا المعرّف، ويُفترض أن يرسل العميل هذا المعرّف مع كل طلب لاحق ليضمن استمرارية الجلسة. إذا لم يُرسل المعرّف، يُعتبر الطلب بمثابة جلسة جديدة ويتم إنشاء MicroVM جديدة، مما يؤدي إلى تكرار هذه العملية مع كل طلب مستقل.
لذلك، إذا بدأ ChatGPT كل تفاعله مع أدوات مستقلة بدون إرسال المعرّف، فإن AgentCore يتعامل معه كجلسة جديدة ويخلق MicroVM جديدة في كل مرة، وهكذا يتكرر الأمر.
هل يمكن إيقاف تخصيص MicroVM للجلسات؟
للأسف، لا يوجد خيار واضح لتعطيل هذه الميزة. معرف الجلسة هو المفتاح الرئيسي لتوجيه الطلبات، ولم أجد إعداداً رسمياً يسمح بمشاركة الطلبات عبر جلسات بدون معرفة المعرّف.
هل يمكن للطلبات المستقلة إعادة استخدام نفس الموارد بدون أن يرسل العميل المعرّف؟
عادة، لا يمكن ذلك بشكل مباشر، إلا أن الحل العملي هو أن يزوّد وكيلك (Proxy) هذا المعرّف بشكل تلقائي. إذا كنت تستخدم CloudFront أمام AgentCore، يمكنك إعداد خدمة تزويد المعرّف في كل طلب قبل أن يصل إلى AgentCore.
أما بخصوص إصدار MCP 2026-07-28، فالمستندات تشير إلى استخدام نمط طلبات متعددة (MRTR) مع الحفاظ على الحالة عبر مخزن خاص بك باستخدام معالجات الحالة المعرفّة. ومع ذلك، فإن المستندات توضح أن التوجيه يعتمد على معرف الجلسة، وليس هناك شرح واضح لكيفية التعامل مع العملاء الذين لا يُرسلون هذا المعرّف. صحيح أن هؤلاء العملاء سيبدأون جلسات جديدة دائماً، لذا من الأفضل طلب دعم AWS أو تقديم طلب ميزة لتمكين ذلك.
هل يمكن أن يفيد استخدام Gateway لـ AgentCore؟
نعم، إذا قمت بنقل الأدوات إلى خدمات Lambda خلف API Gateway، فإن كل استدعاء للأداة يصبح عملية Lambda عادية دون الحاجة إلى MicroVM مرتبطة بجلسة. هذا غالباً يكون أقل تكلفة وأكثر تبسيطاً، لأنه ببساطة يعمَل بشكل لا حالة له. لكن، إذا حاولت ربط Gateway بخادم MCP الحالي، فلا يوجد توثيق واضح حول كيفية تعيين معرف الجلسة فيه، لذا لا تتوقع أن يحل المشكلة.
إليك بعض الحلول المقترحة التي تؤثر بشكل كبير على المشكلة:
أولاً، قم بإضافة معرّف جلسة ثابت عند استخدام CloudFront
استخدام وظيفة CloudFront أو Lambda@Edge لتعيين معرّف جلسة فريد عند عدم وجوده. على سبيل المثال، يمكنك توليد المعرّف عبر تجزئة معرف المستخدم من توكن Bearer، ثم أخذ أول 36 رقم سداسي منه. بهذه الطريقة، يحصل كل مستخدم على جلسة مستقرة، ويظل معزولاً عن الآخرين، مع الحفاظ على أمان التحقق من المستخدم بواسطة JWT من AgentCore.
عند اختبار هذا الحل، تأكد من:
- أن النقل بدون حالة (stateless) يقبل المعرّف المرسل من العميل، وليس فقط المعرّف الذي يولده AgentCore.
- أن طول معرف الجلسة يتجاوز أو يساوي 33 حرفاً، لضمان التوافق.
- أن تتأكد من عمل الطلبات المتزامنة ضمن جلسة واحدة بشكل صحيح، من خلال اختبار الضغط.
- إذا كان المستخدم يرسل طلبات كثيرة ويشبع قدرات MicroVM، فافكر في إضافة بادئة أو تقسيم الطلبات عبر عدة معرفات، مثل
hash(sub) + (n % 4).
ثانياً، قلل حجم ذاكرة heap في GraalVM native-image
قم بتعيين حد أقصى لذاكرة heap، مثل -Xmx256m عند التشغيل، أو استخدم -R:MaxHeapSize=... عند الإعداد. وتفقد استخدام الذاكرة عبر CloudWatch للتحقق من أن الطلبات لا تستهلك أكثر من اللازم.
ثالثاً، قلل وقت انتهاء صلاحية الجلسة الخاملة (idleRuntimeSessionTimeout)
لأنه في النظام بلا حالة، الجلسات الخاملة لا قيمة لها، وتقليل الوقت إلى 60 ثانية يعتبر غير مخاطرة وغالباً مفيد.
رابعاً، استفد من خاصية تحرير الذاكرة الخاملة في AgentCore
النسخة الثانية من AgentCore يُفترض أنها تفرغ الذاكرة غير المستخدمة تلقائياً، وإذا كنت تستخدم هذا الإصدار، فإن الحلول السابقة ستكون كافية لتحسين الأداء وتقليل استهلاك الموارد.
وفي حال واجهت صعوبات مع تصميم الوكيل (Proxy) أو استفسارات أكثر عن إدارة الجلسات، فمن الأفضل أن تعتمد على Gateway مع أدوات Lambda، مع الاستمرار في استخدام AgentCore للمصادقة والنقطة النهائية لـ MCP.
باتباع هذه الحلول، يمكنك تحسين طريقة إدارة الجلسات وتقليل مشكلة إنشاء كل طلب لجلسة جديدة، مما يسرع أدائك ويقلل من استهلاك الموارد.