DeepSeek Harness 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 ustalenie wersji: którą kompilację @deepseek-ai/dsh uruchomiło dzisiaj npx oraz czy posiadana wersja Node.js jest w stanie ją obsłużyć. Gdy narzędzie wystartuje, wyświetlony adres jest powiązany z localhost, a przyczyna, dla której interfejs WWW odpowiada tylko na 127.0.0.1:3080 jest kwestią odrębną od problemów opisanych na tej stronie.

Wszystkie poniższe informacje wynikają z dwóch faktów. Po pierwsze, każda wersja @deepseek-ai/dsh opublikowana dotychczas w npm jest wersją przedpremierową. Większość to kandydaci do wydania (-rc.N), a od 30 sierpnia 2026 dostępne są również kompilacje alfa (-alpha.N). Znacznik latest wskazuje na kandydata do wydania. Według stanu na 6 października 2026 jest to 0.2.0-rc.2, opublikowane 29 września 2026. Po drugie, plik README projektu informuje, że harness znajduje się w fazie developer preview, jest intensywnie rozwijany i będzie zawierał zmiany naruszające kompatybilność. Flaga, która działała w zeszłym tygodniu, może zostać usunięta w bieżącym. Należy przypiąć wersję przed budowaniem czegokolwiek w oparciu o to narzędzie.

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. Jeśli termin harness jest w tym kontekście niejasny, agent harness to program otaczający model, który zarządza pętlą, narzędziami, uprawnieniami oraz stanem sesji. Dlatego wersja, której nie wybrano świadomie, może zmienić sposób działania agenta.

Jakiej wersji Node.js wymaga dsh?

Katalog główny repozytorium package.json deklaruje "engines": {"node": "^22.19.0 || >=24.0.0"}, co odczytano 6 października 2026 r., gdy repozytorium było w wersji 0.2.1-alpha.1. Wymagany jest zatem Node 22.19.0 lub nowszy z 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 często zaskakuje użytkowników. Opublikowany pakiet @deepseek-ai/dsh nie zawiera własnego pola engines. Deklaruje je jedynie katalog główny monorepo, a ten plik nigdy nie jest publikowany w npm. W rezultacie npm nie ma czego sprawdzać, 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, których dane środowisko uruchomieniowe nie posiada. 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 posiadana wersja Node jest zbyt stara, nvm (node version manager) stanowi najmniej inwazyjne rozwiązanie na serwerze VPS, ponieważ instaluje oprogramowanie w katalogu domowym użytkownika, nie naruszając systemowego 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 jest aktywną linią LTS (long term support) na dzień 6 października 2026 r., a jej najnowsze wydanie w tym dniu to 24.21.0. Jest to lepszy cel również z drugiego powodu, opisanego poniżej.

Dlaczego npx uruchamia codziennie inną wersję?

npx @deepseek-ai/dsh web nie określa wersji, więc npx pobiera z rejestru to, na co wskazuje tag latest. Ten tag zmienia się często. Wersja 0.1.0-rc.8 pojawiła się 19 sierpnia 2026, dwa dni po 0.1.0-rc.7, a do 6 października 2026 latest przesunęło się na 0.2.0-rc.2. Za każdym razem, gdy tag się zmienia, polecenie zapisane w notatkach zaczyna uruchamiać inny kod, bez żadnego powiadomienia czy dziennika zmian przed oczami użytkownika.

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 aktualnie wskazuje latest. 6 października 2026 zarówno latest, jak i next wskazywały na 0.2.0-rc.2, a trzeci tag, alpha, wskazywał na 0.2.1-alpha.1. Żaden z nich nie stanowi stabilnego kanału, na który można przejść. Lista versions jest ciekawsza, ponieważ zawiera luki. 6 października 2026 zawierała 30 wersji, od 0.0.1-rc.1 do 0.2.1-alpha.1. Linia 0.0.1 przeskakuje z -rc.2 na -rc.5, linia 0.1.0 przeskakuje z -rc.3 na -rc.6, kompilacje alfa zaczynają się od 0.1.2-alpha.2 i 0.1.3-alpha.2, a wersji 0.1.4 w ogóle nie ma. Numery są pominięte, ponieważ niektóre kompilacje nigdy nie zostały opublikowane, a kompilacje alfa i kandydaci do wydania (release candidates) są przemieszane na tej samej liście. Próba odgadnięcia kolejnego -rc.N w skrypcie wdrożeniowym zakończy się niepowodzeniem, dlatego należy odczytywać listę zamiast liczyć w górę.

