DeepSeek Harness: jak naprawić błędy instalacji i wersji

Czym w rzeczywistości jest instalacja DeepSeek Harness

Instalacja DeepSeek Harness sprowadza się do jednego polecenia: npx @deepseek-ai/dsh web. Nie istnieje żaden instalator ani usługa wymagająca konfiguracji. Większość problemów, na które napotykają użytkownicy, nie dotyczy samej instalacji. Problemem jest rozstrzyganie wersji: którą kompilację @deepseek-ai/dsh uruchomiło dzisiaj npx oraz czy posiadana wersja Node.js jest w stanie ją obsłużyć.

Wszystkie poniższe kwestie wynikają z dwóch faktów. Po pierwsze, każda wersja @deepseek-ai/dsh opublikowana dotychczas w npm jest wersją typu release candidate, a tag latest wskazuje na jedną z nich. Według stanu na 18 sierpnia 2026 jest to 0.1.0-rc.7, opublikowana 17 sierpnia 2026. Po drugie, plik README projektu informuje, że harness znajduje się w fazie developer preview, jest szybko rozwijany i będzie zawierał zmiany powodujące brak kompatybilności wstecznej. Flaga, która działała w zeszłym tygodniu, może zostać usunięta w bieżącym. Przed budowaniem czegokolwiek na bazie tego narzędzia należy przypiąć konkretną wersję.

Najpierw kilka definicji. dsh to narzędzie wiersza poleceń DeepSeek Harness. Node.js to środowisko uruchomieniowe JavaScript, którego wymaga narzędzie. npx to uruchamiacz pakietów dostarczany wraz z npm (node package manager), który pobiera pakiet na żądanie zamiast instalować go na stałe.

Jakiej wersji Node.js wymaga dsh?

Katalog główny repozytorium package.json deklaruje "engines": {"node": "^22.19.0 || >=24.0.0"}, odczytane 18 sierpnia 2026 r. w wersji 0.1.0-rc.7. Wymagany jest zatem Node 22.19.0 lub nowszy w linii 22, albo Node 24 i wyższy. Node 20 nie jest wspierany.

Przed wykonaniem jakichkolwiek działań należy sprawdzić posiadaną wersję.

node -v
npm -v

Oto kwestia, która zaskakuje wielu użytkowników. Opublikowany pakiet @deepseek-ai/dsh nie posiada własnego pola engines. Deklaruje je jedynie katalog główny monorepo, a ten plik nie jest publikowany w npm. W rezultacie npm nie ma czego weryfikować, nie wyświetla ostrzeżenia EBADENGINE i nie blokuje instalacji. W środowisku Node 20 instalacja wygląda na poprawną, a błąd pojawia się później, gdy ładowany kod odwołuje się do składni lub API nieobsługiwanego przez używane środowisko uruchomieniowe. Nie istnieje jeden stały komunikat błędu, który można wyszukać, ponieważ to, która linia zawiedzie jako pierwsza, zależy od kolejności ładowania modułów. Należy zapoznać się z node -v zamiast analizować sam komunikat o awarii.

Jeśli wersja Node jest zbyt stara, nvm (node version manager) stanowi najmniej inwazyjne rozwiązanie na serwerze VPS, ponieważ instaluje środowisko w katalogu domowym użytkownika, nie ingerując w systemowy pakiet 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

Polecenie node -v powinno teraz wyświetlić wersję rozpoczynającą się od v24.. Jeśli powłoka nadal zgłasza starą wersję, oznacza to, że funkcja powłoki nvm nie została załadowana; należy otworzyć nową sesję logowania i spróbować ponownie. Node 24.19.0 jest aktywnym wydaniem LTS (long term support) na sierpień 2026 r. i stanowi lepszy cel z drugiego powodu, omówionego poniżej.

Dlaczego npx uruchamia codziennie inną wersję?

npx @deepseek-ai/dsh web nie określa wersji, więc npx pyta rejestr o to, na co wskazuje tag latest. Ten tag ulega zmianie. Gdy DeepSeek publikuje 0.1.0-rc.8, polecenie zapisane w notatkach zaczyna uruchamiać inny kod, bez żadnego monitu i bez wglądu w dziennik zmian.

Każdy ruchomy element można sprawdzić z poziomu wiersza poleceń.

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

dist-tags pokazuje, na co w tej chwili wskazuje latest. W dniu 18 sierpnia 2026 r. zarówno latest, jak i next wskazywały na 0.1.0-rc.7, więc nie ma osobnego stabilnego kanału, na który można by przełączyć. Lista versions jest bardziej interesująca, ponieważ zawiera luki: 0.0.1-rc.1, 0.0.1-rc.2, 0.0.1-rc.5, 0.1.0-rc.2, 0.1.0-rc.3, 0.1.0-rc.6, 0.1.0-rc.7. Liczby w tej sekwencji są pominięte, ponieważ niektóre wersje kandydackie (release candidates) nigdy nie zostały opublikowane. Próba odgadnięcia kolejnego -rc.N w skrypcie wdrożeniowym zakończy się niepowodzeniem, dlatego należy odczytać listę zamiast liczyć w górę.

Dlaczego npx ciągle uruchamia starą wersję?

Jest to odwrotny problem, a oba są prawdziwe w zależności od używanej wersji npm.

npx przechowuje własny katalog pakietów, oddzielony od pamięci podręcznej archiwów, w folderze o nazwie _npx wewnątrz pamięci podręcznej npm. Wyświetl ścieżkę i sprawdź jej zawartość.

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

Przez lata npx używał ponownie wszystkiego, co znalazł w tym miejscu dla nazwy pakietu bez wersji i nigdy nie odpytywał rejestru ponownie. npm 11.2.0 zmienił to zachowanie. Gdy specyfikacja jest samą nazwą lub zakresem wersji, npx pobiera teraz manifest i używa kopii z pamięci podręcznej tylko wtedy, gdy rozwiązane archiwum pasuje do tego, co właśnie zwrócił rejestr.

To, z jakim zachowaniem będziesz mieć do czynienia, zależy od wydania Node, ponieważ Node zawiera konkretną wersję npm:

• Node 20.20.2 zawiera npm 10.8.2.
• Node 22.19.0 zawiera npm 10.9.3.
• Node 22.23.2, najnowsze wydanie 22, zawiera npm 10.9.8.
• Node 24.19.0 zawiera npm 11.17.0.

Zatem cała linia Node 22, oficjalnie wspierana przez środowisko, dostarcza npm starszy niż 11.2.0. W Node 22 samo wywołanie npx @deepseek-ai/dsh web będzie ciągle uruchamiać wersję kandydującą (release candidate), która została zapisana w pamięci podręcznej tygodnie temu. To samo polecenie w Node 24 dokonuje ponownej weryfikacji przy każdym uruchomieniu. Jedno polecenie, dwa zachowania i żadne z nich nie wyświetla ostrzeżenia. Zapytaj narzędzie, czym jest:

npx @deepseek-ai/dsh --version

Czyszczenie pamięci podręcznej npx

W npm 11.2.0 i nowszych dostępne są dedykowane podpolecenia.

npm cache npx ls
npm cache npx rm --force

Bez użycia --force, npm odmawia usunięcia wszystkiego i wyświetla Please use --force to remove entire npx cache. Użyj najpierw npm cache npx ls, jeśli chcesz usunąć jeden wpis według klucza, zamiast usuwać wszystkie.

W npm 10 te podpolecenia nie istnieją, więc usuń katalog ręcznie.

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

npm cache clean --force w tym przypadku nie pomaga. Czyści ono _cacache, czyli magazyn archiwów, i pozostawia _npx bez zmian. To rozdzielenie jest dokładnie powodem, dla którego npm dodał później podpolecenia npm cache npx. Czyszczenie _npx również nie wiąże się z żadną trwałą utratą danych: przechowuje ono pobrane pakiety, podczas gdy stan Twojego środowiska znajduje się w $DSH_HOME/profiles/<name> i pozostaje nienaruszony.

Jak przypiąć konkretną wersję release candidate?

Należy podać pełny ciąg wersji, włącznie z częścią -rc.N.

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

--yes ma znaczenie w skryptach, ponieważ w przeciwnym razie npx wyświetla monit przed instalacją nieznanego pakietu i oczekuje na odpowiedź, która nigdy nie nadejdzie.

Dokładna wersja to również najszybsza ścieżka wykonania. npx tworzy klucz katalogu pamięci podręcznej na podstawie wpisanego specyfikatora, a w przypadku dokładnej wersji porównuje go z identyfikatorem pakietu już zainstalowanego w tym miejscu i uruchamia go bez żadnego odpytywania rejestru. W npm 11.2.0 i nowszych, użycie samej nazwy powoduje pobranie manifestu przy każdym uruchomieniu.

Instalacja globalna przypina wersję w ten sam sposób i udostępnia krótkie polecenie.

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

Nie znaleziono pasującej wersji dla @deepseek-ai/dsh@^0.1.0

Zakres z użyciem karetki lub tyldy nie pasuje do tego pakietu. npm install -g @deepseek-ai/dsh@^0.1.0 odpowiada kodem błędu ETARGET oraz linią No matching version found for @deepseek-ai/dsh@^0.1.0. Rejestr działa poprawnie. Jest to zasada semver: zakres wersji nie pasuje do wersji przedpremierowej, chyba że sam zakres wskazuje na wersję przedpremierową. Każda opublikowana kompilacja tego pakietu to -rc.N, czyli wersja przedpremierowa, więc ^0.1.0 nie pasuje do niczego. Należy wpisać dokładną wersję.

