تثبيت DeepSeek Harness على VPS مع إبقائه خاصاً

ما هو DeepSeek Harness

إن DeepSeek Harness (dsh) هو بيئة تشغيل لوكيل Node.js يمكنك تشغيلها على VPS (خادم خاص افتراضي). والطريقة الآمنة لتشغيله هي ربطه بـ127.0.0.1، ثم الوصول إليه من المتصفح عبر نفق SSH (صدفة آمنة). يعرض واجهة ويب (واجهة مستخدم) على المنفذ 3080 بدلاً من العمل داخل الطرفية. لا يطلب خادم الويب هذا كلمة مرور خاصة به. لذلك، فإن نشر المنفذ 3080 يتيح لأي شخص يعثر عليه استخدام وكيل يقرأ ملفاتك وينفّذ الأوامر بحساب مستخدم Linux الخاص بك.

أصدرت DeepSeek هذا البرنامج في 13 August 2026 بموجب ترخيص MIT، في صورة حزمة npm باسم @deepseek-ai/dsh. يصف المشروع نفسه بأنه إصدار معاينة للمطورين، ويذكر أن التغييرات التي تكسر التوافق متوقعة. كل رقم إصدار أدناه هو لقطة من August 2026. لذلك، تحقّق من المستودع قبل نسخ أي جزء منه إلى خادم مهم.

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

الهارنس ليس نموذجاً

يشغّل الهارنس حلقة الوكيل. يحدث الاستدلال في نموذج موجود في مكان آخر، لذلك لن يعمل شيء قبل تزويده بمفتاح API (واجهة برمجة التطبيقات) أو بعنوان نقطة نهاية نموذج تستضيفها بنفسك.

تضبط ذلك في واجهة المستخدم من Settings ثم Models. يتضمن الكتالوج بطاقات جاهزة لمزوّدي API الرئيسيين (DeepSeek وOpenAI وAnthropic)، حيث تلصق المفتاح. أما خيار "Add a custom provider" فهو الأهم: إذ يطلب معرّف المزوّد، واسماً معروضاً، وعنوان URL أساسياً، وبروتوكول API، وبيانات اعتماد، ويتحدث ببروتوكول متوافق مع OpenAI، لذلك يعمل معه أي بوابة أو خادم محلي يطبّق هذا البروتوكول. ويمكن للمزوّدين المخصّصين أيضاً الاستعلام عن نقطة النهاية المتوافقة مع OpenAI GET /models لملء قائمة النماذج تلقائياً.

بهذه الطريقة توجّه الهارنس إلى نموذج على VPS نفسه. يوفّر Ollama واجهة API متوافقة مع OpenAI على http://127.0.0.1:11434/v1/، ويتطلب إدخال أي سلسلة نصية في حقل مفتاح API، وهي ollama وفقاً للعرف، لأن الحقل إلزامي ثم يجري تجاهل قيمته. أما السؤال الأصعب فهو ما إذا كان نموذج صغير بما يكفي للعمل على VPS مناسباً لتشغيل وكيل. وتحدد الفروق بين Ollama وvLLM كخادمي نماذج محليين مقداراً من ذاكرة RAM الذي ستستهلكه الإجابة.

المفاتيح التي تُدخلها في واجهة المستخدم مخصّصة للكتابة فقط. يخزّنها الهارنس في $DSH_HOME/.credentials.yaml، ويحتفظ فقط بمرجع إلى بيانات الاعتماد في settings.yaml. القيمة الافتراضية لـ$DSH_HOME هي ~/.dsh. تعامل مع هذا الملف كملف كلمات مرور، لأنه كذلك: فأي شخص يقرأه يستطيع استهلاك ميزانية API الخاصة بك.

ما تحتاج إليه قبل التثبيت

• خادم VPS يعمل بنظام Ubuntu 24.04 أو إصدار حديث آخر من Linux، مع إمكانية الوصول عبر SSH
• Node.js 22.19 أو أحدث ضمن سلسلة 22.x، أو Node.js 24 أو أحدث، وهي الإصدارات التي يُبنى المشروع ويُختبر عليها
• حساب مستخدم عادي، وليس root، لأن الوكيل ينفّذ أوامر shell بصلاحيات المستخدم الذي بدأ العملية
• pnpm في PATH إذا كنت تخطط لتثبيت الإضافات، لأن أمر الإضافة يستدعيه عبر shell
• إغلاق المنفذ 3080 في جدارك الناري وفي جدار الشبكة الناري المنفصل لدى مزود الخدمة

