آموزش نصب و ایمن‌سازی Agent Zero روی VPS

ماهیت Agent Zero و محل خطر

Agent Zero یک چارچوب متن‌باز و مبتنی بر Docker است. عامل اصلی می‌تواند برای تقسیم یک کار به بخش‌های متمرکز، عامل‌های فرعی ایجاد کند. عامل‌ها می‌توانند کد اجرا کنند، مرورگر را کنترل کنند و فرمان‌های shell را اجرا کنند؛ همهٔ این کارها داخل container مربوط به Agent Zero انجام می‌شود. شما کل سیستم را از طریق Web UI کنترل می‌کنید. این ابزار توانمند است و استفاده از آن واقعاً جذاب است. همچنین روی سخت‌افزاری به کوچکی یک VPS شش‌دلاری اجرا می‌شود. اگر چیزی که می‌خواهید شکل چندعاملی است، نه خود چارچوب، دو نشست Claude Code روی یک ماشین می‌توانند مستقیماً به یکدیگر پیام بدهند؛ اجرای چنین راهکاری بسیار ساده‌تر است و ایمن‌سازی آن نیز دشواری کمتری دارد.

خطر در Web UI است. این رابط، control panel سیستمی است که فرمان اجرا می‌کند و فایل می‌نویسد. بنابراین Web UI در معرض اینترنت و بدون احراز هویت، یک نقطهٔ ورود از راه دور به همین سیستم فراهم می‌کند. دام رایج این است که بیشتر راهنماهای نصب شما را مستقیماً به آن وارد می‌کنند: نمونه‌های docker run رابط را بدون تعیین یک address منتشر می‌کنند. در 2026-10-12، فرمان مستقیم README پورت 80 میزبان را نگاشت می‌کند (-p 80:80)، launcher مربوط به A0 Install از پورت 5080 استفاده می‌کند و راهنمای استقرار روی VPS پورت 50080 را پیشنهاد می‌دهد؛ درحالی‌که راهنماهای مربوط به releaseهای حداکثر تا شاخهٔ v0.9.x از پورت 50001 استفاده می‌کنند. هر پورتی را که انتخاب کنید، mapping بدون address روی همهٔ network interfaceها گوش می‌دهد. در یک VPS عمومی، این یعنی به‌محض شروع container، رابط از سراسر اینترنت قابل دسترسی است. اصلاح این وضعیت باید نخستین کاری باشد که انجام می‌دهید، نه آخرین کار.

پیش‌نیازها

شما به یک VPS با Docker نصب‌شده، یک API key برای یک مدل زبانی یا یک مدل محلی برای اتصال به آن، و چند گیگابایت RAM برای شروع نیاز دارید. Agent Zero روی هر محیطی که Docker در آن اجرا شود، از یک VPS کوچک تا یک سرور GPU، قابل اجرا است. اگر با Docker آشنا نیستید، راهنمای مقدماتی Docker مفاهیمی را که دستورات زیر بر پایه آن‌ها هستند، پوشش می‌دهد.

نصب با Docker و اتصال به loopback

راهنمای شروع سریع مستندشده شامل یک docker run است. تفاوت مهم با نسخه‌ای که در منابع دیگر به‌صورت copy-paste پیدا می‌کنید، آدرسی است که روی آن publish می‌کنید. آن را روی همهٔ interfaceها publish نکنید؛ کاری که -p 80:80 انجام می‌دهد. آن را روی loopback publish کنید:

docker run -d --name agent-zero \
  -p 127.0.0.1:5080:80 \
  -v a0_usr:/a0/usr \
  agent0ai/agent-zero

-p 127.0.0.1:5080:80رابط Web UI را فقط به آدرس loopback سرور bind می‌کند؛ بنابراین از اینترنت قابل دسترسی نیست. از طریق یک SSH tunnel، از سیستم خودتان به آن دسترسی پیدا کنید:

ssh -L 5080:127.0.0.1:5080 you@your-vps

سپس http://127.0.0.1:5080 را به‌صورت محلی باز کنید، provider مدل خود را در UI پیکربندی کنید و در بخش Settings، Authentication، یک login و password برای UI تنظیم کنید. مستندات رسمی توصیه می‌کنند این کار را پیش از آن انجام دهید که instance را در اختیار فرد دیگری قرار دهید. برای یک setup دائمی چندکاربره، به‌جای آن instance را پشت یک VPN یا reverse proxy دارای authentication قرار دهید؛ اما هیچ‌گاه UI خام را روی اینترنت عمومی publish نکنید. این رویه را باید برای هر ابزار دیگری روی سرور که interface آن کنترل یک قابلیت حساس را در اختیار دارد نیز رعایت کنید؛ از جمله یک اسکنر open-kritt self-hosted که باید از طریق tunnel به UI به آن دسترسی داشت، نه از طریق یک پورت publish‌شده.

راهنماهای دیگر کجا متوقف می‌شوند و چرا شما نباید متوقف شوید

اگر جست‌وجو کنید که چگونه Agent Zero را نصب کنید، راهنماهای زیادی پیدا می‌کنید؛ ازجمله راهنماهایی از شرکت‌های hosting که شما را به یک Web UI در حال اجرا روی یک پورت منتشرشده می‌رسانند—در نسخه‌های قدیمی‌تر 50001 و در نسخه‌های جدیدتر 80، 5080 یا 50080—و همان‌جا متوقف می‌شوند. خطر دقیقاً از همین‌جا آغاز می‌شود، نه این‌که در همین‌جا پایان یابد. برای تکمیل کار، دو اقدام لازم است. نخست، UI را مانند بخش قبل خصوصی نگه دارید. دوم، یک firewall با سیاست default-deny در برابر سرور قرار دهید تا سرویسی که فراموش کرده‌اید همچنان نتواند به اینترنت پاسخ دهد:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

البته محدودیت آن را بدانید: Docker ترافیک مربوط به پورت‌های منتشرشدهٔ container را پیش از اعمال ruleهای UFW مسیریابی می‌کند؛ بنابراین firewall پورت containerای را که روی همهٔ interfaceها منتشر شده است پوشش نمی‌دهد. به همین دلیل bind روی loopback که در بالا انجام شد اهمیت دارد و نحوهٔ عبور پورت‌های Docker از UFW جزئیات آن را توضیح می‌دهد. برای تصویر کامل، مبانی firewall را دنبال کنید و به شکاف IPv6 توجه داشته باشید، زیرا سرویسی که روی :: قرار دارد، از طریق IPv6 قابل دسترسی است؛ حتی زمانی که ruleهای IPv4 شما محدود به نظر می‌رسند.

ایزوله‌سازی کانتینر از agentها محافظت می‌کند، نه از سرور شما

طراحی Agent Zero در یک نوع ایزوله‌سازی واقعاً مناسب است: چارچوب و هر agentی که ایجاد می‌کند، به‌جای اجرای مستقیم روی host، داخل کانتینر Docker آن اجرا می‌شوند؛ بنابراین کدی که می‌نویسند و اجرا می‌کنند، داخل کانتینر قرار می‌گیرد، نه در دایرکتوری home شما. این قابلیت ارزشمند است. agentهای فرعی همان کانتینر را با agent اصلی به اشتراک می‌گذارند؛ بنابراین مرز ایزوله‌سازی بین agentها و host شماست، نه بین خود agentها. ممکن است به‌راحتی همه این موارد را این‌طور برداشت کنید که «برنامه sandbox شده است، پس ایمن هستم» و بررسی را همان‌جا متوقف کنید. ایزوله‌سازی کانتینر، فعالیت agentها را از host دور نگه می‌دارد. اما از سرور شما در برابر اینترنت محافظت نمی‌کند و مانع نمی‌شود Web UI در معرض اینترنت، کنترل را به فردی ناشناس واگذار کند. این موارد بر عهده شما و در سطح host هستند. از ابتدا مشخص کنید agent در زمانی که کسی بر عملکرد آن نظارت ندارد، تا چه حد مجاز به انجام کار است؛ همان تصمیمی که در modeهای مجوز Claude Code می‌گیرید، با این تفاوت که برای سروری که بدون نظارت اجرا می‌شود باید تنظیم محدودکننده‌تری نسبت به لپ‌تاپی داشته باشد که مقابل شما قرار دارد.

اسرار، کاربران و میزبان

