استضافة Agent Zero ذاتيًا على خادم VPS

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

Agent Zero إطار عمل مفتوح المصدر للوكلاء، قائم على نهج «Docker أولًا». يستطيع الوكيل الرئيسي إنشاء وكلاء تابعين، يعمل كل منهم في حاوية Docker معزولة خاصة به، ويستطيع كل منهم تنفيذ الكود، والتحكم في متصفح، وتشغيل أوامر الصدفة (shell). تتحكم في ذلك كله من واجهة ويب واحدة. إنه فعّال وممتع فعلًا في الاستخدام، ويعمل على عتاد صغير بحجم خادم VPS بستة دولارات.

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

ما الذي تحتاج إليه

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

التثبيت باستخدام Docker، مربوطًا بعنوان الاسترجاع المحلي

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

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

ثم افتح http://127.0.0.1:5080 محليًا، واضبط مزوّد النموذج الخاص بك في الواجهة. أما للإعداد الدائم متعدد المستخدمين، فضعها بدلًا من ذلك خلف VPN أو بروكسي عكسي (reverse proxy) مزوّد بمصادقة، لكن لا تنشر الواجهة كما هي، دون حماية، على الإنترنت المفتوح أبدًا.

أين تتوقف الأدلة الأخرى، ولماذا لا ينبغي أن تتوقف أنت

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

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

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

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

تصميم Agent Zero جيد فعلًا في نوع واحد من العزل: الوكلاء التابعون يعملون في حاويات منفصلة، فهم معزولون بعضهم عن بعض. وهذا أمر يستحق التقدير. لكن من السهل أن تقرأ ذلك على أنه «إنه يعمل داخل بيئة معزولة (sandbox)، إذن أنا آمن» وتتوقف عند هذا الحد. عزل الحاويات يحمي الوكلاء بعضهم من بعض. وهو لا يفعل شيئًا لحماية خادمك من الإنترنت، ولا لمنع واجهة ويب مكشوفة من تسليم التحكم إلى شخص غريب. هذان الأمران من مسؤوليتك أنت، على مستوى المضيف.

الأسرار، والمستخدمون، والمضيف

احتفظ بمفتاح API الخاص بالنموذج وبأي بيانات اعتماد أخرى في إعدادات Agent Zero أو في ملف بيئة (environment file) لا يقرؤه إلا الحساب المخوَّل، بعيدًا عن سجل أوامر الصدفة (shell history) وعن أي مستودع (repository). أدر الخادم بمستخدم محدود الصلاحيات بدلًا من root، وفق مبدأ تشغيل الخدمات بمستخدم محدود الصلاحيات، وانقل SSH إلى المصادقة بالمفاتيح فقط، كما في تحصين SSH على خادم VPS. ثم راجع قائمة التحقق أدناه حتى لا يفوتك شيء.

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

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

FAQ

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

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

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

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

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

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

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

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