حزمة nodejs الخاصة بـUbuntu أقدم من الإصدار الذي يحتاج إليه إطار الاختبار، لذلك ثبّت Node من NodeSource أو nvm بدلاً من استخدام apt install nodejs. إذا كان خادم VPS جديداً، فمن المفيد تخصيص عشر دقائق لتقوية SSH قبل أي شيء آخر، لأن النفق الذي ستعتمد عليه لا يكون أقوى من خادم SSH الذي يقف خلفه.

ثبّت DeepSeek Harness على VPS مع تثبيت الإصدار

node --version
npx @deepseek-ai/dsh@0.1.0-rc.6 web

ينزّل npx الحزمة ويشغّل الملف التنفيذي dsh الخاص بها. web هو اسم مستعار لـ--profile web، الذي يشغّل تطبيق المتصفح، وتطبع العملية العنوان الذي تستمع عليه. القيمة الافتراضية هي http://127.0.0.1:3080.

ثبّت الإصدار. يحلّ npx @deepseek-ai/dsh web الوسم الذي يشير إليه latest وقت تشغيل الأمر، وقد أصدر المشروع بالفعل عدة إصدارات مرشحة، ويذكر أن تغييرات كاسرة للتوافق قادمة. يشير 0.1.0-rc.6 إلى الإصدار الذي كان latest يشير إليه في 13 August 2026. يعني تثبيت الإصدار أن الخادم الذي تعدّه اليوم سيعمل بالطريقة نفسها في الشهر المقبل، ولذلك تصبح الترقية قراراً تتخذه بدلاً من كونها نتيجة تكتشفها بالصدفة.

للاستخدام اليومي، ثبّته مرة واحدة بدلاً من إعادة حل الإصدار عند كل تشغيل.

npm install -g @deepseek-ai/dsh@0.1.0-rc.6
dsh --profile web --help

يستحق السطر الثاني التنفيذ، لأن المشغّل وتطبيق الويب يستخدمان مجموعتي خيارات منفصلتين. يعرض dsh --help خيارات المشغّل نفسه. ويعرض dsh --profile web --help الخيارات التي يقبلها تطبيق الويب، ومنها --port و--host و--trusted-host القابل للتكرار.

تحقق الآن من العنوان الذي يستمع عليه.

ss -tlnp | grep 3080

يجب أن يعرض عمود العنوان المحلي القيمة 127.0.0.1:3080. إذا عرض 0.0.0.0:3080، فستكون واجهة المستخدم قابلة للوصول من الإنترنت، وعليك إيقاف العملية قبل تنفيذ أي شيء آخر.

لماذا يجب ألا تنشر المنفذ 3080 مطلقاً

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

أضف الآن ما يوجد خلف هذا المنفذ. يحرّر الوكيل الملفات في مساحة العمل وينفّذ أوامر shell، كما توجد بيانات اعتماد المزوّد على القرص بجواره. لذلك فإن فتح المنفذ 3080 يوفّر shell بعيداً بواجهة محادثة، ويعمل بحساب المستخدم الذي شغّله، مع إرفاق مفتاح API الخاص بك. لا يحتاج المهاجم إلى استغلال ثغرة. يكفيه معرفة رقم المنفذ، وتجد أدوات المسح أرقام المنافذ خلال ساعات من اتصال المضيف بالإنترنت.

ويتفق CLI، أي واجهة سطر الأوامر، مع ذلك. اعتباراً من 0.1.0-rc.6، لا يدعم عمداً --host 0.0.0.0، ويخرج بخطأ في الاستخدام بدلاً من بدء التشغيل. هذا الرفض ميزة، لذلك لا تبحث عن تصحيح يزيله.

هناك طريقتان معقولتان أخريان للنشر عندما لا يناسبك النفق. ضع الخادم ضمن شبكة overlay خاصة، بحيث يملك عنواناً لا تستطيع توجيه الاتصال إليه إلا أجهزتك، وهذا ما يوفّره خادم تحكم Headscale مستضاف ذاتياً. أو ضع reverse proxy أمامه يصادق على الطلب قبل وصوله إلى المنفذ 3080، مثل خادم الدخول الموحّد Authentik الذي ينفّذ forward auth. إن وجود reverse proxy بلا مصادقة أمام الخدمة ليس ضابطاً أمنياً. إنه مجرد عنوان URL أطول.

الوصول إلى واجهة الويب عبر نفق SSH

نفّذ هذا على حاسوبك المحمول، وليس على الخادم.

ssh -N -L 3080:127.0.0.1:3080 you@your-server

يفتح -L المنفذ 3080 على حاسوبك المحمول، ويمرّر أي اتصال يصل إليه عبر جلسة SSH المشفّرة. يُحلّ الجزء 127.0.0.1:3080 على الخادم، لذلك يصل الاتصال إلى harness من loopback، تماماً كما لو كنت أمام الجهاز. ويعني -N عدم بدء shell بعيد، لأنك تريد إعادة التوجيه فقط.

بعد ذلك، افتح http://127.0.0.1:3080 في المتصفح المحلي. إذا كان المنفذ 3080 مستخدماً بالفعل على حاسوبك المحمول، فغيّر الرقم الموجود على اليسار: ssh -N -L 3180:127.0.0.1:3080 you@your-server، ثم انتقل إلى http://127.0.0.1:3180. الرقم الموجود على اليسار محلي، أما الرقم الموجود على اليمين فيخص الخادم، لذلك يتغير الرقم الأيسر فقط.

احفظه في ~/.ssh/config وتوقف عن كتابته.

Host dsh
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  LocalForward 3080 127.0.0.1:3080

بعد ذلك، يبدأ ssh -N dsh النفق. يعني ظهور رسالة رفض الاتصال في المتصفح عادةً أن النفق يعمل، لكن لا يوجد شيء يستمع على الطرف البعيد، لأن SSH يعيد توجيه المنفذ سواء كان harness يعمل أم لا. افحص الخادم باستخدام الأمر ss أعلاه.

الحفاظ على تشغيل الـharness بعد تسجيل الخروج

يتوقف أمر npx مع الصدفة shell الخاصة بك. أما خدمة systemd للمستخدم فتستمر في العمل، وتعيد تشغيل الـharness بعد حدوث عطل أو إعادة تشغيل الخادم.

loginctl enable-linger $USER
mkdir -p ~/.config/systemd/user
command -v dsh

يهم enable-linger لأن خدمات المستخدم تتوقف عادةً عند انتهاء جلستك الأخيرة. لذلك، من دونه، يتوقف الـharness لحظة إغلاق النفق. خذ المسار المطلق الذي يطبعه command -v dsh وضعه في الوحدة، لأن systemd لا يبحث في PATH الذي تنشئه صدفة تسجيل الدخول.

[Unit]
Description=DeepSeek Harness web UI
After=network-online.target

[Service]
Type=simple
WorkingDirectory=%h/projects/site
ExecStart=/usr/local/bin/dsh web
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

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

systemctl --user daemon-reload
systemctl --user enable --now dsh
systemctl --user status dsh

تكون الوحدة التي ترفض البدء ناتجةً في الغالب عن مسار ExecStart خاطئ أو عن إصدار Node ترفضه الثنائيات، ويحدد journalctl --user -u dsh -n 50 ذلك. وينطبق النمط نفسه على إبقاء أي وكيل برمجي قيد التشغيل على VPS، كما أن حالات الفشل متطابقة.

ما الذي يُسمح للمكوّن الإضافي بفعله

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

• تسجيل موفّر نماذج على ctx.llm
• إضافة أدوات موجّهة إلى النموذج على ctx.tools
• توفير الواجهة الخلفية للـshell خلف ctx.shell
• توفير الوصول إلى نظام الملفات أو السياسات خلف ctx.fs
• تسجيل أوامر المستخدم على ctx.commands
• تشغيل مهام في الخلفية عبر ctx.jobs
• تغليف العمليات المنشأة باستخدام واجهة خلفية ctx.sandbox
• اعتراض الطلبات واستدعاءات الأدوات عبر الحدثين agent/* وtools/*
• توسيع حالة الجلسة الدائمة
• التحكم في واجهة المستخدم عبر ctx.agents

اقرأ هذه القائمة بالطريقة التي سيقرأها بها مهاجم. يستطيع المكوّن الإضافي توفير طبقة نظام الملفات وطبقة الـshell، كما يستطيع اعتراض كل استدعاء أداة يجريه النموذج. لا توجد نافذة أذونات تفصل المكوّن الإضافي عن نقاط التكامل هذه، لأن المكوّن الإضافي هو كود Node عادي يُحمَّل في العملية نفسها التي تعمل فيها بقية المكوّنات. تثبيت مكوّن إضافي يعني تشغيل كود مجهول باستخدام أذونات وكيلك، وأذونات وكيلك هي أذونات مستخدم Unix الخاص بك.

هذا هو قرار الثقة نفسه الذي تتخذه عند إرفاق خادم MCP بوكيل على VPS، حيث إن MCP هو بروتوكول سياق النموذج. ولهذا يبدأ تشغيل وكيل برمجي بأمان على VPS بالحساب الذي يعمل الوكيل تحته، لا بالنموذج، كما يفسر سبب تأثير هجمات سلسلة توريد npm بشدة على الخوادم: خطوة التثبيت هي الاختراق، ولا يطلب النظام تأكيداً.

مصدر الإضافات

توجد الإضافات داخل ملفات التعريف. ملف التعريف هو تكوين مُسمّى مخزّن ضمن $DSH_HOME، وتكون قيمته الافتراضية ~/.dsh، ويحتوي مجلد كل ملف تعريف على الإضافات الخارجية التي يثبّتها. تدير CLI هذه الإضافات بتمرير الوسائط مباشرةً إلى pnpm، مع استخدام مجلد ملف التعريف دليلاً للعمل.

dsh plugin --profile web add github:deepseek-harness/turtle-ui
dsh plugin --profile web remove turtle-ui

بما أنّ الوسائط تصل إلى pnpm دون تغيير، فإنّ add وremove وupdate وwhy تعمل بالطريقة نفسها التي تعمل بها في أي مشروع pnpm، ويمكن أن تكون الإضافة حزمة npm أو مرجعاً إلى GitHub. يجب أن يكون pnpm موجوداً أولاً ضمن PATH. في Node 22 والإصدارات الأحدث، يضعه corepack enable pnpm هناك.

تتم عملية اكتشاف الإضافات عبر موضوع في GitHub. يضيف مؤلفو الإضافات موضوع dsh-plugin إلى مستودعاتهم، ويُستخدم تصفح هذا الموضوع لمعرفة الإضافات المتاحة. الموضوع هو تسمية يضيفها المؤلف إلى مستودعه بنفسه. لا يراجعه أحد ولا يوقّعه أحد، وترتّب صفحة الموضوع المستودعات حسب عدد النجوم، وهو مقياس للشعبية لا للسلامة.

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

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

ما الذي يتعطل أولاً

إصدار Node قديم جداً. يستهدف المشروع Node 22.19 والإصدارات الأحدث ضمن سلسلة 22.x، أو Node 24 وما بعده، وتختبرها CI الخاصة بالمشروع. يفشل وقت تشغيل أقدم عند الإقلاع لأن الشيفرة تستخدم بنية نحوية وواجهات API غير متوفرة فيه. شغّل node --version قبل أي شيء آخر.

المنفذ 3080 مستخدم بالفعل. قد يكون السبب harness ثانية، أو عملية قديمة، أو تطبيقاً آخر يستخدم المنفذ 3080 أيضاً. اعثر عليها باستخدام ss -tlnp | grep 3080، ثم أوقفها أو شغّل harness على منفذ آخر باستخدام dsh web --port 3180. ينتمي --port إلى تطبيق الويب، لذلك يأتي بعد web.

يتعذر على المتصفح الاتصال عبر النفق. تأكد من أنك انتقلت إلى 127.0.0.1 وليس إلى العنوان العام للخادم، لأن المنفذ المُعاد توجيهه موجود على حاسوبك المحمول فقط. ثم تأكد من أن harness تستمع على الخادم، لأن SSH ينشئ إعادة التوجيه سواء كانت هناك خدمة تستجيب في الطرف البعيد أم لا.

يفشل dsh plugin فوراً. الأمر عبارة عن غلاف حول pnpm، لذلك يؤدي غياب الملف التنفيذي pnpm إلى إيقافه قبل بدء تنفيذ أي عمل متعلق بالإضافات.

لا يستطيع الوكيل رؤية مشروعك. تكون مساحة العمل افتراضياً هي الدليل الذي بدأت فيه العملية، لذلك فإن الوحدة التي يكون WorkingDirectory فيها هو الدليل الرئيسي تمنح الوكيل دليلك الرئيسي. اختر مساحة العمل من واجهة المستخدم، أو أصلح الوحدة ثم أعد تحميلها.

FAQ

هل من الآمن إتاحة واجهة الويب لـDeepSeek Harness على المنفذ 3080؟

لا. لا يوفّر خادم الويب نظام تسجيل دخول خاصاً به، والوكيل الذي يعمل خلفه يحرّر الملفات وينفّذ أوامر shell بامتيازات المستخدم الذي بدأ العملية، بينما يُخزَّن مفتاح API الخاص بالمزوّد على القرص نفسه. أبقِ المستمع على 127.0.0.1، ثم صِل إليه عبر نفق SSH. ويمكنك أيضاً استخدام شبكة overlay خاصة، أو reverse proxy يصادق على كل طلب قبل وصوله إلى المنفذ. اعتباراً من الإصدار 0.1.0-rc.6، يرفض CLI الخيار --host 0.0.0.0 ويخرج بخطأ استخدام، ما يوضح رأي المؤلفين في هذه الفكرة.

هل أحتاج إلى مفتاح API لـDeepSeek، أم يمكنني استخدام نموذج محلي؟

كلا الخيارين يعمل، لأن harness بيئة تشغيل وليس نموذجاً. ضمن Settings ثم Models، يمكنك لصق مفتاح في بطاقة مزوّد من الكتالوج، أو اختيار "Add a custom provider" ومنحه عنوان base URL يتحدث بروتوكولاً متوافقاً مع OpenAI. يستجيب خادم Ollama المحلي على http://127.0.0.1:11434/v1/ ويقبل أي سلسلة نصية في حقل مفتاح API. تُحفَظ المفاتيح في $DSH_HOME/.credentials.yaml، الذي تكون قيمته الافتراضية ~/.dsh/.credentials.yaml.

ماذا يتيح تثبيت مكوّن إضافي لـDeepSeek Harness للمكوّن الإضافي فعلياً؟

يمنحه صلاحيات الحساب الذي يشغّل harness. المكوّن الإضافي عبارة عن شيفرة Node تُحمَّل داخل العملية نفسها، وتشمل نقاط التوسعة واجهة shell الخلفية، وطبقة نظام الملفات، وسجل الأدوات، والأحداث التي تغلّف كل استدعاء لأداة. لا يعزل أي شيء المكوّن الإضافي عن هذه الواجهات، إلا إذا وفّر المكوّن الإضافي آلية العزل بنفسه. اقرأ الشيفرة المصدرية قبل التثبيت، وشغّل harness باستخدام مستخدم لا يملك أي شيء يهمك.

ما الإصدار الذي ينبغي تثبيته، وهل سيستمر في العمل؟

ثبّت إصداراً محدداً، مثل npx @deepseek-ai/dsh@0.1.0-rc.6 web. ذلك هو الإصدار الذي أشار إليه الوسم latest في 13 August 2026. يصف المشروع نفسه بأنه إصدار معاينة للمطورين، ويذكر أن التغييرات التي تكسر التوافق متوقعة؛ لذلك قد يتصرف أمر غير مقيّد بإصدار بطريقة مختلفة من يوم إلى آخر. افحص المستودع قبل الترقية، وتوقّع تغيّر مفاتيح الإعدادات وواجهات المكوّنات الإضافية ما دام رقم الإصدار يبدأ بـ0.