رفع خطاهای نصب و نسخه DeepSeek Harness

نصب DeepSeek Harness واقعاً چیست

نصب DeepSeek Harness تنها یک دستور است: npx @deepseek-ai/dsh web. هیچ برنامه نصبی وجود ندارد و هیچ سرویسی برای پیکربندی نیست. بیشتر مشکلاتی که کاربران با آن مواجه می‌شوند، اصلاً مربوط به نصب نیست. مشکل اصلی، تعیین نسخه (version resolution) است: اینکه npx تصمیم گرفته کدام بیلد از @deepseek-ai/dsh را امروز اجرا کند و اینکه آیا نسخه Node.js شما توانایی اجرای آن را دارد یا خیر. زمانی که برنامه اجرا می‌شود، آدرسی که نمایش می‌دهد به localhost محدود شده است و اینکه چرا رابط کاربری وب فقط روی 127.0.0.1:3080 پاسخ می‌دهد، مسئله‌ای جدا از موارد مطرح‌شده در این صفحه است.

دو واقعیت، تمام موارد زیر را تعیین می‌کنند. نخست، هر نسخه از @deepseek-ai/dsh که تاکنون در npm منتشر شده، یک نسخه پیش‌انتشار (prerelease) است. بیشتر آن‌ها کاندیدای انتشار (-rc.N) هستند و از تاریخ 30 August 2026، بیلد‌های آلفا (-alpha.N) نیز وجود دارند. تگ latest به یک کاندیدای انتشار اشاره دارد. تا تاریخ 6 October 2026، این نسخه 0.2.0-rc.2 است که در 29 September 2026 منتشر شده است. دوم، فایل README پروژه بیان می‌کند که این harness در مرحله پیش‌نمایش توسعه‌دهنده است، به‌سرعت در حال تغییر است و تغییرات ناسازگار با نسخه‌های قبلی خواهد داشت. فلگی که هفته گذشته کار می‌کرد، ممکن است این هفته حذف شده باشد. پیش از آنکه چیزی بر پایه آن بسازید، نسخه آن را ثابت (pin) کنید.

ابتدا چند اصطلاح را تعریف می‌کنیم. dsh ابزار خط فرمان DeepSeek Harness است. Node.js محیط اجرای JavaScript است که به آن نیاز دارد. npx یک اجراکننده پکیج است که همراه با npm (مدیریت پکیج نود) عرضه می‌شود و پکیج را به‌جای نصب دائمی، در لحظه دریافت می‌کند. اگر کلمه harness در این جمله برای شما ناآشنا است، یک agent harness برنامه‌ای است که پیرامون مدل قرار می‌گیرد و حلقه، ابزارها، مجوزها و وضعیت نشست (session state) را مدیریت می‌کند؛ به همین دلیل است که یک شماره نسخه که شما انتخاب نکرده‌اید، می‌تواند رفتار agent شما را تغییر دهد.

dsh به کدام نسخه Node.js نیاز دارد؟

فایل package.json در ریشه مخزن، نسخه "engines": {"node": "^22.19.0 || >=24.0.0"} را اعلام می‌کند؛ این موضوع در تاریخ 6 اکتبر 2026 و زمانی که مخزن در نسخه 0.2.1-alpha.1 بود، بررسی شد. بنابراین به Node 22.19.0 یا جدیدتر در شاخه 22، یا Node 24 و بالاتر نیاز دارید. Node 20 پشتیبانی نمی‌شود.

پیش از هر اقدامی، نسخه فعلی خود را بررسی کنید.

node -v
npm -v

این بخشی است که کاربران را غافلگیر می‌کند. بسته منتشرشده @deepseek-ai/dsh هیچ فیلد engines مستقلی ندارد. تنها ریشه monorepo این فیلد را اعلام می‌کند و آن فایل ریشه هرگز در npm منتشر نمی‌شود. در نتیجه، npm چیزی برای بررسی ندارد، هیچ هشدار EBADENGINE چاپ نمی‌کند و مانع نصب نمی‌شود. در Node 20، فرآیند نصب موفقیت‌آمیز به نظر می‌رسد، اما خطا زمانی رخ می‌دهد که کد بارگذاری‌شده به سینتکس یا API خاصی دسترسی پیدا کند که در runtime شما وجود ندارد. هیچ رشته خطای واحد و پایداری برای جستجو وجود ندارد، زیرا اینکه کدام خط ابتدا با شکست مواجه شود، به ترتیب بارگذاری ماژول‌ها بستگی دارد. به جای بررسی متن خطا، node -v را مطالعه کنید.

اگر نسخه Node شما قدیمی است، استفاده از nvm (مدیریت نسخه Node) کم‌دردسرترین راهکار روی یک VPS است، زیرا در دایرکتوری home شما نصب می‌شود و به Node سیستمی دست نمی‌زند.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bash
exec $SHELL -l
nvm install 24
nvm use 24
node -v

دستور node -v اکنون باید نسخه‌ای را چاپ کند که با v24. شروع می‌شود. اگر shell همچنان نسخه قدیمی را گزارش می‌دهد، تابع shell مربوط به nvm بارگذاری نشده است؛ بنابراین یک login shell جدید باز کنید و دوباره امتحان کنید. Node 24 شاخه LTS (پشتیبانی بلندمدت) فعال تا تاریخ 6 اکتبر 2026 است و جدیدترین نسخه آن در این تاریخ 24.21.0 می‌باشد. این نسخه به دلیلی که در ادامه آمده، هدف بهتری است.

چرا npx هر روز نسخه متفاوتی را اجرا می‌کند؟

npx @deepseek-ai/dsh web هیچ نسخه‌ای را مشخص نمی‌کند، بنابراین npx از رجیستری می‌پرسد که برچسب latest به چه چیزی اشاره دارد. آن برچسب جابه‌جا می‌شود و این اتفاق زیاد رخ می‌دهد. 0.1.0-rc.8 در تاریخ 19 اوت 2026، دو روز پس از 0.1.0-rc.7 منتشر شد و تا 6 اکتبر 2026، latest به 0.2.0-rc.2 تغییر کرده بود. هر بار که این برچسب جابه‌جا می‌شود، دستوری که در یادداشت‌های خود دارید شروع به اجرای کد متفاوتی می‌کند، بدون اینکه هیچ اعلان یا لاگ تغییری (changelog) به شما نمایش داده شود.

شما می‌توانید تمام بخش‌های متغیر را از طریق خط فرمان بررسی کنید.

npm view @deepseek-ai/dsh dist-tags
npm view @deepseek-ai/dsh versions --json
npm view @deepseek-ai/dsh time --json

dist-tags نشان می‌دهد که در حال حاضر latest به کجا اشاره دارد. در تاریخ 6 اکتبر 2026، هر دو برچسب latest و next به 0.2.0-rc.2 اشاره می‌کردند و یک برچسب سوم به نام alpha به 0.2.1-alpha.1 اشاره داشت. هیچ‌کدام از این‌ها کانال پایداری برای سوئیچ کردن نیستند. لیست versions جالب‌تر است، زیرا در آن حفره‌هایی وجود دارد. در تاریخ 6 اکتبر 2026، این لیست شامل 30 نسخه از 0.0.1-rc.1 تا 0.2.1-alpha.1 بود. خط 0.0.1 از -rc.2 به -rc.5 می‌پرد، خط 0.1.0 از -rc.3 به -rc.6 می‌پرد، بیلد‌های آلفا از 0.1.2-alpha.2 و 0.1.3-alpha.2 شروع می‌شوند و اصلاً هیچ 0.1.4 وجود ندارد. اعداد به این دلیل گم شده‌اند که برخی بیلدها هرگز منتشر نشده‌اند و بیلد‌های آلفا و کاندیداهای انتشار (release candidates) در همان لیست با هم ترکیب شده‌اند. حدس زدن -rc.N بعدی در یک اسکریپت استقرار (deploy script) با شکست مواجه خواهد شد، بنابراین به‌جای شمارش رو به بالا، لیست را بخوانید.

چرا npx همچنان نسخه قدیمی را اجرا می‌کند؟

این دقیقاً نقطه مقابل شکایت قبلی است و بسته به اینکه از کدام نسخه npm استفاده می‌کنید، هر دو مورد صادق هستند.

npx دایرکتوری پکیج مخصوص به خود را دارد که از کش فایل‌های tarball جداست و در پوشه‌ای به نام _npx در داخل کش npm قرار دارد. مسیر آن را چاپ کنید و بررسی نمایید.

npm config get cache
ls "$(npm config get cache)/_npx"

سال‌ها npx برای نام‌های پکیج ساده (bare package name)، هر چه را در آنجا پیدا می‌کرد مجدداً استفاده می‌کرد و هرگز دوباره از registry پرس‌وجو نمی‌کرد. npm 11.2.0 این رفتار را تغییر داد. اکنون وقتی مشخصات پکیج یک نام ساده یا بازه‌ای از نسخه‌ها باشد، npx ابتدا manifest را دریافت می‌کند و تنها زمانی از نسخه کش‌شده استفاده می‌کند که tarball حل‌شده با آنچه registry به‌تازگی بازگردانده است، مطابقت داشته باشد.

اینکه کدام رفتار را دریافت می‌کنید توسط نسخه Node شما تعیین می‌شود، زیرا Node یک نسخه خاص از npm را همراه خود دارد:

• Node 20.20.2 شامل npm 10.8.2 است.
• Node 22.19.0 شامل npm 10.9.3 است.
• Node 22.23.3، جدیدترین نسخه 22 تا تاریخ 6 اکتبر 2026، شامل npm 10.9.9 است.
• Node 24.19.0 شامل npm 11.17.0 است.
• Node 24.21.0، جدیدترین نسخه 24 تا تاریخ 6 اکتبر 2026، شامل npm 11.19.0 است.

بنابراین کل سری Node 22 که harness به‌طور رسمی از آن پشتیبانی می‌کند، نسخه‌ای از npm قدیمی‌تر از 11.2.0 را ارائه می‌دهد. در Node 22، یک دستور ساده npx @deepseek-ai/dsh web همچنان همان release candidate که هفته‌ها پیش کش شده بود را اجرا می‌کند. همان دستور در Node 24 در هر بار اجرا، دوباره resolve می‌شود. یک دستور، دو رفتار متفاوت، و هیچ‌کدام هشداری به شما نمی‌دهند. از خود ابزار بپرسید که چیست:

npx @deepseek-ai/dsh --version

پاک‌سازی کش npx

در npm 11.2.0 و نسخه‌های جدیدتر، زیردستورهای اختصاصی وجود دارند.

npm cache npx ls
npm cache npx rm --force

بدون استفاده از --force، npm از پاک کردن همه چیز خودداری کرده و Please use --force to remove entire npx cache را چاپ می‌کند. زمانی که می‌خواهید یک ورودی خاص را بر اساس کلید حذف کنید و نه همه آن‌ها را، ابتدا از npm cache npx ls استفاده کنید.

در npm 10 این زیردستورها وجود ندارند، بنابراین باید دایرکتوری را شخصاً حذف کنید.

rm -rf "$(npm config get cache)/_npx"

npm cache clean --force در اینجا کمکی نمی‌کند. این دستور _cacache یعنی محل ذخیره tarballها را پاک می‌کند و کاری به _npx ندارد. همین جداسازی دقیقاً دلیلی است که npm بعداً زیردستورهای npm cache npx را اضافه کرد. پاک کردن _npx نیز هیچ هزینه دائمی برای شما ندارد: این پوشه فقط پکیج‌های دانلود شده را نگه می‌دارد، در حالی که وضعیت harness شما در $DSH_HOME/profiles/<name> قرار دارد و دست‌نخورده باقی می‌ماند.

چگونه یک نسخه release candidate خاص را پین (pin) کنم؟

رشته کامل نسخه، شامل بخش -rc.N را مشخص کنید.

npx --yes @deepseek-ai/dsh@0.1.0-rc.7 web

مثال‌های موجود در این صفحه از 0.1.0-rc.7 استفاده می‌کنند. بیلد (build) مورد نظر خود را که واقعاً تست کرده‌اید جایگزین کنید. در تاریخ 6 اکتبر 2026، تگ latest به 0.2.0-rc.2 اشاره می‌کرد.

استفاده از --yes در اسکریپت‌ها اهمیت دارد، زیرا در غیر این صورت npx پیش از نصب بسته‌ای که قبلاً مشاهده نکرده است، یک اعلان (prompt) نمایش می‌دهد و منتظر پاسخی می‌ماند که هرگز ارسال نمی‌شود.

نسخه دقیق، سریع‌ترین مسیر نیز هست. npx دایرکتوری کش خود را بر اساس رشته مشخصاتی که وارد کرده‌اید کلیدگذاری می‌کند و برای یک نسخه دقیق، آن را با شناسه بسته‌ای که قبلاً در آنجا نصب شده مقایسه کرده و بدون هیچ رفت‌وبرگشتی به registry، آن را اجرا می‌کند. در npm 11.2.0 و نسخه‌های جدیدتر، استفاده از نام ساده (bare name) باعث می‌شود در هر بار اجرا، یک درخواست fetch برای manifest ارسال شود.

نصب سراسری (global install) نیز به همین روش پین می‌شود و یک دستور کوتاه در اختیار شما قرار می‌دهد.

npm install -g @deepseek-ai/dsh@0.1.0-rc.7
dsh --version

هیچ نسخه‌ای مطابق با @deepseek-ai/dsh@^0.1.0 یافت نشد

استفاده از بازه‌های caret یا tilde برای این بسته با شکست مواجه می‌شود. npm install -g @deepseek-ai/dsh@^0.1.0 با کد خطای ETARGET و خط No matching version found for @deepseek-ai/dsh@^0.1.0. پاسخ می‌دهد. وضعیت registry سالم است. این یک قانون semver است: یک بازه نسخه با نسخه پیش‌انتشار (prerelease) مطابقت ندارد، مگر اینکه خود بازه نیز یک نسخه پیش‌انتشار را نام ببرد. هر بیلد منتشرشده از این بسته یک نسخه پیش‌انتشار است، یا -rc.N یا -alpha.N، بنابراین ^0.1.0 با هیچ‌چیزی مطابقت ندارد. نسخه دقیق را بنویسید.

این قانون یک اثر جانبی مفید دارد. از آنجا که بازه‌ها نمی‌توانند به سمت یک release candidate جدید حرکت کنند، هیچ وضعیت نیمه‌پین‌شده‌ای برای تحلیل وجود ندارد. شما یا روی یک نسخه دقیق هستید یا روی یک تگ متغیر.

آیا باید از npx استفاده کنم یا dsh را به‌صورت سراسری (global) نصب کنم؟

برای بررسی اولیه از npx استفاده کنید، زیرا به‌جز یک دایرکتوری کش که اکنون می‌دانید چگونه آن را پاک کنید، هیچ فایلی باقی نمی‌ماند. برای هر چیزی که باید پس از reboot همچنان کار کند، مانند یک عامل برنامه‌نویسی که روی یک VPS اجرا می‌کنید، از نصب سراسری با نسخه ثابت (pinned) استفاده کنید.

این دو روش ممکن است در سیستمی که از هر دو استفاده کرده‌اید با هم تداخل داشته باشند، بنابراین آن‌ها را با هم مقایسه کنید.

which dsh
dsh --version
npx @deepseek-ai/dsh --version

which dsh پیدا نشدن دستور بلافاصله پس از یک نصب سراسری موفق، تقریباً همیشه به این معنی است که دایرکتوری bin سراسری npm در PATH شما وجود ندارد. دستور npm prefix -g را اجرا کنید تا مسیر ریشه را چاپ کنید؛ فایل‌های اجرایی در پوشه bin در زیر آن قرار دارند.

یک نکته امنیتی: npx هر زمان که مورد جدیدی را resolve می‌کند، کد را از registry دریافت و اجرا می‌کند که در یک سرور، یک آسیب‌پذیری واقعی است، نه صرفاً تئوری. ثابت کردن نسخه (Pinning) بخشی از پاسخ است. بخش دیگر در نحوه نفوذ حملات زنجیره تأمین npm به سرور توضیح داده شده است.

معنای نسخه پیش‌نمایش توسعه‌دهنده برای تکرارپذیری

0.1.0-rc.6 در تاریخ 13 اوت 2026 و 0.1.0-rc.7 در 17 اوت 2026 منتشر شد. با فاصله چهار روز. سرعت انتشار از آن زمان کاهش نیافته است: 23 نسخه دیگر بین 19 اوت و 3 اکتبر 2026 منتشر شدند، از جمله 0.2.0-rc.1 در 28 سپتامبر و 0.2.0-rc.2 در روز بعد. با این سرعت، دستورالعمل‌هایی که یک ماه پیش نوشته شده‌اند ممکن است خط فرمانی را توصیف کنند که دیگر وجود ندارد، و این شامل همین صفحه نیز می‌شود. برای هر ادعای نسخه‌ای که یادداشت می‌کنید، از جمله یادداشت‌های خودتان، تاریخ بزنید.

دو عادت باعث می‌شود پیش‌نمایش قابل مدیریت باشد. نسخه دقیق را در هر دستور و هر اسکریپت ثابت (Pin) کنید تا بازسازی سرور، همان محیط اجرایی را ایجاد کند. سپس خروجی راهنما (help) را از همان بیلد ثابت‌شده بخوانید، نه از هیچ راهنمای دیگری.

npx @deepseek-ai/dsh@0.1.0-rc.7 --help
npx @deepseek-ai/dsh@0.1.0-rc.7 web --dump-config

بخش دوم تکرارپذیری، پروفایل است. dsh --profile <name> پروفایل ذخیره‌شده در $DSH_HOME/profiles/<name> را بارگذاری می‌کند و پروفایل‌های web و headless در اولین استفاده، خود را از قالب‌های ارائه‌شده می‌سازند. آن دایرکتوری همچنین جایی است که محیط اجرایی کلید API، مدل و تنظیمات endpoint خود را از آن می‌خواند، بنابراین یک نسخه ثابت‌شده و یک پیکربندی کاری، دو مورد مجزا هستند که باید به‌درستی تنظیم شوند. بسته‌های داخلی (In-box) از نصب dsh که در حال اجراست حل می‌شوند، به این معنی که تغییر نسخه ثابت‌شده شما، آن بسته‌ها را نیز تغییر می‌دهد. افزونه‌های خارج از درخت (Out-of-tree) رفتار متفاوتی دارند. آن‌ها در دایرکتوری پروفایل قرار دارند و dsh plugin --profile <name> add <package> آرگومان‌های خود را برای نصب به pnpm ارسال می‌کند. بنابراین pnpm باید در PATH شما باشد و dsh وقتی این‌طور نیست، به‌وضوح اعلام می‌کند. هر افزونه‌ای که اضافه می‌کنید با همان دسترسی‌هایی اجرا می‌شود که agent شما دارد، که ارزش بررسی دسترسی‌های یک افزونه پیش از نصب را دارد. فایل package.json خودِ پروفایل است که آن افزونه‌ها را ثابت می‌کند، بنابراین یک ثابت‌سازی کامل شامل دو فایل است، نه یکی.

