اجرای یک عامل هوش مصنوعی خودمختار با دسترسی کامل به سیستم، قمار خطرناکی است که معمولاً به پاک شدن فایل‌های تنظیمات یا تخریب دایرکتوری‌ها ختم می‌شود. roc، پروژه‌ای جدید که با زبان Rust نوشته شده و در ۸ اکتبر ۲۰۲۶ منتشر شد، این مشکل را با محصور کردن عامل‌ها در کانتینرهای یک‌بارمصرف داکر (Docker) حل می‌کند.
بسیاری از توسعه‌دهندگان اکنون با یک انتخاب سخت روبره‌اند: یا دسترسی عامل را محدود کنند و شاهد شکست آن در کارهای پیچیده باشند، یا دسترسی کامل بدهند و هر دستور را با نگرانی زیر نظر بگیرند. این تنش به این دلیل است که ابزارهایی مثل Claude Code یا Goose برای مفید بودن به ادغام عمیق با سیستم نیاز دارند، اما حفاظ‌های داخلی برای جلوگیری از حوادث فاجعه‌بار ندارند.
مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — وقتی به عنوان یک عامل (Agent) عمل می‌کند، نیاز به محیطی دارد که بتواند در آن آزمایش کند بدون اینکه خانه را به آتش بکشد. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مرز بین بهره‌وری و ریسک در سیستم‌های خودمختار بسیار باریک است.
سازوکار ایزولاسیون
به نقل از مستندات این پروژه در گیت‌هاب، roc به عنوان یک لایه مدیریتی عمل می‌کند که عامل‌هایی نظیر opencode، goose، claudecode و codex را درون یک محیط کانتینری اجرا می‌کند. این ابزار از قابلیت mount مسیرهای میزبان به صورت ۱:۱ استفاده می‌کند تا دسترسی‌های لازم را به عامل بدهد، در حالی که بقیه سیستم میزبان را نامرئی و امن نگه می‌دارد.
این معماری تضمین می‌کند که عامل بتواند کارهای سنگین را انجام دهد بدون اینکه کاربر مجبور به «پرستاری» مداوم فرآیند باشد. با ایزوله کردن عامل در کانتینر، توسعه‌دهنده می‌تواند صرفاً از یک پرامپت قدرتمند مثل «Implement AGENTS.md» استفاده کند و اجازه دهد هوش مصنوعی در یک محیط امن و ایزوله (Sandbox) کد بزند.
مشخصات سخت‌افزاری و مدل
بر اساس مستندات فنی، استقرار این سیستم روی یک Mac Studio با ۲۵۶ گیگابایت رم شامل مشخصات زیر است:
- هم‌روندی (Concurrency): پشتیبانی از حداکثر ۴ ورکر مدل به صورت هم‌زمان.
- اندازه مدل: هر ورکر مدل‌هایی با اندازه تقریبی ۱۶ گیگابایت را مدیریت می‌کند.
- پنجره متنی (Context Window) — میزان متنی که مدل هم‌زمان در ذهن نگه می‌دارد، شبیه میز کاری که جا برای چند ورق دارد — برای هر ورکر ۲۵۶ هزار توکن است که مجموعاً به ۱ میلیون توکن می‌رسد.
- یکپارچگی: اتصال بومی به LM Studio، Ollama یا هر API سازگار با OpenAI.
- مدیریت پنجره: سیستم از یک پنجره غلتان (Rolling Window) برای مدیریت توکن‌ها استفاده می‌کند.
ویژگی‌های فنی دقیق
roc یک درگاه پروتکل زمینه مدل (MCP) با سیاست‌های سخت‌گیرانه و یک فایل وضعیت (State file) برای ردیابی تنظیمات بین جلسات پیاده‌سازی کرده است. این ابزار کنترل دقیقی روی محیط عامل فراهم می‌کند:
- کنترل دایرکتوری: کاربران دایرکتوری‌های فقط-خواندنی (
-r) و خواندنی-نوشتنی (-w) را از طریق لیست‌های CSV تعریف می‌کنند. این یعنی عامل می‌تواند کد پروژه را تغییر دهد اما به فایل‌های باینری حساس سیستم دست نزند. - مدیریت ورکر: وضعیت ورکرها (در حال اجرا، در دسترس یا آفلاین) با فلگ
-listردیابی می‌شود. کاربران می‌توانند با--worker <N>یک ورکر خاص را انتخاب کنند. - پایداری وضعیت: تنظیمات ارائه‌دهنده، میزبان AI و شناسه مدل در یک فایل وضعیت ذخیره می‌شود که از طریق
--state <PATH>قابل مدیریت است. - قابلیت‌های گسترده: دستور
--build-imageمی‌تواند با--with-playwrightترکیب شود تا Chromium برای تست‌های وب اضافه شود.
برای توسعه‌دهنده، این تغییر یعنی تبدیل «نظارت بر یک ابزار ریسکی» به «استقرار یک نیروی کار». با استفاده از پرامپت AGENTS.md کاربر می‌تواند دستور دهد تا عامل ایزوله شده، ویژگی‌های کامل نرم‌افزار را به صورت خودمختار بسازد.
منطق تخصیص ورکر
سیستم تخصیص ورکرها را به صورت خودکار مدیریت می‌کند. در پیکربندی چهار ورکر مبتنی بر Qwen3.8-27b برای MLX، ابزار roc آن‌ها را به ترتیب تخصیص می‌دهد. اولین اجرا به Q #1 و دومین اجرا به Q #2 اختصاص می‌یابد. این رویکرد اجازه می‌دهد مدل‌های بارگذاری‌شده به صورت موازی فعال باشند در حالی که هم‌روندی برای هر ورکر روی ۱ تنظیم شده است.
این متد، این فرض را که عامل‌های AI برای امنیت باید حتماً در ابر (Cloud) میزبانی شوند، تغییر می‌دهد. با انتقال مرز ایزولاسیون به لایه محلی داکر، roc یک استک عامل‌محور «اول-محلی» (Local-first) ایجاد می‌کند که امنیت سیستم را فدای بهره‌وری نمی‌کند. در واقع، ماشین محلی به محیطی چندمستاجری تبدیل می‌شود که در آن عامل‌های AI به جای کاربران دارای امتیاز، به عنوان مهمان‌های موقتی شناخته می‌شوند.
راه‌اندازی و استقرار
برای شروع، کاربر باید داکر را فعال داشته باشد. فرآیند طبق این توالی پیش می‌رود:
۱. اجرای roc -build-image برای تولید کانتینر. توجه کنید که خودِ roc در کانتینر اجرا نمی‌شود، بلکه باینری‌های عامل (مثل opencode) از طریق Dockerfile نصب و در آنجا اجرا می‌شوند.
۲. شروع تنظیمات هدایت‌شده با roc -init که سوالات پیکربندی را پرسیده و در فایل وضعیت می‌نویسد.
۳. استفاده از گزینه -save برای ثبت دستی تنظیمات در فایل وضعیت.
کاربران هشدار یافته‌اند که کلیدهای API را مستقیماً در آرگومان‌های CLI وارد نکنند تا در تاریخچه شل (Shell history) لو نرود؛ در عوض باید از فلگ --ai-api-token یا متغیرهای محیطی استفاده کنند.
گام بعدی شما
- اگر از عامل‌های کدنویس محلی استفاده می‌کنید، محیط Docker خود را آماده کرده و roc را برای ایزوله کردن دسترسی‌ها تست کنید.
- دایرکتوری‌های پروژه خود را در دو لیست مجزای Read-only و Read-write دسته‌بندی کنید تا امنیت سیستم‌عاملتان تضمین شود.
- برای تسریع در استقرار، از فلگ
-initبرای ایجاد فایل وضعیت دائمی استفاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو