داکر Cloud Sandboxes را معرفی کرده و محیط مبتنی بر microVM خود برای coding agentها را از لپتاپ توسعهدهنده به زیرساخت ابری مدیریتشدهٔ Docker برده است. مسئلهای که این محصول هدف گرفته با طولانیتر شدن کار عاملها اهمیت بیشتری پیدا میکند: وقتی یک agent چند ساعت کار میکند، اگر لپتاپ sleep شود، اتصالش قطع شود یا نتواند دهها کار موازی را اجرا کند، کار کجا ادامه پیدا میکند؟
Docker میگوید Cloud Sandboxes همان abstraction نسخهٔ محلی را با همان CLI و مدل جداسازی microVM ارائه میکند. توسعهدهنده میتواند کار را روی سیستم خودش شروع کند و بعد با sbx move همان sandbox را به cloud منتقل کند. طبق توضیح Docker، این جابهجایی filesystem محیط را ثبت و sandbox را در سمت دیگر دوباره ایجاد میکند. شرکت همچنین این سرویس را برای اجرای موازی چندین agent طراحی کرده و برای هر sandbox محیط محاسباتی، secret و network policy جداگانه در نظر گرفته است.
حالا sandbox مقصد ابری هم دارد
تغییر اصلی یک رابط تازه برای coding agent نیست؛ جدا شدن محیط کار عامل از کامپیوتر فیزیکی توسعهدهنده است.
محصول Docker Sandboxes عامل را داخل یک microVM با kernel لینوکس و Docker daemon مستقل اجرا میکند. Cloud Sandboxes همین مدل عملیاتی را به compute میزبانیشده گسترش میدهد. Docker میگوید توسعهدهنده میتواند یک task را محلی شروع کند، آن را به cloud منتقل کند، اتصال خود را ببندد و بعداً نتیجه را بررسی کند. این انتقال دوطرفه است و کار انجامشده در cloud نیز میتواند دوباره به محیط محلی برگردد.
نتیجه یک مدل اجرای پیوستهتر است. refactor بزرگ، migration، اجرای طولانی testها یا loop چندساعته دیگر مجبور نیست به همان دستگاهی متصل بماند که کار روی آن شروع شده است. برای تیمهایی که چند agent را همزمان آزمایش میکنند، بخشی از دردسر provisioning نیز حذف میشود؛ Docker در معرفی محصول صریحاً از اجرای تعداد زیادی task ایزوله بهصورت موازی بدون آمادهسازی زیرساخت جداگانه صحبت میکند.
عاملهای طولانیمدت، زیرساخت را بخشی از طراحی agent میکنند
اهمیت این تغییر در این است که محدودیت agent دیگر فقط مدل نیست. وقتی یک عامل میتواند پنج، ده یا بیست ساعت کار کند، تصمیمهای زیرساختی مستقیماً وارد طراحی workflow میشوند.
لپتاپ برای اجرای طولانیمدت worker مناسبی نیست: sleep میشود، شبکه عوض میشود، روی باتری کار میکند و همزمان باید پاسخگوی کار تعاملی کاربر باشد. sandbox مدیریتشده میتواند زمانی که انسان آفلاین است فعال بماند. اما انتقال execution به cloud مرز عملیاتی را هم عوض میکند. تیم باید بداند sandbox چه مدت زنده میماند، چه credentialهایی در دسترس آن است، به کدام شبکهها دسترسی دارد، state چگونه منتقل میشود و چه کسی مسئول متوقف کردن محیط است.
جمعبندی Aipolix این است که long-horizon agentها orchestration محیط اجرا را به یک مسئلهٔ زیرساختی تبدیل میکنند. کیفیت مدل همچنان مهم است، اما lifecycle محیط، isolation، policy و هزینه نیز به همان اندازه وارد محاسبه میشوند. اهمیت Cloud Sandboxes این است که Docker این مسائل را پشت همان abstractionی قرار میدهد که توسعهدهنده برای اجرای محلی agent استفاده میکند.
وقتی کسی ناظر نیست، isolation مهمتر میشود
Docker میگوید هر sandbox در یک microVM با kernel مستقل اجرا میشود و مثل container معمولی kernel میزبان را به اشتراک نمیگذارد. مستندات امنیتی شرکت چند لایهٔ جداسازی برای process، filesystem، network و credentialها توصیف میکند. agent داخل sandbox اختیار زیادی دارد، اما مرز VM قرار است این اختیار را از منابع میزبان که صریحاً share نشدهاند دور نگه دارد.
در cloud نیز اجرای unattended فقط به «ماشین جدا» نیاز ندارد. agent برای انجام کار واقعی به network و credential نیاز دارد. Docker میگوید Cloud Sandboxes میتواند برای هر sandbox network policy جداگانه اعمال کند و secretهای ذخیرهشده را از طریق proxy تزریق کند، به شکلی که عامل مقدار اصلی secret را مستقیماً دریافت نکند.
اینها کنترلهای مفیدی هستند، اما نباید بهعنوان اثبات ایمنی خودکار هر workload تفسیر شوند. ادعاهای مربوط به مدل isolation از خود Docker میآیند و معرفی محصول benchmark مستقل امنیتی ارائه نمیکند. سازمان همچنان باید مشخص کند agent اجازهٔ دسترسی به کدام repository، secret، MCP server و سرویس خارجی را دارد.
قیمت، هزینهٔ اجرای agent را قابل اندازهگیری میکند
Docker قیمت Cloud Sandboxes را بر اساس compute مصرفشده تعیین کرده است. در معرفی محصول، کوچکترین اندازه با یک vCPU و ۲ گیگابایت حافظه ۰٫۰۷ دلار در ساعت و بزرگترین گزینه با ۱۶ vCPU و ۳۲ گیگابایت حافظه ۱٫۱۲ دلار در ساعت قیمت دارد. Docker میگوید compute برحسب ثانیه محاسبه میشود، sandbox متوقفشده هزینهای ندارد و در قیمتگذاری اولیه برای volume و egress هزینهٔ جداگانهای دریافت نمیشود.
این مدل به تیمها اجازه میدهد اجرای background agent را با نگهداشتن زیرساخت توسعه یا CI اختصاصی مقایسه کنند. sandbox پیشفرض دو vCPU طبق جدول Docker ساعتی ۰٫۱۴ دلار است؛ بنابراین یک task دهساعته حدود ۱٫۴۰ دلار هزینهٔ compute خواهد داشت، بدون احتساب inference مدل. Docker امکان استفاده از model key خود مشتری را میدهد، پس هزینهٔ inference همچنان جدا و وابسته به provider انتخابی باقی میماند.
مستندات معرفی همچنین سقف ۲۴ ساعت برای هر session ابری را ذکر میکنند. این مدت برای بسیاری از taskهای پسزمینه کافی است، اما همچنان یک مرز lifecycle است که workflow باید آن را مدیریت کند.
abstraction اجرا از governance اولیه جلوتر است
Cloud Sandboxes اجرای local-to-cloud را ساده میکند، اما نسخهٔ اولیه تمام مسائل governance سازمانی را حل نمیکند. Docker در مسیر محصول به کنترلهای متمرکز سازمانی اشاره کرده؛ بنابراین نباید وجود isolation، network policy و secret handling را با کامل بودن لایهٔ governance یکی دانست.
isolation هر sandbox یک کنترل اجرایی است. governance سازمانی پرسشهای دیگری دارد: چه کسی اجازهٔ ساخت sandbox ابری دارد؟ کدام agent و kit مجاز است؟ چه policyهایی باید اجباری باشند؟ usage چگونه audit میشود؟ و اگر چند تیم به مرزهای دسترسی متفاوت نیاز داشته باشند چه اتفاقی میافتد؟
به همین دلیل Cloud Sandboxes را بهتر است زیرساخت اجرای agent بدانیم، نه یک سیستم کامل governance. اهمیت آن در قابلحمل شدن execution layer است: workspace عامل میتواند از لپتاپ توسعهدهنده به compute مدیریتشده منتقل شود و مدل sandbox حفظ شود.
برای تیمهایی که coding agent طولانیمدت میسازند، سؤال طراحی دیگر فقط «کدام مدل یا agent؟» نیست. محل اجرا، محدودیت authority، state قابلانتقال و هزینهٔ اجرای unattended نیز به بخشی از معماری تبدیل شدهاند.