تصور کنید یک برنامه‌نویس می‌خواهد عاملی بسازد که مجموع فروش ماهانه را محاسبه کند یا محتوای فایل‌های سیستمی را بررسی کند، اما نمی‌خواهد یک خطای کوچک در کدِ تولیدشده توسط AI، کل سرور تولید را متوقف کند. برای حل این چالش، توسعه‌دهنده‌ای به نام Mark ابزار plimsoll را منتشر کرد؛ یک محیط ایزوله با مجوز Apache-2.0 که به‌طور اختصاصی برای وظایف Trigger.dev بهینه‌سازی شده است.
اجرای کدهای نامعتبر که توسط هوش مصنوعی تولید شده‌اند مستقیماً روی سرور میزبان، یک ریسک امنیتی بحرانی است. در حال حاضر اکثر توسعه‌دهندگان بین دو گزینه سخت گیر شده‌اند: یا استفاده از محیط‌های ابری بسیار محدود یا پذیرش ریسک اجرای محلی. Plimsoll این شکاف را پر می‌کند و اجرای کد را از منطق اصلی برنامه جدا می‌کند؛ درست مثل یک آزمایشگاه یک‌بارمصرف که ایده‌های عامل در آن تست می‌شود و در صورت انفجار، آسیبی به ساختمان اصلی نمی‌رسد. این رویکرد یادآور چالش‌های امنیتی در انتخاب بین محیط‌های ابری و محلی برای اجرای کدهای AI است که پیش‌تر بررسی کرده بودیم.
زمینه و جایگاه
این ابزار در حال حاضر در وضعیت پیش از نسخه ۱.۰ قرار دارد و به عامل‌ها اجازه می‌دهد ایده‌ها را تست کرده یا فایل‌ها را بدون تداخل با وظایف اصلی بررسی کنند. سیستم به‌گونه‌ای طراحی شده است که ماهیت ناپایدار کدهای تولیدشده توسط AI را مدیریت کند و در عین حال، پایداری محیط تولید (Production) را حفظ نماید.
طبق مستندات فنی، این سامانه از یک چرخه درخواست-پاسخ ساده پیروی می‌کند: وظیفه در Trigger.dev کد را به plimsoll می‌فرستد، کد در محیط ایزوله اجرا شده و خروجی به همراه سطح ایزولاسیون مورد استفاده بازگردانده می‌شود.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های عامل‌محور اشاره کردیم، جداسازی محیط اجرا (Execution Environment) تنها راه مقابله با حملات تزریق کد است. برای کسانی که از نسخه میزبانی شخصی (Self-hosted) در ورژن ۴.۷.۲ استفاده می‌کنند، یک دستور Docker Compose فراهم شده تا سرویس سندباکس در کنار Worker روی زیرساخت خود کاربر اجرا شود. در این پیکربندی، کانتینرهای وظایف از طریق یک شبکه خصوصی داکر به سندباکس دسترسی پیدا می‌کنند.
جزئیات فنی و سازوکار
بر اساس بررسی مستندات، ویژگی‌های کلیدی این سیستم عبارتند از:
- پشتیبانی از زبان‌ها: اجرای مجزا برای پایتون و جاوااسکریپت.
- پایداری وضعیت (State Persistence): پشتیبانی از نشست‌هایی (Sessions) که متغیرها و فایل‌ها را بین چندین فراخوانی حفظ می‌کنند.
- سطوح ایزولاسیون: استفاده از gVisor برای ایجاد مرز هسته (Kernel Boundary) مجزا و در صورت عدم دسترسی، بازگشت به کانتینرهای runc. کانتینرهای معمولی runc هسته میزبان را به اشتراک می‌گذارند و مرز امنیتی ضعیف‌تری فراهم می‌کنند. این متدولوژی شباهت زیادی به استفاده از میکرو-ماشین‌های مجازی برای مدیریت وضعیت عامل‌ها دارد که در ابزارهایی نظیر Claude Code مشاهده می‌شود.
- مدیریت چرخه عمر: یکپارچگی با
onTurnStartبرای گرم کردن سندباکس وonChatSuspendیاonCompleteبرای بستن آن. - زیرساخت: دیمون plimsoll به عنوان زیرساخت مورد اعتماد، دسترسی به Docker socket را دارد که به آن قدرت مدیریت میزبان را می‌دهد.
برای تأیید عملکرد، یک کیت شروع (Starter Kit) شامل وظیفه‌ای است که دو فراخوانی متوالی پایتون را بدون نیاز به مدل AI اجرا می‌کند. در فراخوانی اول، لیستی از اعداد به صورت numbers = [2, 3, 5] ایجاد شده و طول آن (۳) بازگردانده می‌شود. در فراخوانی دوم، مجموع همان اعداد یعنی sum(numbers) محاسبه شده و مقدار ۱۰ بازگردانده می‌شود. گزارش interpreterReused: true و شناسایی سطح «kernel» برای هر دو فراخوانی، ثابت می‌کند که عامل توانسته است فضای کاری خود را در طول فراخوانی‌های مختلف ابزار حفظ کند.
این تغییر، رویکرد طراحی عامل‌ها را از حالت «بدون وضعیت» (Stateless) خارج می‌کند. به‌جای اینکه عامل هر بار برای یک محاسبه ساده، کل فضای کاری را از نو بسازد، اکنون می‌تواند داده‌ها را یک‌بار بارگذاری کرده و روی آن‌ها تکرار کند؛ درست شبیه به محیط Jupyter notebook که سربار بارگذاری مکرر داده‌ها را حذف می‌کند. این انعطاف‌پذیری در مدیریت وضعیت، مکمل معماری‌های پلاگین‌محور در فریم‌ورک‌هایی مانند DeepSeek Harness است که برای ساخت عامل‌های بازمتن بهینه شده‌اند.
امنیت و استقرار
با این حال، مدل امنیتی به‌شدت به سطح ایزولاسیون وابسته است. طبق اعلام توسعه‌دهنده، وظایف پیش‌فرض به ایزولاسیون سطح هسته نیاز دارند؛ اگر فقط سطح کانتینر در دسترس باشد، سیستم از اجرای کد خودداری می‌کند مگر اینکه کاربر صراحتاً سطح امنیت را پایین بیاورد تا از اجرای تصادفی کدهای مخرب در محیط ضعیف جلوگیری شود.
توسعه‌دهندگان می‌توانند plimsoll-trigger-starter را از طریق گیت‌هاب مستقر کنند، به شرطی که از Node.js ۲۲.۱۸ یا نسخه‌های جدیدتر استفاده کنند. فرآیند استقرار شامل کلون کردن مخزن، اجرای دستور npm ci و انجام npm run typecheck پیش از استقرار نهایی است.
این فرآیند نیازمند پیکربندی PLIMSOLL_URL و یک توکن امنیتی PLIMSOLL_TOKEN در محیط تولید Trigger.dev است. کاربران همچنین باید TRIGGER_PROJECT_REF را برای CLI استقرار تنظیم کنند و برای اجرای تست، یک TRIGGER_SECRET_KEY (و در موارد میزبانی شخصی، TRIGGER_API_URL) ارائه دهند.
گام بعدی شما
- اگر از Trigger.dev برای اتوماسیون‌های پیچیده استفاده می‌کنید، کیت شروع Plimsoll را برای تست قابلیت‌های State Persistence بررسی کنید.
- در صورت استقرار روی سرور شخصی، حتماً gVisor را نصب کنید تا از ایزولاسیون سطح هسته بهره‌مند شوید.
- بررسی کنید که آیا گردش‌های کاری شما می‌توانند از مدل «نشست‌محور» به‌جای «فراخوانی‌های تک‌مرحله‌ای» استفاده کنند تا سرعت استنتاج افزایش یابد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو