DeepSeek Harness: Low oder High bei der Denkleistung?

Kurzentscheidung für diese Woche: Verwenden Sie niedrige Denkleistung für klar begrenzte Such-, Zusammenfassungs- und mechanische Änderungsaufgaben; reservieren Sie hohe Denkleistung für komplexe Fehlersuche, Änderungen über mehrere Module und Entscheidungen mit hohem Fehlerpreis. Stellen Sie nicht das gesamte Team dauerhaft auf eine Stufe, sondern definieren Sie einen niedrigen Standard mit klaren Eskalationsregeln.

Das gilt besonders dann, wenn ein DeepSeek-Modell über DeepSeek Harness Werkzeuge wie Dateisuche, Shell, Tests oder Versionskontrolle ausführt. Die Wahl sollte nicht auf der Annahme beruhen, dass „low“ automatisch schneller oder günstiger und „high“ automatisch genauer ist. Entscheidend sind die Prüfbarkeit des Ergebnisses, das Risiko einer falschen Änderung und die Kosten der späteren Nacharbeit.

Wer diesen Beitrag lesen sollte: Einzelne Entwickler, die einfache Aufgaben nicht unnötig lange durchdenken lassen möchten. Agent-Teams, die für unterschiedliche Repository-Aufgaben ein belastbares Modellprofil benötigen. Plattformverantwortliche, die DeepSeek Harness auf einem entfernten Mac dauerhaft ausführen und unnötige Auslastung, Wiederholungen oder unklare Fehlversuche vermeiden wollen.

Hinweis zur aktuellen Konfiguration: Der offizielle Stand dokumentiert für das Denken insbesondere die Parameter reasoning_effort und thinking. Für reguläre Anfragen ist high der dokumentierte Standard; bei kompatiblen Eingaben werden low und medium serverseitig auf high abgebildet. Prüfen Sie deshalb vor einer Auswertung, ob Ihre Harness-Version und der verwendete Modelladapter „low“ tatsächlich als eigenständige Stufe an den Dienst übergeben. (api-docs.deepseek.com)

Letzte Aktualisierung: 18.08.2026. Die technischen Angaben wurden gegen die aktuelle DeepSeek-Dokumentation zum Thinking Mode, den offiziellen API-Änderungsverlauf und die verfügbare Modellkonfigurationsdokumentation geprüft.

Die zentrale Fehlentscheidung besteht darin, low oder high als globale Qualitätsstufe zu behandeln. In einem Agent-System verändert die Denkleistung nicht nur die sichtbare Antwort. Sie kann auch beeinflussen, wie viele Hypothesen der Agent bildet, ob er weitere Dateien untersucht, wann er Tests ausführt und ob er eine Aufgabe als abgeschlossen meldet.

Das macht die Auswahl zu einer Betriebsentscheidung mit mindestens vier getrennten Kosten:

1. Prüfkosten: Ein längerer oder komplexerer Werkzeugpfad muss von Menschen kontrolliert werden.
2. Fehlerkosten: Eine falsche Änderung an Berechtigungen, Datenmigration oder Deployment-Konfiguration kann deutlich teurer sein als ein zusätzlicher Modellaufruf.
3. Wiederholungskosten: Ein unvollständiger Lauf erzeugt neue Prompts, zusätzliche Tool-Aufrufe und weitere Prüfungen.
4. Betriebskosten: Lange Agent-Sitzungen halten CPU, Arbeitsspeicher, Netzwerkverbindungen und gegebenenfalls einen entfernten Mac länger belegt.

Die Aufgabe ist daher nicht: „Welche Stufe liefert die beste Antwort?“ Die belastbare Frage lautet: „Welche Stufe erreicht bei diesem Aufgabentyp ein überprüfbares Ergebnis mit vertretbarem Nacharbeitsrisiko?“

Bei einer Dateisuche mit eindeutigem Suchmuster kann ein niedriger Aufwand genügen, weil die Trefferliste unmittelbar kontrollierbar ist. Bei einem intermittierenden Fehler, der nur unter einer bestimmten Kombination aus Cache, Berechtigung und Hintergrundprozess auftritt, reicht dieselbe Logik nicht aus. Dort müssen konkurrierende Ursachen geprüft und durch reproduzierbare Tests voneinander getrennt werden.

Die offiziellen DeepSeek-Unterlagen beschreiben das Denken als aktivierbare Funktion und nennen high beziehungsweise max als reguläre Steuerwerte. Außerdem wird darauf hingewiesen, dass bestimmte Sampling-Parameter im Thinking Mode keine Wirkung haben können, selbst wenn die Schnittstelle sie akzeptiert. Das ist für einen Harness wichtig: Eine Konfigurationsdatei kann formal gültig sein, ohne dass jede darin gesetzte Option das Verhalten tatsächlich verändert. Die offizielle Parameterbeschreibung erläutert diese Einschränkungen. (api-docs.deepseek.com)

Diese Tabelle ist keine Behauptung über garantierte Geschwindigkeit oder Qualität. Sie ist eine Ausgangsregel, die das Team anschließend mit den eigenen Repositories und Modellversionen überprüfen muss. Der offizielle DeepSeek-Änderungsverlauf zeigt, dass Modellnamen und API-Verhalten im Zeitverlauf angepasst werden können; deshalb dürfen alte Benchmarks nicht ohne erneute Konfigurationsprüfung fortgeschrieben werden. (api-docs.deepseek.com)

Für Code-Repository-Suche, Symbolauflistung und begrenzte Zusammenfassungen ist niedrige Denkleistung der sinnvollere erste Versuch, wenn drei Bedingungen erfüllt sind:

• Das Suchziel ist eindeutig formuliert.
• Der Agent darf lesen, aber nicht unkontrolliert schreiben.
• Das Resultat lässt sich anhand der angezeigten Dateien und Zeilen schnell nachvollziehen.

Ein Beispiel wäre die Suche nach allen Aufrufen einer bestimmten Schnittstelle und die Zusammenfassung ihrer Fehlerbehandlung. Der Agent muss dabei keine neue Architektur entwerfen. Er soll Treffer sammeln, Duplikate entfernen und die Fundstellen in einer kontrollierbaren Form ausgeben.

Die Einstufung ändert sich jedoch, sobald die Suche eine Entscheidung vorbereitet. Wenn etwa unklar ist, ob ein Berechtigungscheck in Middleware, Controller oder Datenbankzugriff erfolgt, ist eine oberflächliche Trefferliste nicht ausreichend. In diesem Fall sollte der Agent entweder mit hoher Denkleistung arbeiten oder das Ergebnis ausdrücklich zur menschlichen Prüfung markieren.

Unterscheidet sich low reasoning effort bei Werkzeugaufrufen automatisch von high reasoning effort? Nicht zwingend. Die Werkzeuge selbst bleiben in der Regel dieselben; entscheidend ist, welche Reihenfolge, Tiefe und Anzahl von Aufrufen der Agent auswählt. Ein Adapter kann außerdem Werte normalisieren oder ignorieren. Deshalb müssen Teams im Protokoll den tatsächlich gesendeten Request, die Werkzeugnamen, die Argumente und die Rückgabestatus erfassen, statt nur die Auswahl im Benutzerinterface zu speichern. Die DeepSeek-Dokumentation beschreibt auch besondere Anforderungen an reasoning_content bei mehrstufigen Werkzeugaufrufen. (api-docs.deepseek.com)

Für personenbezogene oder geschäftskritische Quelltexte sollte zusätzlich geprüft werden, welche Daten in Logs, Sitzungsverläufen und Fehlerberichten gespeichert werden. Eine höhere Denkleistung rechtfertigt keine längere Aufbewahrung sensibler Inhalte. DSGVO-Zweckbindung, Zugriffskontrolle und Löschfristen gehören in dieselbe Betriebsprüfung wie die Modellstufe.

Bei einer Änderung in einer einzelnen Datei ist niedrige Denkleistung oft ein vertretbarer Start, wenn die Anweisung mechanisch und die erwartete Änderung exakt ist. Dazu zählen beispielsweise eine einheitliche Importreihenfolge, eine klar definierte Umbenennung oder das Aktualisieren eines festgelegten Konfigurationsschlüssels.

Der Umfang allein reicht aber nicht als Kriterium. Eine kleine Änderung in einer zentralen Authentifizierungsfunktion kann riskanter sein als eine größere, rein dokumentarische Anpassung. Deshalb sollte der Harness vor der Ausführung eine Auswirkungsfrage beantworten:

• Ist die Datei Teil einer öffentlichen Schnittstelle?
• Wird der geänderte Wert von mehreren Modulen gelesen?
• Gibt es Datenbank-, Netzwerk- oder Berechtigungsfolgen?
• Existiert ein automatisierter Test, der den erwarteten Effekt prüft?
• Kann die Änderung durch einen kleinen, klaren Diff zurückgesetzt werden?

Sind einfache Codierungsaufgaben eher für die niedrige oder die hohe Stufe geeignet? Beginnen Sie mit niedriger Denkleistung, wenn die Änderung lokal, reversibel und durch einen vorhandenen Test oder einen eindeutigen Diff prüfbar ist. Wählen Sie hohe Denkleistung, wenn Verhalten über mehrere Module hinweg erhalten bleiben muss oder wenn der Agent selbst erst die Abhängigkeiten ermitteln soll. Die Stufe sollte nach dem ersten Prüfergebnis neu bewertet werden, nicht nach der ursprünglichen Länge des Prompts.

Ein sauberer Ablauf verlangt mindestens:

1. Arbeitszweig oder Snapshot anlegen.
2. Betroffene Dateien und erwartete Änderung dokumentieren.
3. Agenten mit begrenzten Schreibrechten starten.
4. Diff und Tool-Aufrufkette speichern.
5. Formattierung, statische Analyse und relevante Tests ausführen.
6. Bei unerwarteten Dateien, fehlenden Tests oder widersprüchlichem Ergebnis auf hohe Denkleistung wechseln.
7. Erst nach menschlicher Prüfung in den gemeinsamen Zweig übernehmen.

Hohe Denkleistung gehört in den Standardpfad, wenn Symptome nicht stabil reproduzierbar sind oder mehrere Komponenten beteiligt sein können. Dazu zählen intermittierende Timeouts, widersprüchliche Logmeldungen, Race Conditions, Cache-Probleme, fehlerhafte Berechtigungsvererbung und Fehler, die nur im Hintergrundbetrieb auftreten.

Der Grund ist nicht, dass hohe Denkleistung automatisch eine korrekte Diagnose erzeugt. Sie schafft lediglich mehr Raum für Hypothesen, Gegenprüfungen und alternative Erklärungen. Der Agent muss dennoch gezwungen werden, seine Annahmen an beobachtbare Ergebnisse zu binden:

• Welche Beobachtung spricht für Hypothese A?
• Welcher Test würde Hypothese A widerlegen?
• Welche Logzeile stammt aus welchem Prozess?
• Was geschieht bei einem Neustart, bei leerem Cache oder ohne Netzwerkzugriff?
• Welche Änderung ist nur ein Workaround und welche behebt die Ursache?

Eine Diagnose ohne Reproduktionsschritt sollte nicht als abgeschlossen gelten. Wenn der Agent nach mehreren Versuchen lediglich Konfigurationswerte verändert, ohne den Fehlerzustand erneut zu erzeugen, ist ein Abbruch mit menschlicher Übergabe besser als ein weiterer unkontrollierter Lauf.

Für laufende Umgebungen empfiehlt sich eine klare Trennung von Diagnose- und Änderungsrechten. Der Agent darf Logs lesen und Tests ausführen, erhält aber keine Schreibrechte für produktive Konfigurationen, solange die Ursache nicht bestätigt wurde. Auf einem entfernten Mac sollte zusätzlich die Prozess-, Speicher- und Netzwerkbelastung während langer Diagnoseketten aufgezeichnet werden.

Bei Code-Reviews ist die Menge des Codes ein schlechterer Filter als die Konsequenz eines Fehlers. Ein großer, automatisch erzeugter Formatierungsdiff kann mit niedriger Denkleistung geprüft werden, wenn keine Logik verändert wurde. Eine kleine Änderung an einer Rollenprüfung, einem Deployment-Schlüssel oder einer Datenmigration gehört dagegen in den Hochrisikopfad.

Wir empfehlen drei Risikostufen:

• Niedrig: Formatierung, Kommentare, eindeutig wiederholbare Namensänderungen. Automatisierte Prüfung plus stichprobenartige Kontrolle.
• Mittel: Geschäftslogik ohne Datenverlust, neue Fehlerbehandlung oder Änderung von API-Verträgen. Diff-Prüfung, Tests und gezielte Gegenbeispiele.
• Hoch: Sicherheit, Berechtigungen, Geheimnisse, Datenmigration, Release-Konfiguration und Netzwerkzugriff. Hohe Denkleistung, Negativtests, unabhängige menschliche Freigabe und dokumentierte Rückfalloption.

Die relevante Frage lautet nicht, ob der Agent den Code „verstanden“ hat. Relevant ist, ob die Kontrollkette einen falschen positiven Review-Befund rechtzeitig sichtbar macht. Ein Review-Ergebnis ohne konkrete geänderte Dateien, Teststatus und Risikoannahmen sollte nicht automatisch in den Merge-Prozess gelangen.

Für nächtliche Repository-Scans, wiederholte Dokumentationsprüfungen und andere unbeaufsichtigte Agent-Aufgaben ist ein niedriger Einstieg sinnvoll, sofern jeder Schritt wiederholbar und idempotent ist. Der Agent kann zunächst Dateien sammeln, bekannte Muster prüfen, Statusberichte erzeugen oder Tests mit begrenztem Schreibzugriff ausführen.

Die Eskalation muss technisch sichtbar sein. Speichern Sie mindestens:

• ursprüngliche Denkleistungsstufe,
• Modell- und Harness-Version,
• Werkzeugaufrufe mit Zeitstempel,
• Retry-Anzahl und Retry-Grund,
• Validierungsergebnis,
• Umschaltzeitpunkt auf hohe Denkleistung,
• Abbruch- oder Übergabestatus.

Ein unvollständiges Ergebnis darf nicht einfach als Erfolg markiert werden. Wenn ein Test wegen eines Timeouts nicht ausgeführt wurde, ist das kein bestandener Test. Wenn eine Datei nicht gelesen werden konnte, ist die Zusammenfassung nicht vollständig. Solche Zustände müssen den nächsten Schritt auslösen: Wiederholung, Wechsel der Denkleistung oder menschliche Übernahme.

Wie setzen Teams die Stufe für verschiedene Agent-Aufgaben? Hinterlegen Sie nicht nur ein globales Profil, sondern Regeln pro Aufgabentyp. Ein Repository-Analyst kann standardmäßig niedrig starten, ein Migrations-Agent immer hoch. Für gemeinsame Governance sollten die Regeln in einer versionierten Konfigurationsdatei liegen und zusammen mit den Benchmark-Ergebnissen geändert werden.

Eine belastbare Entscheidung entsteht nicht durch einen einzelnen gelungenen Lauf. Erstellen Sie eine kleine Referenzgruppe aus einfachen, komplexen und risikoreichen Aufgaben. Jede Aufgabe wird mit identischem Repository-Zustand, identischem Modell, identischem Prompt und identischen Werkzeugrechten in beiden Stufen ausgeführt.

Bewerten Sie anschließend nicht nur die Antwort, sondern fünf getrennte Größen:

1. fachlich akzeptiertes Ergebnis,
2. Vollständigkeit der Werkzeugkette,
3. Anzahl und Qualität der Tests,
4. menschliche Nacharbeit,
5. belegte Lauf- und Systemnutzung.

Verwenden Sie für die Teamentscheidung diese Bedingungen:

