إضافات dsh: كيف تعمل وكيف تفحصها قبل التثبيت

ما هي إضافة dsh، وماذا يمكنها أن تفعل؟

إضافات dsh هي حزم Node يحمّلها DeepSeek Harness داخل عمليته الخاصة. يؤدي تثبيت الإضافة إلى تشغيل تعليمات برمجية كتبها طرف آخر بصلاحيات وكيلك، وعلى الجهاز الذي يستطيع وكيلك الوصول إليه مسبقاً. لا يوجد ما يفصل الإضافة المحمّلة عن بقية مكوّنات harness. لذلك، قبل تثبيت أي إضافة، اسأل عن الموارد التي يمكن لهذه التعليمات البرمجية الوصول إليها، وكيف تحصر ذلك الوصول.

dsh ‏(DeepSeek Harness) هو إطار الوكلاء مفتوح المصدر من DeepSeek AI، ومبني على إطار إضافات يُسمّى Cordis. الكلمة الوسطى هي الأهم، لأن إطار الوكيل هو البرنامج المحيط بالنموذج، وهو الذي يدير الحلقة والأدوات والصلاحيات، وتنضم الإضافة إليه على هذا المستوى تحديداً. يذكر README الخاص بالمشروع أن كل شيء إضافة. ومحوّل النموذج إضافة. وواجهة الويب التي تكتب فيها إضافة. وأي مكوّن تثبّته من خارج المشروع يُوضَع في الشجرة نفسها، وعلى مستوى الثقة نفسه الذي تتمتع به المكوّنات التي تأتي معه. إذا لم تكن قد شغّلت واحداً بعد، فابدأ بـDeepSeek Harness على VPS، ثم عد قبل أن تضيف إليه أي شيء.

ترد نقاط التوسعة التي يمكن للإضافة الوصول إليها في AGENTS.md بالمستودع. واعتباراً من August 2026، تشمل ما يلي:

• LLM (نموذج لغوي كبير): المزوّد الذي تدفع له قيمة استخدام مفتاح API
• Shell: إمكانية bash، مع موفّري local وpwsh
• Filesystem: وصول إلى الملفات يخضع للسياسات
• Web: موفّرو البحث والجلب
• Subprocess: موفّر لشجرة العمليات
• Workflow: سلاسل worker
• Subagent: تفويض المهام إلى وكلاء إضافيين
• Settings and credentials: الإعدادات المحفوظة ومتغيرات البيئة

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

كيف يعثر dsh على الإضافات ويحمّلها؟

لا يوجد دليل عام للإضافات. إن dsh قيد التشغيل عبارة عن شجرة إضافات تُركَّب عند الإقلاع من طبقات مرتبة، والوحدة التي تحفظ اختياراتك هي profile. تكون $DSH_HOME افتراضياً هي ~/.dsh، ويقيم كل profile في $DSH_HOME/profiles/<name>. ينشئ profileَان web وheadless نفسيهما عند أول استخدام، اعتماداً على القوالب المضمّنة مع البرنامج.

يحتوي دليل profile على ملفين يحددان كل شيء:

• package.json، ويضم تبعيات الإضافات الخارجية، إضافةً إلى بيان dsh.profile الذي يحتوي على قائمة bundles المرتبة
• cordis.patch.yml، وهي طبقة التعديلات الخاصة بك فوق تلك الحزم

ls ~/.dsh
ls ~/.dsh/profiles/web

يطبّق الإقلاع الطبقات بهذا الترتيب، وتغلب الطبقات اللاحقة ما قبلها:

1. جذر فارغ
2. حزم profile، بالترتيب الذي تسرده قائمة البيان
3. cordis.patch.yml الخاص بـprofile
4. $DSH_HOME/cordis.patch.yml
5. أي طبقات --patch <path> إضافية تُمرَّر في سطر الأوامر

تطبع علامتا خيار النتيجة المركبة من دون بدء أي شيء:

dsh --profile web --dump-default-config
dsh --profile web --dump-config

تطبع --dump-default-config الشجرة المركبة وحدها. وتضيف --dump-config طبقتَي profile والتعديلات المنزلية، ولذلك فهي أقرب طريقة للحصول على قائمة فعلية بما سيحمّله إقلاعك التالي. اقرأها قبل أن تثق بخادم ورثته.

تنبيه بشأن ملفات التعديلات هذه. الإعدادات ليست بيانات خاملة هنا، لأن التنسيق يسمح بقيم موسومة من نوع !!js ضمن كتلة config الخاصة بإضافة. إن مقطع cordis.patch.yml منسوخاً من منشور في منتدى هو شيفرة، لذلك تعامل معه كما تتعامل مع shell script من المصدر نفسه.

ما الذي يشغّله dsh plugin add فعلياً؟

يمرّر dsh plugin --profile <name> <args> الوسائط إلى pnpm داخل مجلد ملف التعريف المعني، لذلك يجب أن يكون pnpm موجوداً في PATH. الأوامر الفرعية هي أوامر pnpm:

dsh plugin --profile web add '<package-or-git-spec>'
dsh plugin --profile web remove '<package-name>'
dsh plugin --profile web why '<package-name>'
dsh plugin --profile web update

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

لا يشغّل pnpm 10 والإصدارات الأحدث نصوص إنشاء التبعيات تلقائياً، وتتم الموافقة لكل حزمة عبر onlyBuiltDependencies أو pnpm approve-builds. تحقّق من إصدار pnpm الموجود لديك:

pnpm --version

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

ما الذي يجب أن تقرأه قبل تثبيت إضافة dsh

نزّل tarball المنشور واقرأه. لا يُنفَّذ أي شيء عند فك أرشيف.

npm pack '<package-name>@<version>'
tar -tzf '<package-name>-<version>.tgz'
tar -xzf '<package-name>-<version>.tgz'
less package/package.json

تحتوي package.json على أربعة حقول توفّر لك معظم المعلومات التي تحتاج إليها. اقرأ scripts بحثاً عن إدخالات preinstall وinstall وpostinstall. اقرأ dependencies بحثاً عن الأسماء التي لا تتعرّف إليها، أو الأسماء التي تختلف بحرف واحد فقط عن أسماء تعرفها. اقرأ bin بحثاً عن أي شيء تريد الحزمة إضافته إلى PATH لديك. اقرأ main أو exports لمعرفة ملف الإدخال، ثم افتح ذلك الملف واتّبعه.

ثم اقرأ الشيفرة التي سيجري تحميلها فعلياً. لا يوجد سبب يجعل إضافة تعلن عن أداة للإشعارات تقرأ ~/.ssh أو تتصل بمضيف لم تسمع به من قبل أو تنشئ shell. إذا كانت الحزمة لا تتضمن إلا JavaScript مضمّنة أو مصغّرة، ولم يكن المصدر المطابق متاحاً في مستودع عام، فهذه هي الإجابة. فضّل الإضافات التي يمكنك قراءة مصدرها، وفضّل الإضافات الصغيرة.

يمكنك أيضاً فحص السجل من دون تثبيت أي شيء:

pnpm view '<package-name>' dependencies
pnpm view '<package-name>' versions

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

ثبّت الإصدار واحتفظ بملف القفل

يعني نطاق الإصدار العائم أن الشفرة داخل عملية الوكيل قد تتغير عند أي تثبيت أو تحديث من دون أن تتخذ قراراً بذلك. ثبّت الإصدار.

dsh plugin --profile web add --save-exact '<package-name>@<version>'

يختلف موضع الخيار بين إصدارات pnpm، لذلك تحقّق من النتيجة بدلاً من الوثوق بالأمر. افتح ملف تعريف profile's package.json بعد ذلك، وتأكد من أن التبعية تظهر كإصدار مجرد، من دون ^ أو ~ قبلها. يحدد ذلك الملف ما سيتم تثبيته.

بعد ذلك، احتفظ بملف القفل، فهو يثبت شجرة التبعيات الانتقالية بالكامل، وليس الاسم في المستوى الأعلى فقط:

find ~/.dsh -maxdepth 3 -name 'pnpm-lock.yaml'

انسخه إلى مكان تُجري له نسخاً احتياطية، مع profile's package.json. يعيد هذان الملفان إنشاء الشجرة نفسها على خادم جديد. شغّل dsh plugin --profile web update عندما تقرر تغيير الإصدارات، وليس كإجراء تنظيف روتيني، ثم اقرأ الفروقات في ملف القفل.

