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

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

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

Нижче все визначають два факти. По-перше, усі версії @deepseek-ai/dsh, опубліковані в npm досі, є release candidate, а тег latest вказує на одну з них. Станом на 18 August 2026 це 0.1.0-rc.7, опублікована 17 August 2026. По-друге, у README проєкту зазначено, що harness перебуває на етапі developer preview, швидко розвивається й матиме зміни, що порушують сумісність. Прапорець, який працював минулого тижня, цього тижня може зникнути. Зафіксуйте версію, перш ніж будувати на її основі будь-які інтеграції.

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

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

Кореневий файл репозиторію package.json містить вимогу "engines": {"node": "^22.19.0 || >=24.0.0"}, зафіксовану 18 August 2026 на версії 0.1.0-rc.7. Отже, потрібна 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 і далі повідомляє стару версію, функцію nvm для shell не було завантажено. Відкрийте новий login shell і повторіть спробу. Станом на August 2026 Node 24.19.0 є активним LTS (long term support) релізом. Це краща ціль також з іншої причини, описаної нижче.

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

npx @deepseek-ai/dsh web не містить номера версії, тому npx запитує в реєстру версію, на яку вказує тег latest. Цей тег змінюється. Коли DeepSeek випускає 0.1.0-rc.8, команда у ваших нотатках починає запускати інший код без попередження та без журналу змін перед вами.

Усі змінні компоненти можна перевірити з командного рядка.

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

dist-tags показує, на що зараз вказує latest. 18 August 2026 і latest, і next вказували на 0.1.0-rc.7, тому окремого стабільного каналу, на який можна переключитися, немає. Список versions цікавіший, оскільки в ньому є пропуски: 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. У цій послідовності відсутні деякі номери, оскільки окремі release candidate ніколи не випускалися. Якщо в deploy script вгадувати наступний -rc.N, він завершиться помилкою, тому читайте список, а не збільшуйте номери послідовно.

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

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

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

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

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

Фактичну поведінку визначає ваш випуск Node, оскільки Node містить конкретну версію npm:

• Node 20.20.2 містить npm 10.8.2.
• Node 22.19.0 містить npm 10.9.3.
• Node 22.23.2, найновіший випуск 22, містить npm 10.9.8.
• Node 24.19.0 містить npm 11.17.0.

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

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-версію?

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

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

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

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

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

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

Це правило має корисний побічний ефект. Оскільки діапазони не можуть непомітно перейти на нову release candidate-версію, не виникає проміжного стану з частковою фіксацією, який потрібно аналізувати. Ви або використовуєте точну версію, або рухомий тег.

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

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

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

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

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

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

Що попередня версія для розробників означає для відтворюваності

0.1.0-rc.6 було опубліковано 13 August 2026, а 0.1.0-rc.7 — 17 August 2026. Між ними лише чотири дні. За таких темпів інструкції, написані місяць тому, можуть описувати командний рядок, якого вже не існує. Це стосується і цієї сторінки. Датуйте кожне твердження про версію, яке записуєте, включно з власними нотатками.

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

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

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

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

Ці помилки надходять від власного парсера CLI. Тому вони стабільні в усій лінійці release candidate, і кожна з них точно вказує на проблему.

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

Виберіть один із них. --dump-default-config виводить шари поставленого bundle і не приймає --patch. --dump-config виводить зведену конфігурацію профілю. Обидві команди виводять результат і завершують роботу, не запускаючи 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

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

У корені репозиторію у файлі package.json, переглянутому 18 August 2026 у версії 0.1.0-rc.7, репозиторій оголошує ^22.19.0 || >=24.0.0. Отже, потрібна 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 під час кожного запуску повторно перевіряє реєстр для назви пакета без версії. У 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.1.0-rc.7, а діапазон semver не відповідає версіям попередніх випусків, якщо сам діапазон не містить таку версію. Установіть точний рядок версії, включно із суфіксом -rc.N. Виконайте npm view @deepseek-ai/dsh versions --json, щоб переглянути доступні версії, оскільки в послідовності є пропуски, де кандидати на випуск не публікувалися.

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

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

Чи достатньо стабільний DeepSeek Harness для розроблення на його основі?

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