AWS تطلق مُحاكيًا محليًا كتبته بالكامل وكلاء ذكاء اصطناعي مستقلون

أصدرت AWS محاكي AWS في 11 نوفمبر 2026، وهو محاكي محلي متاح عموماً، بُني استناداً إلى 438 نموذجاً لواجهات AWS البرمجية تغطي أكثر من 200 خدمة. كتبت وكلاء ذكاء اصطناعي مستقلون شفرته واختبروها، ما أتاح للمطورين ووكلاء البرمجة وسيلة لاختبار واجهات AWS البرمجية على أجهزتهم من دون حساب AWS.

يتصل كل من AWS CLI وحزم تطوير البرمجيات من AWS ووكلاء البرمجة عبر نقطة نهاية محلية تستخدم HTTPS، وتتيح لهم استخدام واجهات البرمجة نفسها التي يستخدمونها في السحابة. وتعيد متغيرات البيئة توجيه هذه الأدوات إلى جهاز المستخدم، من دون تغيير شفرة التطبيق. ويشرح إعلان AWS عن الإطلاق تفاصيل حزم RPM وDebian لنظام Linux، وDocker على macOS وWindows، ووضع التضمين لاختبارات Rust. لا توجد رسوم إضافية على الخدمة، مع أن العملاء يواصلون دفع تكلفة موارد AWS التي ينشرونها في السحابة.

بالنسبة إلى وكلاء البرمجة، يضع المحاكي بنية AWS التحتية ضمن دورة من الكتابة والتنفيذ والقراءة: إذ يمكن للوكيل إنشاء مورد، وفحص النتيجة، ومراجعة شفرته من دون انتظار نشرها في إحدى مناطق AWS. كما يدرج توثيق AWS خوادم التطوير والتكامل المستمر ضمن البيئات المناسبة للمحاكي، بحيث تُوجَّه الطلبات إلى موارد محاكاة بدلاً من AWS.

ثلاثة فرق من الوكلاء تبني الشفرة وتحافظ عليها

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

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

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

تنتقل التغييرات بعد ذلك عبر AWS CodeCommit وCodePipeline قبل نشرها على GitHub. ويتيح المستودع العام الاطلاع على سجل التغييرات ومجلدين منفصلين للمشكلات التي حُلّت وتلك التي لم تُحل بعد والمتعلقة بمطابقة السلوك. ونشرت AWS الشفرة بموجب ترخيص CC0، وهو إقرار بوضعها في الملكية العامة، باستثناء شفرة الموردين المنشورة بموجب ترخيص Apache 2.0؛ ولا يقبل المستودع طلبات السحب، لكن يمكن للمستخدمين الإبلاغ عن الأخطاء وفجوات المطابقة عبر قسم GitHub Issues.

درجات المطابقة ترسم حدود الإمكانات

اختبار المطابقة هو سير عمل قصير يُتحقق منه باستخدام AWS الحقيقية. ولكي يجتاز المُحاكي الاختبار، يجب أن تطابق استجابته لكل استدعاء الاستجابةَ الأصلية، بما في ذلك رمز الحالة ومتن الاستجابة ورمز الخطأ ورسالته حرفيًا، فضلًا عن الموارد والبيانات التي ينشئها سير العمل. وتُرجع العمليات غير المنفذة رمز HTTP 501 (غير منفذ)، فتظهر حالات الإخفاق فورًا. ويتضمن كل إصدار أعداد الاختبارات المجتازة لكل خدمة، وتحذر AWS من أن إضافة اختبارات قد تخفض الدرجة حتى مع تحسن المُحاكي.

جرى التحقق من كل اختبار في مجموعة التقييم العامة باستخدام حسابَين على الأقل من حسابات AWS المعزولة في بيئة اختبار، ويوضح المستودع أن السلوك الذي لا يغطيه اختبار لم يُتحقق منه.

لكن هذه الدرجات لا تجعل المُحاكي بيئةً لاختبار الأمان. فهو لا يقيّم AWS Identity and Access Management (IAM) أو السياسات القائمة على الموارد بالطريقة التي تعتمدها AWS، ولذلك قد ينجح محليًا طلبٌ ترفضه AWS. ويقتصر الاستخدام المدعوم على البناء والاختبار؛ أما أعباء العمل الإنتاجية واختبارات أمان التطبيقات فهما خارج النطاق. وصُمم كل مثيل لحساب واحد ومنطقة واحدة، ويحتفظ بالموارد في الذاكرة ويحذفها عند إيقافه.

يتحول العمل الهندسي نحو المواصفات والاختبارات

في منشور الإطلاق، وصف سواميناثان سيفاسوبرامانيان دور المهندس بأنه تحديد ما ينبغي بناؤه، وإعداد المواصفات والاختبارات وبوابات الدمج التي تحدد صحة العمل، فيما يكتب الوكلاء الشفرة ويتحققون منها.

ويقدم تشبيهه بخدمة Alf، وهي خدمة مبكرة من Amazon للأقفال الموزعة، مثالاً ملموساً. فقد استغرق بناء محرك التكرار الأصلي نحو أربعة أشهر. وقال سيفامانيثان سيفاسوبرا مانيان إن إعادة بناء الخدمة باستخدام Kiro استغرقت في البداية أربع ليالٍ تحت الإشراف، لأن الوكيل لم يكن يملك وسيلة للتحقق من نتائجه؛ وبعد أن زوده بمواصفات وبيئة اختبار، استغرقت إعادة البناء نحو ساعتين.

يحوّل AWS Emulator هذا الدرس إلى منتج مطروح للاستخدام: إذ ينشئ الوكلاء التطبيق البرمجي ويصلحونه، فيما يحدد المهندسون السلوك المقبول ويؤتمتون إنفاذه. ويتوقف نطاق استخدامه عمليًا الآن على توسع مجموعة الاختبارات العامة وفجوات المطابقة المتبقية، مع استمرار الحاجة إلى AWS الحقيقية للتحقق الأمني والتحقق في بيئة الإنتاج.