سندباکسها برای ایجنتهای هوش مصنوعی: چرا لازمن و چطور کار میکنن
هوش مصنوعیخلاصهٔ کاملتر
نویسنده از لحظهای شروع میکنه که Claude Code داشت روی لپتاپ شخصیش با API keyها و فایلهای خصوصیش کار میکرد. این تجربه، بحث رو به سمت اینه که چرا ایجنتها به یه «کامپیوتر قابل دور انداختن» نیاز دارن میبره.
سندباکس یه محیط ایزولهست با فایلسیستم و پردازشهای مجزا، محدودیت سخت روی CPU و حافظه، و یه مرز که کد داخلش نمیتونه ازش رد بشه. ایجنت داخلش هر کاری بخواد میکنه؛ وقتی تمام شد همه چیز پاک میشه.
نویسنده پنج دلیل اصلی برای استفاده از سندباکس رو توضیح میده:
- Containment: حملاتی مثل EchoLeak نشون دادن که یه ایمیل مسموم کافیه تا ایجنت فایلهای خصوصی رو بیرون بفرسته. سندباکس سقف این دسترسی رو میچینه.
- Parallelism: چند ایجنت روی یه ماشین با هم تداخل دارن. هر ایجنت با sandbox خودش port و dependency مجزا داره.
- Reproducibility: سندباکس هر بار از یه image تمیز شروع میکنه و وابستگی به state قبلی نداره.
- Resource governance: حلقههای بینهایت یا پردازشهای سنگین به سقف میخورن و kill میشن.
- Cheap recovery: اگه یه run خراب بشه، دور انداختن sandbox و برگشت از snapshot چند ثانیه طول میکشه.
دو معماری اصلی وجود داره. در اولی (sandbox بهعنوان tool backend)، حلقه ایجنت محلی میمونه و فقط دستورات bash و عملیات فایل به sandbox فرستاده میشن؛ این رویکرد API key رو روی ماشین محلی نگه میداره ولی انتقال فایل دستیه.
در معماری دوم (sandbox بهعنوان خانه ایجنت)، کل حلقه ایجنت داخل sandbox اجرا میشه. این برای ایجنتهای بلندمدت و autonomous بهتره، ولی API key داخل sandbox قرار میگیره.
نویسنده با Daytona و Modal هر دو معماری رو آزمایش کرده. نتیجهگیریش اینه که سندباکس لایه اول دفاعه، نه لایه آخر، و انتظار داره با گسترش ایجنتهای بلندمدت، سندباکس به بخش استاندارد هر deployment بشه.
نکات کلیدی:
- سندباکس محیطی ایزولهست که ایجنت داخلش اجرا میشه و بعد دور انداخته میشه
- پنج مزیت اصلی: containment، parallelism، reproducibility، resource governance، cheap recovery
- دو معماری: sandbox بهعنوان tool backend یا خانه کامل ایجنت
- Daytona و Modal از providers رایجن