بالنسبة إلى plugin المثبّت من git بدلاً من registry، ثبّت commit بدلاً من branch. تمنحك مواصفة بالشكل github:owner/repo#<full commit sha> شجرة ثابتة. أما اسم branch فيمنحك كل ما يحتويه ذلك الفرع في المرة التالية التي يحل فيها pnpm التبعيات، وقد سلّمت بذلك القرار إلى جهة أخرى. يحتاج harness نفسه إلى الانضباط نفسه، لأن كل dsh build منشور هو release candidate، ولأن التثبيت غير المثبّت قد يحل إلى إصدار مختلف في أي يوم، وهذا هو مصدر معظم أخطاء تثبيت dsh وإصداره.

سوق الإضافات، وما تستحقه كلمة «منسّق»

لدى dsh سوق، ويُثبَّت كسكوّن، وهذا يخبرك بشيء عن البنية:

dsh plugin --profile web add dshmarket

بعد إعادة التشغيل، يظهر ضمن Settings، ثم Plugin Market. يوضح ملف README الخاص به حدود السوق بعبارات صريحة. تقتصر عمليات التثبيت على المصادر المدرجة في سجل منسّق، ويُرفض أي مصدر آخر. تُحظر نصوص البناء افتراضياً، ويتطلب تفعيل أي منها موافقة لكل حزمة. وتُعلَّم إضافات Terminal قبل إدراجها في ملف تعريف الويب. أما الجملة الأهم، فهي أن الإدراج لا يعني التزكية، لأن الإضافات عبارة عن تعليمات برمجية من جهات خارجية.

ترفع القائمة المنسّقة الحد الأدنى من الجودة. لكنها لا تقرأ التعليمات البرمجية نيابةً عنك، ولا يمكنها إخبارك بما سيفعله الإصدار التالي من إضافة بعد انتقال حساب المشرف إلى جهة أخرى. تعامل مع التثبيت بنقرة واحدة بالطريقة التي تتعامل بها مع curl | bash من المؤلف نفسه. وهناك سطر آخر من ملف README يستحق التكرار: قد تحتوي النسخة الاحتياطية المُصدَّرة على بيانات اعتماد من إعدادات ملفك الشخصي، لذلك لا ترفقها مطلقاً بمشكلة عامة أو بموقع للصق النصوص. إذا كنت تريد قائمة بداية بدلاً من منهج، فإن إضافات dsh التي تستحق التثبيت هي المقالة المرافقة لهذه المقالة.

شغِّل dsh بحساب مستقل، وليس بحساب root

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

أنشئ للحاضنة حساب Unix خاصاً بها ودليلاً منزلياً خاصاً بها، ولا تشغّلها بحساب root مطلقاً:

sudo adduser --disabled-password --gecos "" dshrun
sudo -iu dshrun

داخل تلك الجلسة، ابدأ تشغيل الحاضنة لكي تكتب دليلها المنزلي ضمن ذلك الحساب:

npx @deepseek-ai/dsh web

تقدّم واجهة الويب الخدمة على http://127.0.0.1:3080 افتراضياً. اتركها على هذا العنوان. إذا نقرت من قبل على الرابط المطبوع من جهاز آخر ولم تحصل على استجابة، يشرح مقصود dsh عند طباعة ذلك العنوان سبب ذلك. يمكن لأي شيء يصل إلى ذلك المنفذ التحكم في وكيل لديه shell، ولذلك فإن نشر المنفذ 3080 يعادل نشر shell بعيد بلا صلاحيات root مع واجهة سهلة الاستخدام. اتصل به من حاسوبك المحمول عبر نفق SSH بدلاً من ذلك:

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

ثم تأكد من عدم وجود أي عملية تستمع على عنوان عام:

ss -lnt | grep 3080

يجب أن يظهر العنوان المحلي على أنه 127.0.0.1:3080. إذا ظهر على أنه 0.0.0.0:3080، فسيكون جدارك الناري هو الحاجز الوحيد بين شخص غريب ووكيلك. ينطبق المنطق وراء تشغيل Claude Code بأمان على VPS على dsh من دون تغيير. امنح الوكيل دليلاً واحداً لمساحة عمل يُسمح له بإتلافها، وأبقِ كل ما لا يمكنك إعادة بنائه خارج ذلك الجهاز. والأفضل من ذلك أن تتعامل مع الجهاز على أنه VM مؤقتة لوكلاء البرمجة، لأن إعادة بناء VPS تستغرق ساعة، بينما تدقيقه يستغرق أسبوعاً.

مكان تخزين مفاتيحك، ولماذا لا تكفي أذونات الملفات وحدها

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

chmod 600 ~/.dsh/.credentials.yaml ~/.dsh/.env
ls -l ~/.dsh

يمنح الوضع 600 المالكَ صلاحية القراءة والكتابة، ولا يمنح أي صلاحية للآخرين. من المفيد معرفة ذلك بالصياغتين (أوضاع chmod الرقمية والرمزية). كن دقيقاً بشأن ما توفره هذه الأذونات. تحمي أوضاع الملفات تلك الملفات من الحسابات الأخرى على الخادم. لكنها لا تحميها من مكوّن إضافي، لأن المكوّن الإضافي يعمل بالمستخدم نفسه الذي يملك الملفات، وداخل العملية التي تقرؤها. لذلك يعني إبعاد الأسرار عن متناول وكيل الذكاء الاصطناعي عدم وضعها على الجهاز أصلاً. يجب أن يحتوي خادم dsh على مفتاح النموذج الوحيد الذي يحتاج إليه. أما بيانات اعتماد الخدمات السحابية ومفاتيح التوقيع، فيجب أن تكون في مكان آخر.

لماذا يغيّر المكوّن الإضافي الذي يقرأ الويب نموذج التهديد

توفّر وصلة Web للمكوّنات الإضافية مزوّدي البحث والجلب. عندما يجلب المكوّن الإضافي صفحة إلى جلستك، فهو يجلب نصاً يستطيع المهاجم كتابته. لا يفصل طلب النموذج بين التعليمات والبيانات، لذلك يمكن أن تحتوي الصفحة التي جُلبت على سطر موجّه إلى وكيلك، ويصبح الـharness الذي يملك صلاحية shell على بُعد خطوة طيّعة واحدة من تشغيله.

توجد آلية التحكم داخل الـharness بالفعل. dsh-base، وهي الحزمة الأولى في كل profile، توفّر sandbox وسياسة الموافقة. استخدمها. يجب أن تتطلب الجلسة التي تستطيع جلب صفحات غير موثوقة موافقة على أي إجراء يكتب أو ينفّذ، حتى لا تتحول التعليمات التي جُلبت إلى إجراء تلقائياً. يوضّح فرض الموافقة قبل إجراءات الوكيل كيفية تحديد موضع هذا الحد. وتسري العلاقة في الاتجاهين أيضاً، لأن خادمك نفسه صفحة سيجلبها وكيل شخص آخر، وهذا هو موضوع حظر روبوتات زحف الذكاء الاصطناعي على خادمك.

كيف أتحقق مما غيّره مكوّن إضافي؟

أنشئ لقطة قبل التثبيت، ثم ثبّت المكوّن الإضافي، وأنشئ لقطة بعده، ثم اقرأ الفرق.

dsh --profile web --dump-config > /tmp/dsh-before.txt
dsh plugin --profile web add '<package-name>@<version>'
dsh --profile web --dump-config > /tmp/dsh-after.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after.txt

يوضح diff إدخالات المكوّن الإضافي التي أضافها التثبيت إلى الشجرة المركّبة. إذا ثبّتَّ مكوّناً إضافياً لميزة صغيرة واحدة، لكنه أضاف عدة إدخالات لا تستطيع تفسيرها، فتوقّف واقرأ الشيفرة المصدرية قبل تشغيله. يجيب dsh plugin --profile web why <package-name> عن السؤال الآخر: أيّ من تبعياتك المباشرة جلب حزمة معيّنة.

تُثبَّت الحزم ضمن $DSH_HOME/profiles/node_modules، لذا يمكنك أيضاً فحص الشجرة على القرص:

ls ~/.dsh/profiles/node_modules

احتفظ بملف تعريف ثانٍ لا تُجري فيه أي تجارب. عندما يتسبب التثبيت في تعطيل بيئة الاختبار، يوضح لك تشغيل dsh --profile <clean-name> خلال ثوانٍ ما إذا كان المكوّن الإضافي هو السبب.

كيفية إزالة إضافة dsh؟

dsh plugin --profile web remove '<package-name>'
dsh --profile web --dump-config > /tmp/dsh-after-removal.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after-removal.txt

لا تؤدي إزالة التبعية دائماً إلى إزالة الإعدادات. تبقى الإدخالات المكتوبة في cordis.patch.yml الخاص بالملف الشخصي في مكانها، لأن هذا الملف يخصك ولن يعيد الـharness كتابته نيابةً عنك. افتح الملف واحذف أي كتلة تذكر الحزمة التي أزلتها.

less ~/.dsh/profiles/web/cordis.patch.yml

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

الخلاصة

• اقرأ أرشيف tarball المنشور قبل التثبيت، وابدأ من scripts ومن ملف الإدخال
• ثبّت الإصدار الدقيق، أو commit الدقيق عند استخدام مواصفة git، واحتفظ بملف القفل
• ثبّت البرامج في profile واحد، واحتفظ بـprofile نظيف يمكنك الإقلاع به عند حدوث مشكلة
• اعرض الفروقات في --dump-config قبل كل تثبيت وبعده
• شغّل harness باستخدام مستخدم unix مستقل، على loopback، مع الوصول إليه عبر SSH
• احتفظ بمفتاح API واحد على الخادم، وبدّله في اليوم الذي تزيل فيه plugin لم تعد تثق به

لا يعني أي من ذلك تجنّب plugins. فنموذج plugin هو سبب فائدة dsh، كما أن harness الذي لا يمكنك توسيعه هو harness ستستبدله. المقصود هو أن تعرف ما الذي ثبّتَّه، ومن أي جهة، وبأي إصدار، وأن تشغّل كل ذلك في مكان يمكنك إعادة بنائه.

FAQ

هل يعزل dsh الإضافات عن بعضها؟

لا. تُحمَّل الإضافة في عملية harness عبر Cordis، ويمكنها الوصول إلى واجهات القدرات الموثقة، بما فيها shell وfilesystem وweb وsubprocess وsubagent وcredentials. dsh-base، وهي الحزمة الأولى في كل profile، توفّر سياسة العزل والموافقة التي تحدد ما يمكن لأدوات agent فعله، وهذه السياسة هي مصدر الحماية لديك. لا توجد حدود صلاحيات منفصلة لكل إضافة، لذلك النموذج الواقعي هو أن تثبيت إضافة يوسّع نطاق الثقة ليشمل مؤلفها وكل حزمة في شجرة تبعياتها.

هل يمكنني تثبيت إضافة dsh من دون تشغيل نصوص التثبيت الخاصة بها؟

يحظر pnpm 10 والإصدارات الأحدث نصوص بناء التبعيات افتراضياً، وdsh plugin ... add يُحيل إلى pnpm، لذلك لا يشغّل pnpm الحالي نصوص الحزم أثناء التثبيت إلا إذا وافقت على تلك الحزمة. تحقّق من إصدارك باستخدام pnpm --version. هذا لا يجعل الإضافة غير المقروءة آمنة. تُشغَّل الشفرة الخاصة بالإضافة عند الإقلاع التالي لأن harness يحمّلها عمداً، ولا يؤثر أي تقييد أثناء التثبيت في ذلك.

أين توجد إضافات dsh وإعداداتها فعلياً؟

$DSH_HOME يستخدم ~/.dsh افتراضياً. توجد profiles في $DSH_HOME/profiles/<name>، ويحتوي كل منها على package.json مع تبعيات إضافاته، وعلى manifest dsh.profile للحزم المرتبة، وطبقة تصحيح cordis.patch.yml. تُثبَّت الحزم تحت $DSH_HOME/profiles/node_modules. توجد المفاتيح في $DSH_HOME/.credentials.yaml، وقيم البيئة في $DSH_HOME/.env، ويُطبَّق $DSH_HOME/cordis.patch.yml على مستوى home فوق كل profile. شغّل dsh --profile web --dump-config لعرض النتيجة المركبة من دون الإقلاع.

هل التثبيت من سوق إضافات dsh آمن؟

يقصر السوق التثبيت على المصادر الموجودة في registry منتقاة، ويحظر نصوص البناء ما لم توافق عليها لكل حزمة. وهذا تحسّن فعلي مقارنةً بلصق اسم حزمة من نافذة محادثة. يذكر README الخاص بالسوق نفسه أن الإدراج لا يعني المصادقة، لأن الإضافات شفرة من جهات خارجية ومن أشخاص آخرين. اقرأ الشفرة وثبّت الإصدار. أبقِ harness على حساب مستخدم، ويفضل على جهاز، يمكنك تحمّل فقدانه.