أضافت AWS إلى Bedrock AgentCore تخزينًا دائمًا للجلسات وتشغيل أوامر shell

أضافت AWS تخزينًا دائمًا للجلسات وتنفيذ أوامر shell إلى Bedrock AgentCore

أوضحت AWS كيفية حل مشكلتين نموذجيتين في بيئات الوكلاء في Amazon Bedrock AgentCore Runtime: فقدان الملفات بعد إيقاف الجلسة وتنفيذ الأوامر المتوقعة مثل الاختبارات أو عمليات git من خلال النموذج نفسه. تسمح الإمكانيات الجديدة بحفظ حالة عمل الوكيل بين إعادات التشغيل وتنفيذ أوامر shell مباشرة في بيئته.

ما يتغير

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

المشكلة الثانية هي الإجراءات الحتمية. عندما تحتاج ببساطة إلى تشغيل مجموعة اختبارات أو linter أو أمر git push، لا معنى لإرسالها عبر LLM. يضيف النموذج زمن الوصول وتكاليف الرموز والالتباس غير الضروري حيث يكون الأمر معروفًا بالفعل مقدمًا. تقترح AWS تقسيم الأدوار: يتعامل الوكيل مع التفكير والتعديلات على الكود، بينما تقوم المنصة بتنفيذ الأوامر مباشرة في نفس الجلسة. بالنسبة لسيناريوهات الإنتاج، يبدو هذا التقسيم للمسؤوليات عمليًا بكثير.

كيف يعمل

الميزة الأولى — تخزين الجلسة المُدار — حاليًا في حالة المعاينة العامة. عند إنشاء runtime، يمكنك تحديد دليل دائم، مثل مسار داخل مجلد /mnt. كل شيء يكتبه الوكيل في هذا المجلد يتم الاحتفاظ به بين الإيقاف والاستئناف، حتى لو تم تدمير microVM نفسها وتم تشغيل بيئة حسابية جديدة عند الإطلاق التالي. في الوقت ذاته، منطق الحفظ مدمج في runtime، لذلك لا يحتاج الوكيل إلى كود منفصل للنقاط الفاصلة أو التسلسل أو تحميل الملفات يدويًا إلى التخزين الموضوعي.

توضح AWS سيناريوًا قريبًا من التطوير الحقيقي: في اليوم الأول، يقوم الوكيل بتنزيل المشروع وفك ضغطه وإعداد المتطلبات والتبعيات، وفي اليوم الثاني يستمر في العمل مع نفس runtime-session-id. يرى نفس الكود المصدري ومجلد node_modules وأرتفاكتات البناء وسجل .git دون إعادة تهيئة.

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

البيئة الحسابية بالأمس قد اختفت بالفعل، لكن نظام الملفات تم الحفاظ عليه.

الميزة الثانية — InvokeAgentRuntimeCommand. تنفذ أوامر shell مباشرة داخل جلسة AgentCore Runtime النشطة وتدفق stdout و stderr أثناء التنفيذ. تفصيل مهم: الأمر لا ينفذ في عملية sidecar منفصلة ولا عبر orchestrator خارجي، بل في نفس الحاوية وبنفس نظام الملفات حيث يعمل الوكيل. إذا كتب الوكيل ملفًا في مجلد العمل، يمكن للأمر قراءته واختباره أو تأكيده على الفور. في الوقت ذاته، يبدأ كل أمر كعملية bash منفصلة: بدون جلسة shell مشتركة وبدون نقل سجل الأوامر وبدون حفظ متغيرات البيئة بين الاستدعاءات.

حيث سيكون هذا مفيدًا

بالنسبة لفرق الهندسة، هذا المزيج مفيد بشكل خاص في السيناريوهات حيث لا يقوم الوكيل فقط بالرد في الدردشة، بل يقود فعلاً دورة عمل على قاعدة أكواد. تؤكد AWS بشكل خاص على أن أوامر shell تُستخدم بشكل أفضل حيث يجب أن تكون النتيجة قابلة للتكرار والملاحظة بدقة. بعبارة أخرى، يقوم النموذج بالتفكير والتعديلات، بينما يتم تسليم جميع الخطوات المتوقعة للتحقق والتسليم للمنصة بدون استدعاءات أدوات غير ضرورية عبر LLM.

• تشغيل الاختبارات بعد تغييرات الوكيل: npm test و pytest والتحققات الأخرى
• عمليات git: إنشاء فرع والتزام وdiff بدون منطق التحكم في الإصدار داخل LLM
• تحضير البيئة: استنساخ المستودع وتثبيت الحزم وتكوين أدوات البناء
• بوابات التحقق: linters وفاحصي النوع وماسحات الأمان قبل الالتزام
• تصحيح أخطاء البيئة: التحقق من الحزم المثبتة والقرص والعمليات أثناء فشل الوكيل

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

ما يعنيه هذا

تجعل AWS Bedrock AgentCore أقرب لا إلى chatbots، بل إلى بيئة كاملة لتطوير الوكلاء. إذا كان الوكيل في السابق يفقد السياق على مستوى الملف ويتطلب تكاملًا خارجيًا للاختبارات وأوامر git، فإن المهمتين الآن يتم التعامل معهما ضمن runtime واحد. بالنسبة للفرق التي تبني وكلاء الترميز، هذا يقلل من التنسيق غير الضروري ويجعل دورة "الوكيل يكتب — المنصة تتحقق — يتم حفظ العمل" أكثر عملية بشكل ملحوظ. خاصة حيث تكون عملية متعددة الأيام للعمل على نفس المستودع مهمة.