اگر ابزارهای پایتون را در محیط‌های ایزوله روی سرور نگه داشته باشید، این جداسازی برایتان آشنا خواهد بود: ابزار و چیزهایی که به آن اضافه می‌کنید در مکان‌های جداگانه‌ای ثابت می‌شوند. هنگامی که محیط اجرایی شروع به کار می‌کند، سوال بعدی معمولاً به جای نسخه‌ها، شبکه است؛ جایی که دسترسی به رابط کاربری وب dsh روی یک VPS راه دور و راهنمای طولانی‌تر در نصب DeepSeek Harness روی یک VPS وارد عمل می‌شوند.

خطاهای آرگومان که با آن‌ها مواجه خواهید شد

این خطاها از پارسر داخلی CLI ناشی می‌شوند و هر کدام مشکل دقیق را مشخص می‌کنند. متن پیام‌ها در نسخه‌های مختلف تا حد زیادی ثابت مانده است، اما نه به‌طور کامل؛ بنابراین پیام‌های زیر در تاریخ 6 اکتبر 2026 با نسخه 0.2.0-rc.2 مطابقت داده شده‌اند.

error: --profile <name> is required

شما npx @deepseek-ai/dsh را بدون زیردستور و بدون پروفایل اجرا کرده‌اید. دستور پایه یک پروفایل را بوت می‌کند، بنابراین به یک نام نیاز دارد. dsh web بدون --profile کار می‌کند زیرا پارسر اولین کلمه را به عنوان نام پروفایل می‌خواند و در نتیجه پروفایل پیش‌فرض web را برای شما بوت می‌کند.

error: --patch needs a path

--patch بدون هیچ مقداری پس از آن فراخوانی شده است. این فلگ قابل تکرار است و هر بار استفاده از آن، یک مسیر فایل دریافت می‌کند.

error: --dump-config and --dump-default-config are mutually exclusive

یکی را انتخاب کنید. در 0.2.0-rc.2، یعنی بیلد latest که در تاریخ 6 اکتبر 2026 به آن اشاره شد، پیام خطا به یک فلگ سوم نیز اشاره دارد و به صورت error: --dump-config, --dump-default-config, and --dump-config-schema are mutually exclusive نمایش داده می‌شود؛ زیرا --dump-config-schema که طرح JSON برای ورودی‌های پروفایل و پچ‌ها را چاپ می‌کند، به دو مورد دیگر اضافه شده است. --dump-default-config لایه‌های باندل ارائه‌شده را چاپ می‌کند و هیچ --patch را نمی‌پذیرد. --dump-config پیکربندی نهایی (composed) برای یک پروفایل را چاپ می‌کند. تمام این دستورات بدون راه‌اندازی harness، اطلاعات را چاپ کرده و خارج می‌شوند؛ این ویژگی آن‌ها را به روشی ایمن برای مشاهده تغییرات اعمال‌شده در یک نسخه کاندید (release candidate) تبدیل می‌کند.

error: plugin needs pnpm arguments to forward (e.g. add <package>)

به dsh plugin --profile <name> هیچ مقداری برای انتقال داده نشده است. این زیردستور در صورت نبود پروفایل، آن را مقداردهی اولیه می‌کند و سپس باقی خط فرمان را به pnpm می‌سپارد، بنابراین به آرگومان‌هایی مانند add @scope/dsh-plugin-example نیاز دارد.

FAQ

DeepSeek Harness به کدام نسخه از Node.js نیاز دارد؟

مخزن پروژه در فایل package.json ریشه خود، نسخه ^22.19.0 || >=24.0.0 را اعلام کرده است. این موضوع در تاریخ 6 اکتبر 2026 و زمانی که مخزن در نسخه 0.2.1-alpha.1 بود، بررسی شد. بنابراین به Node 22.19.0 یا نسخه‌های جدیدتر در شاخه 22، یا Node 24 و بالاتر نیاز دارید. Node 20 کار نخواهد کرد. بسته منتشر شده در npm فاقد فیلد engines است، بنابراین npm هرگز به شما هشدار نمی‌دهد و نصب را مسدود نمی‌کند؛ در نتیجه خطا در زمان اجرا (runtime) ظاهر می‌شود. ابتدا node -v را بررسی کنید. در هر صورت Node 24 انتخاب بهتری است، زیرا شامل npm 11 است که مشکل استفاده مجدد از نسخه در npx را برطرف می‌کند.