کلید API مدل و هرگونه اعتبارنامه دیگر را در فایل پیکربندی Agent Zero یا یک فایل محیطی (environment file) قرار دهید که فقط حساب کاربری مجاز قادر به خواندن آن باشد؛ این اطلاعات را از تاریخچه shell و هرگونه مخزن (repository) دور نگه دارید. همین منطق برای هر مورد دیگری در سیستم که از اسرار محافظت می‌کند نیز صادق است، چرا که ایمن‌سازی Vaultwarden بیش از آنکه به رمزنگاری داخلی برنامه وابسته باشد، به توکن مدیریتی و فایل پشتیبان آن بستگی دارد. مطابق با اصل حداقل دسترسی کاربران، مدیریت سیستم را به‌جای کاربر root با یک کاربر فاقد دسترسی‌های ویژه انجام دهید و همان‌طور که در ایمن‌سازی SSH آمده است، احراز هویت SSH را فقط به استفاده از کلید محدود کنید. سپس چک‌لیست زیر را دنبال کنید تا موردی از قلم نیفتد.

اگر در حال مقایسه عامل‌ها (agents) هستید، این همان وضعیت امنیتی است که در راهنمای ایمن‌سازی OpenClaw و راهنمای OpenHands اتخاذ شده است: سطح کنترل را خصوصی نگه دارید، با یک کاربر فاقد دسترسی ویژه اجرا کنید، به‌صورت پیش‌فرض از فایروال استفاده کنید و با میزبان طوری رفتار کنید که گویی کدهایی را اجرا می‌کند که خودش ننوشته است. برای مشاهده مقایسه‌ای هر پنج عامل، به بهترین عامل‌های هوش مصنوعی self-hosted در سال 2026 مراجعه کنید.

مفاهیم زیربنایی هر یک از این موارد در ساخت عامل هوش مصنوعی شخصی روی VPS آمده است و Dify نیز پلتفرم دیگری با قابلیت self-hosting است که ارزش مقایسه دارد.

FAQ

آیا self-host کردن Agent Zero امن است؟

اگر Web UI آن را خصوصی نگه دارید و host را ایمن‌سازی کنید، بله. Agent Zero کد، مرورگر و shell را اجرا می‌کند و از طریق Web UI روی هر پورتی که روی host منتشر می‌کنید کنترل می‌شود؛ بنابراین خطر اصلی، interface در معرض اینترنت است، نه خود framework. Web UI را به loopback bind کنید و از طریق SSH یا VPN به آن دسترسی داشته باشید، برای UI نام کاربری و password تعیین کنید، یک firewall با سیاست پیش‌فرض deny در مقابل آن قرار دهید و برنامه را با یک کاربر بدون دسترسی‌های privileged اجرا کنید.

آیا Agent Zero به‌طور پیش‌فرض Web UI را در اینترنت در معرض دسترسی قرار می‌دهد؟

دستورهای مستندشدهٔ docker run، interface را بدون تعیین address منتشر می‌کنند (README از -p 80:80 استفاده می‌کند) و چنین mappingای روی همهٔ network interfaceها گوش می‌دهد؛ بنابراین در یک VPS عمومی، به‌محض شروع container از اینترنت قابل دسترسی است. UFW جلوی آن را نمی‌گیرد، چون Docker پورت‌های منتشرشده را از مسیر firewall عبور می‌دهد. 127.0.0.1 را به address منتشرشده اضافه کنید تا UI فقط روی loopback گوش دهد، سپس از طریق SSH tunnel یا VPN به آن دسترسی پیدا کنید.

آیا Agent Zero روی یک VPS کوچک اجرا می‌شود؟

بله. Agent Zero هر جا که Docker اجرا شود، از جمله روی یک VPS کوچک و کم‌هزینه، اجرا می‌شود؛ هرچند taskهای سنگین‌تر و modelهای local بزرگ‌تر به memory بیشتری نیاز دارند. اگر به‌جای یک API میزبانی‌شده، آن را به یک model self-hosted متصل می‌کنید، ظرفیت server را بر اساس نیاز model تعیین کنید، نه فقط بر اساس نیاز Agent Zero.

Agent Zero چه تفاوتی با OpenClaw یا Hermes دارد؟

این ابزارها هم‌پوشانی دارند، اما هدف‌های متفاوتی را دنبال می‌کنند. Agent Zero یک framework مبتنی بر Docker است که حول یک agent اصلی ساخته شده و agentهای فرعی را داخل container خود ایجاد می‌کند و کنترل آن از طریق Web UI انجام می‌شود. OpenClaw و Hermes دستیارهای شخصی هستند که از طریق chat appها به آن‌ها دسترسی پیدا می‌کنید. وضعیت امنیتی در همهٔ آن‌ها یکسان است: سطح کنترل را خصوصی نگه دارید و host را ایمن‌سازی کنید.