אפליקציית השולחן עבודה DeepSeek Harness: מה המתקין למעשה מכניס למכונה שלך

אפליקציית הדסקטופ DeepSeek Harness היא מעטפת Electron העוטפת את אותו ממשק ווב שמקבלים מ־npx @deepseek-ai/dsh web, והיא מגיעה כשלושה מתקינים מותאמים לפלטפורמה עבור ארנס שנמצא כעת בגרסה 0.2.1-rc.2. התיאור הזה נשמע מזלזל, וזה לא מכוון. עטיפת ממשק עובד במעטפת שולחנית היא עבודה של סוף שבוע; עטיפתו במעטפת שמחזיקה בספריית ריצה משלה, משאירה את המשימות שלך פעילות כשאתה סוגר את החלון, מעדכנת את עצמה בערוץ בלי גרסה יציבה, ושומרת את הסשנים שלך לאורך כל אחת מהפעולות האלה — זה החלק שלוקח חודשים, וזה החלק ששווה לקרוא עליו. אם אתה רוצה להריץ את DeepSeek-V4.1-Flash דרך ארנס שחי בחלון ולא בטרמינל, זו הבנייה הזאת, והשאלות המעניינות כולן נוגעות למה שקורה סביב החלון.

שני דברים צריך לומר לפני הפרטים. ראשית, המאמר הזה מחליף את ההנחיה הקודמת שלנו שלפיה אין אפליקציית שולחן עבודה — ההנחיה הזו הייתה נכונה כשנכתבה באוגוסט 2026, והיא שגויה כעת. שנית, זו תצוגה מקדימה ציבורית, שעדיין מסומנת ככזו באתר של DeepSeek עצמו, ולאריזה יש את הקצוות המחוספסים שמשתמעים מהתווית הזו. המתקין עובד. ההפצה סביבו דקה יותר ממה שהייתם מנחשים.

מהו למעשה הבילד של שולחן העבודה

אפליקציית שולחן העבודה היא שכבת Electron דקה שתפקידה להפעיל תהליך Host ולהצביע חלון לעברו. החלון אינו פורש ממשק צ'אט משל עצמו: הוא טוען את ערך ה-Web הארוז שנכלל באפליקציה בכתובת dsh-app://app/, ודיאלוגי העדכון שתראו מגיעים ממקור ארוז שני בכתובת dsh-app://shell/. תהליך Node בן מופעל במצב RunAsNode של Electron כדי להפעיל את מריץ הפרופיל המשותף, וה-shell מעביר HTTP אל ה-Web Host המאומת, תוך השמטת הכותרות transfer-encoding, connection ו-keep-alive בדרך. תגובות חבילת תוספים מסומנות ב-no-store, וזהו פרט קטן עם השלכה גלויה לעין: שנו תוסף והטעינה הבאה תציג את השינוי.

מכיוון שכתובת ה-URL היא dsh-app:// ולא localhost, אין פורט קבוע לזכור ואין התנגשות פורטים להתמודד איתה. ה-Host השולחני מאזין כברירת מחדל לפורט שהוקצה על ידי מערכת ההפעלה. אם דרוש לך פורט מסוים, אפשר להגדיר אותו באמצעות דריסת webserver.config.port, אבל ברירת המחדל אינה קבועה במכוון, וה-Host נקשר ל-127.0.0.1זה חשוב אם עקבת אחר הוראות ישנות: המספר 19387 שהופיע במדריכי התקנה מאוגוסט אינו הפורט של ה-Host השולחני, והתייחסות אליו כאל פורט כזה תשלח אותך לחפש שירות שאינו קיים.

קיבוע הגרסה מחמיר יותר ממה שהוא נראה במבט ראשון. Electron ו-@deepseek-ai/dsh תמיד נושאים בדיוק את אותה גרסה — לא טווח, לא גרסה ראשית תואמת — כך ששדרוג ה-harness הוא מהדורת שולחן עבודה, ואין שילוב נתמך של גרסה חדשה של dsh וחלון ישן. תהליך Electron מחזיק בנעילת מופע יחיד לכל חיי התהליך, ובעל בלעדיות על $DSH_HOME/profiles/desktop. הבלעדיות הזו אמיתית: ה-CLI לא יכול לאתחל את הפרופיל הזה, ו-npm-מותקן dsh לא יכול לשנות אותו. מה ששתי ההתקנות כן חולקות הוא המצב שחשוב לך — סשנים, הגדרות, פרטי גישה, סביבות עבודה ואחסון, הכול תחת $DSH_HOME. מה שהן לא חולקות הוא חבילות הרצה, הפעלת תוספים, קובצי נעילה או node_modules, ולכן התקנת תוסף בפרופיל שולחן העבודה אינה אותה פעולה כמו התקנתו בפרופיל ה-CLI.

שלושה מתקינים, ערוץ עדכון אחד, בלי גרסה יציבה

קיימים שלושה מתקינים ושלושתם מגיבים. קובץ ההפעלה של Windows 64-bit הוא 289,385,456 בתים ומוגש עם HTTP 200. תמונת הדיסק ל-Apple silicon היא 264,990,950 בתים, גם 200. תמונת הדיסק ל-Intel Mac היא 289,480,824 בתים, גם 200. שלושתם עודכנו לאחרונה ב-17 באוקטובר 2026. רק שניים מהם מקושרים מדף ההורדה. גרסת ה-Intel פעילה, נגישה, ואין שום קישור שמפנה אליה בשום מקום ב-deepseek.com/en/harness/ — אם אתם על Intel Mac ופעלתם לפי הדף, סביר להניח הייתם מסיקים שאין גרסה בשבילכם.

גרסת ה-Intel גם מפגרת בגרסה אחת. פיד העדכונים שלה מפרט 0.2.1-rc.1; פידי העדכונים של Windows ו-Apple-silicon מפרטים שניהם 0.2.1-rc.2. מועמד שחרור אחד אינו פער גדול בתכונות, אבל הוא איתות ממשי לגבי אילו יעדים נבנים ראשונים ואילו נבדקים אחרונים, וזה בדיוק מסוג הדברים שתרצה לדעת לפני שאתה מחייב את הפעלות העבודה שלך לפלטפורמה.

ערוצי העדכון הם המקום שבו סיפור ההפצה נהיה דל. הפידים הם לפי יעד, תחת /dsh-desk/feeds/<target>/ באותו מארח. Windows x64 מפנה אל nightly.yml; שני יעדי macOS מפנים אל nightly-mac.yml. בקשו מכל אחד מהשלושה latest.yml או latest-mac.yml ותקבלו 404 — אין ערוץ יציב, אין ערוץ בטא, ואין דרך לבטל את ההצטרפות לערוץ היחיד שקיים. הערות הפרסום של DeepSeek עצמה מאשרות את הסידור ולא סותרות אותו: כל גרסה מפרסמת פיד nightly, ורק גרסאות יציבות מפרסמות פיד latest שמצביע על אותם ארטיפקטים. "Nightly" בהקשר הזה הוא שם של ערוץ ולא קצב בנייה — הפידים של Windows ו-Apple silicon מגישים שניהם את אותה בנייה 0.2.1-rc.2, מתאריך 17 באוקטובר, כאשר חבילת Windows נושאת חותמת זמן של 09:22 UTC וחבילת Apple silicon 09:57 UTC. אז מקבלים את מנגנון העדכון האוטומטי, תשאול עם ג'יטר, המתנה מדורגת עד לתקרה של שעה, ואין דרך לבקש דבר מלבד מה שערוץ התצוגה המקדימה מחזיק כעת.

GitHub מציג את אותה נקודה מזווית אחרת. deepseek-ai/deepseek-harness — המאגר, עם 256,559 כוכבים ו-30,921 פורקים כשנקרא ב-21 באוקטובר 2026 — הכיל 31 מהדורות באותו תאריך, כולן מסומנות כגרסה מוקדמת, ולכולן אפס נכסים בינאריים מצורפים. שום דבר בעמוד Releases אינו ניתן להורדה. אם אתם רוצים בנייה, משיגים אותה מdownload.deepseek.com או מnpm, שם @deepseek-ai/dsh פותר כעת את latest ל-0.2.1-rc.2. המאגר הוא מקור אמת ליומן השינויים ומבוי סתום עבור הארטפקט, וזה יוצא דופן מספיק כדי שיהיה שווה לומר זאת בפשטות, מפני שהאינסטינקט כשרואים 31 מהדורות הוא לצפות למתקין באחת מהן.

מה המתקין כותב, ומה הוא מסרב לגעת בו

מתקין Windows הוא חבילת NSIS נייטיבית, לא עטיפה סביב MSI, והוא מתנהג בהתאם. תקבלו פלטות צבע בהירה, כהה ואוטומטית — הניתנות לבחירה בזמן ההתקנה עם /THEME=light, /THEME=dark או /THEME=auto — תיקיית יעד ניתנת לעריכה, והיקף התקנה המוגבל למשתמש הנוכחי. שורשי כוננים נדחים כיעדי התקנה, ותיקיית יעד לא ריקה מתקבלת רק אם היא כבר התקנה רשומה, כלומר המתקין מסרב לדרוס תיקייה לא קשורה. בעת עדכון, המסלול השקט ממתין עד עשר שניות לסגירת היישום הפעיל, ואז נעצר עם קוד יציאה 2 אם הוא עדיין פועל. מדובר בכשל כן ולא בהתקנה פגומה, והוא יתגלה בכל פריסה מתוסרטת שלא סוגרת את האפליקציה תחילה.

מסיר ההתקנה משרטט את הגבול שרוב מסירי ההתקנה טועים בו. הוא מסיר את ספריית userData של Electron, את ספריית המוצר תחת %APPDATA%, ואת מטמון המעדכן תחת %LOCALAPPDATA%. הוא אינו נוגע בבית ה-harness — ~/.dsh, או בכל מקום שאליו DSH_HOME מצביע — שמחזיק את הסשנים, ההגדרות, פרטי הכניסה והתוספים שלך. העברת --updated או /KEEP_APP_DATA משמרת גם את נתוני Electron. כך שהסרה והתקנה מחדש הן דרך נתמכת לתקן חלון שבור בלי לאבד את העבודה שלך, וזו החלטת עיצוב מכוונת ולא מקרית.

כדאי להכיר את סביבות הריצה המצורפות porque הן גדולות והן נמצאות מחוץ לספריית האפליקציה. Python עם numpy, pandas, python-docx, python-pptx, openpyxl, Pillow, lxml ו-XlsxWriter, וכן Node ו-pnpm, מותקנים תחת $DSH_HOME/dsh-runtimes/dsh-primary-runtime — בדרך כלל ~/.dsh/... בשתי הפלטפורמות — בפעם הראשונה שסביבת עבודה מצהירה שהיא זקוקה להם. לכן טביעת הרגל בדיסק לאחר שבוע של שימוש אינה טביעת הרגל בדיסק לאחר ההתקנה, ולכן הסרה שמשמרת את $DSH_HOME משמרת גם כמה מאות מגה-בייט של סביבות ריצה.

ההגדרות נקראות פעם אחת בעת האתחול מתוך desktop/settings.json בתיקיית userData של Electron, אשר ב-Windows פירושה %APPDATA%\@deepseek-ai\dsh-desktop\desktop\settings.json וב-macOS פירושה ~/Library/Application Support/@deepseek-ai/dsh-desktop/desktop/settings.json. DSH_HOME אינה מעבירה את הקובץ הזה למקום אחר — נקודה שראויה לציון, משום שזו פריט התצורה היחיד שאינו עוקב אחרי המשתנה שכל השאר עוקבים אחריו. הגדרות העדכון בקובץ זה הן במילישניות: intervalMs ברירת המחדל היא 600,000, ו-maxBackoffMs ברירת המחדל היא 3,600,000 והוא חייב להיות לפחות intervalMs. ערך ברירת המחדל של Jitter הוא 0.2, הוא מוגבל לטווח של אפס עד אחד, ומוגבל מלמטה לשנייה אחת תוך שהוא לעולם אינו עולה על תקרת ה-backoff. מועד אי-פעילות של 60,000 מילישניות לכל חיבור חל על תעבורת HTTP של עדכונים, אך להורדה פעילה אין מועד סיום כולל — חיבור איטי לא ינותק באמצע ההורדה.

סגירת החלון אינה סוגרת את היישום

בשתי הפלטפורמות, סגירת החלון מסתירה אותו. ב-macOS זה Command-W; ב-Windows זהו כפתור הסגירה, Alt-F4, או סגירה משורת המשימות. Windows מבקש אישור לפני ההסתרה הראשונה וכותב background-close-confirmed כדגל בספריית userData של Electron כך שהוא שואל פעם אחת ולא בכל פעם. Windows גם מחזיק סמל מגש לאורך כל הריצה. ב-macOS אין בכלל סמל שורת תפריט, מה שהופך את המצב המוסתר לבלתי נראה ממש שם — האפליקציה פועלת, המשימות פועלות, ושום דבר על המסך לא אומר זאת עד שתפתחו אותה מחדש עם dsh://open או המגש, בהתאם לפלטפורמה.

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

יציאה היא פעולה נפרדת עם היגיון משלה. לפני היציאה, המעטפת בודקת ב-Host אם יש סוכנים פועלים, כולל תתי-סוכנים וסוכנים שממתינים לאישור, הודעות בתור, משימות שרצות או נעצרות, ותזכורות מתוזמנות שנמצאות במצב פעיל. אם אף אחד מאלה לא קיים, היא יוצאת בשקט. אם יש כאלה, מוצג לך חלון אישור נייטיבי שכותרתו לצאת מ-DeepSeek Harness? עם אחד משלושה הסברים בהתאם למה שנמצא: משימות ייקטעו, משימות מתוזמנות לא יתבצעו, או שניהם. Host שמעולם לא הגיע למצב מוכן לא יכול היה להתחיל משימות כלשהן, ולכן יציאה במצב כזה ממשיכה בלי לשאול. ההבחנה בין "סגירה" ל"יציאה" היא כל הרעיון של העיצוב, והיא תקפה בשתי הפלטפורמות למרות שרק אחת מהן מציגה לך סמל קבוע.

פקודת dsh, והסדר שחשוב

המתקין יכול למקם את dsh ב-PATH שלך, וזה מה שמאפשר לך להריץ את ה-CLI מול אותה תיקיית בית של ה-harness שבה משתמשת אפליקציית הדסקטופ. הפקד הוא ניהול פקודת dsh…, והוא נמצא מיד מתחת לבדוק אם קיימים עדכונים… בתפריט, עם שלוש פעולות: התקן, תקן והסר. ב-macOS הוא כותב משגר ב-/usr/local/bin/dsh ויבקש הרשאת מנהל כשהוא זקוק לכך; ב-Windows הוא רושם את הפקודה ב-PATH של המשתמש הנוכחי.

שני כללי סדר קלים לפספוס ומרגיזים לגלות בדיעבד. הראשון: יש להריץ את Remove לפני הסרת ההתקנה של אפליקציית שולחן העבודה, משום שהמסיר אינו מסיר את הרישום של dsh. אם תסירו קודם את ההתקנה, תישארו עם ערך PATH שמצביע על קובץ בינארי שכבר אינו קיים. השני: אם תעבירו את האפליקציה למיקום אחר, השתמשו ב-Repair ב-macOS או ב-Install מהמיקום החדש ב-Windows, במקום להניח שהרישום עוקב אחרי האפליקציה.

לניהול תוספים בפרופיל הדסקטופ יש מורכבות משלו. מכיוון ש-Electron מחזיק באופן בלעדי ב-$DSH_HOME/profiles/desktop בזמן שהוא פועל, התקנה לתוך אותו פרופיל אינה משהו שעושים כשהאפליקציה פתוחה. הרצף הנתמך הוא להפעיל את אפליקציית הדסקטופ פעם אחת, לצאת ממנה, ואז להריץ dsh plugin --profile desktop add <package> משורת הפקודה. החבילה נוחתת בפרופיל הדסקטופ ופעילה בפעם הבאה שתפתח את החלון.

מה שהאריזה כבר מספרת לך הוא לא שלם

המדור "מגבלות ידועות" ב-README גלוי לב באופן יוצא דופן, ושתיים מהרשומות בו הן אלה שישפיעו עליך ראשונות.

• כניסה לחשבון אינה מחוברת. לחצן הכניסה מושבת. במקום זאת, בהרצה הראשונה נפתח חלון ברוכים הבאים בגודל 600 על 700 עם טופס מפתח API; שמירה והמשך כותבת את המפתח למאגר אישורי הפיתוח, והגדרה מאוחר יותר פותחת את סביבת העבודה האמיתית בלי לשמור מפתח. לחיצה על כניסה היכן שהיא מופיעה פותחת בדפדפן המערכת את דף הפלטפורמה המוגדר, כאשר ה-Host אחראי על החלפת ה-PKCE ועל callback loopback זמני — התשתית קיימת, קישור החשבון לא. בפועל, היערכו להביא מפתח.

• חתימת מהדורה ונוטריזציה (notarisation) מופיעות כדורשות את סביבת ההפצה לייצור. זהו ה-README שמקפיד, וזה גם המקום שבו מדידה מועילה יותר ממשפט. קובץ ההפעלה Windows שפורסם נושא חתימת Authenticode תקפה עם שרשרת אימות מורחב (extended validation): GlobalSign Root CA–R3, ומטה דרכו דרך GlobalSign Code Signing Root R45 ו-GlobalSign GCC R45 EV CodeSigning CA 2020, עד לתעודת עלה שהונפקה ל-Hangzhou DeepSeek Artificial Intelligence Co., Ltd. עם תחום שיפוט CN / Zhejiang / Hangzhou, וקטגוריית עסק של ארגון פרטי. חותמת הזמן RFC-3161 על חתימה זו מציינת 2026-10-17T09:22:04Z, מה שמתאים לתאריך השחרור בפיד העדכונים של Windows בטווח של דקה, ותמצית SHA-512 של הקובץ שהורד תואמת את ה-hash שפורסם בפיד הזה בייט אחר בייט. לכן ב-Windows הקובץ הבינארי חתום, חתום-בזמן ותואם-האש היום, יהא אשר יאמר ה-README על כך שהתהליך אינו מיוצר במלואו. צד ה-macOS הוא שאלה אחרת ולא אימתתנו נוטריזציה שם; אין להסיק מהתוצאה של Windows.

דוחות קריסה, ופרט אחד שכדאי להכיר

דוחות קריסה נכתבים כcrash-<UTC time>-<source>.log, אל ~/Library/Logs/DeepSeek Harness ב-macOS או בתיקיית logs שתחת נתיב ה-userData של Electron ב-Windows, ועשרת האחרונים נשמרים. מספר השמירה הזה קטן מספיק כדי שיהיה משמעותי: אם משהו משתבש שוב ושוב ואתם לא בודקים במשך כמה ימים, היומן שהיה מסביר את הכשל הראשון נעלם. העתיקו את התיקייה אם אתם מדבגים תקלה שמופיעה לסירוגין.

נתיב השחזור עבור תצורה פגומה הוא ספציפי באותה מידה. ה-shell משנה את השם של cordis.patch.ymlל-cordis.patch.yml.bak-<timestamp> בלי לנתח אותו, כך שהקובץ נשמר ולא מתוקן, והאפליקציה מתחילה מברירות המחדל. אם ערכתם את הקובץ הזה ידנית, קובץ ה-.bak הוא המקום שאליו עברו העריכות שלכם, והוא עדיין קריא.

מה זה אומר לגבי העצה הקודמת "אין אפליקציית שולחן עבודה"

פרסמנו הנחיה באוגוסט 2026 שלפיה ל-harness אין אפליקציית שולחן עבודה ושאלה המשתמשים ב-Windows צריכים להריץ את גרסת הטרמינל — זה היה מדויק באותו זמן וכיום זה מיושן. גרסת הטרמינל עדיין עובדת ועדיין הבחירה הנכונה לשרת, לקונטיינר או לכל דבר שמופעל בסקריפטים. מה שהשתנה הוא שגרסת שולחן העבודה אינה עטיפה צעצועית: יש לה פרופיל נפרד, היא משאירה משימות פעילות גם לאחר סגירת חלון, מתעדכנת מעצמה, ומשתפת מצב עם ה-CLI בכיוון שמועיל לך. אם נמנעת מגרסת שולחן העבודה כי המאמר הקודם אמר שהיא לא קיימת, הסיבה הזו כבר לא רלוונטית.

שלבי ההתקנה עצמם מכוסים במדריך ההתקנה שלנו ואינם מופיעים כאן שוב, במכוון. מה שמדריך זה אינו יכול לומר לכם הוא איזה מבין שלושת המתקינים אינו מקושר בעמוד ההורדות, איזה יעד נמצא מהדורה אחת מאחור, שאין ערוץ עדכונים יציב שאפשר לבחור בו, ושהקובץ הבינארי של Windows חתום למרות שה-README אומר שהחתימה שייכת למהדורה עתידית. אלה העובדות שמכריעות אם גרסת שולחן העבודה היא הדבר הנכון להתקין, והן הסיבה שעמוד זה קיים בנפרד.

אם אתה מעדיף לא להתקין שום דבר

התקנת harness כדי להגיע למודל אחד היא הרבה מורכבות עבור מעט עבודה, ואפליקציית שולחן העבודה היא תצוגה מקדימה עם ערוץ עדכון יחיד וגרסת Intel שאיש לא מקשר אליה. אם מה שאתם באמת רוצים הוא DeepSeek-V4.1-Flash — המודל שבו ה-harness משתמש כברירת מחדל, אותו מודל שההערות של 0.2.1-rc.2 מוסיפות לו תמיכה — נקודת קצה של API עושה זאת בלי מתקין, בלי תיקיית פרופיל ובלי סמל במגש שאתם צריכים לזכור שהוא פועל.

ההשוואה שצריך לעשות אינה בין אפליקציית שולחן עבודה לבין API באופן מופשט. השאלה היא אם העבודה דורשת סוכן שיכול להחזיק סביבת עבודה פתוחה גם כשהחלון סגור, להריץ סקריפטים על המחשב שלך ולהשאיר סשן פעיל במשך שעות — ובמקרה כזה שווה לסבול את בעיות האריזה שלעיל, וגרסת שולחן העבודה היא הדרך היחידה לקבל את ההתנהגות הזו — או אם העבודה היא זרם בקשות למודל שכבר מוגש במקום אחר. במקרה השני, ספריית המודלים היא המסלול הקצר יותר, ואין שום דבר במאמר הזה שמשנה את זה.