Ta zasada ma użyteczny efekt uboczny. Ponieważ zakresy nie mogą samoczynnie przejść na nowy release candidate, nie występuje stan częściowego przypięcia, który wymagałby analizy. Użytkownik korzysta albo z dokładnej wersji, albo z ruchomego tagu.

Czy używać npx, czy zainstalować dsh globalnie?

Użyj npx do wstępnego sprawdzenia, ponieważ nie pozostawia on żadnych śladów poza katalogiem pamięci podręcznej, który można łatwo wyczyścić. Użyj przypiętej instalacji globalnej dla wszystkiego, co musi działać po restarcie systemu, na przykład agenta programistycznego uruchomionego na VPS.

Obie metody mogą powodować konflikty na serwerze, jeśli użyto obu, dlatego należy je porównać.

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

which dsh brak wyników zaraz po poprawnej instalacji globalnej prawie zawsze oznacza, że globalny katalog binarny npm nie znajduje się w zmiennej PATH. Uruchom npm prefix -g, aby wyświetlić ścieżkę główną; pliki binarne znajdują się w folderze bin wewnątrz niej.

Uwaga dotycząca bezpieczeństwa. npx pobiera i wykonuje kod z rejestru przy każdym nowym rozwiązaniu zależności, co na serwerze stanowi realne zagrożenie, a nie tylko teoretyczne. Przypinanie wersji jest częścią rozwiązania. Reszta znajduje się w artykule jak ataki na łańcuch dostaw npm docierają do serwera.

Co wersja developer preview oznacza dla powtarzalności

0.1.0-rc.6 opublikowano 13 sierpnia 2026, a 0.1.0-rc.7 17 sierpnia 2026. Różnica wynosi cztery dni. W takim tempie instrukcje napisane miesiąc temu mogą opisywać wiersz poleceń, który już nie istnieje; dotyczy to również tej strony. Oznaczaj datą każde twierdzenie o wersji, które zapisujesz, wliczając w to własne notatki.

Dwa nawyki pozwalają przetrwać fazę preview. Przypinaj dokładną wersję w każdym poleceniu i skrypcie, aby ponowne budowanie serwera tworzyło ten sam zestaw narzędzi. Następnie czytaj dane wyjściowe pomocy z przypiętej kompilacji, zamiast polegać na jakimkolwiek przewodniku.

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

Druga połowa powtarzalności to profil. dsh --profile <name> uruchamia profil przechowywany w $DSH_HOME/profiles/<name>, a profile web oraz headless tworzą się same z dostarczonych szablonów przy pierwszym użyciu. Ten katalog jest również miejscem, z którego zestaw narzędzi odczytuje swój klucz API, model oraz ustawienia punktu końcowego, więc przypięta wersja i działająca konfiguracja to dwie oddzielne kwestie, które należy poprawnie skonfigurować. Pakiety wbudowane są rozwiązywane na podstawie aktualnie uruchomionej instalacji dsh, co oznacza, że zmiana przypiętej wersji zmienia również te pakiety. Wtyczki spoza drzewa (out-of-tree) zachowują się inaczej. Znajdują się one w katalogu profilu, a dsh plugin --profile <name> add <package> przekazuje swoje argumenty do pnpm w celu ich instalacji. Zatem pnpm musi znajdować się w Twoim PATH, a dsh jasno o tym informuje, gdy tak nie jest. Własny plik package.json profilu odpowiada za przypięcie tych wtyczek, więc kompletne przypięcie obejmuje dwa pliki, a nie jeden.

Ten podział będzie znajomy, jeśli utrzymywałeś narzędzia Python w odizolowanych środowiskach na serwerze: narzędzie oraz dodawane do niego elementy są przypięte w oddzielnych miejscach. Gdy zestaw narzędzi już wystartuje, kolejnym pytaniem jest zazwyczaj sieć, a nie wersje; w tym miejscu pomocne stają się uzyskiwanie dostępu do interfejsu Web UI dsh na zdalnym VPS oraz dłuższy przewodnik w instalacji DeepSeek Harness na VPS.

Błędy argumentów, które faktycznie wystąpią

Pochodzą one z własnego parsera CLI, dlatego są stabilne w całej linii wersji kandydujących (release candidate), a każdy z nich precyzyjnie wskazuje problem.

error: --profile <name> is required

Uruchomiono npx @deepseek-ai/dsh bez podkomendy i bez profilu. Polecenie wywołane w podstawowej formie uruchamia profil, więc wymaga podania nazwy. dsh web to podkomenda, która nie przyjmuje --profile, ponieważ automatycznie uruchamia dostarczony profil web.