چگونه npx را مجبور کنم به جای نسخه کش‌شده، از جدیدترین dsh استفاده کند؟

در npm 11.2.0 و نسخه‌های جدیدتر، npx @deepseek-ai/dsh در هر بار اجرا، رجیستری را برای نام بسته بررسی می‌کند. در npm 10 که همراه با تمام نسخه‌های Node 22 ارائه می‌شود، این اتفاق نمی‌افتد. کش npx را در npm 11 با npm cache npx rm --force پاک کنید، یا در npm 10 پوشه مربوطه را با rm -rf "$(npm config get cache)/_npx" حذف نمایید. سپس با npx @deepseek-ai/dsh --version تأیید کنید. توجه داشته باشید که npm cache clean --force دایرکتوری متفاوتی را پاک می‌کند و این مشکل را حل نخواهد کرد.

چرا نصب @deepseek-ai/dsh@^0.1.0 با شکست مواجه می‌شود؟

npm کد خطای ETARGET را همراه با خط No matching version found for @deepseek-ai/dsh@^0.1.0. برمی‌گرداند. تمام نسخه‌های منتشر شده، پیش‌انتشار (prerelease) هستند، مانند 0.2.0-rc.2 یا 0.2.1-alpha.1، و یک بازه semver با نسخه‌های پیش‌انتشار مطابقت ندارد مگر اینکه خود بازه شامل یکی از آن‌ها باشد. نسخه دقیق را به همراه پسوند آن نصب کنید. دستور npm view @deepseek-ai/dsh versions --json را اجرا کنید تا ببینید کدام نسخه‌ها موجود هستند، زیرا در توالی نسخه‌ها شکاف‌هایی وجود دارد که در آن‌ها هیچ بیلد (build) منتشر نشده است.

آیا باید dsh را به صورت سراسری (global) نصب کنم یا از طریق npx اجرا کنم؟

npx برای بررسی اولیه مناسب است، زیرا به جز دایرکتوری کش، چیزی در سیستم باقی نمی‌ماند. نصب سراسریِ ثابت (pinned) مانند npm install -g @deepseek-ai/dsh@0.1.0-rc.7 برای هر کاری که باید به طور مداوم کار کند مناسب است، زیرا نسخه فقط زمانی تغییر می‌کند که شما آن را تغییر دهید. اگر پس از نصب سراسری، دستور dsh پیدا نشد، دایرکتوری bin سراسری npm در PATH شما وجود ندارد و npm prefix -g مسیری که در آن قرار دارد را چاپ می‌کند.

آیا DeepSeek Harness برای توسعه به اندازه کافی پایدار است؟

هنوز خیر، طبق توضیحات خود پروژه. فایل README بیان می‌کند که این پروژه در مرحله پیش‌نمایش توسعه‌دهنده (developer preview) است، به سرعت در حال تغییر است و تغییرات ناسازگار با نسخه‌های قبلی خواهد داشت. نسخه‌های کاندیدای 0.1.0-rc.6 و 0.1.0-rc.7 در آگوست 2026 با فاصله چهار روز از هم منتشر شدند و 0.2.0-rc.1 و 0.2.0-rc.2 در سپتامبر 2026 با فاصله یک روز از هم منتشر شدند. یک نسخه دقیق را ثابت (pin) کنید و --help را از همان بیلد ثابت بخوانید، نه از هیچ راهنمای دیگری. برای یادداشت‌های خود تاریخ بزنید تا بتوانید تشخیص دهید چقدر قدیمی شده‌اند.