اگر در حال ساخت عامل‌هایی هستید که نیاز به اجرای فرآیندهای طولانی یا تعامل با مرورگر دارند، دیگر مجبور نیستید هر بار محیط اجرای آن‌ها را از صفر بسازید. Lizard در ۵ اکتبر ۲۰۲۶ معماری جدیدی را معرفی کرد که در آن به‌جای استفاده از کانتینرهای مشترک، برای هر نشست یک میکرو-ماشین مجازی (microVM) اختصاصی ایجاد می‌شود. این تغییر بر اساس این اصل است که «یک عامل کدنویس تنها به اندازه محیطی که دستورات را در آن اجرا می‌کند، توانمند است.»
بسیاری از عامل‌های فعلی در کانتینرهایی اجرا می‌شوند که هسته سیستم‌عامل میزبان را به اشتراک می‌گذارند؛ این وضعیت شبیه به آپارتمان‌های دیواری است که صدای همسایه به اتاق شما می‌رسد و امنیت پایین است. اما Lizard با استفاده از Firecracker — که مثل ساختن یک خانه ویلایی مجزا برای هر کاربر است — یک هسته مهمان (Guest Kernel) و یک مرز سخت مجازی‌سازی ایجاد کرده است. طبق اعلام تیم Lizard، این ساختار تضمین می‌کند که کرش کردن یا نفوذ به یک عامل، به سیستم میزبان آسیبی نرساند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، ایزوله‌سازی محیط اجرا برای جلوگیری از حملات تزریق کد حیاتی است. برای کاهش پیچیدگی‌های راه‌اندازی، این پلتفرم قالب‌های تخصصی ارائه می‌دهد. بر اساس مستندات Lizard، کاربران می‌توانند از گزینه‌های زیر استفاده کنند:
- Base Python 3.11: برای اسکریپت‌های ساده و تنظیمات سفارشی.
- Interpreter: مجهز به pandas، numpy، matplotlib، scipy و Jupyter برای تحلیل داده.
- Desktop: محیط لینوکس همراه با Chromium برای کارهای مبتنی بر مرورگر.
- Agent-Specific: پیش‌نصب با عامل‌های کدنویسی مثل Claude، Codex، OpenCode، Pi و Prime.
علاوه بر ایزولاسیون، قابلیت «توقف و بازگشت» (Pause and Resume) یک تغییر کلیدی در مدیریت وضعیت است. در جریان‌های کاری قدیمی، اگر یک عامل (Agent) — همان دستیار هوشمندی که می‌تواند ابزارها را به کار بگیرد — نیاز به تایید انسانی داشت، کل محیط اغلب باید از ابتدا ساخته می‌شد. این چالش مدیریت زیرساخت را به یاد رویکرد OpenAI در Agents API می‌اندازد که تلاش کرد با اتوماسیون ارکستراسیون، پیچیدگی‌های عملیاتی عامل‌ها را کاهش دهد. اکنون فایل‌ها و فرآیندهای در حال اجرا دقیقاً در همان حالت باقی می‌مانند و عامل می‌تواند از آخرین وضعیت خود ادامه دهد.
این قابلیت سه نیاز متفاوت را از هم تفکیک می‌کند: بازگشت به نشست (حفظ وضعیت کاری)، پایداری فایل‌ها (نگهداری خروجی‌ها) و استخراج مصنوعات (انتقال نتایج به خارج از محیط سندباکس).
برای توسعه‌دهندگان، این تغییر باعث می‌شود گلوگاه از مدیریت زیرساخت به «تعیین محدوده دسترسی» (Permission Scoping) منتقل شود. از آنجایی که یک microVM جایگزین کنترل‌های دسترسی در سطح اپلیکیشن نمی‌شود، امنیت عامل همچنان به اعتبارنامه‌های (Credentials) خاصی بستگی دارد که به محیط پاس داده می‌شوند.
این معماری نشان می‌دهد که آینده‌ی هوش مصنوعی عامل‌محور (Agentic AI) تنها به مدل‌های بهتر وابسته نیست، بلکه به زیرساخت‌های «دارای وضعیت» (Stateful) نیاز دارد. با تبدیل محیط اجرا از یک کانتینر یک‌بارمصرف به یک دارایی قابل بازیابی، Lizard تأخیر و هزینه گردش‌های کاری «انسان در حلقه» را کاهش داده است. این بهینه‌سازی در هزینه‌های عملیاتی، در راستای روند کاهش هزینه‌های استنتاج و نظارت بر عامل‌هاست که اخیراً توسط OpenAI با معرفی Decisions API پیش برده شد.
از نظر هزینه، محاسبات از ۰.۰۰۹ دلار در ساعت شروع شده و به‌صورت ثانیه‌ای محاسبه می‌شود. برای یک تسک ۱۰ دقیقه‌ای، هزینه محاسباتی تقریباً ۰.۰۰۱۵ دلار است (بدون احتساب هزینه‌های سرویس).
گام بعدی شما
- اگر از عامل‌های کدنویس استفاده می‌کنید، چرخه توقف و بازگشت را تست کنید تا ببینید چقدر از زمان راه‌اندازی سرد حذف می‌شود.
- قالب‌های Desktop را برای تسک‌هایی که نیاز به تعامل با وب دارند جایگزین اسکریپت‌های ساده کنید.
- محدوده دسترسی (Permission Scoping) عامل‌های خود را بازبینی کنید، چون microVM جایگزین کنترل دسترسی در سطح اپلیکیشن نیست.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو