كيفية استضافة Agent Zero بأمان على VPS

ماهية Agent Zero ومكمن الخطر

Agent Zero هو إطار عمل مفتوح المصدر، ومصمم أولاً للعمل مع Docker. يمكن لوكيل أساسي إنشاء وكلاء تابعين، يعمل كل منهم داخل حاوية Docker معزولة خاصة به. ويمكن لكل وكيل تنفيذ التعليمات البرمجية، والتحكم في متصفح، وتشغيل أوامر shell. يمكنك التحكم في النظام بأكمله من خلال Web UI. الإطار قادر وممتع فعلاً في الاستخدام، ويعمل على عتاد لا تتجاوز تكلفته ستة دولارات في VPS. إذا كنت تريد بنية الوكلاء المتعددين لا الإطار نفسه، فيمكن لـجلستي Claude Code على الجهاز نفسه إرسال الرسائل مباشرة إلى إحداهما الأخرى، وهذا حل أصغر بكثير من حيث التشغيل والتأمين.

يكمن الخطر في Web UI. فهي لوحة التحكم لنظام يشغّل الأوامر ويكتب الملفات، ولذلك فإن Web UI مكشوفة وغير موثّقة تمنح وصولاً أولياً عن بُعد إلى هذا النظام تحديداً. وهذه هي المشكلة التي تقودك إليها معظم أدلة الإعداد مباشرة: ينشر docker run القياسي الواجهة على المنفذ 50001 على كل واجهة شبكة، ما يعني أنها تصبح قابلة للوصول من الإنترنت بالكامل فور بدء الحاوية على VPS عام. يجب أن تعالج هذه النقطة أولاً، لا أخيراً.

ما تحتاج إليه

تحتاج إلى VPS مثبّت عليه Docker، ومفتاح API لنموذج لغوي أو نموذج محلي لتوجيه Agent Zero إليه، وذاكرة RAM بسعة بضعة غيغابايت للبدء. يعمل Agent Zero أينما يعمل Docker، بدءاً من VPS صغير وصولاً إلى خادم مزوّد بـGPU. إذا كان Docker جديداً عليك، يوضّح دليل أساسيات Docker الافتراضات التي تستند إليها الأوامر أدناه.

ثبّت البرنامج باستخدام Docker مع ربطه بعنوان loopback

يتكوّن التشغيل السريع الموثّق من أمر docker run واحد. التغيير المهم مقارنةً بإصدار النسخ واللصق الذي ستجده في أماكن أخرى هو العنوان الذي تنشر عليه الخدمة. لا تنشر الخدمة على جميع الواجهات عبر المنفذ 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 واجهة Web UI بعنوان loopback للخادم فقط، لذلك لا يمكن الوصول إليها من الإنترنت. يمكنك الوصول إليها من جهازك عبر نفق SSH:

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

بعد ذلك، افتح http://127.0.0.1:5080 محلياً، واضبط موفّر النموذج في الواجهة. عند إعداد الخدمة لعدة مستخدمين بشكل دائم، ضعها خلف VPN أو Reverse Proxy يطلب المصادقة بدلاً من ذلك. لا تنشر واجهة UI الخام على الإنترنت المفتوح مطلقاً. وينبغي تطبيق هذا الأسلوب على كل أداة أخرى في الخادم تتحكم واجهتها في شيء حساس. وينطبق ذلك أيضاً على ماسح open-kritt مستضاف ذاتياً، إذ ينبغي الوصول إليه عبر نفق إلى واجهته بدلاً من نشر منفذ له.

عند النقطة التي تتوقف فيها الأدلة الأخرى، ولماذا يجب ألا تتوقف أنت

ابحث عن طريقة تثبيت Agent Zero، وستجد أدلة كثيرة، بما فيها أدلة من شركات الاستضافة، توصلك إلى واجهة Web UI تعمل على المنفذ 50001 ثم تتوقف. هذه هي النقطة التي يبدأ عندها الخطر، لا النقطة التي ينتهي عندها. هناك خطوتان لإكمال الإعداد. أولاً، أبقِ الواجهة خاصة كما سبق. ثانياً، ضع جداراً نارياً بسياسة رفض افتراضية أمام الخادم، حتى لا تتمكن حاوية شاردة أو خطأ مستقبلي من كشف منفذ نسيته:

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

اتبع أساسيات الجدار الناري لفهم الصورة كاملة، وانتبه إلى فجوة IPv6، لأن الخدمة على :: يمكن الوصول إليها عبر IPv6 حتى عندما تبدو قواعد IPv4 لديك محكمة.

العزل بالحاويات يحمي الوكلاء، وليس خادمك

يطبّق تصميم Agent Zero عزلاً جيداً فعلاً من نوع واحد: تعمل الوكلاء الفرعيون في حاويات منفصلة، لذلك يكون كل وكيل معزولاً عن الوكلاء الآخرين. وهذا أمر مفيد. لكن من السهل تفسير ذلك على أنه «إنه يعمل داخل sandbox، لذلك أنا آمن» والتوقف عند هذا الحد. يحمي عزل الحاويات الوكلاء من بعضهم بعضاً. لكنه لا يحمي خادمك من الإنترنت، ولا يمنع Web UI مكشوفاً من منح شخص غريب التحكم. وهذه مسؤوليتك على المضيف. قرّر مسبقاً مقدار ما يُسمح للوكيل بفعله عندما لا يراقبه أحد، وهو القرار نفسه الكامن وراء أوضاع أذونات Claude Code، حيث يتطلب الخادم غير المراقَب إعداداً أكثر تقييداً من الحاسوب المحمول الموجود أمامك.

الأسرار والمستخدمون والخادم

احتفظ بمفتاح model API وأي بيانات اعتماد أخرى في إعدادات Agent Zero أو في ملف بيئة لا يستطيع قراءته إلا الحساب المصرّح له، وأبعدها عن سجل shell وعن أي repository. وينطبق المبدأ نفسه على كل ما يحمي الأسرار على الخادم، لأن تقوية إعداد Vaultwarden تتركز في admin token وملف النسخ الاحتياطي، لا في التشفير الذي ينفذه التطبيق جيداً بالفعل. أدر الخادم باستخدام مستخدم غير مميّز بدلاً من root، وفقاً لمبدأ أقل الصلاحيات للمستخدمين، وانقل SSH إلى المصادقة بالمفاتيح فقط، كما هو موضح في تقوية SSH. ثم نفّذ قائمة التحقق أدناه حتى لا يفوتك شيء.

إذا كنت تقارن بين الوكلاء، فهذه هي الوضعية الأمنية نفسها التي يتبعها كل من دليل تقوية OpenClaw ودليل OpenHands: أبقِ سطح التحكم خاصاً، وشغّل الخدمة باستخدام مستخدم غير مميّز، وفعّل الجدار الناري افتراضياً، وتعامل مع الخادم على أنه يشغّل شيفرة لم تكتبها. للحصول على مقارنة جنباً إلى جنب بين الوكلاء الخمسة، راجع أفضل وكلاء الذكاء الاصطناعي المستضافين ذاتياً في 2026.

توجد المفاهيم الأساسية وراء هذه الخيارات في إنشاء وكيل ذكاء اصطناعي خاص بك على VPS، كما أن Dify منصة أخرى قابلة للاستضافة الذاتية تستحق المقارنة.

FAQ

هل يُعد Agent Zero آمناً للاستضافة الذاتية؟

نعم، إذا أبقيت واجهة Web الخاصة به خاصةً وعزّزت أمان المضيف. يشغّل Agent Zero التعليمات البرمجية والمتصفح وshell، وتتحكم به من خلال واجهة Web تُنشر افتراضياً على المنفذ 50001. لذلك يكمن الخطر في كشف الواجهة، وليس في إطار العمل نفسه. اربط الواجهة بعنوان loopback، ووصل إليها عبر SSH أو VPN، وضع جداراً نارياً بسياسة منع افتراضية، وشغّلها كمستخدم غير مميّز.

هل يعرّض Agent Zero واجهة Web للإنترنت افتراضياً؟

تنشر docker run القياسية الواجهة على المنفذ 50001 في كل واجهة شبكة. وهذا يعني أنها تصبح قابلة للوصول من الإنترنت فور بدء الحاوية على VPS عام. غيّر العنوان المنشور إلى 127.0.0.1 بحيث تستمع واجهة Web على loopback فقط، ثم صِل إليها عبر نفق SSH أو VPN.

هل يمكن تشغيل Agent Zero على VPS صغير؟

نعم. يعمل Agent Zero حيثما يعمل Docker، بما في ذلك VPS صغير منخفض التكلفة، لكن المهام الأثقل والنماذج المحلية الأكبر تحتاج إلى ذاكرة أكبر. إذا وجّهته إلى نموذج مستضاف ذاتياً بدلاً من API مستضاف، فحدّد موارد الخادم وفقاً للنموذج، وليس وفقاً لـAgent Zero فقط.

ما الفرق بين Agent Zero وOpenClaw وHermes؟

تتداخل هذه الأدوات، لكنها تستهدف استخدامات مختلفة. Agent Zero إطار عمل يركّز على Docker، ويعتمد على وكيل أساسي ينشئ وكلاء فرعيين داخل حاويات معزولة، وتتم إدارته من خلال واجهة Web. أما OpenClaw وHermes فهما مساعدان شخصيان تصل إليهما عبر تطبيقات الدردشة. الوضع الأمني واحد في جميع هذه الأدوات: أبقِ سطح التحكم خاصاً وعزّز أمان المضيف.