• Wenn das Ergebnis lokal, reversibel und vollständig prüfbar ist, dann niedrige Denkleistung als Standard verwenden.
• Wenn mehrere Module, widersprüchliche Logs oder unbekannte Abhängigkeiten betroffen sind, dann hohe Denkleistung wählen.
• Wenn ein Sicherheits-, Berechtigungs-, Migrations- oder Release-Risiko besteht, dann hohe Denkleistung plus menschliche Freigabe verlangen.
• Wenn ein niedriger Lauf unvollständig ist oder die Validierung fehlschlägt, dann einmal kontrolliert eskalieren und den Grund protokollieren.
• Wenn beide Stufen wiederholt kein reproduzierbares Ergebnis liefern, dann den Agenten stoppen und die Aufgabe an einen Menschen übergeben.
• Wenn der Adapter „low“ nachweislich auf „high“ normalisiert, dann diese beiden Läufe nicht als unabhängigen Vergleich auswerten.

Damit wird auch sichtbar, ob die scheinbare Ersparnis einer niedrigen Stufe durch zusätzliche Wiederholungen oder manuelle Korrekturen verloren geht. Umgekehrt kann hohe Denkleistung bei gut prüfbaren Routineaufgaben unnötige Modell- und Betriebsressourcen binden, ohne den Abnahmewert zu erhöhen. Genaue Qualitäts-, Token- oder Zeitvorteile sollten erst nach einer Messung im eigenen Modell- und Harness-Setup veröffentlicht werden; allgemeingültige Prozentwerte wären hier nicht belastbar.

Für die weitere Planung können Sie zunächst den Leitfaden zur DeepSeek-Harness-Kostenkontrolle als Einstieg verwenden. Wenn die Benchmark dauerhaft im Hintergrund laufen soll, gehört außerdem eine getrennte Planung der Mac-Kapazität für Agent-Aufgaben in den Prüfplan.

1. Versionen einfrieren: Notieren Sie Modell-ID, Harness-Version, Adapter, Konfigurationsdatei und Datum.
2. Aufgaben klassifizieren: Markieren Sie jede Aufgabe als Routine, komplex, hochriskant oder ungeeignet für autonome Ausführung.
3. Rechte begrenzen: Starten Sie zunächst mit Leserechten beziehungsweise einem isolierten Arbeitszweig.
4. Niedrig beginnen: Verwenden Sie die niedrige Stufe nur bei Aufgaben mit klarer Abnahmebedingung.
5. Werkzeugpfad erfassen: Speichern Sie Suchbefehle, Dateizugriffe, Testaufrufe und Fehlermeldungen.
6. Ergebnis prüfen: Kontrollieren Sie Diff, Tests, Vollständigkeit und unerwartete Dateien.
7. Gezielt eskalieren: Wechseln Sie bei unklarer Ursache, fehlgeschlagener Validierung oder größerem Änderungsradius auf hohe Denkleistung.
8. Abbruch definieren: Beenden Sie den Lauf, wenn Wiederholungen keinen neuen Beleg liefern.
9. Benchmark aktualisieren: Übernehmen Sie nur Ergebnisse mit identischem Ausgangszustand in die Teamtabelle.
10. Betrieb überwachen: Prüfen Sie bei langen Remote-Mac-Läufen Prozesslast, Arbeitsspeicher, Netzwerk und Sitzungsstatus.

Die Einstellung „high reasoning effort“ ist somit kein Ersatz für Tests, Berechtigungsgrenzen oder eine menschliche Freigabe. Sie ist ein Werkzeug für Aufgaben, bei denen Hypothesenprüfung und Abhängigkeitsanalyse den zusätzlichen Aufwand rechtfertigen.

Wenn der aktuelle Ansatz alle Aufgaben mit einer einzigen Stufe ausführt, entstehen typischerweise drei Nachteile: Routineaufgaben erhalten mehr Rechen- und Prüfaufwand als nötig, komplexe Fehler werden trotz niedriger Einstellung zu früh als gelöst markiert, und im Hintergrund bleiben Wiederholungen sowie Ressourcenverbrauch schwer erklärbar. Für einen ersten belastbaren Vergleich ist daher eine isolierte Mac-Umgebung sinnvoll, in der identische Low- und High-Läufe mit vollständiger Protokollierung stattfinden. Wenn der lokale Rechner durch lange Agent-Sitzungen blockiert wird, kann ein zeitlich begrenzter Test auf einem gemieteten Mac von JEXCLOUD die sauberere Trennung zwischen Entwicklungsarbeit, Benchmark und unbeaufsichtigtem Betrieb ermöglichen.