Ein fehlgeschlagener Lauf kann in DeepSeek Harness als „aktiv“ erscheinen, obwohl seit dem letzten Ereignis keine neue Anfrage gestartet wurde. Die offizielle Dokumentation beschreibt DeepSeek Harness weiterhin als Developer Preview mit möglichen kompatibilitätsbrechenden Änderungen. (github.com)
Anzeige: DeepSeek Harness wartet, aber es erscheint keine neue Anfrage.
Schnellste Lösung: Prüfen Sie zuerst die Ereigniskette aus Fehler, geplanter Wiederholung und gestarteter Wiederholung. Fehlt der Nachweis oder bleibt die Wartezeit unkontrollierbar, sichern Sie den Zustand und brechen Sie den Lauf ab. Wiederholen Sie nicht blind und laden Sie die Weboberfläche nicht einfach neu.
Diese Anleitung ist für drei Gruppen gedacht:
- Lokale Nutzer: Sie sehen einen dauerhaften Wartezustand und wissen nicht, ob der Lauf noch arbeitet.
- Remote-Operatoren: Sie betreiben Agent-Aufgaben unbeaufsichtigt und benötigen belastbare Stop- und Wiederanlaufgrenzen.
- Plattform- und Betriebsteams: Sie müssen LLM retry, DeepSeek API, Netzwerk, Tools und Prozesszustand gemeinsam auswerten.
Ausgangslage mit fehlendem Fortschrittsnachweis
Ein typischer Fall: Die Oberfläche zeigt weiterhin „Running“. Der letzte sichtbare Eintrag ist jedoch ein Modellaufruf oder eine Tool-Anforderung. Danach erscheinen weder neue Sitzungsereignisse noch eine Tool-Rückgabe. Der Ladeindikator bewegt sich, aber im Protokoll und im Prozessstatus gibt es keinen Fortschritt.
Das ist noch kein Beweis für einen aktiven Retry.
DeepSeek Harness wird über die Weboberfläche lokal gestartet; laut offizieller Anleitung verwendet der Prozess das aufrufende Verzeichnis als Standard-Arbeitsbereich. Ein neuer Weblauf besitzt außerdem nicht automatisch einen ausgewählten Workspace. (github.com) Dadurch können zwei scheinbar gleiche Sitzungen tatsächlich auf unterschiedlichen Arbeitsverzeichnissen oder Prozesszuständen beruhen.
Prüfen Sie zuerst vier Signale:
- Sitzungsereignisse: Gibt es nach dem letzten Fehler ein Ereignis für die Retry-Planung?
- Retry-Start: Gibt es anschließend ein eigenes Ereignis, das den Beginn der nächsten Modellanfrage belegt?
- Prozessfortschritt: Ändert sich der Prozessstatus, die CPU-Aktivität oder die Ausgabe im Terminal?
- Tool- oder Genehmigungsphase: Wartet der Agent auf Freigabe, Hook, Bash-Ausgabe oder eine externe Rückgabe?
| Beobachtung | Wahrscheinlichere Ursache | Erste Aktion | Vorläufige Entscheidung |
|---|---|---|---|
| Ladeanzeige ohne neue Ereignisse | UI zeigt alten Laufstatus | Ereignisprotokoll und Prozess prüfen | Nicht weiter warten, wenn kein Fortschritt belegbar ist |
| Fehler, Retry geplant, Retry gestartet | Transienter Provider- oder Netzwerkfehler möglich | Neue Anfrage und Fehlerklasse dokumentieren | Kontrolliert weiterlaufen lassen |
| Modellantwort mit Tool-Aufruf, danach keine Rückgabe | Tool, Hook oder Genehmigung blockiert | Tool- und Berechtigungsstatus prüfen | Nicht als Modell-Retry behandeln |
| Sitzung getrennt, Prozess unbekannt | Remote-Umgebung unklar | Prozess, Arbeitsverzeichnis und Systemzustand sichern | Bei Identitätsverlust neuen Test starten |
Achtung: Ein Browser-Refresh erzeugt keinen neuen Modellaufruf und stellt keinen entfernten Prozess wieder her. Nutzen Sie ihn höchstens zur Anzeigeprüfung, niemals als Wiederherstellungsmaßnahme.
Retry-Kette statt Ladeanimation prüfen
Für die Diagnose benötigen Sie eine Ereignispaarung. Ein Fehler allein bedeutet nur, dass ein Versuch fehlgeschlagen ist. Ein Planungseintrag allein bedeutet, dass eine Wiederholung vorgesehen wurde. Erst der zusätzliche Startnachweis zeigt, dass der nächste LLM-Aufruf tatsächlich begonnen hat.
Die offizielle DeepSeek-Harness-Dokumentation beschreibt die schnelle Weiterentwicklung der Preview-Version. Deshalb sollten Sie Ereignisnamen, Persistenzformat und Retry-Regeln immer gegen die zu Ihrer Installation gehörende Version prüfen, statt eine feste Versuchszahl oder Wartezeit aus älteren Beiträgen zu übernehmen. (github.com)
Gehen Sie in dieser Reihenfolge vor:
- Sitzungs-ID notieren. Speichern Sie die ID, den Startzeitpunkt, die Harness-Version und den Workspace-Pfad.
- Letztes Modellereignis feststellen. Notieren Sie, ob es ein Fehler, eine Antwort oder ein Tool-Aufruf war.
- Retry-Planung suchen. Prüfen Sie, ob die Persistenz einen geplanten erneuten Versuch enthält.
- Retry-Start suchen. Kontrollieren Sie, ob danach eine neue Anfrage mit eigener Zeitmarke beginnt.
- Abbruch oder Unterbrechung prüfen. Ein geplanter Retry kann vor dem Start durch Cancellation, Prozessende oder Sitzungsabbruch hinfällig werden.
- Netzwerkstatus danebenlegen. Ein Verbindungsabbruch erklärt eine fehlende Anzeige, beweist aber nicht, dass der Prozess beendet wurde.
- Arbeitsverzeichnis verifizieren. Ein Neustart aus einem anderen Verzeichnis kann einen neuen oder leeren Workspace erzeugen.
Die korrekte Schlussfolgerung lautet daher:
- Retry geplant und gestartet: begrenztes Weiterwarten ist vertretbar.
- Retry geplant, aber nicht gestartet: Stop- und Sicherungsphase einleiten.
- Kein Retry-Ereignis: andere Diagnosepfade prüfen, insbesondere Tool, Genehmigung oder Prozess.
- Gleicher deterministischer Fehler: nicht durch weitere Versuche verdecken.
Modellkonfiguration und API-Fehler trennen
Wenn jede Wiederholung denselben Fehlertext oder dieselbe Fehlerklasse liefert, behandeln Sie den Fall zunächst als Konfigurationsproblem. Mehr Retries beheben keinen falschen API-Schlüssel, keinen ungültigen Base URL und keine nicht unterstützte Modellroute.
DeepSeek dokumentiert unter anderem die Fehlerklassen 400 für ein ungültiges Anfrageformat, 401 für fehlgeschlagene Authentifizierung, 402 für fehlendes Guthaben, 422 für ungültige Parameter, 429 für Rate-Limit-Probleme sowie 500 und 503 für serverseitige beziehungsweise Überlastungsfehler. Verwenden Sie im Incident aber nur den Fehlercode und Text, der in Ihrer aktuellen Antwort tatsächlich vorliegt. (api-docs.deepseek.com)
Prüfen Sie:
- API-Schlüssel: Ist der Schlüssel gesetzt, nicht abgelaufen und dem richtigen Konto zugeordnet?
- Base URL: Zeigt die Konfiguration auf den vorgesehenen DeepSeek-Endpunkt?
- Modellname: Wird eine aktuell verfügbare Modellroute verwendet?
- Provider-Profil: Ist wirklich DeepSeek als Provider aktiv, oder überschreibt eine alternative Konfiguration die Auswahl?
- Anfrageformat: Sind Nachrichtenrollen, Parameter, Tool-Schema und Ausgabeformat kompatibel?
- Umgebungsvariable: Wird der Schlüssel im selben Benutzerkontext geladen, in dem der Agent läuft?
Der offizielle Entwicklungshinweis nennt DEEPSEEK_API_KEY und eine optionale DEEPSEEK_BASE_URL. Er warnt außerdem davor, echte Zugangsdaten zu committen. (github.com) Behandeln Sie API-Schlüssel als vertrauliche Zugangsdaten. Schreiben Sie sie nicht in Sitzungsprotokolle, Screenshots oder Support-Tickets.
| Fehlerbild | Konfigurationsprüfung | Minimaler Verifikationstest | Wiederaufnahme erst, wenn |
|---|---|---|---|
| Authentifizierung schlägt wiederholt fehl | Schlüssel und Benutzerkontext | Kurze Textanfrage ohne Tools | Eine gültige Modellantwort vorliegt |
| Ungültige Parameter | Modellroute und Request-Body | Standardparameter verwenden | Request ohne Validierungsfehler angenommen wird |
| Rate Limit oder Überlastung | Parallelität und Provider-Status | Einzelne Anfrage mit niedriger Last | Neue Anfrage tatsächlich startet |
| Antwortformat bleibt leer | JSON- oder Streaming-Konfiguration | Textausgabe ohne strukturiertes Format | Inhalt und Abschlussstatus eintreffen |
Die DeepSeek API ist für Chat Completions zustandslos. Der Client muss den bisherigen Gesprächskontext bei jeder Anfrage selbst mitsenden. (api-docs.deepseek.com) Das ist für Agenten wichtig: Ein scheinbarer Retry kann in Wirklichkeit eine neue Anfrage mit unvollständiger Historie sein. Prüfen Sie deshalb die übergebene Nachrichtenfolge und nicht nur die Oberfläche.
Tool-Ausführung und Modellantwort auseinanderhalten
Eine erfolgreiche Modellantwort beendet nicht automatisch die gesamte Agent-Aufgabe. DeepSeek kann eine Antwort mit tool_calls liefern. Die API dokumentiert außerdem, dass Tool-Argumente im Client validiert werden müssen, weil sie nicht immer dem erwarteten Schema entsprechen. (api-docs.deepseek.com)
Der Ablauf kann so aussehen:
- Das Modell antwortet erfolgreich.
- Es fordert einen Bash-, Hook- oder externen Tool-Aufruf an.
- DeepSeek Harness wartet auf Genehmigung oder Prozessausgabe.
- Das Tool liefert nichts zurück.
- Die Oberfläche wirkt wie ein LLM retry, obwohl keine neue Modellanfrage läuft.
Prüfen Sie deshalb die letzte abgeschlossene Phase:
- LLM abgeschlossen: Antwort-ID, Abschlussstatus oder Tool-Aufruf vorhanden.
- Tool gestartet: Prozess-ID, Startzeit und konkrete Argumente vorhanden.
- Genehmigung offen: Der Lauf wartet auf eine Benutzerentscheidung.
- Hook blockiert: Vor- oder Nachverarbeitung beendet sich nicht.
- Externer Dienst blockiert: DNS, SSH, HTTP, Datei- oder Datenbankzugriff liefert keine Antwort.
Öffnen Sie nicht testweise alle Berechtigungen. Das vergrößert den Schaden, wenn ein Tool falsche Argumente erhält oder in einem unkontrollierten Arbeitsverzeichnis läuft. Führen Sie stattdessen einen minimalen Tool-Aufruf aus: eine harmlose Arbeitsverzeichnisabfrage, eine lesende Dateiprüfung oder ein klar begrenzter Prozessstatus.
Stop-Bedingung: Kein Tool-Output, keine Genehmigungsentscheidung und kein Prozessfortschritt innerhalb des für Ihre Aufgabe festgelegten Betriebsfensters.
Wiederherstellungskriterium: Ein minimaler Tool-Aufruf startet, beendet sich sauber und liefert eine protokollierte Rückgabe. Erst danach sollten Sie den ursprünglichen Agent-Lauf erneut ausführen.
FAQ zur Retry-Diagnose
Woran erkennen Sie einen echten Retry?
Eine echte Wiederholung braucht mehr als eine unveränderte Statusanzeige. Suchen Sie nach der Abfolge aus fehlgeschlagenem Modellaufruf, geplanter Wiederholung und gestarteter neuer Anfrage. Fehlt der Startnachweis, warten Sie nicht unbegrenzt. Prüfen Sie stattdessen Tool-Genehmigungen, Prozessstatus und Sitzungsunterbrechungen.
Wie viele Wiederholungen sind vorgesehen?
Eine feste Anzahl ist ohne versionsbezogene Quelle nicht belastbar. Die Preview kann ihre Retry-Logik verändern. Dokumentieren Sie daher die tatsächlich gespeicherten Ereignisse. Ein deterministischer 401-, 402-, 400- oder 422-Fehler bleibt auch nach weiteren Versuchen ein Konfigurationsproblem.
Wann ist Abbrechen die bessere Entscheidung?
Brechen Sie ab, wenn keine neue Anfrage startet, der Prozess nicht mehr identifizierbar ist, das Arbeitsverzeichnis gewechselt hat oder ein Tool ohne Rückgabe hängt. Sichern Sie vor dem Abbruch Sitzungsereignisse, Fehlermeldung, Version, Konfiguration ohne Geheimnisse und den letzten bekannten Workspace.
Wie gelingt die Wiederaufnahme nach einer Remote-Unterbrechung?
Prüfen Sie zuerst, ob derselbe Prozess mit derselben Sitzungs-ID und demselben Arbeitsverzeichnis noch läuft. Eine getrennte Verbindung ist kein Beweis für den Abbruch. Nach einem Neustart, Schlafmodus oder Identitätswechsel ist ein neuer Minimaltest vorzuziehen. Übernehmen Sie Änderungen erst nach einer gezielten Prüfung des Arbeitsstands.
Remote-Prozess und Umgebung verifizieren
Bei langen Aufgaben kommen mehrere versteckte Fehlerquellen hinzu. Das Betriebssystem kann schlafen oder neu starten. Ein Terminal kann die Verbindung verlieren. Ein Prozess kann weiterlaufen, während die Weboberfläche nicht mehr erreichbar ist. Umgekehrt kann die Oberfläche einen alten Zustand anzeigen, obwohl der Prozess beendet wurde.
Die offizielle Web-UI-Anleitung weist darauf hin, dass Sie einen Workspace ausdrücklich auswählen müssen und dass Agent-Aufgaben Dateien lesen, ändern, Befehle ausführen und Genehmigungen anfordern können. (github.com) Für Remote-Betrieb bedeutet das: Prozess-, Sitzungs- und Arbeitsverzeichnisstatus müssen gemeinsam gesichert werden.
Führen Sie bei einer Unterbrechung diese Schritte aus:
- Remote-Verbindung testen. Prüfen Sie, ob der Host erreichbar ist und ob Sie sich mit demselben Benutzer anmelden.
- Prozessliste sichern. Suchen Sie nach dem Harness-Prozess und seinen Kindprozessen.
- Arbeitsverzeichnis prüfen. Stellen Sie fest, ob der Prozess noch im ursprünglichen Projektpfad arbeitet.
- Systemereignisse ansehen. Prüfen Sie Schlafmodus, Neustart, Speicherprobleme und Netzwerkwechsel.
- Dateiänderungen sichern. Erfassen Sie Status, Zeitstempel und nicht versionierte Dateien.
- Sitzungsereignisse exportieren. Bewahren Sie die letzten Ereignisse vor und nach der Unterbrechung auf.
- Minimaltest starten. Verwenden Sie eine kurze Modellanfrage ohne Tools und anschließend einen begrenzten Tool-Aufruf.
Ein alter Lauf darf nicht fortgesetzt werden, wenn sich die Umgebung nicht mehr eindeutig identifizieren lässt. Das betrifft etwa einen neuen Container, einen anderen Benutzer, einen geänderten Workspace oder einen Rechner, der nach einem Neustart einen anderen Mount verwendet.
Betriebserfahrung: Wenn die Umgebungsidentität unklar ist, ist ein neuer Validierungslauf sicherer als ein erzwungenes „Resume“. So vermeiden Sie doppelte Änderungen und nicht nachvollziehbare Seiteneffekte.
Stoppen, wiederherstellen und eskalieren
Nutzen Sie zum Abschluss eine feste Entscheidung statt eines Bauchgefühls.
- Weiterwarten: Es gibt neue Ereignisse, der Retry wurde gestartet, der Prozess läuft und die Wartephase ist kontrollierbar.
- Abbrechen und neu starten: Es gibt keinen neuen Retry-Start, der Fehler ist deterministisch oder ein Tool blockiert.
- Umgebung wechseln: Prozess oder Workspace sind nach Remote-Problemen nicht mehr eindeutig, oder der Rechner wurde neu gestartet.
- Eskalieren: Der Minimaltest scheitert trotz bestätigter Zugangsdaten, korrekter Modellroute und unverändertem Netzwerk.
Vor jeder Eskalation sichern Sie mindestens:
- DeepSeek-Harness-Version und Installationsweg
- Sitzungs-ID und Startzeit
- verwendeten Workspace-Pfad
- Ereignisse vor und nach dem Fehler
- exakten API-Fehler aus der aktuellen Antwort
- Provider-, Modell- und Base-URL-Konfiguration ohne Geheimnisse
- Netzwerk- und Prozessstatus
- kleinsten reproduzierbaren Prompt
- Ergebnis des Minimaltests
Wenn Sie das Verhalten nachstellen, vergleichen Sie außerdem die aktuelle Release-Version und die offiziellen Dokumentationsänderungen. Die Repository-Dokumentation nennt für die Entwicklung konkrete Node-, pnpm- und Git-Voraussetzungen; solche Laufzeitänderungen können bei einer Preview die Fehlerursache sein, ohne dass der Provider selbst ausgefallen ist. (github.com)
Prüfliste für den nächsten Einsatz
- [ ] Sitzungs-ID, Version und Workspace-Pfad notiert
- [ ] Letztes LLM-Ereignis identifiziert
- [ ] Retry-Planung und Retry-Start getrennt geprüft
- [ ] Abbruch, Cancellation oder Prozessende ausgeschlossen
- [ ] API-Schlüssel ohne Offenlegung im richtigen Benutzerkontext geprüft
- [ ] Base URL, Provider und Modellroute bestätigt
- [ ] Minimaler Texttest ohne Tools ausgeführt
- [ ] Tool-Aufruf, Genehmigung und Hook separat untersucht
- [ ] Remote-Prozess und Arbeitsverzeichnis verifiziert
- [ ] Schlafmodus, Neustart und Netzwerkwechsel geprüft
- [ ] Stop-Bedingung dokumentiert
- [ ] Wiederherstellung erst nach erfolgreichem Minimaltest begonnen
Für längere, unbeaufsichtigte Läufe sollten Sie diese Kriterien in Ihre eigene Betriebsdokumentation übernehmen. Die Anleitung zur Abnahme von DeepSeek-Harness-Hintergrundaufgaben kann dabei als ergänzender Prüfpfad für Laufstatus und Übergabe dienen. Wenn Sie die Umgebung remote bereitstellen, verknüpfen Sie die Diagnose zusätzlich mit einer Mac-Übergabeprüfung für DeepSeek Harness, damit Modellkette, Arbeitsbereich und Wiederanlauf nicht getrennt bewertet werden.
Wenn das Problem nur nach Verbindungsabbrüchen, langen Wartephasen oder wechselnden Remote-Umgebungen auftritt, liegt die Ursache häufig nicht in einem „zu langsamen“ Modell. Eine lokale Installation kann dann durch Schlafmodus, Benutzerwechsel, fehlende Dauerverbindung und schwer kontrollierbare Hintergrundprozesse unzuverlässig werden. Ein eigener Mac beseitigt diese Risiken nicht automatisch, bindet aber Kapital und muss selbst gewartet werden. Für zeitlich begrenzte Tests oder einzelne lange Agent-Läufe ist ein von MACCOME bereitgestellter Mac oft die sauberere Option: Sie erhalten eine definierte Remote-Umgebung, können den Workspace vorab festlegen und nach einem Abbruch gezielt neu validieren, ohne vorschnell das gesamte DeepSeek-Harness-Setup neu zu installieren.
Für stabile Dauerlast mit eigener Peripherie, lokalen Datenschutzvorgaben oder dauerhaft benötigten Spezialdiensten kann ein eigener Rechner weiterhin sinnvoller sein. Für temporäre Reproduktion, unbeaufsichtigte Tests und kontrollierte Wiederherstellung sollten Sie dagegen zuerst die Umgebungs- und Übergabebedingungen prüfen. Die verfügbaren Mac-Optionen von MACCOME sind der nächste sinnvolle Schritt, wenn Ihr Fehlerbild an der Remote-Stabilität und nicht an der Modellkonfiguration hängt.