SSD Nodes Learn Hosting plans →
راهنماها Matt Connorتوسط Matt Connor · به‌روزرسانی شده 2026-08-27

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

نصب Agent Zero روی VPS بدون محدودیت دسترسی، خطرناک است. در این راهنما یاد می‌گیرید چگونه با بستن پورت 50001 و تنظیم احراز هویت، از اجرای کد و دسترسی shell در Web UI محافظت کنید.

Agent Zero چیست و خطر در کجا نهفته است

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

خطر اصلی در رابط کاربری وب نهفته است. این رابط، پنل کنترل سیستمی است که دستورات را اجرا کرده و فایل‌ها را می‌نویسد؛ بنابراین یک رابط کاربری وبِ در دسترس و بدون احراز هویت، یک نقطه ورود از راه دور برای نفوذ به دقیقاً همین قابلیت‌هاست. و این همان دامی است که اکثر راهنماهای نصب، شما را مستقیماً به سمت آن هدایت می‌کنند: فایل docker run استاندارد، رابط کاربری را روی پورت 50001 در تمام کارت‌های شبکه منتشر می‌کند که در یک VPS عمومی به این معناست که به محض شروع کانتینر، از کل اینترنت قابل دسترسی است. رفع این مشکل اولین کاری است که باید انجام دهید، نه آخرین کار.

پیش‌نیازها

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

نصب با Docker و محدود کردن به loopback

دستور سریع مستند شده یک docker run واحد است. تفاوت مهم این دستور با نسخه‌ای که در جاهای دیگر برای کپی-پیست می‌بینید، آدرسی است که روی آن سرویس را منتشر می‌کنید. سرویس را روی تمام رابط‌ها (interfaces) در پورت 50001 منتشر نکنید. آن را فقط روی loopback منتشر کنید:

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 رابط کاربری وب را فقط به آدرس loopback سرور متصل می‌کند، بنابراین از طریق اینترنت قابل دسترسی نخواهد بود. از طریق یک SSH tunnel آن را از دستگاه خود باز کنید:

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

سپس http://127.0.0.1:5080 را به‌صورت محلی باز کنید و ارائه‌دهنده مدل خود را در رابط کاربری پیکربندی نمایید. برای یک راه‌اندازی دائمی چندکاربره، آن را پشت یک VPN یا یک reverse proxy دارای احراز هویت قرار دهید، اما هرگز رابط کاربری خام را در اینترنت عمومی منتشر نکنید. این عادت را برای هر ابزار دیگری روی سرور که رابط کاربری آن بخش‌های حساسی را کنترل می‌کند، رعایت کنید؛ این همان روشی است که یک اسکنر open-kritt خود-میزبانی‌شده نیز باید از طریق تونل به رابط کاربری‌اش در دسترس قرار گیرد، نه با انتشار پورت.

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

اگر در مورد نحوه نصب Agent Zero جستجو کنید، راهنماهای بسیاری از جمله راهنماهای ارائه‌شده توسط شرکت‌های میزبانی پیدا خواهید کرد که شما را تا مرحله اجرای Web UI روی پورت 50001 پیش می‌برند و در همان‌جا متوقف می‌شوند. این دقیقاً نقطه‌ای است که ریسک شروع می‌شود، نه جایی که پایان می‌یابد. دو اقدام کار را تکمیل می‌کند. نخست، رابط کاربری را همان‌طور که در بالا گفته شد، خصوصی نگه دارید. دوم، یک فایروال با سیاست default-deny در مقابل سرور قرار دهید تا یک کانتینر سرگردان یا یک اشتباه در آینده، نتواند پورتی را که فراموش کرده‌اید در معرض دید قرار دهد:

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

برای درک کامل موضوع، اصول فایروال را دنبال کنید و به شکاف IPv6 توجه داشته باشید، زیرا سرویسی که روی :: قرار دارد، حتی زمانی که قوانین IPv4 شما کاملاً سخت‌گیرانه به نظر می‌رسند، از طریق IPv6 قابل دسترسی است.

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

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

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

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

ToolVPS hardening checklist

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

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

FAQ

آیا میزبانی شخصی Agent Zero امن است؟

اگر رابط کاربری وب (Web UI) آن را خصوصی نگه دارید و امنیت میزبان را تقویت کنید، بله. Agent Zero کد، مرورگر و shell اجرا می‌کند و از طریق یک رابط کاربری وب کنترل می‌شود که به‌صورت پیش‌فرض روی پورت 50001 در دسترس است؛ بنابراین خطر اصلی ناشی از در معرض قرار گرفتن این رابط است، نه خودِ چارچوب (framework). رابط کاربری را به loopback محدود کنید و از طریق SSH یا VPN به آن دسترسی داشته باشید، یک فایروال با سیاست پیش‌فرض deny در مقابل آن قرار دهید و آن را با یک کاربر بدون دسترسی‌های ویژه (unprivileged) اجرا کنید.

آیا Agent Zero به‌صورت پیش‌فرض رابط کاربری وب را در اینترنت منتشر می‌کند؟

پیکربندی استاندارد docker run رابط کاربری را روی پورت 50001 در تمام کارت‌های شبکه منتشر می‌کند که در یک VPS عمومی به این معنی است که به محض شروع کانتینر، از طریق اینترنت قابل دسترسی خواهد بود. آدرس انتشار را به 127.0.0.1 تغییر دهید تا رابط کاربری فقط روی loopback گوش دهد، سپس از طریق یک تونل SSH یا VPN به آن متصل شوید.

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

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

تفاوت Agent Zero با OpenClaw یا Hermes چیست؟

این ابزارها هم‌پوشانی دارند اما اهداف متفاوتی را دنبال می‌کنند. Agent Zero یک چارچوب Docker-first است که حول یک عامل اصلی (primary agent) ساخته شده و عوامل زیرمجموعه را در کانتینرهای ایزوله ایجاد می‌کند و از طریق یک رابط کاربری وب هدایت می‌شود. OpenClaw و Hermes دستیاران شخصی هستند که از طریق برنامه‌های چت به آن‌ها دسترسی پیدا می‌کنید. وضعیت امنیتی برای همه آن‌ها یکسان است: سطح کنترل را خصوصی نگه دارید و امنیت میزبان را تقویت کنید.