استضافة Hermes Agent ذاتيًا على VPS

ما هو Hermes Agent

Hermes Agent وكيل ذكاء اصطناعي مستضاف ذاتيًا من Nous Research، صدر في فبراير 2026. تشغّله على خادمك الخاص، وهو يحتفظ بذاكرة دائمة لمشاريعك، ويكتب مهاراته القابلة لإعادة الاستخدام بنفسه أثناء عمله، ويصل إليك عبر تطبيقات المراسلة مثل Telegram وDiscord. وهو مستقل عن النموذج (model-agnostic)، فتوجّهه إلى أي نموذج لغوي تفضّله، وهو خفيف بما يكفي للعمل على VPS بـ 5 دولارات، أو داخل Docker، أو عبر SSH.

مثل أي وكيل، تأتي قيمته من كونه يتصرف نيابة عنك، ولهذا السبب أيضًا تُعِدُّه بعناية. فالوكيل الذي يتذكر ويتعلم وينفّذ المهام هو عملية قائمة تملك وصولًا حقيقيًا إلى خادمك. يثبّت هذا الدليل الوكيل بالطريقة الآمنة، والتحصين المعروض هنا هو نفسه الذي تطبّقه عند تشغيل OpenClaw بأمان.

التثبيت بأمر واحد، ولماذا تقرؤه أولًا

يُثبَّت Hermes بأمر واحد:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

هذا مريح، وهو أيضًا نمط يستحق الحذر. توجيه سكربت (script) مباشرة من الإنترنت إلى الصدفة (shell) عبر أنبوب (pipe) ينفّذ كل ما يحتويه ذلك السكربت، بصلاحيات المستخدم الذي شغّله. قبل أن تنفّذه على خادم حقيقي، نزّله أولًا، واقرأه، ونفّذه بحساب مستخدم مخصص لا بحساب root:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh -o hermes-install.sh
less hermes-install.sh

لا يتعلق الأمر بعدم الثقة بـ Hermes تحديدًا. إنها العادة التي تمنع أي عملية تثبيت بنمط curl | bash من أن تتحول بهدوء إلى الحلقة الأضعف في إعدادك.

امنحه مستخدمًا محدود الصلاحيات

شغّل Hermes بحساب نظام خاص به، لا بحساب root أبدًا، حتى لا يصل خطأ برمجي أو تعليمة سيئة إلى بقية الجهاز. أنشئ مستخدمًا بلا صدفة تسجيل دخول (login shell):

sudo useradd --system --home /opt/hermes --shell /usr/sbin/nologin hermes

ثبّت Hermes تحت /opt/hermes واجعل ذلك الحساب مالكه. يثبّت المثبِّت الرسمي الملفات للمستخدم الذي شغّله أيًّا كان، فنفّذ السكربت الذي نزّلته بحساب المستخدم hermes، على سبيل المثال sudo -u hermes bash hermes-install.sh، فتحطّ الملفات في دليله الرئيسي بدلًا من دليلك أنت. المنطق نفسه المتبع في تشغيل الخدمات بمستخدم محدود الصلاحيات: الحساب الذي يعمل الوكيل تحته هو السقف الذي يحدّ مما يمكنه إتلافه.

احمِ الجهاز بجدار حماية واعزل أسراره

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

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

انتبه هنا إلى ثغرة IPv6 في جدار الحماية، لأن مجموعة قواعد تغطي IPv4 فقط قد تترك خدمة مكشوفة على IPv6. احفظ مفتاح API الخاص بالنموذج وأي رموز مراسلة (chat tokens) في ملف لا يقرؤه سوى المستخدم hermes (بأذونات 600)، وحمِّله إلى الخدمة بدلًا من لصقه في سطر أوامر يبقى أثره في سجلّ الصدفة (shell history).

شغّل Hermes كخدمة systemd محصّنة

تُبقي وحدة systemd خدمة Hermes تعمل بعد خروجك من الجلسة وبعد إعادة الإقلاع، وتعيد تشغيلها إذا تعطلت، وتتيح لك إضافة عزل على مستوى النواة (kernel) يحدّ مما يمكنها لمسه. فعّل NoNewPrivileges وProtectSystem=strict وPrivateTmp وProtectHome حتى يبقى أي اختراق محصورًا.

وَلِّد هنا وحدة محصّنة، ثم انسخها إلى /etc/systemd/system/hermes.service. تبدأ الوحدة تشغيل hermes gateway، وهي العملية الطويلة الأمد التي تربط تطبيقات المراسلة لديك؛ نفّذ hermes --help بعد التثبيت للتأكد من هذا الأمر ومن مسار الملف التنفيذي (binary) في نسختك قبل تفعيل الخدمة:

التوجيهات، إلى جانب خطوتَي daemon-reload وenable --now، مشروحة في تشغيل برنامج كخدمة systemd:

sudo systemctl daemon-reload
sudo systemctl enable --now hermes

حصّن الخادم المحيط بالوكيل

أنهِ العمل بتحصين الباب الأمامي. حوّل SSH إلى المصادقة بالمفاتيح فقط وعطّل تسجيل دخول root، كما في تحصين SSH على خادم VPS، حتى لا يمكن تخمين الحساب الذي تدير به الجهاز. الوكيل الذي يحتفظ بذاكرة دائمة يستحق الحماية، وأرخص حماية هي التأكد من ألا يستطيع أحد تسجيل الدخول إلى الخادم الذي يعيش عليه.

وإن كنت تفضّل فهم الآلية الداخلية على تشغيل وكيل جاهز، فإن بناء وكيل ذكاء اصطناعي خاص بك على VPS يشرح ذلك خطوة بخطوة.

FAQ

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

نعم. صُمم Hermes ليعمل على خادم صغير، وVPS بـ 5 دولارات يكفي لوكيل شخصي يعمل باستمرار. فهو يتواصل مع نموذج لغوي ومع تطبيقات المراسلة لديك بدلًا من خدمة حركة مرور ثقيلة، لذا فهو خفيف الوطأة على الموارد. امنحه مستخدمه الخاص، وجدار حماية، وخدمة systemd، وسيتولاه VPS صغير براحة.

هل سكربت التثبيت بسطر واحد آمن للتشغيل؟

التثبيت بنمط curl | bash مريح، لكن العادة الآمنة هي تنزيل السكربت وقراءته قبل تشغيله، وتنفيذه بحساب مستخدم مخصص بدلًا من root. بهذه الطريقة لا يستطيع مثبِّت يُوجَّه عبر أنبوب (pipe)، من أي مشروع كان، أن يفعل أكثر مما يسمح به ذلك الحساب المحدود. لا شيء هنا خاص بـ Hermes تحديدًا؛ إنها ممارسة جيدة لكل تثبيت من هذا النوع.

كيف أشغّل Hermes من دون root؟

أنشئ مستخدم نظام مخصصًا بلا صدفة تسجيل دخول، وثبّت Hermes تحت دليل يملكه ذلك المستخدم مثل /opt/hermes، وشغّل الخدمة بذلك الحساب. وإذا تعرّض الوكيل يومًا للاختراق، يبقى الضرر محصورًا فيما يستطيع ذلك الحساب الواحد الوصول إليه.

كيف أُبقي Hermes يعمل بعد خروجي من الجلسة؟

شغّله كخدمة systemd. ملف الوحدة يبدأ تشغيل Hermes عند الإقلاع، ويعيد تشغيله إذا تعطل، ويُبقيه يعمل بعد انتهاء جلسة SSH لديك، بينما تحدّ خيارات العزل في systemd مما تستطيع العملية لمسه. وَلِّد وحدة محصّنة بالأداة أعلاه وفعّلها بالأمر systemctl enable --now hermes.

هل يحتاج Hermes Agent إلى GPU؟

لا. Hermes هو بيئة تشغيل الوكيل (runtime)، لا النموذج اللغوي، فهو يعمل جيدًا على VPS صغير يعتمد على CPU فقط. تحدث الحسابات الثقيلة أينما يعمل النموذج، وعادة ما تكون تلك واجهة API مستضافة تتصل بها. وإذا أردت أيضًا استضافة النموذج ذاتيًا على الجهاز نفسه، فحدّد حجم الجهاز بحسب حاجة النموذج لا بحسب حاجة Hermes نفسه. لاستضافة النموذج بالاعتماد على CPU فقط، تنطبق الأرقام الواردة في دليل Ollama.