SSD Nodes Learn Hosting plans →
Посібники Matt ConnorВід Matt Connor

Як виправити помилки встановлення DeepSeek Harness

Усі збірки DeepSeek Harness ще prerelease. Зафіксуйте точну версію dsh, очистьте кеш npx і перевірте, який npm фактично запускаєте.

Що насправді являє собою встановлення DeepSeek Harness

Встановлення DeepSeek Harness — це одна команда: npx @deepseek-ai/dsh web. Інсталятора немає, і налаштовувати сервіс не потрібно. Більшість проблем, з якими стикаються користувачі, взагалі не пов’язані з інсталяцією. Це проблеми визначення версії: яку збірку @deepseek-ai/dsh сьогодні вирішив запустити npx і чи сумісна вона з вашою версією Node.js. Після запуску програма прив’язує виведену нею адресу до localhost. Причина, через яку Web UI відповідає лише на 127.0.0.1:3080, описана окремо: чому Web UI відповідає лише на 127.0.0.1:3080.

Нижче все визначають два факти. По-перше, усі версії @deepseek-ai/dsh, опубліковані в npm дотепер, є попередніми. Більшість із них — кандидати на випуск (-rc.N), а з 30 August 2026 також доступні alpha-збірки (-alpha.N). Тег latest вказує на кандидата на випуск. Станом на 10 October 2026 це 0.2.0-rc.2, опублікована 29 September 2026. По-друге, у README проєкту зазначено, що harness перебуває на етапі developer preview, швидко розвивається та матиме зміни, які порушують сумісність. Прапорець, який працював минулого тижня, цього тижня може зникнути. Зафіксуйте версію, перш ніж будувати на її основі будь-яку інфраструктуру.

Спочатку визначимо кілька термінів. dsh — це інструмент командного рядка DeepSeek Harness. Node.js — середовище виконання JavaScript, потрібне цьому інструменту. npx — засіб запуску пакетів, який постачається з npm (node package manager) і завантажує пакет за потреби, не встановлюючи його назавжди. Якщо термін harness у цьому реченні незрозумілий, harness агента — це програма навколо моделі, яка керує циклом виконання, інструментами, дозволами та станом сеансу. Саме тому номер версії, який ви не вибирали, може змінити поведінку вашого агента.

Яка версія Node.js потрібна dsh?

Кореневий файл репозиторію package.json оголошує "engines": {"node": "^22.19.0 || >=24.0.0"}. Ці дані актуальні станом на 10 October 2026, коли репозиторій мав версію 0.2.1-alpha.2. Тому потрібна 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 version manager) є найменш інвазивним способом виправлення на VPS, оскільки він встановлюється у ваш домашній каталог і не змінює системну 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 і далі показує стару версію, виконайте which node. Шлях поза ~/.nvm зазвичай має одну з двох причин. Або функцію shell nvm не було завантажено: відкрийте новий login shell і повторіть перевірку. Або рядок у профілі shell змінює PATH після рядків, які завантажують nvm, і додає іншу Node на початок шляху: перемістіть цей рядок вище за рядки nvm. Станом на 10 October 2026 Node 24 є активною гілкою LTS (long term support), а її найновіший реліз на цю дату — 24.21.0. Цього місяця ситуація зміниться: 20 October 2026 Node 24 перейде в режим maintenance, а 28 October 2026 Node 26, яку також дозволяє діапазон >=24.0.0, стане активною гілкою LTS. Будь-яка з них є кращою ціллю, ніж Node 22, з другої причини, описаної нижче.

Чому npx щодня запускає іншу версію?

npx @deepseek-ai/dsh web не містить номера версії. Якщо тільки в поточному каталозі проєкту вже не встановлено @deepseek-ai/dsh. У такому разі npx запускає цю копію. Інакше npx запитує в registry версію, на яку вказує тег latest. Цей тег часто змінюється. 0.1.0-rc.8 було опубліковано 19 August 2026, через два дні після 0.1.0-rc.7, а станом на 10 October 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. 10 October 2026 і latest, і next вказували на 0.2.0-rc.2, а третій тег, alpha, вказував на 0.2.1-alpha.2, опублікований напередодні. Жоден із них не є стабільним каналом, на який можна перейти. Список versions цікавіший, оскільки в ньому є пропуски. 10 October 2026 він містив 31 версію — від 0.0.1-rc.1 до 0.2.1-alpha.2. Рядок 0.0.1 переходить від -rc.2 до -rc.5, рядок 0.1.0 — від -rc.3 до -rc.6, alpha-збірки починаються з 0.1.2-alpha.2 і 0.1.3-alpha.2, а 0.1.4 взагалі немає. Номери відсутні, оскільки деякі збірки не було опубліковано, а alpha-збірки та release candidate розміщено в одному списку впереміш. Спроба вгадати наступний -rc.N у deploy-скрипті завершиться помилкою, тому читайте список, а не збільшуйте номер послідовно.

Чому npx продовжує запускати стару версію?

Це протилежна проблема. Обидва твердження правильні — усе залежить від версії npm, яку ви запускаєте.

npx має власний каталог пакетів, окремий від кешу tarball. Він розташований у каталозі _npx всередині кешу npm. Виведіть цей шлях і перегляньте каталог.

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

Протягом багатьох років npx повторно використовував усе, що знаходив там для простого імені пакета, і більше не звертався до registry. npm 11.2.0 змінив цю поведінку. Якщо spec є простим іменем або діапазоном версій, а пакет ще не встановлено в поточному проєкті, npx тепер отримує manifest і повторно використовує кешовану копію в _npx лише тоді, коли tarball після визначення версії збігається з тим, який щойно повернув registry. Просте ім’я все одно відповідає версії, встановленій у поточному проєкті, без перевірки registry.

Поведінка залежить від фактичної версії npm, яку ви запускаєте. Якщо ви не оновлювали npm окремо за допомогою npm install -g npm, використовується версія npm, яку постачає ваш реліз Node:

  • Node 20.20.2 постачається з npm 10.8.2.
  • Node 22.19.0 постачається з npm 10.9.3.
  • Node 22.23.3, найновіший реліз 22 станом на 10 October 2026, постачається з npm 10.9.9.
  • Node 24.19.0 постачається з npm 11.17.0.
  • Node 24.21.0, найновіший реліз 24 станом на 10 October 2026, постачається з npm 11.19.0.

Отже, у всій лінійці Node 22, яку офіційно підтримує harness, використовується npm, старіший за 11.2.0. У Node 22 із вбудованою версією npm простий npx @deepseek-ai/dsh web продовжить запускати release candidate, який було кешовано кілька тижнів тому. Та сама команда в Node 24 під час кожного запуску повторно визначає версію через registry, якщо каталог, з якого її запущено, не є проєктом із власною копією dsh. Одна команда, дві різні поведінки, і жодна з них не попереджає про це. Запитайте інструмент, яку версію він використовує:

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 cache npx в npm. Очищення _npx також не має постійних наслідків: там зберігаються завантажені пакети, а стан harness розташований у $DSH_HOME/profiles/<name> і не змінюється.

Як зафіксувати точний release candidate?

Укажіть повний рядок версії, включно з частиною -rc.N.

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

У прикладах на цій сторінці використовується 0.1.0-rc.7. Замініть його на збірку, яку ви фактично протестували. 10 October 2026 тег latest вказував на 0.2.0-rc.2.

--yes має значення у скрипті, оскільки інакше npx виводить запит перед інсталяцією пакета, якого ще не знаходив, і чекає на відповідь, яка не надходить.

Точна версія також є найшвидшим варіантом. npx формує шлях до каталогу кешу на основі введеного рядка специфікації. Для точної версії він порівнює цей рядок з ідентифікатором пакета, який уже встановлено в кеші, і запускає його без жодного звернення до registry. У npm 11.2.0 і новіших версіях запуск bare name поза проєктом, який інсталює dsh, спричиняє завантаження manifest під час кожного запуску.

Глобальна інсталяція працює за тим самим принципом фіксації та дає змогу використовувати коротку команду.

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-версії, якщо жоден із власних comparator цього діапазону не містить prerelease з такими самими номерами major, minor і patch. Кожна опублікована збірка цього пакета є prerelease: або -rc.N, або -alpha.N. ^0.1.0 не містить жодного prerelease, тому він не відповідає нічому. Укажіть точну версію.

Це правило працює в обох напрямках. Звичайний діапазон ніколи не перейде на новий release candidate, але діапазон із prerelease може це зробити. ^0.1.0-rc.7 означає >=0.1.0-rc.7 <0.2.0-0, тому він приймає 0.1.0-rc.8 і прийняв би фінальну версію 0.1.0, тоді як 0.1.1-rc.1 не відповідає йому через інші номери. Це частково зафіксований стан між точною версією та рухомим тегом. Він змінює версію, яка запускається, без будь-яких змін із вашого боку. Якщо потрібна саме протестована збірка й нічого іншого, укажіть точну версію.

Чи варто використовувати npx або встановити dsh глобально?

Використовуйте npx для першої перевірки, оскільки після цього нічого не залишається, крім каталогу кешу, який ви тепер знаєте як очистити. Для всього, що має й надалі працювати після перезавантаження, використовуйте глобальне встановлення з фіксованою версією, наприклад для coding agent, який ви постійно запускаєте на VPS.

На сервері, де ви використовували обидва варіанти, результати можуть відрізнятися. Тому порівняйте їх.

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

which dsh виведення нічого одразу після успішного глобального встановлення майже завжди означає, що глобальний каталог bin для npm відсутній у вашому PATH. Виконайте npm prefix -g, щоб вивести кореневий каталог. Бінарні файли розташовані в каталозі bin під ним.

Важливе зауваження щодо безпеки. npx завантажує та виконує код із registry щоразу, коли знаходить новий пакет. На сервері це реальний ризик, а не теоретична загроза. Фіксація версії є частиною рішення. Інша частина описана в матеріалі як атаки на ланцюг постачання npm проникають на сервер.

Що developer preview означає для відтворюваності

0.1.0-rc.6 було опубліковано 13 серпня 2026 року, а 0.1.0-rc.7 — 17 серпня 2026 року. Між ними минуло чотири дні. Відтоді темп не сповільнився: з 19 серпня до 9 жовтня 2026 року було опубліковано ще 24 версії, зокрема 0.2.0-rc.1 28 вересня та 0.2.0-rc.2 наступного дня. За такого темпу інструкції, написані місяць тому, можуть описувати командний рядок, якого вже не існує. Це стосується і цієї сторінки. Датуйте кожне твердження про версію, яке записуєте, включно з власними нотатками.

Перегляд можна зробити передбачуваним за допомогою двох звичок. Фіксуйте точну версію в кожній команді та кожному скрипті, щоб повторне створення сервера формувало той самий harness. Потім читайте довідку з зафіксованої збірки, а не з будь-якого посібника.

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

Друга складова відтворюваності — profile. dsh --profile <name> запускає profile, збережений у $DSH_HOME/profiles/<name>, а profiles web і headless створюються з вбудованих шаблонів під час першого використання. У цьому каталозі harness також зчитує ключ API, модель і параметри endpoint, тому зафіксована версія та робоча конфігурація — це дві окремі речі, які потрібно правильно налаштувати. Вбудовані bundles завантажуються з інсталяції dsh, яка зараз виконується. Отже, зміна зафіксованої версії також змінює ці bundles. Плагіни out-of-tree працюють інакше. Вони зберігаються в каталозі profile, а dsh plugin --profile <name> add <package> передає їхні аргументи до pnpm для встановлення. Тому pnpm має бути в PATH, і dsh прямо повідомляє про це, якщо його немає. Кожен доданий плагін працює з тими самими дозволами, що й ваш agent. Тому варто перевірити, до яких ресурсів плагін може отримати доступ, перш ніж його встановлювати. Власний package.json profile фіксує ці плагіни, тому повна фіксація охоплює два файли, а не один.

Цей поділ буде знайомим, якщо ви зберігали Python-інструменти в ізольованих середовищах на сервері: інструмент і додані до нього компоненти фіксуються в різних місцях. Після запуску harness наступне питання зазвичай стосується мережі, а не версій. Тут у пригоді стануть підключення до Web UI dsh на віддаленому VPS і докладніший посібник зі встановлення DeepSeek Harness на VPS.

Помилки аргументів, які ви побачите на практиці

Ці помилки генерує власний парсер CLI, і кожна з них точно описує проблему. Формулювання здебільшого залишалися незмінними в різних збірках, але не повністю, тому наведені нижче повідомлення перевірено для 0.2.0-rc.2 6 October 2026.

помилка: потрібен --profile <name>

Ви запустили npx @deepseek-ai/dsh без підкоманди та профілю. Команда без аргументів запускає профіль, тому їй потрібне ім’я. dsh web працює без --profile, оскільки парсер сприймає перше слово без префікса як ім’я профілю та запускає для вас поставлений профіль web.

помилка: для --patch потрібен шлях

--patch передано без наступного аргументу. Цей прапорець можна вказувати кілька разів, і кожне вказування приймає шлях до одного файлу.

помилка: --dump-config і --dump-default-config взаємовиключні

Виберіть один із них. У 0.2.0-rc.2, на яку вказувала збірка latest 6 October 2026, повідомлення містить назву третього прапорця та має вигляд error: --dump-config, --dump-default-config, and --dump-config-schema are mutually exclusive, оскільки до цих двох прапорців додано --dump-config-schema, який виводить JSON Schema для записів профілів і патчів. --dump-default-config виводить шари поставленого bundle і не приймає --patch. --dump-config виводить сформовану конфігурацію профілю. Усі ці параметри виводять результат і завершують роботу без запуску harness, тому це безпечний спосіб перевірити, що змінила нова release candidate.

помилка: для plugin потрібні аргументи pnpm для передавання далі (наприклад, add <package>)

dsh plugin --profile <name> передано без аргументів для подальшого передавання. Якщо профіль відсутній, підкоманда ініціалізує його, а потім передає решту командного рядка до pnpm, тому їй потрібні такі аргументи, як add @scope/dsh-plugin-example.

FAQ

Яка версія Node.js потрібна для DeepSeek Harness?

Репозиторій оголошує ^22.19.0 || >=24.0.0 у кореневому package.json. Це було перевірено 10 October 2026, коли версією репозиторію була 0.2.1-alpha.2. Тому потрібен Node 22.19.0 або новіший у гілці 22, або Node 24 чи новіший. Node 20 не працюватиме. Опублікований npm-пакет не має власного поля engines, тому npm не показує попередження й не блокує інсталяцію. Помилка натомість виникає під час виконання. Спочатку перевірте node -v. Node 24 все одно є кращим вибором, оскільки він містить npm 11, який виправляє повторне використання версії в npx.

Як змусити npx використовувати найновіший dsh, а не версію з кешу?

У npm 11.2.0 і новіших версіях npx @deepseek-ai/dsh під час кожного запуску повторно перевіряє реєстр для назви пакета без версії. Виняток — поточний каталог є проєктом із встановленим dsh. У такому разі npx запускає локальну копію. У npm 10, який входить до складу кожного випуску Node 22, така поведінка відсутня. Очистіть кеш npx за допомогою npm cache npx rm --force у npm 11 або видаліть каталог за допомогою rm -rf "$(npm config get cache)/_npx" у npm 10. Потім перевірте результат командою 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.. Кожна опублікована збірка є попереднім випуском, наприклад 0.2.0-rc.2 або 0.2.1-alpha.2. Діапазон semver не відповідає версіям попередніх випусків, якщо сам діапазон не містить попередній випуск із такими самими номерами major, minor і patch. Установіть точний рядок версії разом із суфіксом. Виконайте npm view @deepseek-ai/dsh versions --json, щоб переглянути доступні версії, оскільки в послідовності є пропуски для збірок, які не публікувалися.

Чи слід установлювати dsh глобально або запускати його через npx?

npx зручний для першого ознайомлення, оскільки, крім каталогу кешу, нічого не зберігається. Фіксована глобальна інсталяція, наприклад npm install -g @deepseek-ai/dsh@0.1.0-rc.7, підходить для всього, що має працювати стабільно. Версія змінюється лише після явної зміни. Якщо після глобальної інсталяції команду dsh не знайдено, каталог глобальних виконуваних файлів npm відсутній у PATH. Команда npm prefix -g виводить кореневий каталог, у якому він розташований.

Чи достатньо стабільний DeepSeek Harness для побудови на його основі?

Поки що ні, згідно з описом самого проєкту. У README зазначено, що проєкт перебуває на етапі попередньої версії для розробників, активно розвивається та матиме зміни, що порушують сумісність. Release candidates 0.1.0-rc.6 і 0.1.0-rc.7 було опубліковано з інтервалом у чотири дні в August 2026, а 0.2.0-rc.1 і 0.2.0-rc.2 — з інтервалом в один день у September 2026. Зафіксуйте точну версію та прочитайте --help саме з цієї зафіксованої збірки, а не з будь-якого посібника. Додавайте дати до власних нотаток, щоб визначати, наскільки вони застаріли.