يضيف AWS AgentCore Runtime جلسات أكبر وإمكانية تركيب أنظمة الملفات

وسّعت Amazon Web Services، في 12 نوفمبر 2026، الجيل التالي من Amazon Bedrock AgentCore Runtime، وأضافت إليه جلسات أكبر للوكلاء، وفوترةً قائمة على حد أدنى أساسي ملتزم به، وإمكانية تركيب أنظمة الملفات ديناميكيًا. وتفيد AWS بأن التحديثات توفر بدءًا للجلسات أسرع بما يصل إلى 15 مرة، مع الحفاظ على العزل على مستوى الأجهزة.

أصبح إصدار بيئة التشغيل المحدّث متاحًا في مناطق AWS في أمريكا الشمالية وأمريكا الجنوبية وأوروبا وآسيا والمحيط الهادئ. ويمثل AgentCore Runtime طبقة الحوسبة المُدارة ضمن AgentCore، منصة AWS لبناء الوكلاء باستخدام أطر عمل ونماذج مختلفة؛ وتشمل المنصة الأوسع أيضًا المصادقة والتحكم في الوصول وإمكانية المراقبة.

يأتي هذا الإصدار عقب إطلاق AgentCore Runtime V2 في 18 سبتمبر 2026، الذي أتاح بدء التشغيل بالاستعادة من اللقطات واستعادة الذاكرة. وكانت AWS قد أدرجت حينها زيادة موارد الحوسبة والتخزين والتسعير الأساسي الملتزم به ضمن الميزات التي ستتوفر قريبًا؛ وتشكل هذه الإمكانات الآن جزءًا كبيرًا من التحديث، إلى جانب تركيب أنظمة الملفات.

جلسات أكبر من دون مجموعات جاهزة مسبقًا

يمكن لكل جلسة الآن استخدام ما يصل إلى 8 وحدات معالجة مركزية افتراضية و32 GB من الذاكرة، كما يمكنها دعم صور حاويات يصل حجمها إلى 10 GB. وتقول AWS إن ذلك يوفر أربعة أضعاف قدرة الحوسبة التي أتاحها الإصدار السابق، وإن الجلسات تبدأ في أقل من ثانيتين بصرف النظر عن حجم الصورة أو مستوى التزامن، ما يلغي حاجة العملاء إلى إدارة مجموعات جاهزة مسبقًا أو عناقيد مُهيأة مسبقًا لمعالجة حالات البدء البارد.

تعتمد آلية بدء التشغيل على استعادة اللقطات بدلًا من تكرار التهيئة. إذ تهيئ AgentCore بيئة حاوية سليمة مرة واحدة، ثم تحفظ حالتها بعد التهيئة وتستعيد تلك اللقطة لكل مثيل جديد؛ وبذلك لا تتكرر مهام مثل تحميل ملفات النماذج واسترجاع الإعدادات الثابتة عند كل بدء بارد.

وصف Siwei Shen، نائب رئيس الهندسة في Coinbase، النتائج في بيئة الإنتاج قائلًا: «أدى انتقالنا إلى الجيل التالي من AgentCore Runtime إلى خفض أوقات البدء البارد لجلسات وكلائنا من نحو دقيقة إلى أقل من خمس ثوانٍ، حتى خلال ذروة حركة المرور. كما أزال تأخيرات بدء التشغيل التي تتجاوز 30 ثانية، وذلك في الوقت الذي تضاعف فيه حجم وكلائنا الأسبوعي أكثر من مرة».

أفادت Mission Cloud بأن مقارنة أولية لحمل عمل الاستعلامات باللغة الطبيعية نفسه على إصداري بيئة التشغيل أظهرت بدءًا باردًا أسرع بنسبة 35% لطلبات الاستدلال، وبدءًا أسرع بنسبة 77% لفحوصات الحالة الصحية، وانخفاضًا بنسبة 17% في التكلفة المقيسة لبيئة التشغيل لكل استدعاء. ويسترجع وكيلها رؤى عن العقارات والمبيعات من دون أن يضطر المستخدمون إلى التنقل في أنظمة بيانات معقدة.

استعادة الذاكرة والفوترة الأساسية

تغيّر AWS أيضًا طريقة احتساب رسوم الذاكرة خلال فترات الخمول. إذ تستعيد بيئة التشغيل الذاكرة في غضون دقائق من تحرير الوكيل لها، وتخفض تخصيص الموارد لوكيل خامل إلى الصفر؛ وتقول AWS إن الوكلاء الذين يعملون عبر جولات متعددة تتخللها فترات توقف طبيعية قد يستهلكون ذاكرة أقل لكل جلسة بنسبة تصل إلى 68%. ويعالج ذلك ميل النموذج السابق إلى احتساب الرسوم على أساس ذروة التخصيص في الجلسة حتى بعد توقف استخدام الذاكرة.

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

أفادت Zuora بأن بيئة التشغيل الجديدة خفضت مساحة الذاكرة التي يستهلكها كل استدعاء بنحو 60% في كثير من حالات الاستخدام، مع التعامل مع حركة مرور أكبر وزمن استجابة مستقر.

التخزين والعزل وحدود النشر

تواصل كل جلسة العمل ضمن آلة Firecracker افتراضية مصغّرة (microVM) معزولة على مستوى الأجهزة، ولها هويتها الخاصة وسياسة الوصول الخاصة بها وسجل تدقيق خاص بها. ويمكن للوكلاء الآن تركيب نظام ملفات ديناميكيًا وحفظ أعمالهم فيه، مثل حاوية Amazon S3 تدعم FUSE. وتقول AWS إن البيانات تظل داخل حدود الثقة الخاصة بالجلسة طوال مدة المهمة، وتخضع لمجموعة واحدة من الضوابط، ما يوسع نطاق العزل ليتجاوز بيئة الحوسبة.

لم يُدرج تحديد نطاق مجلد التخزين لكل جلسة ضمن الإتاحة المعلنة. وتقول AWS إنه بحلول re:Invent، ستربط بيانات الاعتماد الموسومة بالجلسة كل جلسة بمجلد التخزين الخاص بها، مضيفةً بذلك مستوى تحكم أدق إلى إمكانية التركيب.

وتتضمن الوثائق الحالية لـ V2 أيضًا اختلافات تتعلق بالنشر. فما زال استخدام V2 يتطلب تفعيله اختيارًا، لأن V1 هو الإعداد الافتراضي ما لم platformVersion يُضبط على V2؛ إذ يستغرق إنشاء بيئة تشغيل V2 أو تحديثها عدة دقائق بينما تجهز AWS اللقطة، ويجب أن تُبلغ الحاوية عن سلامتها عبر /ping نقطة النهاية الخاصة بها خلال 120 ثانية. وتختلف أوقات الإعداد هذه عن زمن استجابة بدء الجلسة البارد.

يمكن أن تستمر الجلسات حتى ثماني ساعات، لكنها تنتهي بعد 15 دقيقة من عدم النشاط، أو عند بلوغ الحد الأقصى لمدة استمرارها، أو إذا أصبحت غير سليمة. وحالة الجلسة مؤقتة، ويؤدي إنهاؤها إلى تدمير الآلة الافتراضية المصغّرة ومحو الذاكرة بأمان.

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