Dlaczego npx ciągle uruchamia starą wersję?

To odwrotny problem, jednak 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, nigdy nie odpytując rejestru ponownie. Zmieniło się to w npm 11.2.0. 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 zgadza się z tym, co właśnie zwrócił rejestr.

O tym, które zachowanie występuje, decyduje wydanie Node, ponieważ Node zawiera w pakiecie konkretną wersję npm:

• Node 20.20.2 zawiera npm 10.8.2.
• Node 22.19.0 zawiera npm 10.9.3.
• Node 22.23.3, najnowsze wydanie 22 na dzień 6 października 2026, zawiera npm 10.9.9.
• Node 24.19.0 zawiera npm 11.17.0.
• Node 24.21.0, najnowsze wydanie 24 na dzień 6 października 2026, zawiera npm 11.19.0.

Cała linia Node 22, oficjalnie wspierana przez środowisko, dostarcza npm starszy niż 11.2.0. W Node 22 samo polecenie 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 rozwiązuje zależności ponownie przy każdym uruchomieniu. Jedno polecenie, dwa zachowania, a żadne z nich nie wyświetla ostrzeżenia. Sprawdź wersję narzędzia:

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 flagi --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 wszystkich.

W npm 10 te podpolecenia nie istnieją, więc należy usunąć katalog ręcznie.

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

Polecenie npm cache clean --force tutaj 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 nie powoduje trwałych strat: przechowuje ono pobrane pakiety, podczas gdy stan ś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

Przykłady na tej stronie używają 0.1.0-rc.7. Należy podstawić wersję, która została faktycznie przetestowana. W dniu 6 października 2026 tag latest wskazywał na 0.2.0-rc.2.

--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 używa specyfikacji jako klucza dla katalogu pamięci podręcznej. W przypadku dokładnej wersji npx porównuje ją z identyfikatorem pakietu już zainstalowanego w pamięci podręcznej i uruchamia go bez odpytywania rejestru. W npm 11.2.0 i nowszych, podanie samej nazwy powoduje pobranie manifestu przy każdym uruchomieniu.

Instalacja globalna pozwala na przypięcie w ten sam sposób i zapewnia krótką komendę.

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

No matching version found for @deepseek-ai/dsh@^0.1.0

Zakresy z użyciem karetki lub tyldy nie działają w przypadku tego pakietu. npm install -g @deepseek-ai/dsh@^0.1.0 odpowiada kodem błędu ETARGET oraz komunikatem 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 jest wersją przedpremierową, oznaczoną jako -rc.N lub -alpha.N, dlatego ^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 dynamicznego taga.

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

Użyj npx do pierwszego 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 wersji 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 bin npm nie znajduje się w 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 sposobach, w jakie ataki na łańcuch dostaw npm docierają do serwera.

Co oznacza wersja developer preview dla powtarzalności

0.1.0-rc.6 opublikowano 13 sierpnia 2026, a 0.1.0-rc.7 17 sierpnia 2026. Dzieliły je cztery dni. Od tego czasu tempo nie spadło: między 19 sierpnia a 3 października 2026 wydano 23 kolejne wersje, w tym 0.2.0-rc.1 28 września oraz 0.2.0-rc.2 dzień później. Przy takim tempie instrukcje napisane miesiąc temu mogą opisywać wiersz poleceń, który już nie istnieje; dotyczy to również tej strony. Należy datować każde stwierdzenie dotyczące wersji, w tym własne notatki.

Dwa nawyki pozwalają przetrwać korzystanie z wersji preview. Należy przypiąć dokładną wersję w każdym poleceniu i skrypcie, aby ponowne budowanie serwera skutkowało tym samym środowiskiem. Następnie należy czytać dane wyjściowe pomocy z przypiętej kompilacji, a nie z jakiegokolwiek poradnika.

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

