AWS در ۱۱ نوامبر ۲۰۲۶ امولاتور AWS را منتشر کرد، یک شبیهساز محلی که بیش از ۲۰۰ سرویس ابری را پیادهسازی میکند. این اولین امولاتور ابری بهصورت عمومی در دسترس است که هر خط کد آن توسط تیمهای عاملهای خودمختار نوشته و تست شده، بدون دخالت برنامهنویس انسانی.
بستههای نصب و نحوه اجرا
- بستههای RPM و Debian برای لینوکس، ایمیجهای Docker برای macOS و ویندوز، و حالت تعبیهشده (embedded mode) برای تستهای Rust.
- هیچ کارمزد خدماتی اضافهای وجود ندارد؛ هزینههای استاندارد تنها برای منابع مستقرشده در ابر اعمال میشود.
معماری سه تیم عامل
به گزارش متیو گولدبرگ (Matthew Goldberg)، مهندس ارشد اصلی AWS، کار بین سه تیم عامل محدود (bounded agent team) تقسیم شده:
- نویسندگان تست: سناریوها را از مدلهای API عمومی استخراج و در برابر حسابهای واقعی AWS تأیید میکنند.
- یابندگان خطا: تستها را بازپخش و خرابیهای ریشهی اشتراکی را گروهبندی میکنند.
- عاملهای اصلاحکننده (fixer agent): هر مشکل را بهتنهایی برمیدارند و وصله (patch) پیشنهاد میدهند.
گولدبرگ میگوید روزانه دهها هزار تست وفاداری (fidelity test) اجرا میشود و هزاران ایراد با همزمانی صدها عامل برطرف شدهاند. هر وصله پیشنهادی باید کامپایل شود و بررسیهای خودکار استانداردهای کدنویسی، امنیت و وفاداری را بگذرد. یک عامل امنیتی مستقل تغییرات را در طول توسعه و مجدداً در خط لوله انتشار بهصورت خصمانه (adversarial) مرور میکند. این رویکرد امنیتی همخوانی دارد با نحوهی ایزولهسازی MicroVMها که در مقالهای درباره امنیت کدهای تولیدشده توسط AI توضیح داده شده است.
انتشار کد و مجوز
کد از طریق AWS CodeCommit و AWS CodePipeline حرکت کرده و در GitHub تحت تقدیم ملکی عمومی CC0 منتشر میشود، بهجز کدهای وندور که تحت Apache 2.0 هستند. مخزن درخواست ادغام (pull request) نمیپذیرد، اما کاربران میتوانند باگها و شکافهای وفاداری را از طریق Issues گیتهاب گزارش دهند.
تستهای وفاداری و مرزها
تستهای وفاداری مرزهای امولاتور را تعریف میکنند. هر تست یک گردشکار کوتاه است که در برابر حداقل دو حساب جدا شده (sandboxed account) بررسی میشود. برای عبور، امولاتور باید در هر پاسخ مطابقت دقیق داشته باشد — کد وضعیت، بدنه، کد و پیام خطای دقیق، و منابع و دادههای ایجادشده. عملیات پیادهسازینشده HTTP 501 برمیگردانند، بنابراین شکافها بلافاصله قابل مشاهدهاند.
هر انتشار شمارش عبور هر سرویس را همراه دارد، و AWS هشدار میدهد که افزودن تستها میتواند نمره را کاهش دهد حتی در حالی که امولاتور بهبود مییابد. امولاتور سیاستهای IAM یا مبتنی بر منبع را همانند AWS ارزیابی نمیکند، بنابراین درخواستهایی که AWS رد میکند ممکن است بهصورت محلی موفق شوند. بارهای کاری تولیدی (production workload) و تستهای امنیتی کاربردی خارج از دامنهاند. ابزارهای جدید مایکروسافت برای تسریع گردشکارهای توسعه، مانند آنهایی که در گزارش اخیر Azure AI و GitHub Copilot آمده، همجهت با حلقه نوشتن-اجرا-خواندن امولاتور AWS عمل میکنند.
تغییر نقش مهندس: از پیادهسازی به مشخصه و تست
سوامیناتان سیواسوبرامانیان (Swaminathan Sivasubramanian) این را با Alf، یک سرویس قفل توزیعشده اولیه Amazon، مثال زد. موتور تکرار اصلی حدود چهار ماه طول کشید. یک بازسازی با Kiro در ابتدا چهار شب تحت نظارت مصرف کرد چون عامل راهی برای بررسی نتایج نداشت (write-run-read loop). پس از اینکه سیواسوبرامانیان یک مشخصه و محیط تست فراهم کرد، بازسازی حدود دو ساعت طول کشید. AWS Emulator آن درس را به یک محصول تحویلشده تبدیل میکند: عاملها پیادهسازی را تولید و تعمیر میکنند در حالی که مهندسان اجرای رفتار قابلقبول را از طریق دروازه ادغام (merge gate) خودکار میسازند.
حلقه نوشتن-اجرا-خواندن برای عاملهای کدنویسی
برای عاملهای کدنویسی، امولاتور زیرساخت AWS را در یک حلقه نوشتن-اجرا-خواندن (write-run-read loop) قرار میدهد. یک عامل میتواند یک منبع بسازد، نتیجه را بازبینی کند و کد خود را بازنگری کند بدون انتظار برای استقرار در یک منطقه AWS (AWS Region). خط لولههای یکپارچهسازی مداوم و سرورهای توسعه اکنون میتوانند به جای نقاطپایانی زنده AWS، منابع شبیهسازیشده را هدف قرار دهند.
گام بعدی شما
- بسته امولاتور را روی ماشین توسعه نصب کنید و یک گردشکار ساده S3 یا DynamoDB را بهصورت محلی اجرا کنید تا سرعت حلقه بازخورد را بسنجید.
- اگر عامل کدنویسی (مانند Cursor، Copilot Agent یا Kiro) استفاده میکنید، متغیرهای محیطی را به نقطهپایانی محلی هدایت دهید و تستهای واحد را بدون هزینه ابری بگذارید.
- گزارشهای وفاداری هر سرویس را در مخزن گیتهاب رصد کنید؛ سرویسهایی که نمره پایینتری دارند برای مشارکت در تستنویسی اولویتدارند.




گفتگو