פתרון שגיאות התקנה וגרסאות ב-DeepSeek Harness

מהי למעשה התקנת DeepSeek Harness

התקנת DeepSeek Harness מסתכמת בפקודה אחת: npx @deepseek-ai/dsh web. אין תוכנית התקנה ואין שירות להגדרה. רוב הקשיים שמשתמשים נתקלים בהם אינם קשורים כלל להתקנה. מדובר בפתרון גרסאות: איזו גרסה של @deepseek-ai/dsh החליט npx להריץ היום, והאם גרסת ה-Node.js שלכם מסוגלת להריץ אותה. כאשר הכלי מתחיל לפעול, הכתובת שהוא מציג קשורה ל-localhost, ונושא ה-מדוע ממשק ה-Web מגיב רק ב-127.0.0.1:3080 הוא בעיה נפרדת מהבעיות המתוארות בדף זה.

שתי עובדות מכתיבות את כל המפורט להלן. ראשית, כל גרסה של @deepseek-ai/dsh שפורסמה ב-npm עד כה היא גרסת release candidate, והתגית latest מצביעה על אחת מהן. נכון ל-18 באוגוסט 2026, מדובר ב-0.1.0-rc.7, שפורסמה ב-17 באוגוסט 2026. שנית, ה-README של הפרויקט מציין שה-harness נמצא ב-developer preview, עובר שינויים מהירים, ויכלול שינויים ששוברים תאימות. דגל (flag) שעבד בשבוע שעבר עלול להיעלם השבוע. קבעו גרסה (pin) לפני שאתם בונים משהו על גביה.

כמה מונחים תחילה. dsh הוא כלי שורת הפקודה DeepSeek Harness. Node.js הוא סביבת זמן הריצה של JavaScript הנדרשת לו. npx הוא מפעיל החבילות שמגיע עם npm (node package manager), והוא מוריד חבילה לפי דרישה במקום להתקין אותה לצמיתות. אם המילה harness אינה מוכרת בהקשר הזה, agent harness הוא התוכנית העוטפת את המודל, ומנהלת את לולאת העבודה, את הכלים, את ההרשאות ואת מצב ההפעלה. לכן מספר גרסה שלא בחרתם בו עלול לשנות את אופן הפעולה של ה-agent שלכם.

באיזו גרסת Node.js דרוש השימוש עבור dsh?

שורש המאגר package.json מצהיר על "engines": {"node": "^22.19.0 || >=24.0.0"}, נכון ל-18 באוגוסט 2026 בגרסה 0.1.0-rc.7. לכן, יש להשתמש ב-Node 22.19.0 או גרסה חדשה יותר בתוך סדרת 22, או ב-Node 24 ומעלה. גרסה 20 אינה נתמכת.

בדקו איזו גרסה מותקנת אצלכם לפני כל פעולה אחרת.

node -v
npm -v

כאן מגיע החלק שמפתיע משתמשים רבים. חבילת ה-@deepseek-ai/dsh המפורסמת אינה כוללת שדה engines משל עצמה. רק שורש ה-monorepo מצהיר על אחד כזה, וקובץ השורש הזה לעולם אינו מפורסם ל-npm. לפיכך, ל-npm אין מה לבדוק, הוא אינו מציג אזהרת EBADENGINE ואינו חוסם דבר. ב-Node 20 ההתקנה נראית כאילו עבדה בהצלחה, אך הכשל מופיע מאוחר יותר, כאשר הקוד שנטען ניגש לתחביר או ל-API שאינם קיימים בסביבת ה-runtime שלכם. אין מחרוזת שגיאה יציבה אחת שניתן לחפש, כיוון שהשורה שנכשלת ראשונה תלויה במודול שנטען ראשון. קראו את node -v במקום לנסות לפענח את הודעת הקריסה.

אם גרסת ה-Node שלכם ישנה מדי, nvm (מנהל גרסאות Node) הוא הפתרון הפולשני פחות ב-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 עדיין מדווח על הגרסה הישנה, פונקציית ה-shell של nvm לא נטענה; פתחו session חדש של login shell ונסו שוב. Node 24.19.0 היא גרסת ה-LTS (תמיכה ארוכת טווח) הפעילה נכון לאוגוסט 2026, והיא היעד המועדף גם מסיבה שנייה שנסקרת להלן.

מדוע npx מריץ גרסה שונה בכל יום?

npx @deepseek-ai/dsh web לא מציין גרסה, לכן npx מבקש מה-registry את הגרסה שאליה מצביע התג 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 באוגוסט 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 מעולם לא פורסמו. ניחוש של ה--rc.N הבא בתסריט פריסה (deploy script) ייכשל, לכן קראו את הרשימה במקום לנסות לנחש את המספר הבא.

מדוע npx ממשיך להריץ גרסה ישנה?

זוהי התלונה ההפוכה, ושתי הטענות נכונות, תלוי באיזו גרסה של npm אתם מריצים.

הכלי npx מנהל ספריית חבילות משלו, נפרדת מ־tarball cache, בתיקייה שנקראת _npx בתוך ה־cache של npm. הציגו את הנתיב ובדקו אותו.

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

במשך שנים, npx השתמש מחדש בכל מה שמצא שם עבור שם חבילה ללא גרסה, ומעולם לא פנה שוב ל־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.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 שנשמר ב־cache לפני שבועות. אותה פקודה ב־Node 24 תבצע פתרון מחדש בכל הרצה. פקודה אחת, שתי התנהגויות, ואף אחת מהן לא מזהירה אתכם. שאלו את הכלי מה הוא:

npx @deepseek-ai/dsh --version

ניקוי ה־cache של 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 מציג הנחיה (prompt) לפני התקנת חבילה שאינו מכיר וממתין לתשובה שלעולם לא תגיע.

גרסה מדויקת היא גם הדרך המהירה ביותר. npx משתמש במחרוזת המפרט שהקלדת כמפתח לספריית ה-cache שלו; עבור גרסה מדויקת, הוא משווה אותה למזהה החבילה שכבר מותקן שם ומריץ אותה ללא צורך בביצוע round trip מול ה-registry כלל. בגרסאות npm 11.2.0 ומעלה, שימוש בשם בלבד יגרום לביצוע fetch של ה-manifest בכל הרצה.

התקנה גלובלית מקבעת את הגרסה באותו אופן ומספקת פקודה קצרה לשימוש.

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

No matching version found for @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 אלא אם הטווח עצמו מציין prerelease. כל build שפורסם עבור חבילה זו הוא -rc.N, שהיא גרסת prerelease, ולכן ^0.1.0 אינו תואם לכלום. כתבו את הגרסה המדויקת.

לכלל זה יש תופעת לוואי מועילה. מכיוון שטווחים אינם יכולים "לנדוד" לגרסת release candidate חדשה, אין מצב של "חצי-קיבוע" שצריך להתחשב בו. אתם נמצאים או על גרסה מדויקת או על תגית משתנה.

האם להשתמש ב-npx או להתקין את dsh באופן גלובלי?

השתמשו ב-npx לבדיקה ראשונית, כיוון שלא נותר דבר מלבד ספריית מטמון שאתם יודעים כעת כיצד לנקות. השתמשו בהתקנה גלובלית עם גרסה נעולה עבור כל מה שצריך להמשיך לעבוד לאחר אתחול, כגון סוכן פיתוח שאתם מריצים ב-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. הפרש של ארבעה ימים. בקצב הזה, הוראות שנכתבו לפני חודש עלולות לתאר שורת פקודה שכבר אינה קיימת, וזה כולל את הדף הזה. ציינו תאריך לכל טענת גרסה שאתם כותבים, כולל בהערות האישיות שלכם.

שני הרגלים הופכים את ה-preview לניתן להישרדות. קבעו (pin) את הגרסה המדויקת בכל פקודה ובכל סקריפט, כך שבנייה מחדש של שרת תייצר את אותה סביבת עבודה. לאחר מכן, קראו את פלט העזרה מהגרסה שקיבעתם במקום מכל מדריך אחר.

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 שלו, לכן גרסה מקובעת ותצורה תקינה הן שני דברים נפרדים שיש להקפיד עליהם. חבילות מובנות (in-box bundles) נפתרות מתוך התקנת ה-dsh שרצה כרגע, מה שאומר ששינוי הגרסה המקובעת שלכם משנה גם את החבילות הללו. תוספים חיצוניים (out-of-tree plugins) מתנהגים אחרת. הם נמצאים בתיקיית ה-profile, ו-dsh plugin --profile <name> add <package> מעביר את הארגומנטים שלו ל-pnpm כדי להתקין אותם. לכן, pnpm חייב להיות ב-PATH שלכם, ו-dsh מצהיר על כך בבירור כאשר הוא אינו נמצא. כל תוסף שאתם מוסיפים רץ עם אותן הרשאות שיש לסוכן שלכם, ולכן כדאי לבדוק למה תוסף יכול לגשת לפני שמתקינים אותו. ה-package.json של ה-profile הוא זה שמקבע את התוספים האלה, כך שקיבוע מלא מכסה שני קבצים, לא אחד.

הפיצול הזה ייראה מוכר אם שמרתם כלי Python בסביבות מבודדות על שרת: הכלי והתוספים שאתם מוסיפים לו מקובעים במקומות נפרדים. ברגע שה-harness מתחיל לרוץ, השאלה הבאה היא בדרך כלל רשת ולא גרסאות, וזה השלב שבו גישה לממשק ה-Web של dsh ב-VPS מרוחק והמדריך המפורט ב-התקנת DeepSeek Harness על VPS נכנסים לתמונה.

שגיאות ארגומנטים נפוצות

שגיאות אלו נובעות מהמנתח (parser) של ה-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

Which Node.js version does DeepSeek Harness need?

The repository declares ^22.19.0 || >=24.0.0 in its root package.json, read on 18 August 2026 at version 0.1.0-rc.7. So Node 22.19.0 or later in the 22 line, or Node 24 and newer. Node 20 will not work. The published npm package has no engines field of its own, so npm never warns you and never blocks the install, and the failure appears at runtime instead. Check node -v first. Node 24 is the better choice anyway, because it bundles npm 11, which fixes npx version reuse.

How do I force npx to use the newest dsh instead of a cached one?

On npm 11.2.0 and newer, npx @deepseek-ai/dsh already re-checks the registry for a bare package name on every run. On npm 10, which every Node 22 release bundles, it does not. Clear the npx cache with npm cache npx rm --force on npm 11, or delete the folder with rm -rf "$(npm config get cache)/_npx" on npm 10. Then confirm with npx @deepseek-ai/dsh --version. Note that npm cache clean --force clears a different directory and will not fix this.

Why does installing @deepseek-ai/dsh@^0.1.0 fail?

npm returns error code ETARGET with the line No matching version found for @deepseek-ai/dsh@^0.1.0. Every published build is a prerelease such as 0.1.0-rc.7, and a semver range does not match prerelease versions unless the range itself names one. Install the exact version string, -rc.N suffix included. Run npm view @deepseek-ai/dsh versions --json to see which versions exist, because the sequence has gaps where release candidates were never published.

Should I install dsh globally or run it through npx?

npx suits a first look, since nothing persists except a cache directory. A pinned global install such as npm install -g @deepseek-ai/dsh@0.1.0-rc.7 suits anything that has to keep working, because the version changes only when you change it. If the dsh command is not found after a global install, npm's global bin directory is missing from your PATH, and npm prefix -g prints the root it lives under.

Is DeepSeek Harness stable enough to build on?

Not yet, by its own description. The README states that the project is in developer preview, is iterating rapidly, and will have compatibility-breaking changes. Release candidates 0.1.0-rc.6 and 0.1.0-rc.7 were published four days apart in August 2026. Pin an exact version and read --help from that pinned build rather than from any guide. Date your own notes, so you can tell how stale they have become.