Drugą połową powtarzalności jest 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 środowisko 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. Dlatego pnpm musi znajdować się w PATH, o czym dsh wyraźnie informuje, gdy tak nie jest. Każda dodana wtyczka działa z tymi samymi uprawnieniami, co agent, dlatego warto sprawdzić, do czego wtyczka ma dostęp przed jej instalacją. Własny plik package.json profilu przypina te wtyczki, więc kompletne przypięcie obejmuje dwa pliki, a nie jeden.

Ten podział będzie znajomy dla osób, które utrzymywały narzędzia Python w izolowanych środowiskach na serwerze: narzędzie oraz dodane do niego elementy są przypięte w oddzielnych miejscach. Gdy środowisko już wystartuje, kolejnym pytaniem zazwyczaj nie są wersje, lecz sieć. 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 i każdy z nich wskazuje dokładny problem. Sformułowania pozostały w większości niezmienne w kolejnych kompilacjach, choć nie całkowicie, dlatego poniższe komunikaty zostały zweryfikowane względem 0.2.0-rc.2 w dniu 6 października 2026.

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 działa bez --profile, ponieważ parser odczytuje pierwsze słowo jako nazwę profilu, więc automatycznie uruchamia dostarczony profil web.

error: --patch needs a path

--patch zostało przekazane bez argumentu. 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. W 0.2.0-rc.2, w kompilacji latest wskazanej 6 października 2026, komunikat wymienia trzecią flagę i brzmi error: --dump-config, --dump-default-config, and --dump-config-schema are mutually exclusive, ponieważ do pozostałych dwóch dołączyła flaga --dump-config-schema, która wypisuje schemat JSON dla wpisów profilu i łatek. --dump-default-config wypisuje dostarczone warstwy pakietu i nie przyjmuje żadnych --patch. --dump-config wypisuje złożoną konfigurację dla profilu. Wszystkie one wypisują dane i kończą działanie bez uruchamiania środowiska testowego, co czyni je bezpiecznym sposobem na sprawdzenie zmian wprowadzonych przez nowy kandydat do wydania.

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

dsh plugin --profile <name> nie otrzymało żadnych argumentów do przekazania dalej. Podkomenda inicjalizuje profil, jeśli go brakuje, a następnie przekazuje resztę wiersza poleceń do pnpm, więc 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 6 października 2026 r., gdy repozytorium znajdowało się w wersji 0.2.1-alpha.1. 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ń i nie blokuje instalacji, a błąd pojawia się 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 pod kątem nazwy paczki. W npm 10, który jest dołączany 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ź za pomocą 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.2.0-rc.2 lub 0.2.1-alpha.1, a zakres semver nie pasuje do wersji przedpremierowych, chyba że sam zakres taką wersję wskazuje. Zainstaluj dokładną wersję, wliczając w to sufiks. Uruchom npm view @deepseek-ai/dsh versions --json, aby sprawdzić, które wersje istnieją, ponieważ w sekwencji występują luki, w których kompilacje nigdy nie zostały opublikowane.

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 pozostaje w systemie. Przypięta instalacja globalna, taka jak npm install -g @deepseek-ai/dsh@0.1.0-rc.7, jest odpowiednia dla wszystkiego, co musi działać w sposób ciągły, ponieważ wersja zmienia się tylko wtedy, gdy użytkownik sam ją zmieni. Jeśli po instalacji globalnej polecenie dsh nie zostanie znalezione, oznacza to, że globalny katalog binarny npm nie znajduje się w zmiennej PATH, a npm prefix -g wyświetla ścieżkę główną, w której się on znajduje.

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

Według własnego 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., a 0.2.0-rc.1 i 0.2.0-rc.2 w odstępie jednego dnia we wrześniu 2026 r. Przypnij dokładną wersję i czytaj --help z tej konkretnej kompilacji, a nie z jakiegokolwiek poradnika. Datuj własne notatki, aby móc ocenić, jak bardzo stały się nieaktualne.