error: --patch needs a path

Przekazano --patch bez żadnego argumentu po nim. Flaga jest powtarzalna, a każde jej wystąpienie wymaga podania jednej ścieżki do pliku.

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

Należy wybrać jedną z nich. --dump-default-config wypisuje warstwy dostarczonego pakietu i nie akceptuje --patch. --dump-config wypisuje złożoną konfigurację dla profilu. Obie opcje wyświetlają dane i kończą działanie bez uruchamiania środowiska testowego (harness), co czyni je bezpiecznym sposobem na sprawdzenie, co zmieniło się w nowej wersji kandydującej.

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

Dla dsh plugin --profile <name> nie podano żadnych argumentów do przekazania dalej. Podkomenda inicjalizuje profil, jeśli go brakuje, a następnie przekazuje resztę linii poleceń do pnpm, dlatego wymaga argumentów, takich jak add @scope/dsh-plugin-example.

FAQ

Jakiej wersji Node.js wymaga DeepSeek Harness?

Repozytorium deklaruje ^22.19.0 || >=24.0.0 w swoim głównym pliku package.json, odczytanym 18 sierpnia 2026 r. w wersji 0.1.0-rc.7. Wymagany jest zatem Node 22.19.0 lub nowszy z linii 22, albo Node 24 i nowsze. Node 20 nie będzie działać. Opublikowana paczka npm nie posiada własnego pola engines, więc npm nie wyświetla ostrzeżeń ani nie blokuje instalacji, a błąd występuje dopiero w czasie wykonywania. W pierwszej kolejności sprawdź node -v. Node 24 jest lepszym wyborem, ponieważ zawiera npm 11, który rozwiązuje problem ponownego użycia wersji przez npx.

Jak wymusić na npx użycie najnowszej wersji dsh zamiast wersji z pamięci podręcznej?

W npm 11.2.0 i nowszych, npx @deepseek-ai/dsh przy każdym uruchomieniu sprawdza rejestr dla nazwy paczki. W npm 10, który jest dołączony do każdego wydania Node 22, mechanizm ten nie działa. Wyczyść pamięć podręczną npx za pomocą npm cache npx rm --force w przypadku npm 11 lub usuń folder za pomocą rm -rf "$(npm config get cache)/_npx" w przypadku npm 10. Następnie potwierdź działanie poleceniem npx @deepseek-ai/dsh --version. Pamiętaj, że npm cache clean --force czyści inny katalog i nie rozwiąże tego problemu.

Dlaczego instalacja @deepseek-ai/dsh@^0.1.0 kończy się niepowodzeniem?

npm zwraca kod błędu ETARGET wraz z linią No matching version found for @deepseek-ai/dsh@^0.1.0.. Każda opublikowana kompilacja jest wersją przedpremierową, taką jak 0.1.0-rc.7, a zakres semver nie pasuje do wersji przedpremierowych, chyba że sam zakres taką wersję wskazuje. Zainstaluj konkretną wersję, uwzględniając przyrostek -rc.N. Uruchom npm view @deepseek-ai/dsh versions --json, aby sprawdzić dostępne wersje, ponieważ w sekwencji występują luki, w których kandydaci do wydania nie zostali opublikowani.

Czy instalować dsh globalnie, czy uruchamiać przez npx?

npx jest odpowiedni do pierwszego zapoznania się z narzędziem, ponieważ poza katalogiem pamięci podręcznej nic nie zostaje w systemie. Przypięta instalacja globalna, taka jak npm install -g @deepseek-ai/dsh@0.1.0-rc.7, jest odpowiednia dla środowisk produkcyjnych, ponieważ wersja zmienia się tylko wtedy, gdy użytkownik sam ją zmieni. Jeśli po instalacji globalnej polecenie dsh nie jest odnajdywane, oznacza to, że katalog binarny npm nie znajduje się w zmiennej PATH; polecenie npm prefix -g wyświetla ścieżkę, w której znajduje się ten katalog.

Czy DeepSeek Harness jest wystarczająco stabilny, aby na nim budować?

Według opisu projektu – jeszcze nie. Plik README wskazuje, że projekt znajduje się w fazie przeglądu deweloperskiego, szybko ewoluuje i będzie zawierał zmiany naruszające kompatybilność. Kandydaci do wydania 0.1.0-rc.6 i 0.1.0-rc.7 zostali opublikowani w odstępie czterech dni w sierpniu 2026 r. Należy przypiąć konkretną wersję i czytać --help z tej konkretnej kompilacji, a nie z zewnętrznych poradników. Notatki własne należy opatrywać datą, aby móc ocenić stopień ich dezaktualizacji.