DeepSeek Harness v0.1.0-rc.7: Upgrade prüfen

Ein laufendes DeepSeek Harness startet nach dem Upgrade nicht mehr, ein altes Gespräch bleibt leer oder ein Plugin erscheint in der Web UI nicht.

Die schnellste sichere Lösung: Installieren Sie das Upgrade auf DeepSeek Harness v0.1.0-rc.7 nicht direkt über Ihre einzige Arbeitsumgebung. Erfassen Sie zuerst Version, Konfiguration und Basistests, prüfen Sie die neue Version isoliert und schalten Sie erst nach erfolgreicher Regression schrittweise um.

Für wen dieser Ablauf gedacht ist: Für Entwickler, die DeepSeek Harness täglich lokal einsetzen, sowie für Betreiber eines Remote Mac mit laufenden Aufgaben. Ebenso für Plattformverantwortliche, die eine gemeinsame Upgrade-Freigabe mit nachvollziehbaren Belegen benötigen.

Zuletzt aktualisiert am 18.08.2026; Versions- und Verhaltensangaben wurden mit den offiziellen Projektunterlagen und der offiziellen Harness-Dokumentation abgeglichen.

Warum ein direktes Überschreiben beim Entwickler-Preview riskant ist

DeepSeek Harness befindet sich weiterhin in der Entwicklungs- beziehungsweise Entwicklervorschau. Die offizielle Projektbeschreibung weist ausdrücklich darauf hin, dass kompatibilitätsbrechende Änderungen möglich sind. Das ist für ein Upgrade wichtiger als die Frage, ob einzelne Fehler laut Release-Notizen bereits behoben wurden. Eine behobene Ursache bedeutet nicht automatisch, dass Ihre Kombination aus Plugins, Sitzungen, Modellroute, Berechtigungen und Arbeitsverzeichnis ebenfalls fehlerfrei läuft. (offizielle Projektbeschreibung)

Bei einem direkten Überschreiben entstehen mindestens fünf reale Risiken:

1. Die Rückkehr ist nicht mehr eindeutig. Wenn ein Update Konfigurationsdateien, Sitzungsdaten oder Plugin-Metadaten anpasst, reicht ein einfaches Zurücksetzen des Paketmanagers möglicherweise nicht aus.
2. Die Konfigurationsquelle kann unbemerkt wechseln. Einstellungen können aus Umgebungsvariablen, einer .env-Datei, einer Benutzerkonfiguration, einem Arbeitsverzeichnis oder einer Web-UI-Konfiguration stammen.
3. Ein Plugin-Fehler kann wie ein Modellfehler aussehen. Da Modelle, Werkzeuge, Sitzungen, Sandboxes und UI-Bestandteile als Plugins zusammengesetzt werden, kann eine nicht geladene Erweiterung die gesamte Arbeitskette verändern.
4. Ein laufender Prozess kann mit der alten Umgebung vermischt werden. Das betrifft besonders dauerhafte Bash-Sitzungen, Hintergrundaufgaben und geöffnete Web-UI-Sitzungen.
5. Auf einem Remote Mac ist der Fehler teurer. Ohne getrennten Benutzer, Snapshot oder reproduzierbaren Arbeitsbereich müssen Sie zusätzlich Fernzugriff, Prozessverwaltung und Zugangsschutz reparieren.

Die zentrale Entscheidung lautet deshalb nicht „Release-Notiz gelesen oder nicht gelesen“, sondern: Kann ich den alten Zustand innerhalb eines klar definierten Zeitfensters wiederherstellen?

Zeitplan für diese Woche: erst erfassen, dann isoliert testen

Planen Sie das Upgrade in drei Abschnitte:

• Vor dem Test: aktuelle Umgebung einfrieren, Basistests ausführen, Sicherungen prüfen;
• Im Testfenster: v0.1.0-rc.7 in einem getrennten Bereich starten und die kritischen Pfade einzeln prüfen;
• Nach Freigabe: zunächst risikoarme Repositories migrieren, danach Daueraufgaben und sensible Projekte.

Für diese Woche ist die sinnvolle Aktion daher nicht die sofortige Aktualisierung, sondern die Einrichtung eines zweiten, wegwerfbaren Testplatzes. Das kann ein eigener Arbeitsbereich auf Ihrem Mac, ein unabhängiges Benutzerverzeichnis oder ein neu bereitgestellter Remote Mac sein. Wenn Sie dafür keinen freien Rechner besitzen, kann ein zeitlich begrenzter Mac-Arbeitsplatz von VPSMAC die Trennung zwischen produktiver Umgebung und Testinstanz vereinfachen; die Entscheidung bleibt trotzdem an Ihre Datenschutz- und Zugriffsanforderungen gebunden.

Erste Phase: aktuellen Zustand und Rückfallziel festhalten

Erstellen Sie zunächst ein kurzes Upgrade-Protokoll. Es muss nicht lang sein, aber nach dem Test darf keine wichtige Annahme nur in Ihrem Gedächtnis stehen.

Erfassen Sie mindestens:

1. Aktuell geladene DeepSeek-Harness-Version. Prüfen Sie die Ausgabe des tatsächlich verwendeten Startbefehls oder der lokalen Paketinstallation. Verlassen Sie sich nicht nur auf den Namen eines Verzeichnisses.
2. Installationsweg. Halten Sie fest, ob Sie über npx, eine lokale Quellcode-Kopie oder einen anderen reproduzierbaren Paketweg starten.
3. Node.js- und Paketmanager-Version. Die aktuelle Entwicklungsdokumentation nennt Node.js 22.19 oder neuer beziehungsweise Node.js 24 als unterstützte Entwicklungsbasis; für Quellcode-Installationen wird außerdem pnpm@11.7.0 im Projekt festgelegt. Prüfen Sie dennoch den konkreten Stand Ihrer Zielversion, weil ein Release-Tag eigene Anforderungen haben kann. (offizielle Entwicklungsdokumentation)
4. Konfigurationsquellen. Notieren Sie Umgebungsvariablen, .env-Dateien, Startparameter, Web-UI-Einstellungen und den verwendeten Arbeitsordner.
5. Plugin-Bestand. Speichern Sie Namen, Quelle, lokale Änderungen, Aktivierungsstatus und gegebenenfalls die für einzelne Plugins benötigten Berechtigungen.
6. Aktive Aufgaben. Dokumentieren Sie laufende Sitzungen, geplante Arbeiten, offene Änderungen und Prozesse, die eine dauerhafte Shell verwenden.

Sichern Sie nicht blind das gesamte Benutzerverzeichnis. Ermitteln Sie zuerst, welche Ordner und Dateien DeepSeek Harness laut aktueller Dokumentation tatsächlich verwendet, und gleichen Sie diese Liste mit Ihrem realen System ab. Sitzungsprotokolle, Konfigurationen, Plugin-Verzeichnisse, eigene Presets und wichtige Arbeitsartefakte gehören getrennt voneinander in die Sicherung. API-Schlüssel dürfen nicht in ein ungeschütztes Archiv gelangen; die offizielle Entwicklungsdokumentation empfiehlt Umgebungsvariablen oder eine ignorierte .env-Datei und warnt davor, echte Zugangsdaten einzupflegen. (offizielle Konfigurationshinweise)

Hinweis: Eine Sicherung gilt erst dann als brauchbar, wenn Sie mindestens eine Datei daraus in einer getrennten Testumgebung öffnen und die Rückkehr praktisch nachvollziehen können. Ein nicht getestetes Archiv ist nur eine Annahme über Ihre Wiederherstellbarkeit.

Basistest vor dem Upgrade

Führen Sie vor dem Wechsel eine kleine, wiederholbare Aufgabenfolge aus:

• Web UI öffnen;
• Modell auswählen;
• Arbeitsbereich hinzufügen;
• eine Datei nur lesend untersuchen;
• einen kontrollierten, harmlosen Bash-Befehl ausführen;
• eine kurze Antwort zurückgeben;
• eine Sitzung schließen und erneut öffnen;
• ein vorhandenes Plugin aufrufen;
• falls relevant, eine Bilddatei anhängen.

Notieren Sie pro Schritt nicht nur „funktioniert“, sondern das konkrete Erfolgssignal: sichtbarer Arbeitsbereich, erwarteter Modellname, bestätigte Berechtigungsabfrage, korrektes Ergebnis oder wiederhergestellter Sitzungsverlauf. So können Sie nach dem Upgrade exakt unterscheiden, ob ein Problem neu entstanden war oder bereits vorher vorhanden ist.

Zweite Phase: rc.7 in einem isolierten Arbeitsbereich installieren

Für den ersten Start ist ein zweiter Arbeitsbereich besser als ein Klon Ihrer gesamten Produktionsumgebung. Ziel ist eine Umgebung, die Sie löschen und erneut aufbauen können, ohne die produktive Konfiguration zu beschädigen.

Bei einer npm-basierten Installation beschreibt die offizielle Anleitung den Web-UI-Start über:

npx @deepseek-ai/dsh web

Die Web UI wird dabei standardmäßig unter http://127.0.0.1:3080 bereitgestellt. Bei einer Quellcode-Installation nennt die offizielle README unter anderem pnpm install, pnpm run build und pnpm dsh web. Prüfen Sie vor dem Test, ob der konkrete rc.7-Stand diese Befehle unverändert verwendet; Befehle aus einem älteren Dokument dürfen nicht automatisch als Release-Vertrag behandelt werden. (offizielle Installationsanleitung)

Gehen Sie in dieser Reihenfolge vor:

1. Erstellen Sie einen neuen, leeren Testordner oder verwenden Sie ein unabhängiges Benutzerverzeichnis.
2. Verwenden Sie keine produktiven API-Schlüssel, sofern ein separater Testschlüssel oder ein klar begrenzter Endpunkt verfügbar ist.
3. Starten Sie rc.7 mit möglichst wenigen übernommenen Einstellungen.
4. Prüfen Sie die tatsächlich ausgegebene Version.
5. Prüfen Sie, aus welchem Arbeitsordner der Prozess Dateien liest und schreibt.
6. Öffnen Sie die Web UI erst dann mit einem Testprojekt.
7. Halten Sie Prozess-ID, Startzeit, Protokollpfad und verwendeten Port fest.

Die offizielle Web-UI-Dokumentation weist darauf hin, dass der aufrufende Ordner als Standard-Dateisystemort dient, während eine frische Web UI zunächst keinen ausgewählten Arbeitsbereich besitzt. Genau diese beiden Punkte müssen Sie kontrollieren: Ein falscher Startordner kann dazu führen, dass Testanfragen in ein echtes Repository gelangen; ein fehlender Arbeitsbereich kann dagegen fälschlich wie ein Modell- oder Plugin-Fehler wirken. (offizielle Web-UI-Dokumentation)

Dritte Phase: zuerst nur die kleinste Aufgabenfolge prüfen

Beginnen Sie nicht mit einem komplexen Multi-Agent-Auftrag. Eine isolierte Prüfung muss Ihnen sagen, welcher einzelne Baustein funktioniert oder ausfällt.

Schritt 1: Web UI und Serverantwort

Prüfen Sie, ob der Prozess startet, die lokale Adresse erreichbar ist und die Oberfläche ohne sichtbare Fehlermeldung lädt. Kontrollieren Sie außerdem, ob der Prozess nur an der erwarteten lokalen Schnittstelle lauscht oder ob Sie für einen Remote Mac bewusst einen abgesicherten Zugriff eingerichtet haben.

Schritt 2: Modellkonfiguration

Öffnen Sie die Modelleinstellungen, wählen Sie den vorgesehenen Eintrag und speichern Sie ihn. Die offizielle Anleitung beschreibt, dass die Modellroute nach dem Speichern ohne Neustart nutzbar werden soll. Testen Sie genau dieses Verhalten, statt nur die Konfigurationsseite zu öffnen. (offizielle Modellkonfiguration)

Schritt 3: Arbeitsbereich

Fügen Sie ausschließlich ein Test-Repository hinzu. Lassen Sie DeepSeek Harness den Projektinhalt zusammenfassen und prüfen Sie, ob die Antwort wirklich Dateien aus diesem Arbeitsbereich verwendet.

Schritt 4: kontrollierter Bash-Aufruf

Verwenden Sie einen ungefährlichen Befehl, der nur den aktuellen Ordner, eine Dateiliste oder eine Versionsinformation ausgibt. Prüfen Sie, ob die Freigabeabfrage erscheint, ob der Befehl im erwarteten Arbeitsbereich läuft und ob die Ausgabe in der Sitzung sichtbar bleibt.

Schritt 5: Rückgabe und Sitzungsprotokoll

Lassen Sie eine kurze Aufgabe beenden, schließen Sie die Sitzung und öffnen Sie sie erneut. Erfolg bedeutet nicht nur, dass eine Antwort erscheint. Sie müssen erkennen können, welche Eingabe, welches Werkzeug und welches Ergebnis zur Sitzung gehören.

Stoppen Sie die Migration, sobald ein Schritt scheitert. Zusätzliche Plugins, neue Modelle oder komplexere Eingaben würden die Fehlerquelle nur verdecken.

Die entscheidenden Regressionen für Sitzung, Plugin, Bash und Bilder

DeepSeek Harness beschreibt Sitzungen als nachvollziehbare Ereignisströme, in denen unter anderem Systemanweisungen, Werkzeugaufrufe, Ergebnisse und Kontextinjektionen aufgezeichnet werden. Deshalb sollten Sie nicht nur eine neue Sitzung testen, sondern auch einen kontrollierten Wiederaufnahmefall. (offizielle Sitzungsdokumentation)

Prüfen Sie mindestens diese Fälle:

• Große alte Sitzung: Öffnen Sie eine repräsentative, aber nicht sensible Sitzung mit langem Verlauf.
• Fortsetzung nach Begrenzung: Wenn Ihre Arbeitsweise eine maximale Token- oder Kontextgrenze verwendet, provozieren Sie keine produktive Aufgabe. Nutzen Sie stattdessen einen Testverlauf und prüfen Sie, ob die Sitzung nach der Kürzung weitergeführt werden kann.
• Persistente Bash-Sitzung: Starten Sie einen harmlosen Zustand, der über mehrere Befehle erhalten bleiben muss, und kontrollieren Sie, ob der zweite Befehl denselben Zustand sieht.
• Plugin-Einstellungen: Öffnen Sie die Einstellungsansicht, ändern Sie eine unkritische Option und starten Sie die Web UI beziehungsweise Sitzung neu.
• Safari-Eingabe: Testen Sie Texteingabe, Einfügen, Zeilenumbrüche, Dateianhänge und das Abschicken längerer Eingaben in Safari. Eine funktionierende Ansicht in einem anderen Browser ersetzt diesen Test nicht.
• Bildanhang: Verwenden Sie eine unkritische Testgrafik und prüfen Sie, ob Dateiauswahl, Upload, Vorschau und Modellverarbeitung jeweils sichtbar abgeschlossen werden.

DeepSeek Harness rc.7 kann direkt überschrieben werden?
Für eine einzige, nicht reproduzierbare Arbeitsumgebung sollten Sie das verneinen. Ein direktes Überschreiben ist nur vertretbar, wenn Sie die aktuelle Umgebung vollständig reproduzieren, alle kritischen Assets separat gesichert haben und den alten Zustand ohne denselben laufenden Prozess wiederherstellen können. Für produktive Daueraufgaben bleibt ein isolierter Vorabtest die bessere Entscheidung.

Was muss vor dem Upgrade gesichert werden?
Sichern Sie die nachweislich verwendeten Konfigurationen, Sitzungsdaten, Plugins, eigenen Presets, Startparameter und Arbeitsartefakte. Kopieren Sie nicht automatisch sämtliche Cache-Dateien oder das ganze Benutzerverzeichnis. Prüfen Sie jede Sicherung gegen die tatsächlich geladene Konfigurationsschicht und dokumentieren Sie, welche Geheimnisse bewusst nicht im Archiv liegen.

Neue Funktionen nicht in einem einzigen Großtest vermischen

Falls rc.7 neue oder geänderte Wege für Job Panel, Subagent-Verwaltung, MCP- beziehungsweise ACP-Bildanhänge oder eine niedrige Schlussfolgerungsintensität enthält, testen Sie jeden Punkt als eigene Aufgabe. Die offiziellen Projektunterlagen unterscheiden mehrere Laufmodi, darunter Standard, PTC, Minimal und Create. Diese Modi stellen unterschiedliche Werkzeug- und Plugin-Kombinationen bereit; ein erfolgreicher Test in einem Modus ist daher kein Beleg für alle anderen. (offizielle Laufmodi-Dokumentation)

Legen Sie pro Funktion einen kleinen Abnahmetest an:

• Job Panel: einen einzelnen Auftrag erstellen, Statuswechsel beobachten, Auftrag beenden und Ergebnis prüfen;
• Subagent: eine begrenzte Unteraufgabe delegieren und kontrollieren, ob Ergebnis und Hauptsitzung sauber verknüpft werden;
• MCP oder ACP: eine einzelne Werkzeugverbindung öffnen, Berechtigungsabfrage und Rückgabe dokumentieren;
• Bildanhang: eine Datei anhängen, verarbeiten lassen und anschließend die Sitzung wieder öffnen;
• niedrige Schlussfolgerungsintensität: dieselbe kurze Aufgabe mit einer normalen und der niedrigen Einstellung durchführen, ohne daraus eine allgemeine Qualitätsaussage abzuleiten.

Bewerten Sie jeden Test mit einer einfachen Punktzahl:

• 2 Punkte: reproduzierbar bestanden;
• 1 Punkt: bestanden, aber mit Warnung oder manueller Abweichung;
• 0 Punkte: fehlgeschlagen oder nicht nachvollziehbar.

Eine Migration sollte erst beginnen, wenn alle für Ihren Arbeitsablauf kritischen Pfade mindestens 2 Punkte erreichen. Ein nicht benötigtes Feature muss nicht künstlich freigegeben werden; dokumentieren Sie es als „nicht im Einsatz“.

Entscheidungstabelle für die Freigabe

Die Tabelle ist kein Leistungsranking der Hardware. Sie bewertet die Wahrscheinlichkeit, dass Sie einen Fehler sauber isolieren und den alten Zustand wieder aufnehmen können. Bei sensiblen Repositories zählen zusätzlich DSGVO-Anforderungen, Zugangsschlüssel, Festplattenverschlüsselung, Protokollaufbewahrung und die Frage, wer den Remote Mac administrieren darf.

Plugin-Fehler nach rc.7 kontrolliert zurücksetzen

Ein Plugin öffnet sich nach dem rc.7 Upgrade nicht mehr. Wie gehen Sie zurück?
Beenden Sie zunächst die betroffene DeepSeek-Harness-Instanz und starten Sie keine weiteren Plugins, bis Sie den Fehler eingegrenzt haben. Vergleichen Sie danach Plugin-Liste, Aktivierungsstatus, Konfigurationsdifferenzen und Startprotokolle mit dem Vorher-Zustand. Wenn der Fehler nur in rc.7 auftritt, wechseln Sie auf den dokumentierten alten Startweg oder die vorherige Quellcode- beziehungsweise Paketversion zurück und verwenden Sie die gesicherte Konfiguration nur selektiv.

Übernehmen Sie nicht automatisch die nach rc.7 veränderten Sitzungs- oder Konfigurationsdateien in die alte Umgebung. Bewahren Sie beide Zustände getrennt auf. Andernfalls kann eine Datei, die für rc.7 angepasst wurde, den Rückfall scheinbar erfolgreich machen, während die alte Version weiterhin mit einem unpassenden Datenformat arbeitet.

Erfahrungshinweis: Ein Rückfall ist erst abgeschlossen, wenn eine alte Sitzung geöffnet, ein Bash-Test ausgeführt und die produktive Web UI wieder mit dem erwarteten Arbeitsbereich verbunden wurde. Nur die Anzeige einer alten Versionsnummer reicht nicht aus.

Nach erfolgreichem Test in kleinen Gruppen umschalten

Beginnen Sie mit einem risikoarmen Repository ohne laufende Langzeitaufgabe. Beobachten Sie diesen Zustand im normalen Arbeitsrhythmus und prüfen Sie dabei Sitzungsfortsetzung, Plugin-Aufrufe, Bash-Verhalten und Web-UI-Nutzung. Erst danach folgen Daueraufgaben, sensible Projekte und gemeinsam genutzte Remote-Umgebungen.

Die Freigabeakte sollte enthalten:

• getestete und freigegebene Version;
• Installationsweg und Node.js-Umgebung;
• verwendete Konfigurationsquellen;
• Test-Repository und Basistask;
• Ergebnisse für Web UI, Modell, Bash, Sitzung, Plugin und Bildanhang;
• Fehlermeldungen mit Zeitstempel;
• Konfigurationsdifferenz zwischen alter und neuer Umgebung;
• genaue Rückfallaktion;
• verantwortliche Person und Ende des Rückfallfensters.

Für ein Team ist dieses Dokument wichtiger als ein pauschales „Upgrade erfolgreich“. Es zeigt, welche Oberfläche und welche Werkzeugpfade tatsächlich geprüft wurden und welche Bereiche bewusst nicht freigegeben sind.

Entwicklervorschau mit wiederkehrender Prüfung betreiben

Solange DeepSeek Harness als Entwicklervorschau geführt wird, sollten Sie rc.7 nicht als dauerhaft unveränderliche Plattform behandeln. Prüfen Sie vor jedem weiteren Versionswechsel die offizielle Release-Seite, die README und die relevanten Dokumentationsseiten. Die offizielle Projektseite nennt ausdrücklich eine schnelle Weiterentwicklung und mögliche kompatibilitätsbrechende Änderungen. (offizielle Release-Übersicht)

Ein wartbarer Rhythmus besteht aus vier festen Punkten:

1. Release-Stand und Installationsbefehl prüfen;
2. denselben Basistask in sauberer und bestehender Umgebung ausführen;
3. Plugin- und Sitzungsregressionen wiederholen;
4. Rückfall-Assets auf Lesbarkeit und Vollständigkeit prüfen.

Wenn Sie den Test auf einem Remote Mac durchführen, halten Sie zusätzlich den Zugangsweg, den Benutzer, die Netzwerkfreigabe, die lokale Bind-Adresse der Web UI und die Löschung des Testarbeitsbereichs fest. Die offizielle Anleitung nutzt standardmäßig eine lokale Adresse; jede bewusst geänderte Erreichbarkeit muss deshalb separat abgesichert werden.

Für die technische Vorbereitung können Sie außerdem die passende Mac-Arbeitsumgebung von VPSMAC prüfen oder einen konkreten M4-Knoten für parallele Tests heranziehen. Ein solcher Weg ist besonders dann sinnvoll, wenn Ihr vorhandener Mac bereits produktive Sitzungen ausführt und Sie den Upgrade-Test nicht in dessen Benutzer- und Prozessraum durchführen möchten.

Aktuelle Umgebung oder getrennte Mac-Umgebung?

Ihre aktuelle Umgebung ist meist günstiger, aber sie vermischt Produktiv- und Testdaten, konkurriert mit laufenden Aufgaben und macht einen sauberen Rückfall schwieriger. Ein eigener Mac-Testplatz verursacht dagegen zusätzliche Mietkosten und organisatorischen Aufwand, bietet aber eine klarere Trennung von Plugins, Sitzungen, Zugangsdaten und Arbeitsverzeichnissen. Für einen einmaligen, risikoarmen Patch kann ein lokaler zweiter Arbeitsbereich genügen. Für eine Entwicklervorschau mit laufenden Aufgaben ist die isolierte Remote-Mac-Variante häufig die kontrollierbarere Lösung.

Mieten Sie keinen Mac, wenn Sie eine dauerhaft unveränderte Umgebung mit hoher Auslastung, spezielle physische Schnittstellen oder langfristig kalkulierbare Gesamtkosten benötigen. Wenn Sie jedoch nur für die Upgrade-Prüfung, eine Teamabnahme oder ein begrenztes Rückfallfenster zusätzliche Kapazität brauchen, kann VPSMAC gegenüber dem direkten Überschreiben Ihrer einzigen Arbeitsumgebung die bessere Risikostruktur bieten. Entscheidend ist nicht die Bezeichnung „Upgrade“, sondern ob Sie nach einem Fehler innerhalb Ihres festgelegten Fensters wieder arbeitsfähig sind.